Ну что, даешь девопс от 1С!
https://wonderland.v8.1c.ru/blog/1c-ispolnitel/

Интересно компилятор а не интерпретатор 1С пользовался бы спросом?
Нечто по типу Golang чтобы в бинарники достаточно шустрые и компактные.

(301) Ты представляешь, сколько какая-нибудь УТ11 собираться будет? Кнопку подвинул и на 2 часа компиляции

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

Наверное это всё будет в FreeRAD

(299) я потестил ванскрипт и перешел на него с баша

(302) Ну проекты на C# собираются не так уж и долго. Правда как правило куча библиотек, которые не изменяются.
Проблемы времени компиляции обычно с C++ со специализацией шаблонов. Но в том же .Net компиляция двойная сначала в байт код, затем джитится в машинный.
Есть .Net Native это UWP. Там уже используется С++ компилятор и хорошо оптимизируется в том числе с использованием  SIMD инструкций. Да компиляция более долгая. Но не 2 часа.
1С по уму нуно переходить на сборку мусора. Тот же .Net Native хотя и компилируется сразу в машинный код, но сборка мусора такая же как и в среде .Net

(305) какие плюсы?

(306) быстро - это борландовский компилятор турбо-паскаля... на ХТ компиляция летала!!!

(308) хм.. кто сейчас помнит про борланд...

(309) вот прикинь, в прошлой конторе было в штатном 3 вакухи дельфинов (дельфи).

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

(311) Смотря какому бизнесу.

Который пользуется 1С даст лишние расходы в обмен на фирменность от производителя.
А бизнесу по продаже 1С вытеснение бесплатного OneScript и замена на коммерческий Экзекутор

(312) С другой стороны зайду - что даёт бизнесу ОСкрипт?
Это не стёб, я просто пытаюсь понять, что на этих штуках можно сделать такого, что бы директор такой сказал "Вах! На тебе денег на новый доширак!"

(313) Автоматизация различных операций с серверами, базами 1С, платформами 1С и юзверями.

(314)+ Ну например юзер заводится в домен - и автоматом скрипт прописывает его во все нужные базы 1С.
Или не во все а по шаблону от подразделения/должности в базе ЗУПа.

Короче примеров дофига, юзер в отпуске/уволен - автоматом учетка в 1С блочится.

А интерфейсная часть у ОСкрипта есть? Что-то читаю и пока там только консоль попадается. Понимаю, что это из разряда фантастики, но может там можно сделать, например, получение простого отчёта без 1С? Начальнику зачем вся платформа, если он только ексель разглядывает?
Более предметно: Можно через ОСкрипт сделать так, что бы было какое-то предупреждение за 2 дня до дня рождения главного бухгалтера?

Я до сих пор нигде не нашел главного: этот Испольнитель требует какие-то лицензии или нет?

Ещё вопрос: если 1С:Исполнитель пойдёт в народ, то он не заглохнет по причине "он не приспособлен для жизни", "тяжёлый зараза", "дорогой слишком хад" или ещё из-за чего либо?
И какие перспективы у ОСкрипта в плане живучести?

(316) https://oscript.io/docs/page/libraries
https://github.com/oscript-library

есть интерфейсная хотя она нафик не нужна

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

(318) у ОСкрипта лично для меня только один недостаток - оно на C#/.Net написано, вместо чего то более низкоуровневого и легко переносимого.
Вот если 1С:Исполнитель в этом плане лучше и будет развиваться то вполне пойдет в народ.
Лицензирование думаю там не будет сильно напряжное ибо есть бесплатный опенсурсный конкурент.

А насчет живучести ОСкрипта то все зависит от поддержки и развития автором и сообществом. Если там будут фишки лучше чем в Исполнителе то почему оно сразу загнется.

(320) Хотя 1С:Исполнитель нифига в этом плане не лучше - он требует установки JRE

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

(320) >> Если там будут фишки лучше чем в Исполнителе то почему оно сразу загнется.
Как обычно, станет скучно без денег.
А вот прослойка из C# сразу всё портит. Значит опасно глядеть в сторону этих скриптов

(322) Прослойка из Java ничуть не лучше

