Первый пример кода на новом языке разработки Dynamics NAV - AL

[Александр Ермаков]

Всех интересующихся приглашаю посмотреть сюда: https://github.com/Microsoft/AL

Сегодня Freddy Kristiansen - один из идеологов разработки Microsoft NAV в Копенгагене - выложил пример кода Hello, World! на AL. А вы что думаете по поводу такого синтаксиса?

Ваше мнение важно. От него зависит, как вы дальше будете кодить ))

[mazzy]

прикольно.
и файл app.json в формате JSON, а не XML...

[Александр Ермаков]

В зарубежной ветке развернулась дискуссия "Давайте BEGIN..END везде заменим на { }"... и вообще сдвинем всё как можно больше в C#повость...

[Predatore]

Цитата:

В зарубежной ветке развернулась дискуссия "Давайте BEGIN..END везде заменим на { }"... и вообще сдвинем всё как можно больше в C#повость...

Солидарен с зарубежными братьями

P.S. Кстати, я что-то не в курсе последних новостей. Этот "новый" язык, это то на чём мы будем кодить в Visual Studio Code, который обещали показать к ихнему рождеству? Или это что-то другое?

[rmv]

Тогда уже Javascript, зачем мелочиться

[Predatore]

Цитата:

Сообщение от rmv

Тогда уже Javascript, зачем мелочиться

И чем же синтаксис Javascript кардинально отличается от шарпового синтаксиса?
Вы же не думаете, что нам вот прям новый язык выкатят, максимум синтаксического сахарку дадут в качестве той же замены BEGIN END на {} и дай Бог, перестанут заставлять ставить двоеточие перед знаком присвоения.
То что нам показали, это всё тот же C/AL, только без устаревшего 20 лет назад интерфейса объявления переменных.

[artkashin]

Цитата:

Сообщение от Predatore

И чем же синтаксис Javascript кардинально отличается от шарпового синтаксиса?
Вы же не думаете, что нам вот прям новый язык выкатят, максимум синтаксического сахарку дадут в качестве той же замены BEGIN END на {} и дай Бог, перестанут заставлять ставить двоеточие перед знаком присвоения.
То что нам показали, это всё тот же C/AL, только без устаревшего 20 лет назад интерфейса объявления переменных.

хм.. интересно, почему этот интерфейс объявления переменных "устарел"? на мой взгляд, это одна из фишечек Нава. И переменные типизированные, и код избавлен от хлама. Это одна из фишек, которая позволяет при соблюдении стандартов разработки просто читать код и понимать, как он работает.
Смотришь код Аксапты, а там 30% строк - объявление переменных, 25-40% - обвертки, в виде try catch и exception и всякими ttsbegin с ttscommit, ну а собственно бизнес-логика в оставшихся 30%, дай бог. И она может быть написана как угодно сложно и зачастую без дебаггера не обойтись - ибо там может быть и переопределенные наследниками методы и прочие плюшки для программистов, которые на самом деле - ад для поддержки.

Я это говорю не в претензию к Акс - там много других плюшек, отсутствующих в NAV, да и не так хорошо я ее знаю - а к тому, что вы недооцениваете эту возможность скрывать объявленные переменные с глаз долой. Наряду с готовыми блоками триггеров, в которых просто остается написать свой код, это - одна из приятнейших особенностей навика. Вам не надо писать кучу кода в каком нибудь методе validateWrite для обработки изменения цены, изменения кучи других полей. Вы всегда можете найти код в onValidate условного "Unit Price".

Все-таки, почему же это считается устаревшим, а смешивание объявления переменных с кодом - модным?
на мой взгляд, тут прямая аналогия с css и html.

[artkashin]

Цитата:

Сообщение от Александр Ермаков

Всех интересующихся приглашаю посмотреть сюда: https://github.com/Microsoft/AL

Сегодня Freddy Kristiansen - один из идеологов разработки Microsoft NAV в Копенгагене - выложил пример кода Hello, World! на AL. А вы что думаете по поводу такого синтаксиса?

Ваше мнение важно. От него зависит, как вы дальше будете кодить ))

Я, к сожалению, еще не смотрел новое чудо юдо. У меня просто вопросы.
Правильно ли я понимаю, что в новом языке мне надо все свойства объекта прописывать руками?
Т.е. не просто как раньше, нажал Shift + F4, нашел нужное свойство, с указанным значением по умолчанию, изменил на требуемое, сохранил объект - запустил- изменения отразились?
я должен руками написать все простановки propeties?

               
 Image = CheckDuplicates;
 PromotedCategory = Category8;

