Интерфейс универсального моделера
Универсальный моделер должен иметь не менее универсальный интерфейс:
а) собираемый (а хоть и composable в смысле функционального программирования -- см. прикидки на эту тему тут: http://www.youtube.com/watch?v=faJ8N0giqzw). Другой вариант для того же самого: верстка интерфейса (http://ailev.livejournal.com/809410.html). Богатство и мощность прикладных библиотек не должны закрываться жесткой логикой "приложения". Это значит, что должны быть не "приложения", а (возможно, графические) развиваемые DSL (=модель предметной области) и средства выразить модель требований к конкретному расчету.
б) высокоуровневые. Думайте об intentional programming (http://en.wikipedia.org/wiki/Intentional_programming -- и не путайте с intenSional): компьютеру нужно сообщить лишь намерение, а остальное он должен сделать сам. Все эти DSL, языкоориентированность, программные трансформации и т.д. -- это об этом.
в) интерактивное программирование -- отладчик должен быть, а изменение кода в одном месте должно приводить к коррекции кода в другом месте (http://ailev.livejournal.com/763851.html, много ссылок тут: http://ailev.livejournal.com/760334.html). Уж не знаю, как с этим быть для суперкомпиляторов, отсюда любовь к динамическим языкам.
г) "фасетное моделирование", много разных DSL (language workbench), онтологическое объединение разных моделей (не обязательно "общего вида", как ISO 15926, но хотя бы типа UEML для языков моделирования предприятия -- http://hal.archives-ouvertes.fr/docs/00/40/51/42/PDF/UEML-CII2009-20.pdf). Другое дело, что "онтологическое объединение" и "объединение в абстрактном синтаксисе" пока не очень понятно, как связаны -- они, скорее, дополняют друг друга.
Суть постинга: язык и интерфейс существенно связаны. Как говорится в презентации по первой же ссылке, "текст программы -- это интерфейс командной строки". GUI с бесчисленными выскакивающими окошечками, в которых бесчисленное число заполняемых полей и выборов параметров из огромного числа списков мне представляется тоже не лучшим решением. Верстаемый интерфейс (как математических программах, где исполняемые формулы перемежаются поясняющим текстом и выходными графиками) тут явно выигрывает. Ну, или в варианте свежевыложенного в марте 2010 активного эссе Text Field Specification -- http://www.vpri.org/pdf/m2010002_lobjects.pdf.
Это я к тому, что не следует ожидать независимости языков (а хоть и DSL) от интерфейса IDE -- эти DSL, скорее всего, будут определяться как и в случае SmallTalk или других подобных языков вместе со "средой исполнения". То есть нельзя "сочинять язык предметной области", пока не определился с интерфейсом моделера. И наоборот, нельзя определиться с интерфейсом моделера, ежели не разобрался с тамошними DSL.
а) собираемый (а хоть и composable в смысле функционального программирования -- см. прикидки на эту тему тут: http://www.youtube.com/watch?v=faJ8N0giqzw). Другой вариант для того же самого: верстка интерфейса (http://ailev.livejournal.com/809410.html). Богатство и мощность прикладных библиотек не должны закрываться жесткой логикой "приложения". Это значит, что должны быть не "приложения", а (возможно, графические) развиваемые DSL (=модель предметной области) и средства выразить модель требований к конкретному расчету.
б) высокоуровневые. Думайте об intentional programming (http://en.wikipedia.org/wiki/Intentional_programming -- и не путайте с intenSional): компьютеру нужно сообщить лишь намерение, а остальное он должен сделать сам. Все эти DSL, языкоориентированность, программные трансформации и т.д. -- это об этом.
в) интерактивное программирование -- отладчик должен быть, а изменение кода в одном месте должно приводить к коррекции кода в другом месте (http://ailev.livejournal.com/763851.html, много ссылок тут: http://ailev.livejournal.com/760334.html). Уж не знаю, как с этим быть для суперкомпиляторов, отсюда любовь к динамическим языкам.
г) "фасетное моделирование", много разных DSL (language workbench), онтологическое объединение разных моделей (не обязательно "общего вида", как ISO 15926, но хотя бы типа UEML для языков моделирования предприятия -- http://hal.archives-ouvertes.fr/docs/00/40/51/42/PDF/UEML-CII2009-20.pdf). Другое дело, что "онтологическое объединение" и "объединение в абстрактном синтаксисе" пока не очень понятно, как связаны -- они, скорее, дополняют друг друга.
Суть постинга: язык и интерфейс существенно связаны. Как говорится в презентации по первой же ссылке, "текст программы -- это интерфейс командной строки". GUI с бесчисленными выскакивающими окошечками, в которых бесчисленное число заполняемых полей и выборов параметров из огромного числа списков мне представляется тоже не лучшим решением. Верстаемый интерфейс (как математических программах, где исполняемые формулы перемежаются поясняющим текстом и выходными графиками) тут явно выигрывает. Ну, или в варианте свежевыложенного в марте 2010 активного эссе Text Field Specification -- http://www.vpri.org/pdf/m2010002_lobjects.pdf.
Это я к тому, что не следует ожидать независимости языков (а хоть и DSL) от интерфейса IDE -- эти DSL, скорее всего, будут определяться как и в случае SmallTalk или других подобных языков вместе со "средой исполнения". То есть нельзя "сочинять язык предметной области", пока не определился с интерфейсом моделера. И наоборот, нельзя определиться с интерфейсом моделера, ежели не разобрался с тамошними DSL.