Обсуждение

Языко-ориентированный подход изначально неперспективный: разработка языка - крайне дорогостоящее занятие, под силу только компаниям а-ля Сан и Микрософт (для промышленных языков). Можно и меньшими ресурсами но и результат будет попроще. Сейчас появилось много наработок которые позволяют сократить издержки при разработки языка, в частности JVM и CLR, которые можно использовать в качестве таргет-платформ. Хорошо развита теория трансляции, разработаны языковые конструкции. Тем не менее, разработка языка - это все еще очень затратное мероприятие, ведь остаются огромные издержки на обучение и поддержку пользователей. В результате, всеми этими языками, созданными в рамках парадигмы ЯОП, будут пользоваться только лишь авторы. Гораздо реальнее альтернативная концепция DSL - Domain Specific Language, восходящая еще к Лиспу и хорошо развитая в рамках функционального (вообще декларативного) программирования. Микрософтовский F# весьма перспективен в этой роли - эффективная поддержка со стороны CLR/.Net, поддержка Микрософта, юзерская база и библиотеки от OCaml'а. Martin'у Ward'у и Сергею Дмитриеву с ним тягаться просто смешно. ЯОП - как раз подход одиночек, т.е. одиночка хочет создать язык подходящий именно ему. В принципе, если работать в одиночку, а мощь таких подходов как ЯОП и ДСЛ как раз и позволяет в одиночку делать то, что раньше пытались делать десятки программеров, то ЯОП - концепция жизнеспособная. В то же время ДСЛ, особенно с учетом макросов, метапрограммирвания и модифицируемого синтаксиса (более-менее стандартные разработки) все равно перспективнее - ибо коммуникация с другими проходит гораздо проще, ведь базовый язык тот же самый.

А как вы различаете языкоориентированный подход и подход DSL? По смыслу DSL никак не подразумевает типа реализации, да и те типы реализации, что у вас помянуты, вполне укладываются в языкоориентированный подход -- как вырожденные случаи. Ежели вы хотите просто заметить, что есть языки, а есть речь каждого конкретного человека (и языки живут промеж людей, а речь есть у конкретных людей), то я тут вполне согласен. Но не могу не напомнить о существовании моего любимого проекта FONC, в котором DSL-языки создаются "по настроению" в пределах нескольких строк -- как пишет Ian Piumarta 27 ноября 2007г. в их списке рассылки:

We should be able to go beyond even domain-specific languages, to what I've been calling 'mood-specific languages'. If it makes my (e.g.) message-passing code more readable to be able to write 'x[y,z]' instead of '(x at: y) at: z' during a three-line region of my program in the middle of some function or method, I want to be able to instantiate my new syntactic convention for just those three lines of code. It'll certainly not look anything like this...

  `push-syntax expr += expr-1[expr-2,expr-3]     -> ((expr-1 at: expr-2) at: expr-3) ;

   c[i,k] = a[i,j] * b[j,k].

   `pop-syntax expr

but the closer we can get to the spirit of the above, the better.

На всякий случай еще дам подтверждающую ссылочку: все эти DSL -- изводы language-oriented programming, как прямо говорится в конце первого же абзаца http://en.wikipedia.org/wiki/Domain-specific_programming_language

Спасибо!

> А как вы различаете языкоориентированный подход и подход DSL? По смыслу DSL никак не подразумевает типа реализации, да и те типы реализации, что у вас помянуты, вполне укладываются в языкоориентированный подход -- как вырожденные случаи. Тут есть неточность в терминах. И DSL и ЯОП можно трактовать узко и широко. В широком смысле DSL и ЯОП эквивалентны: под задачу делаему удобный язык, что повышает эффективность на порядок. Концепция восходит еще к 4G языкам. Но в узком смысле DSL и ЯОП - противоположные концепци: ЯОП (в рамках реализации Сергея Дмитриева) - есть создание нового языка с помощью удобных тулзов, а DSL (иногда используется термин внутренний DSL) в частности употребляют для обозначения подхода, который состоит в том, чтобы домейн-специфичный язык делать сугубо в рамках некого расширяемого хост-языка типа Лисп или Хаскел. Т.е. новый синтаксис и семантика вводятся крайне осторожно. В этом узком смысле я и упоминал DSL и ЯОП. Опасность ЯОП в том, что новые конструкции очень тяжело сделать целостными, в плане семантики, отладка может проходить годами. В случае выражений аля c[i,k] = a[i,j] * b[j,k] все просто и понятно, это даже понятнее чем исходный синтаксис. Тут чистый выигрыш. Но сам по себе ЯОП толкает неуравновешенных программеров на создание новых шизофренических конструкций. В этом смысле, внутренний DSL гораздо реалистичнее.

