Всем гуру птичьих языков посвящается

[metaclass]

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

Корпоративный движок правил

Мягкое кодирование


Особенно, бля, это касается разработчиков всякого ненавидимого нами enterprise-говна. С вашими долбаными поделками потом десятки лет люди мучиться будут.

Comments

[adews.livejournal.com]

Главное не нервничать ;-)
И стремиться к простоте...

[sbj-ss.livejournal.com]

..и это говорит разработчик фреймворка, на котором с большего можно создавать приложения, не написав ни строчки кода :-Р

[1ceheart.livejournal.com]

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

Это еще хорошо, если этот птичий язык имеет текстовое представление, которое либо грузится в контроллер напрямую, либо компилится в байт-код. Некоторые выдают счастливому разработчику GUI, в котором нужно стрелочками соединять квадратики и типа таким чудным образом программировать. Причем компилится все в итоге в тот же байт-код, но формат, разумеется, закрытый.

Уродыбля.

[nvm.livejournal.com]

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

[metaclass.livejournal.com]

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

[nvm.livejournal.com]

я знаю чем бы кончилось. Накопилась бы критическая масса расширений, а потом кто-нибудь сделал бы своё ядро, совместимое по API, но лучше или дешевле, и разработчики 1с пошли бы по миру.

[nvm.livejournal.com]

то есть путь неадеквата -- это как раз путь, по которому надо идти до конца, или уж не вставать на него. Останавливаться на этом пути нельзя, иначе вылетишь с рынка :)

[metaclass.livejournal.com]

Да, что-то вроде этого :)

[1ceheart.livejournal.com]

> И в принципе достаточно удобно

Это удобно, пока реализуемая логика не выходит за уровень "если сработал датчик 1, открыть клапан 2". Реализация чего-то чуть более сложного превращается в адскую пытку, а поддержка и внесение изменений - вообще невозможны в принципе, хотя бы потому, что квадратикам со стрелочками нельзя сделать diff.

А птичий язык для постпроцессинга G-кода для ЧПУ? Это же пиздец. Конфиг sendmail нервно курит в углу.

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

[metaclass.livejournal.com]

+1
Визуальные и прочие бинарные языки не пригодны для контроля версий. Совсем.

Я все таки очень надеюсь, что их всех отправят пылесосить цеха Железногорского ГХК от плутониевой пыли.

[nvm.livejournal.com]

так надо стрелочки с квадратиками хранить в xml!

[metaclass.livejournal.com]

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

По-моему, все поставщики сложных систем производственного назначения поняли что "делать хорошо" - плохая бизнес-модель. Потому что нормально сделанная система гораздо меньше нуждается во внимании, чем сделанная плохо. А внимание - это деньги для вендора и его партнеров.

[nvm.livejournal.com]

>>Это удобно, пока реализуемая логика не выходит за уровень "если сработал датчик 1, открыть клапан 2".
так в 95% случаев это и надо.
>>Реализация чего-то чуть более сложного превращается в адскую пытку
в основном это из-за убожества контроллерного железа, которое птичьи языки добросовестно и отражают.
>>квадратикам со стрелочками нельзя сделать diff
да, это проблема.

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

[1ceheart.livejournal.com]

> так в 95% случаев это и надо.

В 95% случаев это надо на первом этапе. Потом приходит заказчик (технолог, инженер, не суть) и говорит - а вот мы тут подумали и решили сделать так, чтобы клапан 2 открывался не сразу после срабатывания датчика 1, а через 15 секунд и только если ручка 5 повернута в положение 4, а если за 30 секунд до этого была нажата кнопка 3, то бла-бла-бла. И люди начинают сношаться с квадратиками и стрелочками, воплощая на 20 страницах картинок то, что выражается пятью строками кода.

> а чтобы он ещё мог кодить на С -- уже гораздо тяжелее, и платить ему придётся дикие деньги

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

А люди, которые когда-то нарисовали 20 страниц квадратиков со стрелочками и их теперь приходится держать в штате только потому, что они хотя бы частично помнят, как это работает, обходятся в итоге дороже.

[sbj-ss.livejournal.com]

Да, кстати, процитирую Фоулера. Хорошие идеи.

A separate but often conflated issue is whether to use configuration files or code on an API to wire up services. For most applications that are likely to be deployed in many places, a separate configuration file usually makes most sense. Almost all the time this will be an XML file, and this makes sense. However there are cases where it's easier to use program code to do the assembly. One case is where you have a simple application that's not got a lot of deployment variation. In this case a bit of code can be clearer than separate XML file.

A contrasting case is where the assembly is quite complex, involving conditional steps. Once you start getting close to programming language then XML starts breaking down and it's better to use a real language that has all the syntax to write a clear program. You then write a builder class that does the assembly. If you have distinct builder scenarios you can provide several builder classes and use a simple configuration file to select between them.

I often think that people are over-eager to define configuration files. Often a programming language makes a straightforward and powerful configuration mechanism. Modern languages can easily compile small assemblers that can be used to assemble plugins for larger systems. If compilation is a pain, then there are scripting languages that can work well also.

It's often said that configuration files shouldn't use a programing language because they need to be edited by non-programmers. But how often is this the case? Do people really expect non-programmers to alter the transaction isolation levels of complex server-side application? Non-language configuration files work well only to the extent they are simple. If they become complex then it's time to think about using a proper programming language.

One thing we're seeing in the Java world at the moment is a cacophony of configuration files, where every component has its own configuration files which are different to everyone else's. If you use a dozen of these components, you can easily end up with a dozen configuration files to keep in sync.

My advice here is to always provide a way to do all configuration easily with a programmatic interface, and then treat a separate configuration file as an optional feature. You can easily build configuration file handling to use the programmatic interface. If you are writing a component you then leave it up to your user whether to use the programmatic interface, your configuration file format, or to write their own custom configuration file format and tie it into the programmatic interface.

[metaclass.livejournal.com]

Ага, это я тоже читал, но забыл к ссылкам в посте добавить :)

Вот и подумаешь...

[ex-chistyak.livejournal.com]

И зачем вообще программирование придумали, если боятся программы изменять? И чем "движок" не программирование, только через жопу?

Пишите на Дельфи, и многие проблемы такого типа просто не возникнут. И громоздить не надо. Попроще, попроще...

[leadmd.livejournal.com]

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

[metaclass.livejournal.com]

Отлаживаться заумно малость будет, но мне эта идея в голову тоже приходила, тем более, что фреймворк с собой компилятор тянет.

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