В следующем примере:

codeunit 70051001 HelloWorld
{
    TableNo = Customer;

    trigger OnRun();
    var
        HelloText : Codeunit GreetingsManagement;
    begin
        Message('%1, %2', HelloText.GetRandomGreeting(), Rec.Name);
    end;
}

Мне надо весь этот текст набрать вручную?
Т.е. нельзя как раньше, создать объект, открыть его, в триггере OnRun который для меня услужливо создала среда разработки, открыть список локальных переменных, воткнуть туда HelloText Codeunit GreetingsManagement, а собственно весь видимый код будет состоять из
Message('%1, %2', HelloText.GetRandomGreeting(), Rec.Name)? см. картинку.
P.S. Господи, пусть это будет нормальный объект, просто его выгрузили как текст и нам показывают просто объект, выгруженный в текст.

[Predatore]

Цитата:

Сообщение от artkashin

хм.. интересно, почему этот интерфейс объявления переменных "устарел"? на мой взгляд, это одна из фишечек Нава. И переменные типизированные, и код избавлен от хлама. Это одна из фишек, которая позволяет при соблюдении стандартов разработки просто читать код и понимать, как он работает.
Смотришь код Аксапты, а там 30% строк - объявление переменных, 25-40% - обвертки, в виде try catch и exception и всякими ttsbegin с ttscommit, ну а собственно бизнес-логика в оставшихся 30%, дай бог. И она может быть написана как угодно сложно и зачастую без дебаггера не обойтись - ибо там может быть и переопределенные наследниками методы и прочие плюшки для программистов, которые на самом деле - ад для поддержки.

Я это говорю не в претензию к Акс - там много других плюшек, отсутствующих в NAV, да и не так хорошо я ее знаю - а к тому, что вы недооцениваете эту возможность скрывать объявленные переменные с глаз долой. Наряду с готовыми блоками триггеров, в которых просто остается написать свой код, это - одна из приятнейших особенностей навика. Вам не надо писать кучу кода в каком нибудь методе validateWrite для обработки изменения цены, изменения кучи других полей. Вы всегда можете найти код в onValidate условного "Unit Price".

Все-таки, почему же это считается устаревшим, а смешивание объявления переменных с кодом - модным?
на мой взгляд, тут прямая аналогия с css и html.

Всё очень просто. Спрятанное объявление переменных спрятано. Уж простите за тавтологию и капитанство.
Ну а теперь почему это так плохо. Начнём с того что это примерно в 2-3 раза увеличивает время объявления переменных. При этом не получается, как Вы выразились "просто читать код", потому что не понятно что за переменные, локальные они или глобальные, да и переменные ли? А может поля? Или даже функции? Именование частично решает это проблему, но порождает другую, имена становятся перегруженными, а хуже того, в коде плодится и множится винегрет из "стандартов разработки".
И почему "смешивание"? Объявление переменных это тоже код, его тоже нужно читать, а ещё не плохо бы по нему искать и править его, что опят таки невозможно с такой "фишкой". И такой код, это не модно, это удобно, быстро и легче поддерживать.
А если Вас пугает ручной набор, так Вы видимо никогда не кодили в Студии. Я кроме прочего пишу и на шарпе тоже, так вот, в Студии я в ручную набираю на 70-80% меньше чем в НАВ. А на объявление переменных я трачу и того меньше времени.
Фантастика? Вовсе нет, просто редактор даже 2016-ого (2017 пока ничем не отличается, но держим кулачки) НАВа устарел ещё 20 лет назад. И слава Богу его отправляют на покой.

[artkashin]

Цитата:

Сообщение от Predatore

Ну а теперь почему это так плохо. Начнём с того что это примерно в 2-3 раза увеличивает время объявления переменных.