В общем случае - да, но Internal DSL фактически не являются частным случаем ЯОП, ибо создание нового языка не происходит, используется расширяемый хост-язык.

В любом случае, тренд -- дать людям свободу создавать шизофренические конструкции в тех предметных областях, в которых они соображают. Раньше просто думали, что шизофрения в том, что оператор цикла в каждом языке свой -- а теперь понятно, что дело не в операторах цикла, а в операторах манипулирования с пользовательскими "предметами" (намеренно пишу не "объектами"). Для меня граница спецтулзов и "чистого" языка весьма размыта, ибо есть еще странные среды типа Smalltalk в варианте Squeak (ибо Smalltalk с самого начала был задуман как язык-среда-инструмент, и проект FONC развивается в эту же сторону как экстремальное доведение до ума древних идей о языке-инструментарии). Дискуссия эта очень древняя. Когда-то, году эдак в 1982, на Лиманческой школе программирования темой были языки сверхвысокого уровня. И образцом такого языка был RPG -- язык генератора отчетов. Все с изумлением разъехались с этим результатом (а в 1982 году с языками было не менее все в порядке, чем сегодня -- все основные линии были уже намечены и опыт работы с десятками языков был у каждого программиста, было с чем сравнивать). Туда оно до сих пор и катится: как сделать такую среду, в которой приходилось бы все время программировать на языке сверхвысокого уровня (то есть DSL для той предметной области, в которой предполагается программирование). Так что "инструментальное" разделение для меня нерелевантно.

Если хост-язык рефлексивен (и, тем паче, интроспективен), то граница между языком и специнструментарием размывается. Особенно, если в определение языка входит определение такой среды (как в smalltalk или FONC).

Вот это разумный подход, ибо у програмера большой простор для маневра в рамках языка. Нет нужды изобретать велосипед, пусть даже и очень крутой, типа MPS или ему подобных.

Так я только об этом и пишу: "язык" и "языковый инструментарий" -- это одно и то же, если соблюдать определенные условия. У меня некоторое время назад развертывались большие дискуссии в блоге по поводу того, зачем системам нужна рефлексивность и интроспективность, тоже люди не сразу понимали. Потом понимали и проникались.

На практике, очень удобно когда есть возможность решить все вопросы в рамках языка. Ибо, на практике, программист живет не один, а в коллективе, где есть заказчики, тестеры, коллеши, начальство и т.д. Если я делаю проект сам для себя, то могу позволить себе любую шизофрению, ЯОП тут принципиально картины не меняет. Если же я в коллективе, то гораздо проще обходиться без спецтулзов, согласовать спецтулз, особенно мощный, с контрагентами - не в любом коллективе возможно. К примеру, я не хочу заниматься Веб-проектами, ибо там инфраструктура заточена под ПХП - язык довольно дурацкий, но не в моих силах сменить инфраструктуру.

Вот мне и видится, что ЯОП - это шаг в сторону от такого подхода, ибо отвлекает внимание от действительно важных проблем. Основной способ повышения производительности программеров - это создание более выразительных конструкций. Ибо производительность, измеряемая в строчках кода, не зависит от языка программирования. ЯОП казалось бы решает эту проблему. Но на практике, ЯОП недооценивает проблему внедрения, издержек на обучение и коммуникацию, которые очень велики. Рефлексивность, интроспективность, АОП, генерейтив программирование - все это концепции инкрементальных изменений языка, т.е. мы к существующему ядру языка добавляем относительно простые конструкции, которые повышают выразительность на порядок. В то же время, издержки на внедрение невелики, ибо эти концепции согласованы с ядром языка. В случае чего нетрудно объяснить другому программеру, в чем практическая польза использования этих конструкций.

В экономических терминах, я бы выразился так: создатели инкрементальных языковых расширений аля АОП - решают проблему последующего внедрения, снижают соответствующие издержки, а вот создатели глобальных расширений аля ЯОП/MPS - нет. Соответственно, сие бремя падает на простых программеров и менеджеров, купившихся на рекламу светлого будущего.

Правда, в Вебе возможно много интересных "побочных" проектов. К примеру, ПХП - очень тормозной язык, и не так уж трудно сделать софистикейтед компилятор, который бы повысил скорость на порядок. В качестве примера можно привести тулзу от Caucho которая компилирует PHP в Java и помимо ускорения раз в 5, дает доступ ко всем Java'вским фичам, включая библиотеки и многопоточность.

Веб, замечу, ничем не отличается (особенно сегодня ;) от "просто программирования".

Технологии там другие. Я не переношу ЕЖБ и не люблю ПХП. Можно конечно и без них обходится, но это уже узкий рынок, т.е. я бы даже его Вебэом не стал называть, ибо Веб там не самое главное, раз уж решились на что-то отличное от ПХП и ЕЖБ.