Я бы предпочел "исполнитель" с исходниками на Go или Rust

(320) главная фишка оскрипта - язык 1с. 1сЖисполнитель - это адовый адок.

(323) Именно так и есть. Поэтому пока что остаюсь на PureBasic-е. Просто, мелко и быстро. Для мелких вещей самое оно.
Правда там трудно разобраться другому без опыта, но это уже не обсуждается

(325) PureBasic для меня имеет фатальный недостаток - денег хотят
На синтаксис глубоко мне пофиг банально есть аналоги для меня в виде Lazarus или Golang

(326) >> фатальный недостаток - денег хотят
В точку! За 800 строк многое не сделаешь, но для мелкотни почему бы и нет.
Но С++ слишком тяжёлый для мелкого, fasm вообще неподъёмный

(324) "язык 1с" уже пожил своё

(328) ну если и обновлять, то явно не на то что в 1с:исполнитель же

(320) Вот чем тебе C# то не угодил?
Насчет низкоуровнего. Например Unity компилируют C# в нативный код. Есть .Net Native, CoreRT.
Сейчас работает под любые платформы. И ускоряется https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/

После перехода на кроссплатформенность язык и платформа нехило развиваются. Плюс Блазор итд.
Так, что .Net сейчас одна из самых перспективных платформ.
(322) И чем же это портит? Как раз в этом то и есть преимущество.
Кроме того .Net можно использовать в 1С напрямую.

(320) Не загнется, точнее если изагнется то не сразу.
там на оскрипте уже туева куча легаси живет, так как разумной альтернативы долгое время не было.

(319) Дело даже не в батниках.
на оскрипте удобненько и есть мощные либы.

(330) C# мне нравится как и сами классы .Net - это один из лучших языков и прекрасные фреймворки.
Не нравятся приколы (ой нужная версия .Net не стоит, ой ее нету для этой устаревшей операционки и т.д.) и глюки (все стоит что тебе надо какого хрена глючишь) разные.

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

(333) Ну их сейчас 3 штуки. .Net 3.5 под XP, .Net 4.5-4.8 под Win 7 и выше.
И Core под Win 7 и выше. При этом в Core в отличии от фреймворка нет GAC и можно настроить автономное развертывание.
При публикации автономного развертывания (SCD) пакет SDK для .NET Core создает исполняемый файл для конкретной платформы. Публикация SCD включает в себя все необходимые файлы .NET Core для запуска приложения, но не включает машинные зависимости .NET Core. Эти зависимости должны присутствовать в системе перед запуском приложения.

https://docs.microsoft.com/ru-ru/dotnet/core/deploying/deploy-with-cli

(334) >благодаря его простоте, я, например, никогда не сталкивался с невозможностью разобраться с чужим решением

Есть куча конфигураций где даже идеально зная язык и платформу хрен разберешься в короткие сроки

(334) Именно из-за его простоты там такая куча наворотов и. Правда и в ООП тоже тяжело разобраться без отладки, но при этом код лаконичен и главное типизирован.
Поверь мне на C# приходится разбираться тоже с огромными количеством кода и это проще чем в 1С, где для универсальности из-за отсутствия ООП используют утиную типизацую и прочие костыли

(336) Возможно я не сталкивался с по настоящему сложными решениями. Я дорабатываю в основном самописки.

ИМХО, все эти ООП и строгие типизации хороши когда нужно забубенить сервисный механизм. Например, разобрать/собрать XML с ООП намного удобнее. А вот именно бизнес-логику удобнее писать функционально и с неявной типизацией. А-ля 1с

Но исполнитель это какой-то кастрат получился. Java без ООП...

(339) Чем это лучше? Для примера в Вэбе TypeScript набирает популярность именно за счет типизации.
Тот же Linq очень удобен для запросов. Проблемы возникают только в универсальных отчетах.
Но и там можно использовать кодогенерацию и кэширование запросов.
В конце концов например в C# dynamic. То есть тот же C# он может быть и строго типизирован, и там где нет может быть с динамической типизацией.
Кстати в том же исполнителе они пошли по пути типизации как в TypeScript

