Я бы так ответил: система, у которой имеется внутренний язык - это по существу платформа, на которой разрабатываются прикладные решения. Система, у которой внутреннего языка нет или он мало функционален - это и есть собственно прикладное решение. Или юзайте его as is, или платите бабло разработчику за переделку...

Простой пример: документ "Закрытие месяца" при проведении выдает:
Или я лезу во встроенный язык, нахожу там
и меняю на

Или я звоню разработчикам и получаю от них обещание сделать более подробное сообщение в следующем релизе... Ну, или быстрее, при условии оплаты 5 000 баксов.

Или я беру любимый дизассемблер и за пару месяцев делаю всё сам.

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

Ответ: если ты нормальный разработчик системы, то делать такой внутренний язык не только не надо, но и вредно. Закрой исходный код, предусмотри простенькие возможности визуального конфигурирования, кривой API (желательно возвращающий ссылки на объекты VCL), встроенную выгрузку в Ексел и наслаждайся заключением дополнительных соглашений на доработку системы.

Если ты честный разработчик системы, или тебе придется работать над её поддержкой, нужно предусмотреть по-любому следующее:
а) Нормальная библиотека прикладных объектов и API к ней

и одно из следующих:
а) открытый исходный код системы или хотя бы тех частей, которые напрямую взаимодействуют с пользователями (интерфейсы форм и отчетов) и реализуют бизнес-логику;
б) нормальный Active-Xный API;
в) нормальный встроенный интерпретатор языка, будь то ActiveX Scripting (Визуал Васик там, ЖабаСкрып и т.д.) или свой собственный, главное, что он легко работает с бизнес-объектами (т.е. умеет выполнять операции типа
).

А также обязательно следующее:
а) Нормальное описание языка и объектов бизнес-логики с примерами.
б) Нормальный, не кривой редактор кода с интеллисенсом и контекстным хелпом.

Если система пишется на Java, то class-файлов с бизнес-логикой (нормально декомпилируемых) и хорошего описания библиотеки будет достаточно.

А уж будет там написано Товар.Цена или Nom.Price, не столь важно... Мы люди грамотные, разберемся.

автор
Отсутствие внутреннего языка никак не сказывается на том, является
платформа прикладным решением или нет.
Posted via ActualForum NNTP Server 1.3


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

автор
Гм... И каким образом, если не секрет???

Вся аргументация в моем посте 30 января 17:57. Читай выше.

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


Прикладную систему обслуживает (вернее, дорабатывает) не пользователь, а прикладной программизд-конфигураст. Предложи любой другой (не связанный с внутренним языком) способ быстро и недорого доработать купленную прикладную систему с закрытым исходным кодом.

Возможно, я неправильно понял топик. Вопрос для меня не в том, нужен в системе собственный язык или можно обойтись C++/NET/Pascal и т.д. Вопрос в том, чтобы код, реализующий бизнес-логику, был открытым. А на чем он написан (хоть на Фортране, хоть на PL/I), не так важно.

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