Обсуждение

Они уже год разрабатывают и пиар начали вести раньше. Но открытую бету выставили только в этом месяце. http://habrahabr.ru/blogs/Flash_Platform/96358/

Без дебаггера и профайлера - это текстовый редактор.

А в MPS разве нет дебаггера и профайлера? Думаю, это временное явление.

Прочитал у них в презентациях, что с помощью юзер интерфейса они увеличивают скорость написания кода в несколько раз. А функциональные языки увеличивают скорость написания кода в несколько раз, за счет того, что просто код в несколько раз короче. Вобщем очередное "предчувствие революции", как автор сам и выразился.

Возможно, я что-то не догнал, когда смотрел в свое время MPS, но, имхо, структурный редактор может и мог бы быть удобным, но в той реализации это был какой-то жутко неудобный кошмар. Думается, что обычный текстовый редактор с адекватным дополнением гораздо удобнее. Создание языка тоже какое-то вымученное, долгое и отнюдь не простое. Пожалуй, если бы мне понадобилось создать DSL, то лучше бы я проделал это традиционным путем. По крайней мере, работать с этим языком можно было бы как угодно и откуда угодно. Отсутствие человечной IDE в этом случае серьезный минус, но и то что дает MPS человечной IDE не назовешь. Да и вообще, DSL больше похоже на очередной бестолковый пузырь. Лучше бы потратили силы на создание одного действительно хорошего, действительно гибкого и действительно универсального языка. По большому счету не так принципиально описывать систему полностью в терминах ее предметной области. И чем учить 50 разных языков, лучше действительно хорошо изучить один.

Попытаюсь сформулировать резче: 1. Отличия language workbench и "традиционной IDE" со структурным редактированием пока так и не удалось описать. Более того, для language workbench пока не удалось по-простому описать практику создания языка (ибо для этого опять-таки нужно четко описать архитектуру language workbench). Это как с функциональным (да даже и с "классическим" уже ОО) программированием: привыкшему процедурно писать на Basic просто непонятно, в чем там фишка, а когда фишка становится понятна, непонятно как писать в этом стиле. 2. Дискуссию о пользе/вреде DSL нельзя считать законченной: эксперименты в этой области мало что показывают, и никого не убеждают. Более того, разница между DSL-подходом и расширяемыми языками (типа, например, Factor или ранее Forth. Ну, или нынешними Scala или Haskell) до сих пор не оговорена так, что понятно о чем идет речь. То есть я читаю ваш коммент так: "все то же самое, что обычно -- только путаннее и сложнее, поэтому пустое". Действительно, если MPS рассматривать как "структурный редактор", то это ужас-ужас-ужас. Но MPS это не структурный редактор.... Ну, и DSL не обсуждается в терминах онтологической постановки вопроса (это мы тут начинаем обсуждать онтологическое программирование), поэтому на ваше возражение про "неважность описания системы в терминах ее предметной области" невозможно отвечать, если не знать про принципиальное наличие описаний в нескольких предметных областях и тем самым неизбежность наличия множества разных DSL в одной и той же программе -- что ведет далее к необходимости иметь language workbench. Все это сейчас запутано, и внятных текстов нет, одни декларации -- в этом я совершенно согласен. В чем не согласен: идея с языкоориентированным программированием хороша, и для ее реализации требуется специальный инструментарий.

Ежели смотреть на результаты проекта STEPS, то используя каждый раз соответствие природы задачи и парадигмы программирования, а также используя паттерны кодирования одинаковые к самым разным объектам ("особую онтологию кодирования" -- миры, цепочки компиляции, паттерн-парсинг и т.д.), можно получать порядки на сокращении кода. Ну, и три раза от правильного юзер-интерфейса тут явно не помешают (где три раза наскребли, там и еще три раза эволюционно накапает). Мне кажется, что революции уже не предчувствие, она полным ходом пошла -- хотя как всегда не оттуда, откуда ее ожидали (никакая "многоядерность" тут и рядом не стояла, равно как и обсуждение "парадигм программирования" и "универсального самого крутого языка").