хм. Вот вы утверждаете в 2-3 раза увеличивает. А я говорю, сокращает в 2-3 раза, особенно, если вы пишете код функции или объекта который не помещается на одной странице. Ctrl-G (Ctrl-L), F3, имя переменной, тип. Готово к использованию. Курсор при этом ни на секунду не изменил своего положения. Продолжаешь писать код в том же месте.
Да, справедливости ради, Ctrl-G появился в NAV2016. Раньше была магическая комбинация alt-V + 3-4 клавиши вверх.
В любом случае, при разработке, мышка не используется - если речь идет не об отчетах. Производительность без использования мышки, если что, обычно в разы выше чем с ней.
Чтобы объявить переменную в студии, извините, но во избежание бардака вам придется идти в начало метода/функции и объявлять ее там. А потом возвращаться обратно. Все равно выделяется место где эти переменные объявляются (обычно, в начале). А объявлять переменные вперемежку с кодом в большинстве случаев не комильфо, даже если язык программирования вам это позволяет. И пусть это тоже можно сделать без мышки, но потеря фокуса - при разработке - это как потеря концентрации.

Цитата:

Сообщение от Predatore

При этом не получается, как Вы выразились "просто читать код", потому что не понятно что за переменные, локальные они или глобальные, да и переменные ли? А может поля? Или даже функции? Именование частично решает это проблему, но порождает другую, имена становятся перегруженными, а хуже того, в коде плодится и множится винегрет из "стандартов разработки".

Стандарты разработки, хотите вы того или нет, будут всегда, если вы не работаете один. Правильное именование объектов, все-таки, позволяет читать код без проблем. SalesInvHeader - это, извините, таблица 112. А если какой-то нехороший человек написал, что это boolean, то конечно это факап, и расстрелять надо такого нехорошего человека. Это тоже самое, что в Cях

#define TRUE FALSE

В любом случае, стандартный код "читается" легко.

Цитата:

Сообщение от Predatore

И почему "смешивание"? Объявление переменных это тоже код, его тоже нужно читать, а ещё не плохо бы по нему искать и править его, что опят таки невозможно с такой "фишкой". И такой код, это не модно, это удобно, быстро и легче поддерживать.

Вопрос в частоте. Вам часто приходится править определение типа переменных?
Выгрузите объект в текст - ищите, правьте там. Ведь по-сути, весь этот новый AL - это объекты, выгруженные в текст. Отличий - минимум. Только, если раньше структуру этого текстовичка среда Нава поддерживала сама, теперь это предлагается переложить на мои плечи.
А в моей практике, изменить тип переменной требуется крайне редко и к подобной процедуре я прибегаю дай бог, раз в полгода.
А насчет "быстро и легче поддерживать". Каждому - свое.

Кстати, могли бы просто добавить к текущему виду кода возможность просмотра/правки объекта в текстовом виде, не выходя из редактора кода - и вашим и нашим.
Т.е. смотришь на стандартное окошко с кучей триггеров на таблице onValidate, 99% из которых - пусты, щелкаешь какой-нибудь Ctrl-T, и рядышком открывается этот же объект, но в тексте.

Цитата:

Сообщение от Predatore

А если Вас пугает ручной набор, так Вы видимо никогда не кодили в Студии. Я кроме прочего пишу и на шарпе тоже, так вот, в Студии я в ручную набираю на 70-80% меньше чем в НАВ. А на объявление переменных я трачу и того меньше времени.

Я полагаю, что все когда-то да кодили в студии.
Меня пугает, что появляется возможность ручного набора там, где было все жестко фиксировано, и меня,например, эта жесткая фиксация устраивала - она увеличивала мою производительность. И сильно.
Там где можно руками набрать, можно руками и не набрать, или набрать неправильно.
Что будет, если я не напишу в codeunit из примера триггер OnRun? или назову его OnWalk?

trigger OnRun();