(341) лаконичностью написания лучше. По-моему даже некорректно сравнивать DSL-язык (1с) и язык общего назначения (C#). Последний создавался не для написания бизнес-приложений

(342) C# очень универсальный язык. Один только Linq чего стоит. Что в 1С сильно не хватает и лаконичность побьет 1С однозначно, а учитывая типизацию то выиграет и по скорости написания кода. Так что ты здесь неправ.
Куча конструкций упрощает написания кода. Про отсутствие замыканий вообще промолчу.

Да и 1С DSL то очень сложно назвать. Единственно это в одном модуле написание серверного и клиенсткого кода. Да и то на C# это решается через условную компиляцию и кодогенерацию https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/

C# это не только язык но VIsual Studio c плагинами которые ты сам можешь написать и использовать.

(343) в этом-то и разница. Универсальный VS. узкозаточенный. Про скорость написания кода очень спорно. Сам код может и пишется быстрее, за счет шибко умной IDE, но для решения аналогичной задачи на C# того кода придётся написать намного больше, нежели на 1с

"Один только Linq чего стоит"

Ну и в чём его преимущество перед 1сным "метаданные + язык запросов + конструктор запросов"? Он позволяет за несколько кликов мышкой написать сложные запросы?

(345) Так и в C# метаданные есть. Если хочешь конструктор есть LinqPad https://www.linqpad.net/
Все метатанные легко переносятся на EF Code First
http://catalog.mista.ru/public/402038/
http://catalog.mista.ru/public/402433/

При этом ты получаешь типизированный результат.
А если тебе нужно сделать запросы по различным условиям, то тут либо склейка кода либо лепить условия внутри запроса.
В Linq ты можешь использовать несколько запросов делать соединения итд

(346) кхм...

SELECT ... FROM (SELECT ... FROM (SELECT ... FROM (SELECT ... FROM (SELECT ... FROM (SELECT ...

это ты серьёзно?

Ловите LinqМАНА!!!

(347) Это ты про что? Переведи

(349) про месиво из вложенных запросов. Неужели linq не умеет ни во временные таблицы, ни в табличные выражения?

это противоестественно
но прикольненько

(350) Linq это абстракция. Изначально он был к коллекциям, потом пришпондорили к SQL.
Есть несколько множество фреймворков Entity  Framework, Linq2DB итд.
Суть их в том, что по IQueryable составлять запросы. Например нет особого смысла в во временной таблице если можно применить отдельный запрос по подзапросах.
Например Linq2DB может использовать CTE https://linq2db.github.io/articles/sql/CTE.html
аналитические функции
https://linq2db.github.io/articles/sql/Window-Functions-(Analytic-Functions).html

Чего сильно не хватает в 1С.

Практически можно все!

у LINQ есть как минимум три плюса перед запросами 1С:

1. Он контролируем в Compile-time: метаданные, проверка и вывод типов
2. Он переиспользуемый: LINQ-выражение можно передать в функции, которые могут их дополнить
3. Он расширяемый: Можно расширять своими методами, которые ретранслирует новые недостающие вещи SQL

(353) По ходу ты сейчас СКД описал.

(354) ну нет. Ты не можешь без танцев с бубном взять кусок СКД и засунуть его в другую СКД.

(354) ну точно
1. Нет. Можно получить невалидный код, который вылезет только в запуске
2. Очень сложно получается
3. Он не делает это на SQL

и я не говорю, что в LINQ нет проблем
1. неоптимальные запросы, как у любой абстракции
2. если быть честным, то и он пропустит запрос, который не валидный. Например Comment.Length - а там внезапно неограниченная строка и если тип неспециальный у Comment, то компиляция пройдет
3. разное поведение в Linq-for-SQL и Linq-for-Object

(357) а Linq оно же над стримами? Распараллеливается и все такое?

(357) Это, кстати, готовые вопросы для собеседования. Понимаете-ли вы, как. И какие ограничения у. Разные должности, разные зарплаты, процесс идет, продукт продается...

А свое мнение по поводу правильности - ну, ты можешь свернуть его в трубочку и =)

Вот интересно, что будут делать апологеты типа Смирнова, через полгода, с появлением новой концепции ORM, какого-нибудь "ObjektAlchemie". Переметнутся, признают свое устарение, будут с пеной у рта вспоминать молодость?

(359) так-то тут "форум", не надо никому указывать, что делать с мнением
а иначе - расходимся, обсуждать нечего: про плюсы 1С в официальной литературе от вендора почитать можно

(352) "Например нет особого смысла в во временной таблице если можно применить отдельный запрос по подзапросах"

Это когда у тебя небольшая БД. Когда БД вырастает, все эти соединения подзапросов с подзапросами, построенными на подзапросах, начинает выходить боком

(360) пишет юзер с ником Ненавижу 1С)

(361) Угу большинство в 1С временными таблицами пользуются из-за удобства использования, что бы один и тот же запрос не плодить внутри подзапросов.
В Linq2DB есть поддержка временных таблиц.

(363) Временные таблицы не для удобства использования. Использование ВТ помогают СУБД (в частности MS SQL) строить более оптимальный план запроса. С вложенными таблицами есть некоторые сложности с этим.

(364) Я прекрасно понимаю для чего нужны временные таблицы. А так же вижу как они используются.
Вплоть до использования запроса к таблице значений, для сложных отборов итд.
http://catalog.mista.ru/public/371762/

А с этим и Linq прекрасно справляется. Нет в 1С замыканий!

365 + Вот пример Linq to DataSet аналог таблицы значений
https://www.tutorialspoint.com/linq/linq_dataset.htm#:~:text=Below%20is%20a%20simple%20example,the%20means%20of%20join%20clause.

Ну чего, кто-то что-то сделал полезное с помощью него?

(302) В java кстати давно уже изобрели компиляцию на уровне классов, поправил один класс, только он и компилируется.

(365) бро, я конечно дико экскюзми, но почему ты пишешь код а ля джуниор-стайл? Вроде бы в программировании уже давно, разрабатываешь на C#, а там clean code, clean architecture и вот это вот всё. Должен же знать, как пишется хороший код. Ни разу не хейтерствую. Просто интересно, почему не развиваешь скиллы кодонаписания?

(369) Это признак одиночки. При работе в команде за такой код могут побить.

(369) Всегда учусь и стараюсь улучшать свои навыки.
(370) Меня побить сложно. В зал хожу, на велосипеде катаюсь и вешу почти 100 кг. Но на продуктивную критику не обижаюсь и стараюсь совершенствоваться!
Нет предела совершенства! Работаю кстати к коллективе, но на C#

(370) согласен. Обычно одиночки подзастревают в профессиональном уровне. Сам таким когда-то был

(371) наверно у вас коллектив совсем маленький и/или нет больших проектов. На серьёзных проектах такой code-style уже давно получил бы обратную связь от коллег в виде потоков возмущения

(372) Этот код был написан лет 15 назад под 7.7 , адаптирован под 8.3 на скору руку. Тогда работал один и особо не занимался рефакторингом.
И делать выводы по одной странице кода все таки не стоит. И предполагать кто, где, и чем занимается.

373+ но я очень часто пользовался http://catalog.mista.ru/public/371762/
для группировки данных и отборов в таблице значений для кучи задач.
Кому надо разберется.

(0) 1C фактический расписалась в том в чём я их обвинял в самом начале выхода восьмёрки, а именно в неумении и непонимании в части дизайна языка программирования, то есть выбора конструкций и операторов языка. У меня дома есть пепельница. Я наклею на неё логотип 1С. Пусть она будет 1С совместима, ну или я так буду думать

(374) рефакторинг не делаешь что ли?

(376) Я много чем занимаюсь, в том числе рефакторингом кода и не только своего в сложных алгоритмах, для упрощения понимания кода.
А приведенный код достаточно прост. В нем разобраться может любой программист. И тратить на это время нет смысла.
Если тебе не нравится ну извини.

(377) разбираются и не в таком коде. Разбираются и в куда более сложном и уродливом коде. Но это всё вынужденно. В твоём коде придётся разбираться 10 минут (условно), а будь он написан хорошо, понадобилось бы полминуты. Своим "ай, и так сойдёт" ты фактически породил лишние трудозатраты для других программистов, которые будут читать код после тебя

Facepalm

В конфигураторе даже инкрементального оператора нет, а тут на тебе - статическая типизация.
Аплодирую стоя

(378) Ну сочувствую тебе. Там суть сортировки слиянием. Да может и стоило написать комментарии, но сортировку слиянием знают все. Там единственно проблема на 7 ке  различались сортировка в таблице значение и сравнение на больше меньше.
Но для 8 ки код легко читаем зная алгоритм сортировки слиянием.

380 + Кстати эта одна из моих первых публикаций. И многие жаловались на сложность кода.
Я это учел, и стал стараться писать более понятный код. К последним публикациям стало значительно меньше нареканий
http://catalog.mista.ru/profile/82159/objects/

(380) вот именно в этом и проблема. Чтобы понять, что делает этот код, нужно провалиться внутрь и много раз побегать глазками туда-сюда. Хороший код не заставляет читающего вникать в лишние подробности, а плохой вынуждает перечитывать его весь, вновь и вновь, с немалым усилием продираясь через хитросплетения. В хорошем коде метод сам "кричит" о том, что же он делает.

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

ИсключитьСотрудниковПолностьюОтработавшихНормуПоГрафику(ТаблицаНачислений);

собственно, мне сразу становится понятно, что делает данный алгоритм (да, внутри может быть и куча побочной логики, но это уже отдельная тема). И я понимаю, что внутрь этой процедуры мне заглядывать незачем. А если бы было написано твоим code-style? Я бы наткнулся на что-то такое:

ИсключитьИзТЗЛишних(Таблица);

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

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

+(382) отдельно стоит заметить, что если писавший код "красафчик", и имена переменных/методов в его коде четкие и лаконичные, то с большой долей вероятности нужный код отыскался бы через глобальный поиск по конфигурации.

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

у него просто мысль бежит далеко впереди

(382) Еще раз если знаешь алгоритм сортировки, то хватит беглого просмотра кода.
Если ты его не знаешь, то лучше обратиться к учебникам.
Еще раз прочитай 381. И посмотри эволюцию кода, а не суди по первой публикации.
Я понял, что многие не знают о сортировки слиянием и стал писать более качественный и комментируемый код.

Опять, же что касается кода, то например в Visual Studio, я легко могу просмотреть комментарий к методу и код на той же странице внизу метода.

Проблема 1С ников в том, что среда разработки очень отстает от VS.

начни хотя бы с выравнивания кода
одно это дает +50 к читаемости

385+ Проблема не только в среде но и в отсутствии типизации в 1С. Ты не можешь посмотреть что это за метод и откуда.
А вот в 1С:Исполнитель как раз и вносить аннотацию типов как в тайпскрипт. Плюс возможность редактировать в Visual Code/
Она хоть и отстает от Visual Studio но значительно лучше чем 1С конфигуратор.
После Visual Studio залезаешь в конфигуратор сразу ооочень сильно неудобно разбираться в коде.

(386) Код был выравлен. Просто при вставке на страницу он покурочился и приходилось вручную выравнивать. Я потом стал применять PASTEBIN.COM для правильного отображения

(385) интересно, и что же тут хоть отдаленно намекает на сортировку слиянием?

глСгруппироватьТзПоПолю()

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

(385) только массивы хранят объекты произвольного типа. На этом типизация заканчивается

(385) "я легко могу просмотреть комментарий к методу"

Такой надобности даже не возникло бы, будь название метода удачно подобранным. К тому же комментарии:
- далеко не у всех методов
- имеют свойство становиться неактуальными
- зачастую содержат какую-нибудь туфту, которая ничего не объясняет, а только ещё больше запутывает
Хороший метод с удачно выбранным именем не нуждается в комментарии. По-сути код это лучшая документация, самая актуальная и самая точная. Надо лишь написать код так, чтобы он сам себя документировал

(388) Прошу прощения. Там в статье в исходниках есть сравнение 2х ТЗ там используется алгоритм слияния.
В глСгруппироватьТзПоПолю() глСгруппироватьТзПоПолям используется элементарная сортировка и сравнение 1 элемента в группе с последующими и копирование этих записей в отделную ТЗ. Результирующая ТЗ имеет вид "Поля группировки" и тз с записями содержащие эти поля группировки.
Еще раз это была первая статья. Потом я исправился. Но посчитал, что код элементарен и не стал его оформлять должным образом.
В дальнейшем я исправился!

(390) Я не согласен. А комментарии к аргументам? Особенно когда их под десяток?
Или ты и аргументы будешь писать типа СотрудникДляИсключенияПолностьюОтработавшихНормуПоГрафику.
Кроме того есть куча параметров по умолчанию.
А вот для тебя такой подход правильный потому, что нет возможности в конфигураторе посмотреть пояснение к коду.

(392) 10 аргументов в методе тоже указывают на плохой код. Принципы написания хорошего кода придуманы не мною, и не для конфигуратора 1с. Они как раз "выстраданы" на этих ваших тру-языках, и не теряют актуальности во времена умных IDE

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

МинимальноеПоложительноеЧисло(Массив)

вроде бы понятно, откуда возьмёт и что вернёт функция


МинимальноеПоложительноеЧисло(МассивДляПоискаМинимальногоПоложительногоЧисло)

тут уже лишнее, бессмысленное пояснение

(393) Ошибаешься. Какой аргумент правильно поставить тоже нужно знать и его тип.
В том же C# для очень сложных методов проще создать класс, что бы не передавать кучу параметров и разделять метод на множество коротких.
Что касается  МинимальноеПоложительноеЧисло то и Min(uint[] array) значительно лаконичнее и информативнее.
Кроме того в 1С при вызове метода через точку нет интеллисенса для модуля или если не указан тип. И можно просто элементарно ошибиться набирая длинное название метода.

Поверь программируя на том же C# значительно быстрее разбираешься с кодом чем в 1С. После C# разбираться с кодом 1С одно мучение. (английский еще и лаконичнее)
Поэтому нужна и типизация и более продвинутый редактор кода.

(394) "то и Min(uint[] array) значительно лаконичнее и информативнее"

не-а, присмотрись внимательнее к моему названию метода, оно содержит важное дополнение. К тому же, когда ты будешь читать код, ты увидишь Min(array), а не Min(uint[] array) из заголовка метода

"И можно просто элементарно ошибиться набирая длинное название метода"

Ну это вообще какая-то надуманная проблема

А манера писать короткие имена (экономить на символах) это ментальная ловушка, в которую попадают многие программисты. Да, можно дать короткое лаконичное название методу или переменной, но для этого нужно хорошенько подумать. В большинстве случаев "короткое имя" = "невнятный огрызок"

Против типизации ничего не имею. Она действительно полезна, но не панацея. Идеяльно было бы, если бы в 1с можно было по желанию типизировать аргументы методов

ПроверитьДатуПриёмаНаРаботу(ТаблицаЗначений сотрудники)

тут тебе и контекстная подсказка, и проверка типа

(395) Увижу Min(array) а array  уже имеет тип.
Насчет надуманной проблемы. Из-за того, что нет статической типизации проверки кода нет и
очень часто возникают ошибки у из-за сильного ветвления кода в некоторую часть она может попасть раз в пятилетку, а там элементарная синтаксическая ошибка.
Это проблема всех языков с динамической типизацией, ибо невозможно покрыть все тестами.
(396) Ну вот коммунисты применяли сокращения. Абырвалг и прекрасно до сих пор живем.
Проблема иногда читать код с длинными именами это тоже факт.
Нужна золотая середина.
И имея подсказку в виде комментария в студии это не проблема.

ПроверитьДатуПриёмаНаРаботу(ТаблицаЗначений сотрудники)
Про это то и речь. В том же TypeScript ты можешь написать
ПроверитьДатуПриёмаНаРаботу(сотрудники:ТаблицаЗначений)
так и
ПроверитьДатуПриёмаНаРаботу(сотрудники)
При этом они написали аннотации к куче JS кода.

(397) (398) Вас обоих надо расстрелять за использование буквы "ё" в идентификаторах.

(396) > А манера писать короткие имена (экономить на символах) это ментальная ловушка, в которую попадают многие программисты.

Ты это, между прочим, пишешь изобретателю идентификатора "Ъ" в своей нетленке с сишарпом *сарказм*