Эти разные, разные "Меты".
Если разбираться в том, как работает инженерная компания, то нужно в явном виде описать метод её работы. Из лучших методов этого описания можно предложить на сегодня стандарт Основ (http://ailev.livejournal.com/1051048.html) -- и тут же наткнуться на простоту его применения в части описанных в
( Read more... )
Зачем нужны все эти меты показывает Конрад Бок в своей презентации: http://www.isr.umd.edu/events/m-bsec_PPTs/111128_Bock.pdf -- это как раз наш разговор на тему "на каком уровне меты появляются слова не про реализацию, а про предметную область". У Конрада Бока эти слова появляются главным образом на пути специализации/генерализации, но у метамодельеров обычно эти слова появляются практически по любой линии мет.
Так что это было бы неплохим упражнением для прозрачного персистанса указать на его мета-уровень по отношению к уровню, когда появляются понятия предметной области вверху, и уровню виртуальной машины внизу. Ну, и более чётко прописать мета "выражение -- абстрактный синтаксис", ибо задача-то ставится в абстрактном синтаксисе, а потом только отражается в одном из многочисленных выбранных языков.
Кстати, Алан Кей так же со своими "языками" обходится. У него каждый язык это "идея, как можно рассуждать о программах", а потом идут различные реализации на самых разных языках (ОМета была реализована чуть ли не на десятке языков -- просто как набор идей). Так и "прозрачный персистанс" может быть сформулирован абстрактно (на мета-уровне) один раз, а реализован множество раз. Ну, и пользовательские представления затем могли бы быть реализованы много раз, из них один раз -- с использованием прозрачного персистанса и всеми положительными плюшками от этого. Если так рассказывать, всё становится понятней.
Reply
Ибо если статические типы - то замучаешься объяснять компилятору.
Если динамические - то замучаешься искать ошипки.
А реврайтинг он кагбэ состоит из более-менее правильных кусочков-преобразований.
Соответственно реврайтовый язык эти пробразования оркеструет.
Т.е. тут кагбэ инженерный аспект больше, как это сделать юзабельным на практике. Мне думается без реврайтинага это слишком геморно, разве что детишек с децтва натаскивать. Но отдельные индивиды разумеется могут, но мне в их число как-то не очень хочется - голова слишком болит :).
С прозрачным персистенсом все проще - по моему ощущению, 90% серверного веп-программирования (т.е. если исключить ЮИ: жабаскрипт, темплейты там) связано с последствиями того, что персистенс непрорачен. Нужно делать структуру БД, маппинг в БД, всякие кэши, DTO, DAO и прочую хрень. Т.е. одно поле в БД добавить - это куча геморроя. Различные тулзы тут могут слегка помочь, а могут наоборот все запутать.
Соответственно, если ты на персистенс не отвлекаешься - все настолько проще.
А про ЮИ часть у меня тоже есть соображения. Близкие но немного другие.
Reply
Reply
Вообще говоря чистые функ языки являются реврайтовыми, т.е. реализуются как редукция графа. Ну и вообще лямбда исчисление на этом простроено.
Но там ограничен вид реврайтовых формул, чтобы они обладали полезными свойствами, например сходились, или сходились к единственному виду и т.д.
Плюс там вводятся ограничения, чтобы можно было эффективно реализовывать, к примеру вывод типов, ну или по скорости чтобы было быстро.
Макро-языки тоже понятно дело реврайтовые
Но есть и более выразительные реврайтовые языки. Тот же Pure.
В частности они не обязательно сходятся к единственному виду, т.е. результат зависит от порядка применения правил. Плюс вариантов применения правил может быть слишком много, они могут "разрастаться" и проч.
А значит, этот порядок применения правил надо задавать извне - т.е. оркестрировать, чтобы получалось что-то вразумительное.
Т.е. реврайтовые языки забивают на классические ограничения лямбда исчисления, получая взамен бОльшую выразительность. Ну и пытаются как-то бороться с последствиями (ограничения ведь не просто так придумали), т.е. какие-то срецтва оркестрации.
Я тут не очень подробно знаком, все-таки специфичная тема. Но потенциал крайне интересен. Особенно если речь идет о много-мета, где функ языки на мой взягляд не очень (сложно больно все становится при статических типах).
Reply
Ведь OR маппинг-то по сути есть преобразование на мета уровне. А сделать нормально не могут.
Хотя на первый взгляд там все так просто кажется. Соответственно и тулзов много - (психологический) порог входа низкий.
Reply
Reply
Reply
Кстати, Алан Кей про важность правильного определения "предметной области наверху" буквально пару дней назад (8 января 2013 в списке FONC) про свои chains of meaning писал: it is a huge design task to pull off a good DSL -- actually it is a double design task: you first need to come up with a great design of the domain area that is good enough to make it worth while, and to then try to design and "make a math" for the fruitful ways the domain area can be viewed.
This pays off if the domain area is very important (and often large and complicated). In the STEPS project both Nile (factors of 100 to 1000) and OMeta (wide spectrum flexibility and compactness) paid off really well. K-script also has paid off well because it enabled us to get about a 5-6 reduction in the Smalltalk code we had done the first scaffolding of the UI and Media in. Maru is working well as the backend for Nile and is very compact, etc.
In other words, the DSLs that really pay off are "actual languages" with all that implies.
Понимание того, что это такой стек, и разные люди с разной предметной (domain) экспертизой и разными задачами работают на разных уровнях этого стека, и им не нужно учить все эти языки, тоже помогает.
Reply
По сути речь-то идет о том, что отображать между рядом форматов, которые описывают одни и те же сущности, только расположенные в разных местах:
1 на диске
2 в памяти
3 в пользовательском интерфейсе
4 в интерфейсах передачи данных между ними
5 ну еще в голове пользователя (по крайней мере некоего идеализированного пользователя)
Казалось бы это должно решаться стандартными маппингами на метауровне, в большинстве случаев.
Дык нет же, тулзы наверное в целом помогают, но в результате все все равно так запутанно, просто ужас какой-то.
Потом я делаю разбор полетов в спокойной обстановке: вроде там все получается просто, яйца выделенного не стоит. Почему на практике все так страшно усложнено и запутанно? Я пока не понимаю.
Впрочем, я помню Вы как-то ровно на эту же тему камент написали, что надо как-то уменьшить количество уровней, а то все запутывается, или что-то в этом роде :).
Reply
1 была представлена 5 форматах: UI, JSON, DTO, Entity, SQL
2 проходила 5-6 функциональных уровней: UI, сервис, бизнис-логику, DAO, Stored Procedure, SQL
3 чтобы что-то подправить/создать новую сущность в общем случае может потребоваться внести изменения вплоть до 10-11 файлов
ЗЫ проект довольно-таки простой
ЗЗЫ это не я такой "умный", это типовое мышление диктуемое различными фреймворками и прочими "best practices", т.е. достаточно типично для современных веп-проектов на Жабе, на других языках может быть чуть полегче, но не факт
ЗЗЗЫ самому написать фреймворк под проект может оказаться проще, нежели геморроится с бест-практисисами и 10ью уровнями. Поэтому видимо эти фреймворки и растут как грибы
ЗЗЗЗЫ есть и разумные фреймворки, созданные опытными товарищами, теми кто устал от всего этого кошмара (они вобщем-то так прямо и пишут), но которые достаточно сложно обнаружить в информационном шуме
ЗЗЗЗЗЫ в типичном проекте, достаточно сложно задействовать кодогенерацию либо нестандартные фреймворки - не "поймут" (причины сего - отдельная проблема)
Reply
Reply
Reply
Reply
Leave a comment