Не совсем понятно чем jar отличается от среды Python, при этом все можно упаковать в один исполняемый файл. Вы написвли про var в Java 10, а я только недавно узнал, что в Java 15 добавили multi-line string. В свое время бесило это страшно. Но сейчас есть Kotlin, на котором гораздо приятней вести разработку по JVM, тем более с опытом разработки на Python
В 1С настроены 2 узла, один для передачи товаров, другой для передачи цен. При изменении одного вида цены одного товара к изменению зарегистируется изменение товара на узле товаров и на узле цен. При очередном обмене из первого узла выгрузится товар со всеми свойствами, а из второго все цены, коих могут быть десятки или сотни.
Я окончание неправильное написал, конечно же выгружается карточка товара со всеми ценами. Но так как при изменении цены или остатка помечается к выгрузке карточка товара, то она уйдет вместе со всеми свойствами пусть и в другом узле обмена
И цена почти везде "по запросу" и остатка нет. Не случайно ли? Передать товары можно, раз в неделю полной выгрузкой, так как типовой модуль не умеет передать на сайт информацию что нужно только один товар удалить
Я не про файл спрашивал, он действительно отдельный, а про отдельную выгрузку цен и остатков без информации о товарах. Для этого нужна отдельная регистрация изменений для них, а этого нет
Актуальная версия модуля обмена с сайтом для конфигурации УТ - 7.0.2.23. Регистрация изменений сделана на уровне товаров, то есть при изменении одного вида цены по одному товару типовой модуль обмена будет выгружать все товары, со всеми видами цен, свойствами и т.п. Даже на 100 тыс товаров это просто умрет, пакеты не будут успевать обрабатываться в Битрикс. О каких 2 млн тут вообще может идти речь
Не удивлен, что фронтенд имеет проблемы с масштабируемостью. Подсистема 1С для интеграция с Битрикс, на которую ведутся будущие клиенты, сделана настолько криво и неправильно, что ее проще переписать с нуля. А если переписывать с нуля, зачем тогда Битрикс? Только студентам-недоучкам могла прийти в голову идея передавать цены вместе с карточкой товара и исправить это можно только сторонними средствами, так как эта "особенность" зашита в схему обмена. Все это будет работать только в магазине с несколькими сотнямя товаров и когда подавляющая часть покупателей - розница с одинаковыми ценами На мой взгляд, компания 1С позорит свое доброе имя подобным сотрудничеством. Лучше бы потратили ресурсы на разработку стандартного интерфейса http сервиса для интеграции с интернет-магазинамм и встроили его поддержку в линейку УТ/КА/УП
Для хакеров приложение на Java это как читать исходный код. Хотите сделать защину - выносите чувствительный функционал в отдельные нативные модули и там же делайте проверку лицензии
Можно и нужно. Ведь в работе с кодом на этом языке и заключается основная часть работы.
Вы не сможете использовать платформу 1С:Предприятие без ее встроенного языка, каким бы ужасным он вам не казался. Но вы ругаете платформу без предложения разумной альтернативы для данной предметной области, из которой в итоге вообще ушли. Достаточно странно при таких вводных давать советы о том какие технологии для этой предметной области необходимо использовать.
Так там типов и нет толком. Я вот как раз немало людей встречал кто, как и я, ушел из-за языка.
И куда ушли в итоге? Когда я начинал работать с платформой 1С:Предприятие 7.7 в ней не было вообще ничего, ни функциональности платформы, ни функциональности типовых решений. Было огромное количество неофициальных библиотек, которые позволяли заставить все это как-то работать. Рядом была Axapta 3.0, которая была лишена большинства из этих недостатков и многие переходили на нее. Но потом вышла платформа 1С:Предприятие 8 и после выхода 1С:УПП поток желающих перейти резко остановился, а после выходя 1С:ERP пошел обратный процесс.
А это вообще странное заявление. Может для тех кто только внедрением типовых занимается и их доработкой оно и оправдано
Это оправдано прежде всего с точки зрения клиента. Ему вообще без разницы какой там язык и какая платформа. Ему нужно получить определенную функциональность за определенную стоимость с определенной стоимостью владения.
Вы мне сейчас пытаетесь доказать что то что я при работе с 1с ненавидел и от чего ощущал дискомфорт - это плюсы, а не минусы
Повторюсь, дискомфорт у вас скорее был от предметной области, иначе бы вы ее не поменяли
Если это такие вот плюсы, чего же во всех современных языках перешли на нормальное управление зависимостями вместо прямого включения и прочих вариантов?
Я не говорил что это плюс, это особенность и чтобы понять хорошо это или плохо нужна для сравнения другая система с сопоставимой по размеру кодовой базой и построенная на других архитектурных принципах. Но такой нет, есть либо явно недотягивающие по функциональности, типа Odoo или iDempiere, либо явно недотягивающие по удобству SAP, OEBS. Отдельным особняком всегда стояла Axapta, но там уже много лет такой застой, что она ко второй группе присоединилась
На 1с тоже пишут, но страдают. Есть у меня опыт участия в разработке коробочных решений, писать и поддерживать сотни тысяч строк кода коробки 1сной это боль без типов.
Не смотря на то, что для ряда проектов (в том числе коробочного решения) использую EDT никогда не обращал внимание на типы. И судя по количеству упоминаний об этом в telegram-канале по EDT это точно не является причиной, по которой люди ее используют
Не знаю что вы там подразумевали. typescript это вполне себе отдельный язык от microsoft которой в js транспилируется.
В js много чего транслируется, в том числе 1С. Но я никогда не воспринимал TypeScript как отдельный язык, скорее как надстройна над JavaScript. Но не буду утверждать, т.к. ни строчки кода на нем никогда не написал.
УГ именно язык на котором нужно для них писать.
Нельзя встроенный язык 1С рассматривать отдельно от платформы 1С:Предприятие. Более того, нельзя отдельно рассматривать платформу 1С:Предприятие от типовой конфигурации 1C. По-отдельности они никому не интересны. Кроме того, 1С генерирует байт-код обычной стековой машины, что теоретически позволяет скомпилировать в него код "более современного" языка программирования. Но я о таких попытках не слышал, возможно из-за того что никому это особо не интересно.
Ну и где десятки тысяч библиотек со всякими служебными функциями для 1с вроде аналогов gson, кастомных логгеров, какой нибудь кастомной работы с датами и временем, парсингом html/xml нестандартным?
При таком объеме кодовой базы как в 1С:ERP (даже без УХ или CRM) идет унификация всего и вся. Для этих целей в свое время была создана БСП. Если производительности встроенного языка недостаточно, при достаточном количестве обратной связи это появится в платформе. И всегда есть возможность реализовать ваши хотелки с помощью внешних компонент или вызовом внешних программ.
Так оно нужно. Но оно не должно торчать в тот код который этим будет пользоваться. А предоставляться только через абстракции
Я уже писал ранее, что на проекте внедрения все ваши идеально построенные абстракции могут накрыться медным тазом из-за специфических требований клиента. Система изначально создана для внесения изменений в любую часть функциональности и лишние уровни абстракции тут только вредят. Хотя, например, я бы полностью поддержал появление в платформе интерфейсов для модулей.
Насчет python тут точно не скажу как там в коммьюнити к этому относятся, на мой взгляд это язык либо для датасатанистов, у них вариантов тупо нет других толком, либо для того чтобы наколеночные поделия клепать, если писать без типов
То есть по вашему мнению такие продукты как Odoo или Django (в которых нет type hinting) это "наколеночные поделия"? Не нужно забывать, что есть языки вообще без типов, что не мешает писать на них огромные проекты.
Но вот с typescript вы точно ошибаетесь, там без типов никто не пишет насколько мне известно
Под typescript я разумеется подразумевал javascript с типами и популярным он стал во многом из-за популярности node.js, в том числе из-за того что сам javascript весьма специфичный язык. Но что-то не припомню, чтобы кто-то из знакомых frontend-разработчиков его использовал.
В теории и на брейнфаке можно код писать. Мне как программисту важно чтобы на языке было писать просто и приятно. ... А если мне нужно страдать от неудобства работы с языком - значит язык уг.
Не нужно абсолютизировать. Для каждой каждой предметной области используется свой инструментарий. Вы написали, что не считаете платформу 1С:Предприятие достойной внимания разработчиков, но при этом так и не написали, с помощью какого инструментария в вашем понимании должны быть написаны учетные системы. В то же время многие разработчики, которым нравится эта предметная область и которые работали с множеством из них в последнюю очередь обращают внимание на современность языка.
Соглашусь по поводу 1С:PDM, то что это решение получило сертификат 1С:Совместимо является дискредитацией самой системы сертификации. Но тут дело наверное в том, что отсутствуют аналоги, а они отсутствуют в том числе потому, что все толковые специалисты заняты на проектах внедрения, выхлоп от которых гораздо больше. А тут нужно заморозить огромное количество денег с непонятной перспективой окупить вложения. 1С:УПП хороший продукт для своего времени, единственным недостатком которого являются обычные формы Искренне не понимаю, какие могут быть претензии к 1С:Документооборот, т.к. продукт изначально разрабатывался на управляемых формах
В теории да, на практике не делают этого. Причин много, какие-то я возможно себе надумываю, какие-то реальные, но важно то что выходит на практике
Поставщик конфигурации распространяет ее в виде файла поставки и вы не видите, сколько конфигураций поставщика используется при ее разработке. Так сделано в том числе для упрощения обновления. Но то что они используются это факт. Конфигурация 1С строится не библиотеками, а слоями. То есть разработчики БП, УТ, ЗУП создали функциональность на базе БСП, затем на уровне ERP их интегрировали, затем разработчики ERP:УХ интегрировали УХ в ERP и затем у клиента развернули ERP:УХ + CRM. В результате клиенту достаточно обновлять 2 конфигурации вместо 5. При этом никто не запрещает добавить клиенту новую версию функциональности из новой версии конфигурации на любом из уровней. При очередном обновлении версия поставщика догонит или перегонит добавленную. Механизм обновления конфигураций поставщика вполне справляется с этой задачей.
Пространство имен в случае 1с общее
Если разработчик поставляет отдельный модуль для добавления в другие конфигурации он добавляет префикс
модуль может быть подключен для использования в других модулях и попадать в их пространство имен, а может быть не подключен, и тогда не засоряет его
Вы можете включить в конфигурацию не все объекты конфигурации поставщика, как собственно делают при внедрении БСП
Плюс в 1с нет аналога package private. Потому внутренности модуля на все пространство имен торчат.
В Python тоже нет, только условное. В 1С есть условное разделение на модули - Обычные, Служебные, Перепределяемые, Локальные. При этом в отличие от Python, есть настроящие private функции
При этом даже в python завезли type hinting. А в случае веба на крупных проектах переходят на typescript с js.
И по этому механизму Python до сих пор идут споры, пока договорились до того, что использовать их следует только в публично распространяемых библиотеках. В EDT тоже есть плагин для этого, есть даже директива для strict модуля. Насколько я знаю с TypeScript та же история
По сути в python два режима сейчас, полностью динамическая типизация, которая подходит для скриптов и мелких проектов, и режим статической типизации, который подходит для крупных проектов
Впервые слышу об этом. Вижу кучу популярных публичных библиотек без всяких типов и возбуждаются от отсутствия типов только адепты языков со статической типизацией
Это пожалуй было одной из наибольших болей для меня. В упор не понимаю почему замыканий или просто хотя бы ссылок на функции не добавить
На данным момент разработчики платформы считают, что механизма передачи полного имени функции и последующего Выполнить достаточно для решения текущих потребностей. Было несколько сообщений на партнерском форуме по этому поводу, но ни одно из них не набрало такого количества лайков, чтобы разработчики платформы обратили на это внимание. Они вообще считают, что в платформе все есть для того чтобы разрабатывать бизнес-приложения любой сложности и в основном занимаются добавлением функциональности, а не развитием языка. Сейчас хоть планы свои публикуют на https://wonderland.v8.1c.ru, гораздо понятней стало в каком направлении развивается платформа
Нельзя рассматривать платформу 1С:Предприятие только как язык, это все-таки огромный фреймворк, поэтому сравивать его нужно не с условным Python, Java или Javascript, а с Axapta, Odoo, iDempiere. И я могу сказать, что по многим возможностям этим системах до 1С очень далеко, хотя там есть и ООП, и пакеты, и модули.
Отсутствие системы управления зависимостями Можно организовать с помощью конфигураций поставщика. Можно скрипт сделать, чтобы она обновлялась автоматически, но обычно этого не делают. Не понятно какое к этому имеет отношение "обновление чужого кода" Отсюда же идет отсутствие модульности Открываете регистр сведений "Версии подсистем" и обнаруживаете что модули все-таки есть, как и их версии. Отсутствие ООП / Отсутствие лямбд/замыканий Отчасти соглашусь, причина почему до сих пор не сделали функцию объектом непонятна. Это могло бы более эффективно решить многие задачи Динамическая типизация Это вкусовщина. На мой взгляд ЯП со статический типизацией были сделаны во времена недостаточной производительности компьютеров и популярность Python это доказывает. А популярность Rust показывает, что C++ не решил всех недостатков C. Печальная поддержка плагинов Скорее печальная поддержка EDT. Первоклассной средой разработки он так и не стал. Количество ошибок и скорость их исправления вызывает недоумение.
Необходимо учитывать следующие моменты разработки платформы и типовых решений:
В платформу добавляется только то, что жизненно необходимо, т.к. реализовывать это приходится для нескольких ОС/СУБД/клиентов
Типовые решения содержат огромное количество функциональности, каждую часть которой разрабатывают разные команды разработчиков. При таком подходе создание сложных многоуровневых иерархий классов если и возможно, то будет скорее вредить. Так как на любом более крупном проекте внедрения эта функциональность обрастет дополнительными требованиями от клиентов. А требования конечного пользователя могут погубить самую лучшую архитектуру.
Ориентированность на язык запросов. Началось это с момента разработки ERP, а когда у вас большая часть функциональности связана с построением запросов иерархия классов тоже не пригодится
Не совсем понятно чем jar отличается от среды Python, при этом все можно упаковать в один исполняемый файл.
Вы написвли про var в Java 10, а я только недавно узнал, что в Java 15 добавили multi-line string. В свое время бесило это страшно. Но сейчас есть Kotlin, на котором гораздо приятней вести разработку по JVM, тем более с опытом разработки на Python
Мой выпрос был адресован не вам, а @dima_kos, который написал что из коробки обмен 1С с битрикс прекрасно работает с сотней тысяч товаров
В 1С настроены 2 узла, один для передачи товаров, другой для передачи цен. При изменении одного вида цены одного товара к изменению зарегистируется изменение товара на узле товаров и на узле цен. При очередном обмене из первого узла выгрузится товар со всеми свойствами, а из второго все цены, коих могут быть десятки или сотни.
Я окончание неправильное написал, конечно же выгружается карточка товара со всеми ценами. Но так как при изменении цены или остатка помечается к выгрузке карточка товара, то она уйдет вместе со всеми свойствами пусть и в другом узле обмена
И цена почти везде "по запросу" и остатка нет. Не случайно ли? Передать товары можно, раз в неделю полной выгрузкой, так как типовой модуль не умеет передать на сайт информацию что нужно только один товар удалить
Я не про файл спрашивал, он действительно отдельный, а про отдельную выгрузку цен и остатков без информации о товарах. Для этого нужна отдельная регистрация изменений для них, а этого нет
Актуальная версия модуля обмена с сайтом для конфигурации УТ - 7.0.2.23. Регистрация изменений сделана на уровне товаров, то есть при изменении одного вида цены по одному товару типовой модуль обмена будет выгружать все товары, со всеми видами цен, свойствами и т.п. Даже на 100 тыс товаров это просто умрет, пакеты не будут успевать обрабатываться в Битрикс. О каких 2 млн тут вообще может идти речь
Напишите в таком случае тег формата обмена с сайтом, в котором можно отдельно передать цены и отдельно остатки
Прежде чем писать подобную чушь, ознакомьтесь с предметом
Напишите, для начала, с проектами какой сложности у вас был опыт. Какой объем таблицы товаров и количество видов цен?
Не удивлен, что фронтенд имеет проблемы с масштабируемостью.
Подсистема 1С для интеграция с Битрикс, на которую ведутся будущие клиенты, сделана настолько криво и неправильно, что ее проще переписать с нуля. А если переписывать с нуля, зачем тогда Битрикс? Только студентам-недоучкам могла прийти в голову идея передавать цены вместе с карточкой товара и исправить это можно только сторонними средствами, так как эта "особенность" зашита в схему обмена.
Все это будет работать только в магазине с несколькими сотнямя товаров и когда подавляющая часть покупателей - розница с одинаковыми ценами
На мой взгляд, компания 1С позорит свое доброе имя подобным сотрудничеством. Лучше бы потратили ресурсы на разработку стандартного интерфейса http сервиса для интеграции с интернет-магазинамм и встроили его поддержку в линейку УТ/КА/УП
Историю коммитов в Git можно любую нарисовать, поэтому так себе доказательство
Про 1С:CRM тихо умолчали
Для хакеров приложение на Java это как читать исходный код. Хотите сделать защину - выносите чувствительный функционал в отдельные нативные модули и там же делайте проверку лицензии
Вы не сможете использовать платформу 1С:Предприятие без ее встроенного языка, каким бы ужасным он вам не казался. Но вы ругаете платформу без предложения разумной альтернативы для данной предметной области, из которой в итоге вообще ушли. Достаточно странно при таких вводных давать советы о том какие технологии для этой предметной области необходимо использовать.
И куда ушли в итоге? Когда я начинал работать с платформой 1С:Предприятие 7.7 в ней не было вообще ничего, ни функциональности платформы, ни функциональности типовых решений. Было огромное количество неофициальных библиотек, которые позволяли заставить все это как-то работать. Рядом была Axapta 3.0, которая была лишена большинства из этих недостатков и многие переходили на нее. Но потом вышла платформа 1С:Предприятие 8 и после выхода 1С:УПП поток желающих перейти резко остановился, а после выходя 1С:ERP пошел обратный процесс.
Это оправдано прежде всего с точки зрения клиента. Ему вообще без разницы какой там язык и какая платформа. Ему нужно получить определенную функциональность за определенную стоимость с определенной стоимостью владения.
Повторюсь, дискомфорт у вас скорее был от предметной области, иначе бы вы ее не поменяли
Я не говорил что это плюс, это особенность и чтобы понять хорошо это или плохо нужна для сравнения другая система с сопоставимой по размеру кодовой базой и построенная на других архитектурных принципах. Но такой нет, есть либо явно недотягивающие по функциональности, типа Odoo или iDempiere, либо явно недотягивающие по удобству SAP, OEBS. Отдельным особняком всегда стояла Axapta, но там уже много лет такой застой, что она ко второй группе присоединилась
Не смотря на то, что для ряда проектов (в том числе коробочного решения) использую EDT никогда не обращал внимание на типы. И судя по количеству упоминаний об этом в telegram-канале по EDT это точно не является причиной, по которой люди ее используют
В js много чего транслируется, в том числе 1С. Но я никогда не воспринимал TypeScript как отдельный язык, скорее как надстройна над JavaScript. Но не буду утверждать, т.к. ни строчки кода на нем никогда не написал.
Нельзя встроенный язык 1С рассматривать отдельно от платформы 1С:Предприятие. Более того, нельзя отдельно рассматривать платформу 1С:Предприятие от типовой конфигурации 1C. По-отдельности они никому не интересны. Кроме того, 1С генерирует байт-код обычной стековой машины, что теоретически позволяет скомпилировать в него код "более современного" языка программирования. Но я о таких попытках не слышал, возможно из-за того что никому это особо не интересно.
При таком объеме кодовой базы как в 1С:ERP (даже без УХ или CRM) идет унификация всего и вся. Для этих целей в свое время была создана БСП. Если производительности встроенного языка недостаточно, при достаточном количестве обратной связи это появится в платформе. И всегда есть возможность реализовать ваши хотелки с помощью внешних компонент или вызовом внешних программ.
Я уже писал ранее, что на проекте внедрения все ваши идеально построенные абстракции могут накрыться медным тазом из-за специфических требований клиента. Система изначально создана для внесения изменений в любую часть функциональности и лишние уровни абстракции тут только вредят. Хотя, например, я бы полностью поддержал появление в платформе интерфейсов для модулей.
То есть по вашему мнению такие продукты как Odoo или Django (в которых нет type hinting) это "наколеночные поделия"? Не нужно забывать, что есть языки вообще без типов, что не мешает писать на них огромные проекты.
Под typescript я разумеется подразумевал javascript с типами и популярным он стал во многом из-за популярности node.js, в том числе из-за того что сам javascript весьма специфичный язык. Но что-то не припомню, чтобы кто-то из знакомых frontend-разработчиков его использовал.
Не нужно абсолютизировать. Для каждой каждой предметной области используется свой инструментарий. Вы написали, что не считаете платформу 1С:Предприятие достойной внимания разработчиков, но при этом так и не написали, с помощью какого инструментария в вашем понимании должны быть написаны учетные системы.
В то же время многие разработчики, которым нравится эта предметная область и которые работали с множеством из них в последнюю очередь обращают внимание на современность языка.
Соглашусь по поводу 1С:PDM, то что это решение получило сертификат 1С:Совместимо является дискредитацией самой системы сертификации. Но тут дело наверное в том, что отсутствуют аналоги, а они отсутствуют в том числе потому, что все толковые специалисты заняты на проектах внедрения, выхлоп от которых гораздо больше. А тут нужно заморозить огромное количество денег с непонятной перспективой окупить вложения.
1С:УПП хороший продукт для своего времени, единственным недостатком которого являются обычные формы
Искренне не понимаю, какие могут быть претензии к 1С:Документооборот, т.к. продукт изначально разрабатывался на управляемых формах
Поставщик конфигурации распространяет ее в виде файла поставки и вы не видите, сколько конфигураций поставщика используется при ее разработке. Так сделано в том числе для упрощения обновления. Но то что они используются это факт.
Конфигурация 1С строится не библиотеками, а слоями. То есть разработчики БП, УТ, ЗУП создали функциональность на базе БСП, затем на уровне ERP их интегрировали, затем разработчики ERP:УХ интегрировали УХ в ERP и затем у клиента развернули ERP:УХ + CRM. В результате клиенту достаточно обновлять 2 конфигурации вместо 5. При этом никто не запрещает добавить клиенту новую версию функциональности из новой версии конфигурации на любом из уровней. При очередном обновлении версия поставщика догонит или перегонит добавленную. Механизм обновления конфигураций поставщика вполне справляется с этой задачей.
Если разработчик поставляет отдельный модуль для добавления в другие конфигурации он добавляет префикс
Вы можете включить в конфигурацию не все объекты конфигурации поставщика, как собственно делают при внедрении БСП
В Python тоже нет, только условное. В 1С есть условное разделение на модули - Обычные, Служебные, Перепределяемые, Локальные. При этом в отличие от Python, есть настроящие private функции
И по этому механизму Python до сих пор идут споры, пока договорились до того, что использовать их следует только в публично распространяемых библиотеках. В EDT тоже есть плагин для этого, есть даже директива для strict модуля. Насколько я знаю с TypeScript та же история
Впервые слышу об этом. Вижу кучу популярных публичных библиотек без всяких типов и возбуждаются от отсутствия типов только адепты языков со статической типизацией
На данным момент разработчики платформы считают, что механизма передачи полного имени функции и последующего Выполнить достаточно для решения текущих потребностей. Было несколько сообщений на партнерском форуме по этому поводу, но ни одно из них не набрало такого количества лайков, чтобы разработчики платформы обратили на это внимание. Они вообще считают, что в платформе все есть для того чтобы разрабатывать бизнес-приложения любой сложности и в основном занимаются добавлением функциональности, а не развитием языка. Сейчас хоть планы свои публикуют на https://wonderland.v8.1c.ru, гораздо понятней стало в каком направлении развивается платформа
Нельзя рассматривать платформу 1С:Предприятие только как язык, это все-таки огромный фреймворк, поэтому сравивать его нужно не с условным Python, Java или Javascript, а с Axapta, Odoo, iDempiere. И я могу сказать, что по многим возможностям этим системах до 1С очень далеко, хотя там есть и ООП, и пакеты, и модули.
Отсутствие системы управления зависимостями
Можно организовать с помощью конфигураций поставщика. Можно скрипт сделать, чтобы она обновлялась автоматически, но обычно этого не делают. Не понятно какое к этому имеет отношение "обновление чужого кода"
Отсюда же идет отсутствие модульности
Открываете регистр сведений "Версии подсистем" и обнаруживаете что модули все-таки есть, как и их версии.
Отсутствие ООП / Отсутствие лямбд/замыканий
Отчасти соглашусь, причина почему до сих пор не сделали функцию объектом непонятна. Это могло бы более эффективно решить многие задачи
Динамическая типизация
Это вкусовщина. На мой взгляд ЯП со статический типизацией были сделаны во времена недостаточной производительности компьютеров и популярность Python это доказывает. А популярность Rust показывает, что C++ не решил всех недостатков C.
Печальная поддержка плагинов
Скорее печальная поддержка EDT. Первоклассной средой разработки он так и не стал. Количество ошибок и скорость их исправления вызывает недоумение.
Необходимо учитывать следующие моменты разработки платформы и типовых решений:
В платформу добавляется только то, что жизненно необходимо, т.к. реализовывать это приходится для нескольких ОС/СУБД/клиентов
Типовые решения содержат огромное количество функциональности, каждую часть которой разрабатывают разные команды разработчиков. При таком подходе создание сложных многоуровневых иерархий классов если и возможно, то будет скорее вредить. Так как на любом более крупном проекте внедрения эта функциональность обрастет дополнительными требованиями от клиентов. А требования конечного пользователя могут погубить самую лучшую архитектуру.
Ориентированность на язык запросов. Началось это с момента разработки ERP, а когда у вас большая часть функциональности связана с построением запросов иерархия классов тоже не пригодится