Выигрыш в три раза от правильного юзер интерфейса поможет кодинг манки настругать в три раза больше кода. А что потом с этой кучей хлама делать-то? Тестировать и преобразовывать к компактному виду будет по крайней мере в три раза сложнее.

насколько я понимаю, под правильным юзер-интерфейсом понимается помощь в проведении сложных рефакторингов (то есть как раз анализ и сжатие кода). Другое дело, что рефакторинги обычно не относятся к "другому взгляду на ту же задачу", а просто "синтаксически" упрощают, с точностью до паттернов кодирования, а не паттернов моделирования (отражения в коде только того, что нужно, нахождение правильной абстракции). В DSL можно как раз заранее указать правильные объекты и операции с ними, да еще и в удобном синтаксисе (а не в "эквивалентной записи" на чуждом пользователю языке, типа FOL или Smalltalk).

Конечно, появление хорошего инструментария произойдет. Но не уверен, что это принесет что-то хорошее. Практически любой программер мечтает о "своем самом правильном языке" и если создавать их будет слишком просто, их будут создавать. Если мы вспомним, какие неудобства приносили людям такие простенькие вещи как перегрузка операций и множественное наследование, то можно представить какой взрыв мозга будет происходить от всех этих новых языков (вполне возможно, что их будут десятки в одной системе) с похожим синтаксисом, но совершенно разной семантикой. Конечно, все это может управляться и использоваться во благо, но если мы посмотрим на реальность, то в каждой второй крупной системе увидим огород из перекрывающих друг друга библиотек, утилит и фреймвоков, потому что исторически (а бывает и одновременно) у людей были разные предпочтения. Добавим к этом беспредел в языках и можно будет смело идти стреляться. Так что может это и хорошо, что эти технологии пока в стадии "танцующего медведя". Тем, кому DSL действительно необходимы, создают их и сейчас, а высокий порог входа делает этот процесс более осмысленным и контролируемым.

Кстати, заказали мне одну штуку на Processing. Можно ведь его рассматривать как DSL на базе Java для генерации графики. Думаю, учитывая его популярность, можно считать что этот DSL вполне удачен. Так вот, хотя на первый взгляд действительно все несколько удобнее, чем в Java, я уже начал жалеть, что не убедил людей писать прямо на ней. Потому что потолок Processing'а уже рядом - многие вещи, которые чуть-чуть выходят за рамки Processing'а делаются уже с трудом, хотя на чистой Java делались бы элементарно. К тому же, Processing сильно отстает в развитии. Там, например, до сих пор нет generics'ов и autobox'инга и меня это раздражает. В общем, я вполне уже готов променять процессинговое stroke(255); на более длинное джавовое g.setColor(Color.white). И это частая ситуация с разнообразными DSL.

Дискуссия эта традиционная, ей уже много-много лет. Гена Лебедев обычно говорил по такому поводу: "топор должен быть острым: инструмент должен позволять делать всё. Затуплять инструмент неправильно". Аналогичные выводы у группы Алана Кея. Я придерживаюсь тоже этой точки зрения. Вместо того, чтобы ограничивать людей в языковых средствах, нужно думать о компьютерной грамотности (т.е. массово обучать людей выражать свои мысли на формальных языках, как учат математике). Тут смешаны самые разных дискуссии: а) про выразительные возможности языков программирования б) про программирование-в-большом в) про коллаборацию при программировании большими группами людей г) про компьютерную грамотность д) про пользовательские интерфейсы и так далее. Ваша позиция понятна, текстов в Сети на эту тему огромное количество -- как с поддерживающими вашу позицию аргументами, так и с аргументами противоположными.

Люди, которые занимаются DSL в таких случаях как раз и говорят, что DSL сами по себе должны уметь расширяться: ежели вам захотелось что-то к Processing добавить, то у вас должна быть такая возможность. Или сделать еще один DSL, который закроет потребности (если потребности эти связаны с прихватом какой-то соседней предметной области).

