Йа -- язычнег, дайте мне капище.

[ailev]

Языкоориентированное программирование (http://ailev.livejournal.com/545386.html, и более подробно http://ailev.livejournal.com/548142.html -- это я писал в январе 2008г.), продолжает формироваться

Comments

[ailev]

В программах примерно 1 ошибка на 1000 строк кода, но это не зависит от языка, специалистов я в данном тексте поделил на три категории (специальность и специализация, а потом просто пользователи), а универсальность стоит ровно столько, насколько правильная архитектура ее обеспечения и что под ней вообще имеется ввиду (машинный код универсален, нет? Он, наверное и есть самый дорогой в цене универсальности, раз без него не обойтись? ;)

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

Так что SAP в текущем состоянии как раз является примером того, к чему ведет отсутствие ясного понимания в обсуждаемой предметной области DSL (и SAP очень интересуется обсуждаемым в данном постинге вопросов -- см., например, на организованный SAP семинар по DSL, http://krlz.livejournal.com/74069.html: SAP делает свою DSL-инфраструктуру, и приглашает разработчиков других подобных систем на обмен опытом).

Предложенный вариант с лягушатником из программистов и спецов правильный, только у нас немного разные понимания "универсальных языков программирования". Вот я до сих пор с нежностью вспоминаю свой опыт работы на Forth -- это для меня как раз универсальный язык программирования, потому что на его основе делались DSL, и уже в их терминах решались задачи. Очень удобно, быстро, надежно. Там, правда, были другие проблемы, но они были связаны не с этим свойством языка.

Мне еще кажется, что язык всего этого "метамоделирования" и "доменориентированности" очень мутный и не позволяет людям понимать, о чем идет речь. Я в данном постинге попытался чуть-чуть поработать с терминологией, чтобы можно было обсуждать DSL-часть, ибо она тоже многоуровневая получается.

Кстати, я явно имел тут ввиду очень похожий на SAP комплекс 1C (как минимум -- Бухгалтерию), но который является очень успешным именно за счет того, что язык бухгалтерской учетной технологической платформы была выбран очень грамотно (см. приведенную в постинге ссылку), и DSL приложения РСБУ (российской системы бухгалтерского учета), написанный на языке бухгалтерской технологической платформы поставлялся в составе системы. Опыт был настолько хорош, что 1С, как система DSL-программирования, была повторена специалистами Михаила Донского на наладонных компьютерах и довольно быстро там работала.

У SAP этого всего нет, отсюда и беда. Так что спасибо за возможность это откомментировать ;)

[vit_r]

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

Код - это не готовый продукт. Интересно само производство. Цифры же берут из некого "конечного" состояния. Наиболее правильная метафора софтописания - хоровое пение. Готовятся, готовятся, спели первый релиз, потом готовятся дальше, спели второй. И так далее.

САП - это стандартные модули, которые великолепно работают, но, которые надо впихивать в отличающиеся от стандартных процессы. Чем больше специфики, тем интереснее. При этом есть САП старый (не модульный) и новый (гибкий, нацеленый на DSL и так далее). О втором отзывы такие, что не позволяют их цитировать. Может быть оно и созреет. Только я сомневаюсь. Тем более, некоторые утверждают, что Оракл скупил все перспективные фирмы в этой области.

На практике в большинстве случаев сила абстрактного мышления у большинства спецов такая, что переход от DSL к машинным кодам надо делать максимально коротким, чтоб сократить количество уровней, в которых "нужно творчество". Мутность и запутаность - удел учёных, которым важно написать докторскую по новейшей системе, а не сделать что-то работающее. Потому и изобретаются и новые названия, и хитроумные решения простых задач.

Короче говоря, признавая принципиальную возможность создания языковых рабочих мест и прочих чудес автоматизации, я всё-таки не считаю, что полезно давать в руки неспециалистов столь мощный и гибкий инструмент. И массы программистов поднимать на абстрактные уровни тоже не стоит.