Триггер OnRun может быть написан в середине КЮ из ста функций? Мне его искать надо будет? он не всегда будет в начале?
что будет, если я напишу (CODEUNIT.RUN(70051001, Customer) а триггера OnRun нет? Runtime error?

Цитата:

Сообщение от Predatore

Фантастика? Вовсе нет, просто редактор даже 2016-ого (2017 пока ничем не отличается, но держим кулачки) НАВа устарел ещё 20 лет назад. И слава Богу его отправляют на покой.

Меня пугает то, что предлагают в замен. Красивую студию, но работать придется сугубо с текстовичком? Посмотрим, конечно.
Среда разработки устарела, это безусловно, я с этим и не спорил.
Хотя меня, в большинстве случаев, она, на удивление, устраивала.
И вот интерфейс объявления переменных - это как раз то, чему Студии надо Учиться у навика, а не наоборот.

[Predatore]

Ну что ж, давайте по пунктам.

Цитата:

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

Во-первых, не нужно писать функции не помещающиеся на одной странице, а в объектах по возможности не нужно использовать глобальные переменные. В c#, к слову, вообще отсутствует понятие глобальной переменной, ну это так, к слову.

Цитата:

Ctrl-G (Ctrl-L), F3, имя переменной, тип. Готово к использованию. Курсор при этом ни на секунду не изменил своего положения. Продолжаешь писать код в том же месте.
Да, справедливости ради, Ctrl-G появился в NAV2016. Раньше была магическая комбинация alt-V + 3-4 клавиши вверх.

Я не против рассматривать NAV2016, хотя по сути большинство до сих пор сидит на 2009. Но давайте посмотрим на магические комбинации в Студии. Только давайте ещё затронем объявление функций, так веселее будет.
И так, как это выглядит в Студии? В Студии я просто пишу код и если в нём у меня появляется не объявленная ранее переменная, то я нажимаю магическую комбинацию "Ctrl+." и выбираю лишь где мне нужно создать переменную, в 99% случаев мне даже тип не нужно указывать, т.к. он вычисляется из контекста. Таким же способом объявляются и функции. Т.е. просто пишется вызов, передаются параметры, а потом Ctrl+. и функция создана! В неё ещё заботливо помещается Error, на случай если Вы вдруг забудете её реализовать. Не только курсор не двигается, Вы вообще не покидаете места где кодите, ни на долю секунды нет отвлекаетесь от кода.

Цитата:

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

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

Цитата:

Стандарты разработки, хотите вы того или нет, будут всегда, если вы не работаете один. Правильное именование объектов, все-таки, позволяет читать код без проблем. SalesInvHeader - это, извините, таблица 112. А если какой-то нехороший человек написал, что это boolean, то конечно это факап, и расстрелять надо такого нехорошего человека.

Я не против стандартов, я вовсе даже за, но стандарты в NAV, это как в анекдоте про 15 стандартов, давайте придумаем единый стандарт, теперь у нас 16 стандартов. Но и к правильному именование Вы как-то однобоко подошли. Вот Type это что, поле или переменная? А IsActive, это поле, переменная или функция?

Цитата:

Вопрос в частоте. Вам часто приходится править определение типа переменных?
Выгрузите объект в текст - ищите, правьте там.

Вопрос с подвохом В Студии я часто меняю имена переменных, в NAV почти никогда. А всё потому что изменить имя переменной или функции в Студии это Ctrl+R+R. Во что превращается переименование в NAV я думаю не надо рассказывать. Выгружай в текст и танцуй с бубном. А ещё в Студии я могу отсортировать переменные по типу, по имени, по типу и имени, ну и ещё по уровню доступа, что не актуально в NAV. Могу даже drag'n'drop-ом переставлять местами как переменные так и функции.

Цитата:

А насчет "быстро и легче поддерживать". Каждому - свое.

Вот тут-то Студия и ставит шах и мат. Давайте опять вспомним про стандарты. В них ведь прописано где и как ставить BEGIN END, как писать комментарии и многое другое из оформления. И если Вы не согласны со стандартом, у Вас всего 2 варианта: 1 - быть упёртым бунтарём; 2 - смириться. Студия же предлагает 3-ий вариант. Я открываю Ваш код, нажимаю волшебную комбинацию Ctrl+M+Space и магия, код отформатирован так как МНЕ удобно. Есть и возможность отформатировать его в соответствии со стандартом команды. Поработал в том виде, как тебе удобно, перед тем как вернуть, отформатировал по стандарту.

Цитата:

Кстати, могли бы просто добавить к текущему виду кода возможность просмотра/правки объекта в текстовом виде, не выходя из редактора кода - и вашим и нашим.
Т.е. смотришь на стандартное окошко с кучей триггеров на таблице onValidate, 99% из которых - пусты, щелкаешь какой-нибудь Ctrl-T, и рядышком открывается этот же объект, но в тексте

Возможно так и будет, мы пока не знаем как всё это будет выглядеть. Будет хорошо если и вашим и нашим.

Цитата:

Я полагаю, что все когда-то да кодили в студии.

Написать Hellow World в Студии и работать в Студии не одно и тоже, иначе все бы знали о тех плюшках о которых я толкую.

Цитата:

Меня пугает, что появляется возможность ручного набора там, где было все жестко фиксировано, и меня,например, эта жесткая фиксация устраивала - она увеличивала мою производительность. И сильно.
Там где можно руками набрать, можно руками и не набрать, или набрать неправильно.
Что будет, если я не напишу в codeunit из примера триггер OnRun? или назову его OnWalk?

Мне вот больше пугает что в NAV в кодеюните я могу назвать функцию OnRun и это, чёрт побери, скомпилится! И даже работать будет! Возможно не так как ожидается, но будет! А хуже нет греха в программирование, чем когда код делает не то, что в нём написано.
Ну ладно, давайте по теме, что если я в шарпе не правильно напишу имя конструктора? Ммм... наверное у меня не будет конструктора. А чем это грозит? Ну наверное я не смогу его вызвать, потому что его нет. Так? Нет, не так, Студия не даст мне ошибиться в имени конструктора. Ну ладно, а что если я вообще не напишу конструктора? Да и пожалуйста, будет конструктор по умолчанию. Ну вот так всё просто на самом деле.
И мне правда интересно, каким образом жёсткая фиксация увеличивала Вашу производительность? Уже прописанные триггеры? Серьёзно? Ну тогда Студия тоже так умеет, кодогенерацию никто не отменял, только возможностей больше.

Цитата:

Триггер OnRun может быть написан в середине КЮ из ста функций? Мне его искать надо будет? он не всегда будет в начале?

Там выше про сортировку и форматирование найдите пожалуйста.

Цитата:

что будет, если я напишу (CODEUNIT.RUN(70051001, Customer) а триггера OnRun нет? Runtime error?

Зачем Runtime error? Во-первых триггер OnRun есть, даже если его не написали, хотя бы потому что это триггер, а не обычная функция (вспоминаем историю с конструктором). Во-вторых, если его вдруг не окажется, всё зависит от реализации вызова. В любом случае, либо триггер будет, либо будет ошибка компиляции.

Цитата:

Меня пугает то, что предлагают в замен. Красивую студию, но работать придется сугубо с текстовичком? Посмотрим, конечно.
Среда разработки устарела, это безусловно, я с этим и не спорил.

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

Цитата:

И вот интерфейс объявления переменных - это как раз то, чему Студии надо Учиться у навика, а не наоборот.

Чур меня, чур меня! Самое главное достижение перехода, это отказ от интерфейса объявления!

[artkashin]

Цитата:

Сообщение от Predatore

Я не против рассматривать NAV2016, хотя по сути большинство до сих пор сидит на 2009. Но давайте посмотрим на магические комбинации в Студии. Только давайте ещё затронем объявление функций, так веселее будет.
И так, как это выглядит в Студии? В Студии я просто пишу код и если в нём у меня появляется не объявленная ранее переменная, то я нажимаю магическую комбинацию "Ctrl+." и выбираю лишь где мне нужно создать переменную, в 99% случаев мне даже тип не нужно указывать, т.к. он вычисляется из контекста. Таким же способом объявляются и функции. Т.е. просто пишется вызов, передаются параметры, а потом Ctrl+. и функция создана! В неё ещё заботливо помещается Error, на случай если Вы вдруг забудете её реализовать. Не только курсор не двигается, Вы вообще не покидаете места где кодите, ни на долю секунды нет отвлекаетесь от кода.

Спасибо. Ctrl+. да - удобно. Не знал. Это не отменяет того факта, что скрытие переменных, для меня, благо. Но это уж, каждому свое.

Цитата:

Сообщение от Predatore

Написать Hellow World в Студии и работать в Студии не одно и тоже, иначе все бы знали о тех плюшках о которых я толкую.

... проскипано....

И мне правда интересно, каким образом жёсткая фиксация увеличивала Вашу производительность? Уже прописанные триггеры? Серьёзно? Ну тогда Студия тоже так умеет, кодогенерацию никто не отменял, только возможностей больше.

Насчет кодогенерации, я согласен, возможностей навалом.
Да, студия не является моей основной средой разработки. Поэтому, приходилось вот ручками переменные заводить - на один батхерт меньше будет. На самом деле, было бы неплохо завести тему, где можно будет обмениваться старыми трюками, и как такое же сделать быстро в Студии, или если это делается вообще по другому, то как.
типа комбо для классической формы "Ctrl-F2, Shift-F4, s, s, Tab, Ctrl-C, Shift-F12, Alt-B, tab, Ctrl-V, Enter, Alt-D".. ну а дальше уже по желанию.
А там я буду приводить по мере свободного времени и желания, что я подразумеваю под реально быстрой разработкой в наве.

[artkashin]

Потестил я эти экстеншны. Ну что же. Выдумал Студио Коде - это такой Notepad++ с возможностью билда и разворачивания extentions. Быстрый, легковесный редактор кода. Билд и разворачивание - реально быстро.
На этом его плюсы и заканчиваются. К классическому понятию Visual Studio отношения не имеет никакого - эксплуатация бренда.

Но в целом, сама технология забавна.
В картинках видно, что после деплоя меняется карточка клиента (добавляется экшн и код)
Но из классического клиента это изменение кода не видно от слова вообще. ну или я пока не понял как его можно увидеть. Кодеюнита 70051001 HelloWorld в таблице объектов тоже нет. Как это счастье дебажить, тоже пока под большим вопросом.
Так что, никто классический клиент не заменяет. Покрайней мере, на текущий момент.

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

[rmv]

Цитата:

Сообщение от Predatore

И чем же синтаксис Javascript кардинально отличается от шарпового синтаксиса?
Вы же не думаете, что нам вот прям новый язык выкатят, максимум синтаксического сахарку дадут в качестве той же замены BEGIN END на {} и дай Бог, перестанут заставлять ставить двоеточие перед знаком присвоения.
То что нам показали, это всё тот же C/AL, только без устаревшего 20 лет назад интерфейса объявления переменных.

Дело не в синтаксисе, а в языках. Один со строгой типизацией, другой нет.
В одном я использую замыкания и в функции высших порядков, в другом ООП.
Лично меня сдвиг бизнес-логики Нава в парадигму наследования ООП совершенно точно не порадует - на мой взгляд у бизнес-объектов общими могут быть только методы логирования и доступа к данным.
Так что текущие ограничения вполне закономерно определяют и возможности разработчиков обойти стандарты и сломать систему - вспомните к примеру жаркую дискуссию по поводу try..catch с возможностью продолжить выполнение кода после отката транзакции.
Хотя честно говоря иногда очень хочется написать что-то вроде
addEvent(table, 'modify', function(event) { dispatch(event) });
или
addEvent(form, 'keyUp', function(event) { dispatch(event) });

[Predatore]

Цитата:

Сообщение от rmv

Лично меня сдвиг бизнес-логики Нава в парадигму наследования ООП совершенно точно не порадует - на мой взгляд у бизнес-объектов общими могут быть только методы логирования и доступа к данным.
Так что текущие ограничения вполне закономерно определяют и возможности разработчиков обойти стандарты и сломать систему - вспомните к примеру жаркую дискуссию по поводу try..catch с возможностью продолжить выполнение кода после отката транзакции.
Хотя честно говоря иногда очень хочется написать что-то вроде
addEvent(table, 'modify', function(event) { dispatch(event) });
или
addEvent(form, 'keyUp', function(event) { dispatch(event) });

Ещё у них могут быть общими представления. Вам серьёзно не кажется, что одни и те же печатки для учтёнки и не учтёнки, это не совсем правильно? Особенно учтивая что их нужно поддерживать параллельно!
Логика тоже может быть общей. Меня вот вымораживают абсолютно одинаковые функции для Клиентов и Поставщиков, которые опять же нужно параллельно суппортить.
Я видимо не застал жаркой дискуссии по поводу try..catch, но свято уверен что такая конструкция нужна. Нужны примеры? Их есть у меня. Если сидеть в песочнице, то хотя бы для того что бы залогировать ошибку. Ну а если мы выходим в люди, то это просто must have. Делаем отчёт в Excel, отчёт упал, Excel остался болтаться в памяти. Создаём подключение к любому внешнему источнику, что-то идёт не так и подключение остаётся висеть. Ну и т.д. и т.п. В M$ видимо тоже это понимают, поэтому вроде как с 2016 версии появился аналог (в NAV2017 точно есть) под названием TryFunction.
Ну и ещё, тут в соседней ветке обсуждают что же делать если код закроют? ООП может решить 90% проблем которые при этом могут возникнуть. Придётся конечно учиться этим пользоваться, ну так, прогресс не стоит на месте, и что бы нам оставаться на месте нужно бежать, а если мы хотим куда-то попасть, то бежать надо очень быстро.