Доклад точно повторял ранее уже представленное на конференции JEEConf 2015
Ну да, это в точности он и был. Просто на JEEConf он назывался по английски, здесь я название перевел на русский (долго не мог перевести, доклад придумывался для англоязычной конфы изначально), поэтому могло создастся ощущение, что это другой доклад, сорри.
Ожидал к ранее рассказанному дополнительно услышать какие-нибудь подробности про реализацию поддержки Java 8, недавно появившейся в продукте.
Все таки это доклад был не про Excelsior JET. Конечно он упоминался, но я старался его упоминать только в контексте освещения аспектов достижения Native UX, и как правило только как один из вариантов (просто мы действительно в этом деле поработали и странно было не упоминать). Про то как мы сделали Java 8 я любопытствующим рассказал в кулуарах, слава богу организаторы дали больше времени на кулуарное общение. И это прямо было в струю, время зря никогда не пропадало! На других конференциях часто бывало заообщаешься с кем-нибудь и случайно пропустишь какой-нибудь доклад.
Очень понравились рассуждения про набор языковых фич и экосистему.
Однако, считаю, что следующая «большая вещь» будет вообще не вокруг языка. Те же (очень хорошие) примеры из этой статьи про Delphi и Java подтверждают этот тезис. И Delphi и Java — не были просто новыми языками. В тот момент когда они еще не имели экосистемы, они уже были гораздо больше платформами, чем языками. А язык был вторичен. И действительно, если продумать базис, платформу, то можно на нее хоть LISP натянуть, добавив больше или меньше фич. Та же Java — это, по-большому счету, упомянутый ранее Оберон с синтаксисом C, чья платформа была продумана на качественно новом уровне (но и сам Оберон как язык без Оберон-системы абсолютно бессмысленно рассматривать).
Жду рассказ про Nim и надеюсь, что в рассказе будет поднята также тема Nim как платформы, а не очередного языка, коих сейчас плодятся миллионами аж глаза разбегаются. Новых же платформ за последнии 10 лет, по большому счету, не появилось ни одной (или я не туда смотрю).
Идея же наслоится на существующие платформы (и для «браузера» и для «железа») мне кажется — не жилец.
Слушай, точно! Про Лисп, то я забыл! Все три кита современного мэйнстрима в одном месте.
Сейчас полистал описание языка Cedar, это же офигеть — GC, исключения, статические и динамические типы, типовые параметры и замыкания! 1983 год!
Да, конечно в Обероне, нет особо ничего нового, как собственно и в Java, кроме возможно лозунга «Делай как можно проще», который тоже в общем-то Эйнштейну принадлежал.
По поводу Smalltalk и Oberon есть одна довольно интересная история.
Известный факт, что Джобс стырил идею своего Мака у XEROX Parc, а потом уже Гейтс стырил у Джобса.
Так вот, мало кто знает, что после того как Джобс посетил XEROX Parc, туда наведался с дружественным визитом Вирт с Гуткнехтом и провели они там год в гостях. А кроме Smalltalk у XEROX тогда была еще система Cedar с языком Mesa. Гуй Оберона — это во многом калька с системы Cedar, а Mesa — это язык со статической типизацией, в отличии от Smalltalk (догадайтесь на что больше похож Оберон на Mesa или Smalltalk). Тогда в XEROX были реально два лагеря: одни за динамическую типизацию, другие за статическую, то есть этот современный срач по этому поводу тоже из XEROX перекочевал. Но все это XEROX хозяйство гонялось на мэйнфреймах и было жутко тяжеловесное.
И вот чудо: всем этим парням — Джобсу, Гейтсу и Вирту пришла практически одновременно в голову одна и та же идея: сделать что-то похожее на то, что есть у XEROX, но только для простых людей. А для этого им нужно было облегчить по максимуму все концепции от туда (упопсить). Лучше всего с задачей облегчения, как ни странно, справился Вирт, который сделал максимально легковесную систему, при этом ему удалось впитать лучшее из Mesa/Cedar и Smalltalk, и сохранить в лучшем виде дух этих систем. Но с задачей «упопсения», конечно намного лучше справились Джобс с Гейтсом, которые к тому моменту уже имели опыт промышленного программирования и бизнеса. Вирт же никогда бизнесом не занимался и production quality — это ниже его достоинства: для него главное концепт, а не обертка и качество реализации.
>>Может быть потому что размер «Блокнота» в таком варианте стремился к размеру «Офиса»?
А так сейчас в общем-то и делают! В десктопах очень популярна концепция RCP — Rich Client Platform (Eclipse RCP, Netbeans RCP). Там любой блокнот размером с Офис, при этом стартует этот блокнот, ой как не быстро! Здесь проблема, что проектировались Eclipse и Netbeans изначально без этой простой SmallTalk концепции в голове, а было бы большое счастье если бы эта концепция там была бы изначально, RCP программирование ой как бы облегчилось! Но опять же здесь есть проблема с отгрузкой в Java, без которой концепт нормально не работает.
>>А недостатки динамической перезагрузки модулей в Java это не проблемы языка или архитектуры платформы,
>>это проблемы реализации
Не согласен. В Java hotswap — это вообще опциональная фича для JVM, которая может быть, а может не быть и существует она там вообще только для отладки. Соответственно, как она может быть реализована в JVM не описано в спеке даже в общих чертах. А фича корневая, чтобы ее сделать по уму, однозначно надо менять JVM спецификацию, собирать лучшие умы JVM строения, JCP и прочее.
>> дизайнеру бы пришлось знать слишком много условностей.
Вот это должно стать частью его профессии. Знать про всякие условности. Если вы на данный момент в силу разных обстоятельств знаете больше его, не означает, что он не может с этим справится.
>>Но есть еще и динамические формы, вид которых сильно зависит от отображаемых данных.
Разумеется динамику надо делать кодом. Здесь весь вопрос, что описывать кодом. Вы можете дать дизайнеру специальный layout manager, который будет расставлять контролы в зависимости от отображаемых данных, при этом спихнув на него стилизацию контролов, спец-эффекты и прочее. Или вообще изготовить отдельный контрол для данной предметной области предоставив дизайнеру необходимые ручки для того, чтобы он его сделал хорошо выглядящем.
Мой поинт в том, что программист не должен заниматься двиганием контролов на пискель вверх/вбок, следить за антиалиасингом, выравниванием и прочим. Он должен писать программы.
>>На мой взгляд верстка от дизайнера — прекрасная, но совершенно нежизнеспособная абстракция.
Может быть. По хорошему, надо за такими как вы внимательно последить, когда вы начинаете программировать GUI, чтобы понять, что из этого процесса от вас отделить, а что оставить. Короче, мне кажется, тут есть поле для исследований.
2) В Обероне нет, в Оберон-системе корень был, от кторого все наследовались. Можно было не наследоваться, но это не приветствовалось. И у этого корня Handle был.
3) Да, все моделировали методы процедурными типами и полями объекта. Конечно, это больше похоже на function в JavaScript, но тем не менее все старались, чтобы это было похоже на методы. Лично я больше работал с Мифрилом, который был написан на Оберон-2, соответственно методы там были, и был метод Handlе. В Оберон систему я в основном лазил, чтобы подглядеть какую-нибудь идейку и реализовать ее в Мифрил.
Clojure — клевая, мне нравится. Но чистый ФП — это очень на любителя. Лучше, хуже — я про это не говорю.
Кстати в Clojure на JVM можно перегрузить модуль? Как это там делается? Интересны подробности
WinForms — это описание UI программным кодом, а не рисование GUI. Конечно разметка — это большой шаг вперед, перед описанием GUI в программном коде. Под рисованием GUI, я имел в виду рисование в редакторе мышкой (как в Delphi). Дизайнером. Большинство GUI билдеров 90-х, нулевых как раз порождали программный код, что делало их практически бесполезными — как только код начинал модифицироваться руками, обратно в билдер он уже не всегда лез. Сейчас билдеры порождают текст на языке разметке (если для UI библиотеки есть язык разметки), что тоже шаг вперед (если не считать HTML, где из-за браузерного ада, UI билдеры не WYSIWIG, а значит не работают). В Обероне же GUI мог быть только нарисрован в редакторе и потом сохранен на диск по средством сериализации входящих в GUI объектов. Код к нему прицеплялся метасредствами (через тот же механизм команд). Сам GUI нельзя было редактировать программистами как исходный текст: GUI концептуально был просто документом, наподобие PSD. Любой GUI в Оберон-системе можно было начать в любой момент редактировать. Представляете, что вы сейчас берете какой-нибудь Фотошоп и удаляете из него половину того, что вам не нужно или добавляете ровно то что вам нужно простым движением мыши (плагины конечно есть много где, но это немного не то)? А в Обероне так можно было делать с любым гуем! Или представляете какой был бы ад дизайнерам, если бы они вместо того чтобы рисовать картинки в Фотошопе, сидели бы в тектовом редакторе и «размечали» бы свои картинки? Ровно это сейчас очень часто происходит в ГУЙ строительстве: есть специально обученные верстальщики, которые из дизайнерских макетов пытаются наверстать что-то похожее. Почему дизайнер сразу не может нарисовать GUI? Зачем нужен этот промежуточный слой верстальщиков с очень странными скилами?
Да просто не надо смотреть на внешние проявления, а «зрить в корень». Концептуально Оберон очень хорош, все концепции, которые в него вложил Вирт — правильные, начиная с «делай как можно проще, но не проще чем нужно». К сожалению в Обероне упор на первую часть этого знаменитого высказывания, но если этому принципу не следовать, то мы имеем горы этого ынтырпрайзного г… на, в которое запихивают все, что только можно. К примеру нам в саппорт недавно пожаловалась одна крупная американская компания (типо нашего 1С), у них приложение на 700M — судя по содержимому они туда запихали пол Мавена! Я вообще не понимаю, как у них там может что-то может ворочиться! К сожалению редкий ентерпрайз программист следует принципу «делай как можно проще». При этом принцип KISS (keep it simple, stupid) вполне такая мэйнстримовая методология программирования.
Или возьмем Обероновские модули. Важным их свойством является не только, что их можно динамически загружать, но и отгружать, а соответственно безболезненно перегружать!
Я тут недавно общался с одним своим хорошим знакомым ентерпрайзчиком, и он жаловался, что главная проблема Java сейчас — это hotswap — то есть перегрузка изменившихся классов в живом приложении. Она в ХотСпоте очень плохо работает, поэтому все развлекаются через JRebel, который тоже ни фига не работает. А в Обероне такой проблемы не было! Код любого модуля (кроме корневых) можно было на лету поменять! Поэтому там был реальный Live coding, который в промышленных системах есть только для языков с динамической типизацией, то есть за счет отказа от статической типизации, со всеми вытекающими. Во Обероне же строгая типизация!
Что-то подобное Оберновским модулям на Java можно реализовать, только если грузить каждый класс, отдельным загрузчиком. Что вообще говоря адский оверхед. Я кстати, так и сделал в своей попытке реализовать что-то подобное Оберон-системе на Java — github.com/pjBooms/The-Nothing-System. Но это конечно минимальный прототип, стоит в этом прототипе начать классам друг друга импортировать и начнется такой нехилый computer science, как выгрузить класс по середине циклических зависимостей (кто кстати хочет поразвлекаться и доказать тем самым, что Java рулит — добро пожаловать, жду pull реквесты).
В промышленном же виде для перегрузки модулей есть пока только OSGi (очень крупные модули), но на него все, просто реально все, матерятся кто имел дело в реальном продакшене!
И вообще в Обероне не было не live coding'a. Твоя программа и Оберон-система — это одно целое. Любое программирование в Оберон системе — это расширение системы. Нельзя было к примеру «запустить программу», можно было только расширить систему.
То есть ты всегда находишься в своей собственной программе и развиваешь ее. Эта концепция до промышленных программистов так и не дошла!
Или возьмем REPL, который так нравится Ruby/Python и прочим хипстер программистам. Концепция «команды» в Обероне, очень похожа, но (потенциально) гораздо более мощная, чем REPL. То есть это фактически это тот же REPL, только выполненные кусочки кода не исчезают в истории команд, а остаются там, где ты их написал, и ты их можешь в любой момент вызвать кликом мыши (отредактировав входные параметры, если что). На такой очень простой концепции можно вообще весь UI приложения в обычном текстовом редакторе набить (и UI в ранних версии Оберона, так собственно и был сделан).
Когда я в первый раз увидел Java, мне там все понравилось кроме одной вещи. В Оберон-системе в корне иерархии объекта, есть метод Handle, который принимает абстрактный Message. То есть любому объекту Оберон-системы (которые кстати спокойно все сериализовались), можно было послать любое сообщение и он мог его обработать или нет. То есть, вопрос какая объектная модель лучше Simula или Smalltalk там просто не стояла, были реализованы обе, и вся система асинхронна и event-driven по умолчанию.
Мне реально жаль, что в java.lang.Object нет метода handle.
Кроме того, в корне иерархии была возможность добавлять динамические атрибуты к объекту. То есть сам Оберон — со строгой типизацией, но элементы динамической типизации были встроены в базисные классы.
И в конце концов, я реально считаю, что GUI нужно рисовать в GUI builder, а не описывать в виде программного кода или на языке разметки. В Обероне GUI можно было только рисовать. То что в промышленном программировании до сих пор не сделали внятного GUI билдера, которым можно пользоваться — это позор! То что все трахаются с разметкой и Internet Explorer'ом — это дичайший фэйл промышленного программирования.
Короче, суть этой басни такова, что в промышленном мире программирования пока не найдено «золотое сечение». B Оберон система — это просто маленький пример, стоящий с обратной стороны, показывающий, что все может быть по другому, чем вы привыкли. Никто вас не заманивает в секту «царства Оберона» и не призывает начать программировать на Обероне. Но тем не менее, я считаю, что каждому будет полезно потрогать эту систему для общего развития, чтобы задуматься как те реально клевые фичи Оберона донести до мейнстрима и дотянуть до production quality. Чтобы вместе достичь гармонии и просветления :).
Мое мнение, что Оберон был все-таки сделан «проще, чем нужно». В нем недостает ряда языковых конструкций из-за чего код на нем выглядит много хуже, чем аналогичный на Java/C# и никак не безопасней. Хотя конечно компилятор в 2000 строк — этим не каждый язык может похвастаться. Но я не считаю, что за простоту компилятора должен платить программист.
Также я не считаю, что за простоту реализации пользователького интерфейса системы должен платить конечный пользователь, который должен очень сильно постараться, чтобы тупо растянуть окошко как ему надо.
POSIX — прекрасен. Просто так сейчас уже никто API не пишет. И поэтому, когда с ним работаешь, чувствуешь, что он кругом кривой и косой. Что-то обусловлено кривостью Си, но что-то и с точки зрения дизайна не очень — можно было сделать много лучше.
Если вы спросите меня, я могу сказать, что Оберон-система концептуально очень крутая вещь, я бы даже сказал гениальная вещь! И между прочим, бизнес еще не все концепции (за 30 лет!) смог переварить. Свой трибут Оберон-системе я изложил в выступлении здесь — devday.ru/report/22.
Но все комментарии здесь, тем не менее, по делу. Главная беда Оберон-системы, что она была сделана крайне непрофессионально, как изнутри, так и снаружи. Да, Вирт писал говнокод, его студенты, которые работали над этим проектом писали говнокод, и вся система была с гусями. Именно, поэтому мой науч.рук., упомянутый выше, Недоря решил в свое время написать коммерческий (читай профессиональный) вариант Оберон-системы — Мифрил (над которой я тоже успел поработать, в том числе успел внедрить на одно предприятие).
Но при этом молодеже здесь надо учесть, что большинству кода в Оберон-системе — 20+ лет. Тогда просто не было всех этих современных «практик», «методологий», и т.п. «Все было впервые и вновь» (хотя парное программирование было). Вы посмотрите на POSIX или Win API из тех же времен — это же тоже ад и п… ц! Особенно Win API — поубивал бы всех, кто это придумал в Microsoft во главе с Гейтсом.
Да что там в Microsoft, знаете как мне сейчас стыдно за исторически первый код в упомянутом выше проекте Excelsior JET, написанный мной 19 лет назад (на том же языке Оберон)! Это же говнокодище чистой воды! Мне приходиться закрывать лицо руками, когда я его показываю студентам. Но при этом он живет и работает. Вот недавно туда добавлял поддержку Java 8 (плакал, но добавлял — применил правда пару «практик» и код стал чуть лучше). Но в свое оправдание могу сказать, что за последние лет 10 в этом моем коде, не было найдено серьезных ошибок. При этом при поддержке Java 8, мы нашли 2 доисторических бага (до существования Java) в коде, написанными людьми очень успешными сейчас в редмонде и силиконовой долине (один работает в упомянутом выше Microsoft).
«И я там был, мед пиво пил».
Только недавно очухался :).
Думаю тоже написать отчет, если еще не поздно.
Жаль, что поздно заглянул на Хабр, не знал что вы там будете, а то бы зашел на стенд, пообщался бы:)
>Это менее строго типизированный язык от JetBrains до того, что он, по сути, статически типизированный.
Это из разряда «мы стали более лучше одеваться».
>>Что я имею в виду под MVVM?
Нет я не понял контекста, в котором вы это употребили (то ли за что-то, то ли против чего-то).
>>Трюк в том, что грязная модель двунаправленно связана с представлением библиотекой, и вам вообще не нужно писать никакой код.
>>Юзер вбил данные в гуе? Они уже лежат в грязной модели, вам не нужно вешать события и потом париться,
>>если UX-дизайнер заменит селект на радиобаттон.
Так это же классика GUI! Так делали со времен его изобретения (Smaltalk, Xerox Cedar, Oberon System). То что это переизобрели спустя 30 лет в JavaScript не делает ему никакой чести. В простых сценариях, да можно без контроллера, и что?
Ну да, это в точности он и был. Просто на JEEConf он назывался по английски, здесь я название перевел на русский (долго не мог перевести, доклад придумывался для англоязычной конфы изначально), поэтому могло создастся ощущение, что это другой доклад, сорри.
Все таки это доклад был не про Excelsior JET. Конечно он упоминался, но я старался его упоминать только в контексте освещения аспектов достижения Native UX, и как правило только как один из вариантов (просто мы действительно в этом деле поработали и странно было не упоминать). Про то как мы сделали Java 8 я любопытствующим рассказал в кулуарах, слава богу организаторы дали больше времени на кулуарное общение. И это прямо было в струю, время зря никогда не пропадало! На других конференциях часто бывало заообщаешься с кем-нибудь и случайно пропустишь какой-нибудь доклад.
Однако, считаю, что следующая «большая вещь» будет вообще не вокруг языка. Те же (очень хорошие) примеры из этой статьи про Delphi и Java подтверждают этот тезис. И Delphi и Java — не были просто новыми языками. В тот момент когда они еще не имели экосистемы, они уже были гораздо больше платформами, чем языками. А язык был вторичен. И действительно, если продумать базис, платформу, то можно на нее хоть LISP натянуть, добавив больше или меньше фич. Та же Java — это, по-большому счету, упомянутый ранее Оберон с синтаксисом C, чья платформа была продумана на качественно новом уровне (но и сам Оберон как язык без Оберон-системы абсолютно бессмысленно рассматривать).
Жду рассказ про Nim и надеюсь, что в рассказе будет поднята также тема Nim как платформы, а не очередного языка, коих сейчас плодятся миллионами аж глаза разбегаются. Новых же платформ за последнии 10 лет, по большому счету, не появилось ни одной (или я не туда смотрю).
Идея же наслоится на существующие платформы (и для «браузера» и для «железа») мне кажется — не жилец.
Сейчас полистал описание языка Cedar, это же офигеть — GC, исключения, статические и динамические типы, типовые параметры и замыкания! 1983 год!
По поводу Smalltalk и Oberon есть одна довольно интересная история.
Известный факт, что Джобс стырил идею своего Мака у XEROX Parc, а потом уже Гейтс стырил у Джобса.
Так вот, мало кто знает, что после того как Джобс посетил XEROX Parc, туда наведался с дружественным визитом Вирт с Гуткнехтом и провели они там год в гостях. А кроме Smalltalk у XEROX тогда была еще система Cedar с языком Mesa. Гуй Оберона — это во многом калька с системы Cedar, а Mesa — это язык со статической типизацией, в отличии от Smalltalk (догадайтесь на что больше похож Оберон на Mesa или Smalltalk). Тогда в XEROX были реально два лагеря: одни за динамическую типизацию, другие за статическую, то есть этот современный срач по этому поводу тоже из XEROX перекочевал. Но все это XEROX хозяйство гонялось на мэйнфреймах и было жутко тяжеловесное.
И вот чудо: всем этим парням — Джобсу, Гейтсу и Вирту пришла практически одновременно в голову одна и та же идея: сделать что-то похожее на то, что есть у XEROX, но только для простых людей. А для этого им нужно было облегчить по максимуму все концепции от туда (упопсить). Лучше всего с задачей облегчения, как ни странно, справился Вирт, который сделал максимально легковесную систему, при этом ему удалось впитать лучшее из Mesa/Cedar и Smalltalk, и сохранить в лучшем виде дух этих систем. Но с задачей «упопсения», конечно намного лучше справились Джобс с Гейтсом, которые к тому моменту уже имели опыт промышленного программирования и бизнеса. Вирт же никогда бизнесом не занимался и production quality — это ниже его достоинства: для него главное концепт, а не обертка и качество реализации.
>>Может быть потому что размер «Блокнота» в таком варианте стремился к размеру «Офиса»?
А так сейчас в общем-то и делают! В десктопах очень популярна концепция RCP — Rich Client Platform (Eclipse RCP, Netbeans RCP). Там любой блокнот размером с Офис, при этом стартует этот блокнот, ой как не быстро! Здесь проблема, что проектировались Eclipse и Netbeans изначально без этой простой SmallTalk концепции в голове, а было бы большое счастье если бы эта концепция там была бы изначально, RCP программирование ой как бы облегчилось! Но опять же здесь есть проблема с отгрузкой в Java, без которой концепт нормально не работает.
>>А недостатки динамической перезагрузки модулей в Java это не проблемы языка или архитектуры платформы,
>>это проблемы реализации
Не согласен. В Java hotswap — это вообще опциональная фича для JVM, которая может быть, а может не быть и существует она там вообще только для отладки. Соответственно, как она может быть реализована в JVM не описано в спеке даже в общих чертах. А фича корневая, чтобы ее сделать по уму, однозначно надо менять JVM спецификацию, собирать лучшие умы JVM строения, JCP и прочее.
Вот это должно стать частью его профессии. Знать про всякие условности. Если вы на данный момент в силу разных обстоятельств знаете больше его, не означает, что он не может с этим справится.
>>Но есть еще и динамические формы, вид которых сильно зависит от отображаемых данных.
Разумеется динамику надо делать кодом. Здесь весь вопрос, что описывать кодом. Вы можете дать дизайнеру специальный layout manager, который будет расставлять контролы в зависимости от отображаемых данных, при этом спихнув на него стилизацию контролов, спец-эффекты и прочее. Или вообще изготовить отдельный контрол для данной предметной области предоставив дизайнеру необходимые ручки для того, чтобы он его сделал хорошо выглядящем.
Мой поинт в том, что программист не должен заниматься двиганием контролов на пискель вверх/вбок, следить за антиалиасингом, выравниванием и прочим. Он должен писать программы.
>>На мой взгляд верстка от дизайнера — прекрасная, но совершенно нежизнеспособная абстракция.
Может быть. По хорошему, надо за такими как вы внимательно последить, когда вы начинаете программировать GUI, чтобы понять, что из этого процесса от вас отделить, а что оставить. Короче, мне кажется, тут есть поле для исследований.
2) В Обероне нет, в Оберон-системе корень был, от кторого все наследовались. Можно было не наследоваться, но это не приветствовалось. И у этого корня Handle был.
3) Да, все моделировали методы процедурными типами и полями объекта. Конечно, это больше похоже на function в JavaScript, но тем не менее все старались, чтобы это было похоже на методы. Лично я больше работал с Мифрилом, который был написан на Оберон-2, соответственно методы там были, и был метод Handlе. В Оберон систему я в основном лазил, чтобы подглядеть какую-нибудь идейку и реализовать ее в Мифрил.
Кстати в Clojure на JVM можно перегрузить модуль? Как это там делается? Интересны подробности
Или возьмем Обероновские модули. Важным их свойством является не только, что их можно динамически загружать, но и отгружать, а соответственно безболезненно перегружать!
Я тут недавно общался с одним своим хорошим знакомым ентерпрайзчиком, и он жаловался, что главная проблема Java сейчас — это hotswap — то есть перегрузка изменившихся классов в живом приложении. Она в ХотСпоте очень плохо работает, поэтому все развлекаются через JRebel, который тоже ни фига не работает. А в Обероне такой проблемы не было! Код любого модуля (кроме корневых) можно было на лету поменять! Поэтому там был реальный Live coding, который в промышленных системах есть только для языков с динамической типизацией, то есть за счет отказа от статической типизации, со всеми вытекающими. Во Обероне же строгая типизация!
Что-то подобное Оберновским модулям на Java можно реализовать, только если грузить каждый класс, отдельным загрузчиком. Что вообще говоря адский оверхед. Я кстати, так и сделал в своей попытке реализовать что-то подобное Оберон-системе на Java — github.com/pjBooms/The-Nothing-System. Но это конечно минимальный прототип, стоит в этом прототипе начать классам друг друга импортировать и начнется такой нехилый computer science, как выгрузить класс по середине циклических зависимостей (кто кстати хочет поразвлекаться и доказать тем самым, что Java рулит — добро пожаловать, жду pull реквесты).
В промышленном же виде для перегрузки модулей есть пока только OSGi (очень крупные модули), но на него все, просто реально все, матерятся кто имел дело в реальном продакшене!
И вообще в Обероне не было не live coding'a. Твоя программа и Оберон-система — это одно целое. Любое программирование в Оберон системе — это расширение системы. Нельзя было к примеру «запустить программу», можно было только расширить систему.
То есть ты всегда находишься в своей собственной программе и развиваешь ее. Эта концепция до промышленных программистов так и не дошла!
Или возьмем REPL, который так нравится Ruby/Python и прочим хипстер программистам. Концепция «команды» в Обероне, очень похожа, но (потенциально) гораздо более мощная, чем REPL. То есть это фактически это тот же REPL, только выполненные кусочки кода не исчезают в истории команд, а остаются там, где ты их написал, и ты их можешь в любой момент вызвать кликом мыши (отредактировав входные параметры, если что). На такой очень простой концепции можно вообще весь UI приложения в обычном текстовом редакторе набить (и UI в ранних версии Оберона, так собственно и был сделан).
Когда я в первый раз увидел Java, мне там все понравилось кроме одной вещи. В Оберон-системе в корне иерархии объекта, есть метод Handle, который принимает абстрактный Message. То есть любому объекту Оберон-системы (которые кстати спокойно все сериализовались), можно было послать любое сообщение и он мог его обработать или нет. То есть, вопрос какая объектная модель лучше Simula или Smalltalk там просто не стояла, были реализованы обе, и вся система асинхронна и event-driven по умолчанию.
Мне реально жаль, что в java.lang.Object нет метода handle.
Кроме того, в корне иерархии была возможность добавлять динамические атрибуты к объекту. То есть сам Оберон — со строгой типизацией, но элементы динамической типизации были встроены в базисные классы.
И в конце концов, я реально считаю, что GUI нужно рисовать в GUI builder, а не описывать в виде программного кода или на языке разметки. В Обероне GUI можно было только рисовать. То что в промышленном программировании до сих пор не сделали внятного GUI билдера, которым можно пользоваться — это позор! То что все трахаются с разметкой и Internet Explorer'ом — это дичайший фэйл промышленного программирования.
Короче, суть этой басни такова, что в промышленном мире программирования пока не найдено «золотое сечение». B Оберон система — это просто маленький пример, стоящий с обратной стороны, показывающий, что все может быть по другому, чем вы привыкли. Никто вас не заманивает в секту «царства Оберона» и не призывает начать программировать на Обероне. Но тем не менее, я считаю, что каждому будет полезно потрогать эту систему для общего развития, чтобы задуматься как те реально клевые фичи Оберона донести до мейнстрима и дотянуть до production quality. Чтобы вместе достичь гармонии и просветления :).
Также я не считаю, что за простоту реализации пользователького интерфейса системы должен платить конечный пользователь, который должен очень сильно постараться, чтобы тупо растянуть окошко как ему надо.
Но все комментарии здесь, тем не менее, по делу. Главная беда Оберон-системы, что она была сделана крайне непрофессионально, как изнутри, так и снаружи. Да, Вирт писал говнокод, его студенты, которые работали над этим проектом писали говнокод, и вся система была с гусями. Именно, поэтому мой науч.рук., упомянутый выше, Недоря решил в свое время написать коммерческий (читай профессиональный) вариант Оберон-системы — Мифрил (над которой я тоже успел поработать, в том числе успел внедрить на одно предприятие).
Но при этом молодеже здесь надо учесть, что большинству кода в Оберон-системе — 20+ лет. Тогда просто не было всех этих современных «практик», «методологий», и т.п. «Все было впервые и вновь» (хотя парное программирование было). Вы посмотрите на POSIX или Win API из тех же времен — это же тоже ад и п… ц! Особенно Win API — поубивал бы всех, кто это придумал в Microsoft во главе с Гейтсом.
Да что там в Microsoft, знаете как мне сейчас стыдно за исторически первый код в упомянутом выше проекте Excelsior JET, написанный мной 19 лет назад (на том же языке Оберон)! Это же говнокодище чистой воды! Мне приходиться закрывать лицо руками, когда я его показываю студентам. Но при этом он живет и работает. Вот недавно туда добавлял поддержку Java 8 (плакал, но добавлял — применил правда пару «практик» и код стал чуть лучше). Но в свое оправдание могу сказать, что за последние лет 10 в этом моем коде, не было найдено серьезных ошибок. При этом при поддержке Java 8, мы нашли 2 доисторических бага (до существования Java) в коде, написанными людьми очень успешными сейчас в редмонде и силиконовой долине (один работает в упомянутом выше Microsoft).
Только недавно очухался :).
Думаю тоже написать отчет, если еще не поздно.
Жаль, что поздно заглянул на Хабр, не знал что вы там будете, а то бы зашел на стенд, пообщался бы:)
Это из разряда «мы стали более лучше одеваться».
Нет я не понял контекста, в котором вы это употребили (то ли за что-то, то ли против чего-то).
>>Трюк в том, что грязная модель двунаправленно связана с представлением библиотекой, и вам вообще не нужно писать никакой код.
>>Юзер вбил данные в гуе? Они уже лежат в грязной модели, вам не нужно вешать события и потом париться,
>>если UX-дизайнер заменит селект на радиобаттон.
Так это же классика GUI! Так делали со времен его изобретения (Smaltalk, Xerox Cedar, Oberon System). То что это переизобрели спустя 30 лет в JavaScript не делает ему никакой чести. В простых сценариях, да можно без контроллера, и что?