Жизнь получилась так, что параллельно с разработкой на моём актуальном стеке Python/PHP/C++/C# + MariaDB/PostgreSQL/Oracle DB пришлось программировать в 1С.
В посте не будет поливания говном ни других языков, ни даже 1С (что само по себе удивительно).
Начнём издалека, а именно с того как вообще появляются ЯП и их цели и задачи. Это важно напомнить, для понимания принципиальных отличий 1С и других ЯП.
Начнем с введения про ЯП.
Компьютер понимает только бинарный код, но писать в двоичном стиле:
00010010 00110011 00110010
смогут, но только единицы на планете. Но проблема в другом - ПО требуется много, а так разрабатывать очень долго. Поэтому придумали программы, которые преобразуют условно понятный человеку язык в понятный ЭВМ бинарный код.
Но ни одна программа не может мыслить, поэтому код в редакторе должен строжайше соответствовать встроенным в него шаблонам.
На второй итерации появились конструкции, которые обычно обозначают "синтаксический сахар", когда довольно большие и сложные для понимания структуры заменяются более простыми, а потом компилятор 2-го уровня их преобразует в более примитивные, а потом и в программный код. Макросы, функции, ООП, это всё тоже "синтаксический сахар".
Второй момент - организационный. Программный код сам по себе не появится, его нужно писать. Если напрямую на бинарном коде способны писать единицы, на ассемблере - в лучшем случае тысячи разработчиков, то на современных языках высокого уровня - миллионы. 1С в этом вопросе пошло ещё дальше, хоть что-то работающее на нём способен написать почти каждый человек... У которого на это будет желание.
Но... Это прорыв или провал? Парадоксально, но одновременно и то и то.
Чтобы понять прорыв нужно вспомнить такой момент - современная банковская сфера столкнулась с тем, что разработчики основного международного финансового ПО уже практически пенсионеры, а молодежь туда не особо горит желанием идти. Поэтому ситуация там весьма печальная. Как минимум 80% задач в 1С могут решать школьники с 8 класса (по шаблонам в ИТС). То есть дефицита кадров нет и скорее всего никогда не будет.
Чтобы понять провал... Идеала не существует, поэтому достигая прорыва в чём-либо одном нужно провалиться во что-то другое. И этим провалом опять же стал сам язык. Он слишком простой и примитивный.
1С перенесло всю "тяжелую" в плане понимания и реализации часть типичного ЯП внутрь поставляемой Платформы. С одной стороны всё, что требует сильного напряжения мозгов, уже реализовано... С другой стороны то же самое, но уже в ином ключе:
- выучив 1С программист получает только поверхностные знания о программировании, наиболее сложные моменты остались "за кадром", поэтому полноценным программистом разработчик 1С не является;
- программист, который работает с обычным ЯП знает довольно много трюков, когда небольшая правка "верхнего уровня" (базовых классов) способна сильно упростить код "внизу"... Но не в 1С. Писать тонны кода, когда вопрос можно было решить буквально парой строк в базовом классе... Можно, но психологически напрягает.
- язык 1С в плане структуры максимально однозначен и примитивен. Это позволяет учить его легко, при этом избежать 90% ошибок (мы помним, что порог вхождения почти отсутствует), из оставшихся в 90% довольно легко понять где возникла проблема и как её решать;
- но всё это делает код крайне раздутым. Я решал одни и те же задачи на разных ЯП и в 1С код спокойно может быть в десятки раз больше того же Python. Во сколько раз нужно быть умнее
- программисты 1С работают в жестко сформированной среде. Тот же code-style придумывать не нужно, он вшит в язык. Многие вопросы организации проекта так же уже вшиты в синтаксис. По сути для решения задачи из материалов ИТС (или аналогичных ресурсов) нужно либо копипастить код, либо проходить "мастера" написания кода, при этом подставлять в него свои элементы. Любой другой подход скорее всего просто не будет работать;
- программисты других ЯП в этом вопросе очень свободны. В принципе на любом языке 2 и последующих поколений можно писать в почти бесконечном количестве стилей... Что на порядки повышает эффективность одного разработчика, но приводит к тому, что до 90% времени работы над проектом зачастую тратятся на то, чтобы одни программисты понимали написанное другими программистами.
- все наиболее сложные моменты уже вписаны в 1С, поэтому рядовой разработчик про них ничего не знает, не понимает и главное - в них не ошибается. При этом в самой 1С вшито довольно много проверок, что сильно повышает надежность приложения;
- но если программисты самой 1С где-то накосячили, сделали слабое или не оптимальное место (а этого более чем хватает), то это вообще никак не поправить и остается только смириться. Если проблема критична для проекта, то остается только писать внешнее решение и делать интеграцию, тут без вариантов. Для "только 1С" разработчиков - доводить информацию до руководства о необходимости внешнего решения.
1С является прекрасным (не рискну сказать, что лучшим, но всё возможно) решением, где недостатки платформы не настолько существенны, как её плюсы. Эта сфера - построение бизнес-решений по модели CRUD (C - create - создание, R - read - чтение, U - update - обновление, D - delete - удаление) средствами слабо квалифицированных, но при этом сравнительно легко обучаемых разработчиков.
С позиции типовых требований бизнеса 1С - наилучшее известное мне на сегодня решение.
В этой сфере 1С настолько хороша, что в других сферах её применение объективно является терминальным идиотизмом. И попытки 1С дальше двигаться в направлении расширения сфер применения - изначально тупиковые. Да, за счёт большого числа кадров можно количественно сделать много решений, но вот получаемые при этом продукты будут, мягко говоря, далеко не лучшие и лучшими быть принципиально не могут.
Сейчас я немного обосную вывод на нескольких обобщенных примерах:
1С заточена на работу с фиксированными шаблонами объектов. Документы, Справочники, разные регистры. В сфере учёта (в т.ч. бухгалтерского) и управления такие объекты практически идеально отображают все сущности, которыми нужно оперировать, тут всё замечательно. Если же сущности задачи не укладываются в типовые шаблоны, то строить из них нужную структуру и работать с ней... Возможно, но больно и реализация пишется гораздо дольше, чем на других ЯП.
Из-за шаблонизации и многословности кода разработка под 1С типовых задач идёт гораздо быстрее, чем в других решениях (основные классы, свойства, методы уже написаны и писать их повторно не надо), но написать что-то выходящее за встроенные шаблоны в лучшем случае просто возможно.
Из-за того, что синтаксис языка заточен под работу не квалифицированных специалистов он своим синтаксисом сразу решает многие проблемы (хоть и при этом не дает "вырасти"), но создаёт другую проблему, а именно в том, что для решения не типовой задачи кода нужно слишком много. Решение на другом ЯП потребует в разы меньше времени просто из-за того, что писать нужно в ...дцать раз меньше.
Из-за "единой" архитектуры решения 1С уже сегодня довольно сильно "растолстели". В любом ЯП если мне нужен какой-то функционал, то я просто подключаю (или пишу) библиотеку. В 1С практически все "библиотеки" уже в поставке платформы, в результате чего невозможно писать простые решения, решение под слабое железо и решения требующие действительно высокую производительность (или работу "на пределе"). Просто потому что работа приложения в любом случае идёт только внутри платформы, а она сегодня далеко не "дюймовочка".
Рекомендации разработчикам:
1С которые хотят уметь в другие ЯП - если Вы хотите дальше развиваться и заниматься разработкой на других ЯП, то начинайте учить другой ЯП и работать на нём не позже полугода от начала работы в 1С. Чем дольше вы "варитесь" в 1С, тем меньше шансов на то, что сможете оттуда вырваться и не из-за того, что Вы думаете. Над самыми сложными для понимания и реализации задачами уже подумали в самой 1С при реализации платформы, но разработчики в других ЯП над этим должны думать сами. При этом эти задачи требуют в разы больше знаний теории и умения применять её на практике, чем всё, что вложено в 1С. ИМХО раз в 5.
Других ЯП, которые хотят в 1С - наберитесь колоссального терпения и запаситесь успокоительным. Желаний типа "писать шаблонизаторы под типовые ситуации", "работа в нормальной IDE", "перестать тыкать мышкой там, где в другом месте можно было бы написать строчку кода" не пройдёт вообще никогда, поэтому нужно расслабляться (и поддерживать квалификацию) решением задач на основном ЯП.
