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

[metaclass]

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

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

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


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

Comments

[adews.livejournal.com]

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

[sbj-ss.livejournal.com]

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

[1ceheart.livejournal.com]

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

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

Уродыбля.

[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.

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

[ex-chistyak.livejournal.com]

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

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

[leadmd.livejournal.com]

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