Дело в том, что при динамической типизации как раз и не получится "просто" поменять имена методам, свойствам и классам, невозможно будет найти все места, где они используются.
А если ещё учесть возможности выполнения произвольной текстовой строки и всякие функции вроде $property, то совсем всё плохо становится.
С именами локальных переменных несколько проще. Но если вспомнить, что переменные могут иметь глобальную область видимости, то опять становится грустно.
Плюс ещё дикая смесь разных надстроек одного над другим. Одни CSP чего стоят, что сама Intersystems от них открещивается, а добавьте туда ещё CSR.

Сколько уж нам обещали отдать грамматики хотя бы, но нет. Сейчас опять что-то пообещали, но что неизвестно.
Во времена разработки Atelier уже существовал протокол для языкового сервера, который можно было использовать и в эклипсе и в VSCode. Могли хотя бы сейчас взять наработки Atelier и сделать языковой сервер, чтобы каждый мог использовать его в своих решениях.
Нормального api для развёртывания через CI тоже нет. Попробуйте большой проект скомпилировать через API Atelier и словите таймаут.

В тех же исходниках Atelier, насколько я понимаю, как раз есть парсер ObjectScript. Т.е. можно было бы взять этот парсер и сделать Language Server.
ZPM мало подходит для загрузки кода проекта из git-репозитория. У API Atelier в этом плане есть плюс, в виде единообразного способа загрузки кода, но минус в компиляции больших проектов, т.к. это обычный http запрос и у него есть таймаут.
Больше всего проблем доставляют CSP, очень много нюансов их загрузки и компиляции.

Не совсем точно наверное описал ситуацию.
Для разовой и первоначальной загрузки проекта ZPM наверное подойдёт, но вот для постоянных ежедневных, а то и по несколько раз в день, обновлений кодовой базы уже как-то странно выглядит. Тем более обновление всего проекта в продуктовой среде - фактически остановка его на какое-то время, что тоже очень плохо.
API Atelier - как минимум тот инструмент, который работает в системе из коробки, не нужно предварительно ничего устанавливать. Ещё плюс - это одинаковая работа в разных ОС. Те же терминалы работают по-разному и в контейнерах для windows это ограничивает возможности.

Мы как раз и обновляем только то, что изменилось. Я говорил про то, что ZPM такого функционала не даст.


А вот тут как раз и возникают проблемы и в первую очередь с CSP, через эти методы просто нельзя импортировать их как положено. Да, для CSP есть отдельные методы импорта, но сначала их нужно скопировать в каталог приложения, не забыв переконвертировать в CP1251, потому что в этих методах не посчитали нужным добавить параметр кодировки.
В общем основную боль вызывают конечно CSP, с ними всегда не просто, включая веб-приложения для них.

К тому же в Cache мы использовали cache.exe для выполнения COS, в IRIS эту возможность похоже убрали.

Но это же не аргумент, если кто-то не использует этот функционал, то это не значит, что он не нужен в принципе.
Невозможно архитектуру продумать на несколько десятков лет вперёд, тем более, что сам ObjectScript менялся и подходы тоже.

Да, через irisdb.exe работает.


Это тоже работает.
Спасибо за информацию.
Плохо что такую информацию очень сложно найти и опять же нет единообразия в подходах.

Можно было бы сделать какой-нибудь строгий режим, чтобы внедрить статическую типизацию, убрать лишнее, упростить грамматику и т.д.
Тут бы конечно вместо embedded sql добавить в ObjectScript LINQ как в C#, чтобы всё через объекты делать.

Тут дело не в динамическом исполнении ESQL. Это я писал в привязке к статической типизации, в LINQ это очень хорошо работает.
Готовимся к переходу на IRIS, в 2020.1 выявили ошибки в SQL, которые при компиляции не обнаруживались. И чтобы поймать ошибки в написанном SQL, нужно добавлять новый флаг, с которым этот SQL тоже компилится сразу (а не в рантайме) и выдаёт ошибки, если что-то некорректно.

Там другая библиотека есть готовая Using the Entity Framework Provider


Для каких-то целей неплохо, но опять легко можно ошибиться в названиях полей, классов и т.д. Для больших проектов мало подходит.