Так что может это и хорошо, что эти технологии пока в стадии "танцующего медведя". Тем, кому DSL действительно необходимы, создают их и сейчас, а высокий порог входа делает этот процесс более осмысленным и контролируемым. Мне кажется, ровно наоборот :-) Каждый, кто сейчас пишет какую-нибудь библиотеку, разрабатывает к ней нетривиальный API -- по сути разрабатывает новый язык. Но делает это неосознанно, неосмысленно, считая, что это просто функции да методы. А если бы осознавал -- мог бы научиться делать это намного лучше.

Более того, разница между DSL-подходом и расширяемыми языками (типа, например, Factor или ранее Forth. Ну, или нынешними Scala или Haskell) Классический пример -- это lisp, где программистов с младых ногтей учат писать макросы, объясняя, что создавать internal DSLs везде, где нужно расширить язык -- это нормально и естественно. Т.е. есть та самая языкоориентированная культура.

Фредерик Брукс много лет назад написал свой Мифический Человеко-Месяц, в котором в частности есть статья про то, что Серебрянных Пуль в программировании нет и не предвидится. А идея там очень простая - все эти тулзы и подходы, которые обещают революцию, на самом деле пытаются оптимизировать те аспекты, которые занимают не так много времени и уже оптимизированы. В частности, Брукс приводит статистику, что кодирование занимает 15% времени. Почему я и написал, что если улучшить работу кодинг-манки мы получим в три раза больше хлама. Те рефакторинги что там есть - простые. Их недостаточно, чтобы более-менее серьезно код менять. Тулзы для серьезного рефакторинга никто делать не будет, ибо это как раз проблема уходит корнями в область доказательства теорем. Грубо говоря, для более-менее сложного рефакторинга, автоматически доказать эквивалентность уже не получается. Хотя вообще говоря тут много можно чего сделать в плане автоматизации.

Все продвинутые тулзы типа Аспектов и пр, которые позволяют генерить кода из каких-то компактных описаний, спотыкаются на одной простой вещи - а как тестировать эту нагенеренную кучу кода? Ведь маленькие изменения в описании могут привести к слабопредсказуемым последствиям.

Я согласен с оценкой Брукса по текущему статус-кво. Но компьютерная революция не вся потеряна: мне кажется, что группа Алана Кея потихонечку прорывается в более быстрое программирование-в-малом, а интеграторы данных с их онтологиями типа ISO 15926 потихонечку прорываются в программирование-в-большом. И группа Алана Кея открыто говорит, что она "ищет новую математику" в программировании, а у онтологов этой математики (как уже очевидно) и сейчас с избытком. Как всегда в таких случаях бывает -- кто может заниматься сущностными вопросами, занимается какой-нибудь прикладной ерундой. А кто должен заниматься прикладной ерундой, занимается во всяких университетах "прорывными разработками", четко подтверждая тезисы Брукса. Вообще, я думаю, что даже для сложных рефакторингов тезис Брукса верен. Для прорыва нужно "другое кодирование", перемоделирование со сменой онтологии (выделение в мире других сущностей и переход к другим типам алгоритмов, переход к другим парадигмам), а не просто рефакторинг (который работает уже с кодом -- код ведь появляется после моделирования). Хотя вполне возможно, что под слово "рефакторинг" подведут и подобные крутые перемоделирования.

Я все чаще и чаще об этом думаю. И не только я. Собственно, интерактивное программирование как раз про это: как делать так, чтобы мочь проводить эксперименты с кодом в исходных терминах. Компиляторы в большинстве своем такого не позволяют, а дебагить программу после суперкомпилятора просто невозможно. Я, например, смотрю на все эти "цепочки смыслов" Пиумарты, и думаю: а как они все эти цепочки преобразований дебагят?!

Мне А.Г.Кушниренко говорил, что в действительно серьезных программах (кремниевые компиляторы, например) используются только серьезные языки -- lisp, Smalltalk и т.д. На попсовых языках там ничего не напишешь, сложность слишком велика, требуется существенно задействовать рефлексию, создавать подъязыки и т.д.