Просто сравните язык 1С с С#, Java, Python или Delphi, и всё вылезет.
Так нельзя же их сравнивать, это разные вещи.
Давайте по порядку:
интеграция языка доступа к БД в язык платформы, с автодополнением, подсказками и т.п. (как раз по теме разработки бизнес-приложений).
Да вот только linq query syntax в C# получился достаточно сомнительным и его не так много людей используют.
Замыкания.
Соглашусь.
Типизирование переменных и проверка на типы во время компиляции
Я с вами в целом соглашусь, а вот любители языков с динамической типизацией — нет, и далеко не факт, что здесь нужна статическая.
Полноценное ООП с наследованием и полиморфизмом.
Зачем?
Параллелизм.
Он в 1С есть, сознательно урезанный.
Свёртывание блоков кода.
Дальше IDE: рефакторинг, синхронное редактирование идентификаторов (в Delphi очень удобно), графическое выделение структуры (вертикальные полоски в Delphi), переход на определение функции/переменной по Ctrl-Click, возможность отредактировать код во внешнем редакторе, про системы контроля версий писал автор
если под узким рынком иметь ввиду бизнес-приложения
Конечно, и тогда по совокупности факторов 1С в России вне конкуренции в small и medium business и потихоньку начинает подпирать SAP в больших энтерпрайзах.
В данной статье автор затронул только технический аспект: удобство для разрабов, язык разработки, простота поддержки и доработки, управление версиями и т.п.
Здесь надо все-таки различать легаси, которое существует по историческим причинам и с наличием которых никто не спорит, включая саму 1С, и сознательные решения, которые делают платформу удобной на узких задачах, но отвратительной на задачах на которых ее сравнивают с языками общего назначения.
.net не предлагает использовать для форм ничего. Есть множество фреймворков, каждый из которых предлагает что-то свое. И в .net первичен рантайм.
1С в первую очередь предлагает один единственный «фреймворк-платформу» (в которую входят изоморфные «управляемые формы»), а рантайм и язык являются производными от этого фреймворка и жестко заточены под конкретные задачи.
Я не понимаю как можно сравнивать полноценный язык общего назначения с DSL, который проектируется под очень узкий и конкретный набор задач и конкретный узкий рынок. С какой-то натяжкой можно еще сравнить какой-нибудь фреймворк или набор фреймворков (как технологический стек) для .NET с 1С и… на конкретных задачах, под которые затачивалась 1С, этот конкретный стек будет проигрывать по критериям скорости и стоимости разработки и поддержки. Пока вы не наткнетесь на задачу, которая в рамках 1С нереализуема.
Не могу себе представить сложную информационную систему написанную на .net или python.
Могу представить систему, где бэкенд написан на c# версии 7 (или на vb.net) на фреймворках asp.net core и ef core и работает под .net core, или python + flask + еще куча всего, а фронтенд — на typescript и react, например.
Мне интересно каким образом вы смешали и по каким критериям сравниваете язык программирования общего назначения C#, платформу .NET, технологическую платформу и фреймворк 1С: Предприятие и ее мягкий слой в виде предметно-ориентированного скриптового языка BSL?
Вот через несколько лет после прочтения вывести с нуля объектную систему, не занимаясь все эти года исследованием оснований объектных систем, уже интереснее, но, наверное, среднему программисту не особо нужно.
И все ещё ортогонально умению писать поддерживаемый код, проектировать и решать бизнесовые задачи в рамках той или иной предметной области, только если предметная область не состоит в написании компиляторов или статических анализаторов для языков программирования со статической типизацией и выводом типов. Люди в реальной индустрии до сих пор спорят о нужности и практической пользе var в c# и java, программируют на javascript, а вы хотите на собеседованиях разговаривать о теории (одной из), результатом которой являются несколько абстрактных языков программирования, на которых никто не пишет, ага.
Он пусть дальше ищет тех, кто знает расшифровку SOLID назубок, но не знает, что там в основе лежит
Вопросы «как устроена система типов и почему?» и «как моделировать предметную область средствами java-like ООП?» ортогональны друг другу. И, нет, люди прочитавшие тапл (в чем, кстати, особого достижения нет) не начинают автоматически хорошо понимать второй вопрос и писать поддерживаемый код, несколько примеров вполне себе знаю.
«за последний год я прочитал type theory and formal proof, сейчас уже 7 месяцев читаю algebra: chapter 0 и вот начал certified programming with dependent types»
Знаю как минимум пять компаний только в РФ, в которых чувака встретят с распростертыми объятиями и дадут работу по интересам.
А не синьор без опыта в конкретном фреймворке, который хочет 300кк в секунд, а потом ещё неделю будет тупить.
Уже два раза менял работу с приличным повышением в деньгах и уровне ответственности, один раз без опыта даже не в конкретном фреймворке, а в конкретном языке программирования.
Проблема не в том, что опыт не ценится, опыт как раз ценится.
Вот только считается он не в годах и не во фреймворках, а в решенных проблемах. И если вы хотите роста как программист — надо решать новые проблемы и искать их.
Можно 10 лет делать сайты-визитки, выгореть, разочароваться в профессии и в итоге быть менее опытным как программист (и решать проблемы хуже), чем выпускник хорошего вуза с грамотным фундаментальным образованием.
Спасибо. Я собственно пытался подвести к мысли, что в некоторых архитектурах одна из частей клиента как отдельного приложения тоже может быть бэкендом. А отсюда — к мысли, что у веб-приложения работающего внутри браузера есть бэкенд, который пишет… «фронтендер»!
Мне кажется, что вы сильно преувеличиваете сложность освоения фундаменталки. Но дальше сложно спорить, для этого нужно синхронизировать знания и представления о разработке.
Не очень понимаю, что вам мешает на C++ рисовать формочки, а на Delphi писать dll. И даже класть формочки в dll. И что тут извратного и принципиально разного?
Так нельзя же их сравнивать, это разные вещи.
Давайте по порядку:
Да вот только linq query syntax в C# получился достаточно сомнительным и его не так много людей используют.
Соглашусь.
Я с вами в целом соглашусь, а вот любители языков с динамической типизацией — нет, и далеко не факт, что здесь нужна статическая.
Зачем?
Он в 1С есть, сознательно урезанный.
Почти все есть в EDT.
Без каких?
А что не так с EDT?
Я серьезно спрашиваю, потому что возможно смогу объяснить почему введение каких-то фич из языков общего назначения в DSL может быть не лучшей идеей.
Конечно, и тогда по совокупности факторов 1С в России вне конкуренции в small и medium business и потихоньку начинает подпирать SAP в больших энтерпрайзах.
Здесь надо все-таки различать легаси, которое существует по историческим причинам и с наличием которых никто не спорит, включая саму 1С, и сознательные решения, которые делают платформу удобной на узких задачах, но отвратительной на задачах на которых ее сравнивают с языками общего назначения.
1С в первую очередь предлагает один единственный «фреймворк-платформу» (в которую входят изоморфные «управляемые формы»), а рантайм и язык являются производными от этого фреймворка и жестко заточены под конкретные задачи.
Я не понимаю как можно сравнивать полноценный язык общего назначения с DSL, который проектируется под очень узкий и конкретный набор задач и конкретный узкий рынок. С какой-то натяжкой можно еще сравнить какой-нибудь фреймворк или набор фреймворков (как технологический стек) для .NET с 1С и… на конкретных задачах, под которые затачивалась 1С, этот конкретный стек будет проигрывать по критериям скорости и стоимости разработки и поддержки. Пока вы не наткнетесь на задачу, которая в рамках 1С нереализуема.
На чем угодно и в зависимости от того какой фронт.
Если для вас это так важно, то я, в общем-то, почти уверен, что lair подтвердит мою правомочность разговаривать и про дотнет и про 1С.
Могу представить систему, где бэкенд написан на c# версии 7 (или на vb.net) на фреймворках asp.net core и ef core и работает под .net core, или python + flask + еще куча всего, а фронтенд — на typescript и react, например.
Так что с чем сравниваем?
Мне интересно каким образом вы смешали и по каким критериям сравниваете язык программирования общего назначения C#, платформу .NET, технологическую платформу и фреймворк 1С: Предприятие и ее мягкий слой в виде предметно-ориентированного скриптового языка BSL?
И все ещё ортогонально умению писать поддерживаемый код, проектировать и решать бизнесовые задачи в рамках той или иной предметной области, только если предметная область не состоит в написании компиляторов или статических анализаторов для языков программирования со статической типизацией и выводом типов. Люди в реальной индустрии до сих пор спорят о нужности и практической пользе var в c# и java, программируют на javascript, а вы хотите на собеседованиях разговаривать о теории (одной из), результатом которой являются несколько абстрактных языков программирования, на которых никто не пишет, ага.
Вопросы «как устроена система типов и почему?» и «как моделировать предметную область средствами java-like ООП?» ортогональны друг другу. И, нет, люди прочитавшие тапл (в чем, кстати, особого достижения нет) не начинают автоматически хорошо понимать второй вопрос и писать поддерживаемый код, несколько примеров вполне себе знаю.
Знаю как минимум пять компаний только в РФ, в которых чувака встретят с распростертыми объятиями и дадут работу по интересам.
Боксинг — это не приведение типов. Собственно, дальше можно и не читать.
wut? BSL же всегда был.
Уже два раза менял работу с приличным повышением в деньгах и уровне ответственности, один раз без опыта даже не в конкретном фреймворке, а в конкретном языке программирования.
Вот только считается он не в годах и не во фреймворках, а в решенных проблемах. И если вы хотите роста как программист — надо решать новые проблемы и искать их.
Можно 10 лет делать сайты-визитки, выгореть, разочароваться в профессии и в итоге быть менее опытным как программист (и решать проблемы хуже), чем выпускник хорошего вуза с грамотным фундаментальным образованием.
Но диалог пошел по другой ветке.
Мне кажется, что вы сильно преувеличиваете сложность освоения фундаменталки. Но дальше сложно спорить, для этого нужно синхронизировать знания и представления о разработке.
Не накладно, если разбираться в фундаменталке, которая под всем этим лежит. Собственно, мы тут вернулись к самому первому комментарию в этой ветке.
Не очень понимаю, что вам мешает на C++ рисовать формочки, а на Delphi писать dll. И даже класть формочки в dll. И что тут извратного и принципиально разного?