Язык 1с на какой язык похож

Обновлено: 06.01.2025

Нашел на Хабре комментарий перебежчика с 1C на Java. Можно вместо 1С подставлять в эту копипасту другие технологии.

Ожидал этого вопроса, вот почему я начал учить Java:

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

2.В 1С большие ограничения по дизайну, а в последнее время я сильно проникся material design разрабатываю мобильные приложения. Меня сильно обижает нехотение 1С предоставить возможность кастомизации (сами они предоставить нормальный дизайн не могут)

3.Сам внутрениий язык 1С не несет никакой индивидуальности, не развивается в сторону масштабируемости, оставаясь на уровне версии 7 (новые операторы работы с бинарными данными или асинхронные или другие дополнения не в счет)

4.Еще о языке 1С, он очень грязный и учит программиста халявности. Нет типизации, нет case-sensitive, нет инициализации. Все эти вещи может и снижают порого вхождения, но рождают ленивых (в плохом смысле) программистов и урезают напрочь охоту думать (об этом была статья на инфостарте)

5.Нет ООП, тут можно возразить, что он не нужен, или что он уже частично есть, но это не так! Инкапсуляция? Наследие? Полиморфизм? Когда я изучал Java я смеялся и плакал. Сколько кода можно было написать под другому, какая удобная была бы поддержка таких решений (написанных с ООП)!

7.Проприетарный формат решений / баз данных 1С, решения закрыты в бинарном формате, и это во время когда уже сам Microsoft перешел на xml? Да в 1С зашевелились и начали делать выгрузку, но этого мало и с большим опозданием.

9.Любое ваше решение в 1С будет всего лишь надстройкой для 1С Предприятия, вы не можете считать себя программистом в полной мере и считать продукт своим. Он наполовину собственность фирмы 1С (давайте будет честными)

10.Ваша карьера остановится на 1С, вы не сможете найти работу зарубежом. У меня были фриланс клиенты из-за рубежа, но это не сравнить с количеством с СНГ.

11.Ваша карьера остановится на 1С, вы не сможете найти работу зарубежом, так как вы не учили язык программирования. В крайнем случае можете сказать что знаете Бейсико-Паскаль. Вы не знаете, что такое ООП, деплой, юнит-тесты, методики разработки, паттерны (боже упаси)

12.Ваша карьера остановится на 1С, вы не будете развивать свой мозг. (опять будьте честными)

Что бы меня заставило остаться в 1С: — ООП (да да, создание Object -> Document/Catalog/… ->… Даже с метаданными можно это сделать — улучшениея языка и укорощение, принудительная типизация переменных, инициализация, Case-sensitive — Нормальный IDE (Eclipse далеко не лучший) — Отказ от бинарного проприетарного формата — Нормальная поддержка JS/HTML/CSS и возможность кастомизации, так же и в мобильной платформе. Все ради нормального дизайна

Как вы понимаете в 1С этого сделано не будет никогда.

2.Java прекрасен, ООП возможно для опытных программистов приелся уже (хотя я так не думаю), но горазду хуже без него, любой большой проект превращается в ад

3.Java так и просит использовать чужие решения, использовать наследие и проектировать решения заранее (чего не нужно делать в 1С)

4.Java строг, (но не слишком), требует порядочности, аккуратности и продумывания

5.Изучая Java вы имеете огромный выбор развития карьеры и покрываете большой рынок JAVAEE / JAVASE / JS фреймворки / Scala / Android, и т.д.

6.Изучая Java вы узучите паттерны и сильно удивитесь (если вы пришли из 1С)

7.Прекрасные IDE, Jetbrains/Netbeans/Eclipse/Android studio он продумывает за вас многие вещи и помогает как учитель наблюдающий за вами.

8.Вы найдете работу зарубежом или из дома фрилансером, вы можете участвовать в конкурсах, в Open-Source, выбор за вами.

Привет, Хабр!
В этой статье мы начнем рассказ о том, как устроена внутри платформа «1С:Предприятие 8» и какие технологии используются при ее разработке.

Нативные приложения

STL (в частности, строки, контейнеры и алгоритмы)
множественное наследование, в т.ч. множественное наследование реализации
шаблоны
исключения
умные указатели (собственная реализация)

Компоненты

Разделение способствует лучшему проектированию, в частности лучшей изоляции кода
Из набора компонентов можно гибко собирать разные варианты поставки:
- Например, инсталляция тонкого клиента будет содержать wbase, но не будет backend
- а на сервере wbase, наоборот, не будет
- оба варианта будут, конечно, содержать nuke и bsl
- Предоставляет фабричные методы, позволяющие создать класс из другой компоненты зная только его название (без раскрытия реализации)
- Предоставляет инфраструктуру умных указателей с подсчетом ссылок. За временем жизни SCOM-класса не нужно следить вручную
- Позволяет узнать реализует ли объект конкретный интерфейс и автоматически привести указатель на объект к указателю на интерфейс
- Создать объект-сервис, всегда доступный через метод get_service и т.д.
Этот макрос опишет специальный статический класс-регистратор, конструктор которого будет вызван при загрузке компоненты в память.
После это можно создать его экземпляр в другой компоненте:

Для поддержки сервисов SCOM предлагает дополнительную, достаточно сложную инфраструктуру. Центральным в ней является понятие SCOM-процесса, который служит контейнером для запущенных сервисов (т.е. выполняет роль Service Locator), а также содержит привязку к локализуемым ресурсами. SCOM процесс привязывается к потоку ОС. Благодаря этому внутри приложения можно вот так получать сервисы:

Более, того переключая логические (SCOM) процессы привязанные к потоку, можно получить практически независимые с точки зрения информационного пространства приложения, выполняющиеся в рамках одного потока. Так устроен наш тонкий клиент, работающий с файловой базой — внутри одного процесса ОС находятся два SCOM-процесса, один связан с клиентом, а второй — с сервером. Такой подход позволяет унифицировать написания кода, который будет работать как на локальной файловой базе, так и в «настоящем» клиент-серверном варианте. Цена за такое единообразие — накладные расходы, но практика показывает, что они того стоят.

На основе компонентной модели SCOM реализована и бизнес-логика и интерфейсная часть 1С: Предприятия.

Пользовательский интерфейс

Кстати, об интерфейсах. Мы не используем стандартные контролы Windows, наши элементы управления реализованы напрямую на Windows API. Для Linux-версии сделана прослойка, работающая через библиотеку wxWidgets.
Библиотека элементов управления не зависит от других частей «1С:Предприятия» и используется нами еще в нескольких небольших внутренних утилитах.

За годы развития 1С:Предприятие внешний вид контролов менялся, но серьезное изменение принципов произошло только один раз, в 2009 году, с выходом версии 8.2 и появлением «управляемых форм». Помимо изменения внешнего вида, фундаментально изменился принцип компоновки формы — произошел отказ от попиксельного позиционирования элементов в пользу flow-компоновки элементов. Кроме того, в новой модели элементы управления работают не напрямую с доменными объектами, а со специальными DTO (Data Transfer Objects).
Эти изменения позволили создать веб-клиент «1С:Предприятия», повторяющий С++ логику контролов на JavaScript. Мы стараемся поддерживать функциональную эквивалентность между тонким и веб клиентами. В том случае, когда это невозможно, например, из-за ограничений доступных из JavaScript API (например, возможности работы с файлами очень ограничены), мы часто реализуем нужную функциональность при помощи расширений браузеров, написанных на C++. На данный момент мы поддерживаем Internet Explorer и Microsoft Edge (Windows), Google Chrome(Windows), Firefox (Windows и Linux) и Safari (MacOS).

Кроме того, технология управляемых форм используется для создания интерфейса мобильных приложений на платформе 1С. На мобильных устройствах отрисовка контролов реализована с использованием «родных» для операционной системы технологий, но уже для логики компоновки формы и реакции интерфейса используется тот же код, что и в «большой» платформе «1С:Предприятие».

Интерфейс 1С на ОС Linux

Интерфейс 1С на мобильном устройстве

Интерфейс 1С на ОС Windows

Интерфейс 1С — веб-клиент

Open source

Заключение

В статье мы коснулись нескольких основных аспектов разработки платформы «1С: Предприятие». В ограниченном объеме статьи мы затронули лишь некоторые интересные, на наш взгляд, аспекты.
Общее описание различных механизмов платформы можно посмотреть тут.
Какие темы были бы интересны Вам в следующих статьях?

Как реализована мобильная платформа 1С?
Описание внутреннего устройства веб-клиента?
Или, может быть, Вам интересен процесс выбора фич для новых релизов, разработки и тестирования?

Зачем это надо ? - Самые большие зарплаты программистов на Java и JavaScript.

На 1С зарплата сеньора 150 тысяч руб. в месяц (максимум 200), я на яве уже 250 тысяч руб. (максимум 300). Разработка на ява похожа по смыслу на 1С, поэтому 1С-нику лучше туда.

JavaScript предназначен в основном для рисования форм в веб-браузере, что для 1С-ника вообще не является работой, т.к. в 1С формы рисуются автоматически сами собой. Есть ещё много других языков программирования редких и специализированных, имеющие мало вакансий, поэтому неинтересные.

Что можно сделать на яве:
- backend для корпоративных сайтов, например аналогично как в 1С после нажатие на кнопку "Записать" куда-то что-то записывается, или отправляется емайл или т.п., это и есть бакенд. Для обычных небольших сайтов больше подходит язык php, на котором легче делать то же самое, но он не подходит для крупных сайтов т.к. не имеющий строгой типизации язык быстро превращается в «говнокод», а также там нет масштабируемости, мнгопоточности и др.
- frontend совместно с JavaScript – рисование вебформ, с кнопками и др., изменение их размеров, скрытие и др. Редко используется т.к. легче на JavaScript без Java
- приложения для десктопных компьютеров – редко используется т.к. самый современный фреймворк для этого JavaFX отстаёт по возможностям от 1С и от очень старого Delphi6, т.е. лет на 20. Чтобы создать 1 кнопочку на форме с простым действием уходит 1 час вместо одной минуты на 1С, т.к. кроме долгих настроек надо ещё конфигурировать .xml файл и др.
- приложения для смартфона – редко используется т.к. на андроиде теперь официальный язык Kotlin, а на iOS – Swift
- приложения для специализированных устройств – редко используется т.к. нет вакансий
Работа 1С-ника итак состоит в создание бакенда на 80%, 10% - рисование форм frontend, 10% - общение с пользователями, т.е. работа по смыслу совсем не изменится. Вместо пользователей будут аналитики, вместо создания форм будет общение с фронтендерами, добавится только создание автоматических юнит-тестов, которые 1С-ники не делают вообще никогда, а может и не добавится, если это сделают отдельные тестировщики, в общем ничего не изменится в режиме работы.

В 1С все программируют на русском языке, можно и на английском, но никто этого делать не будет, поэтому казалось бы нет ничего общего с явой, совсем не похоже, и знания из 1С не пригодятся уже, но достаточно просто сделать «перевод» терминов из 1С в ява, тогда всё будет намного проще – что я и попытаюсь сделать.
1. IDE - как конфигуратор в 1С, IntelliJ IDEA или NetBeans
2. Java core - синтаксис языка, он простой, совместно с фреймворками становится всё сложно, а сам язык легкий для изучения.
3. Работа с коллекциями - аналогичные коллекции как в 1С: "Массив", "Список значений", "Структура", "Соответствие" и др., точно такие же коллекции есть в java, достаточно написать таблицу соответствий как они называются тут и там.
4. Maven - для собирания всех файлов разных компонент, фреймворков в одну папку, нужной структуры, а также их обновления, выполнения скриптов. В 1С версии 8 обычно не нужно, там редко бывают внешние файлы, а в 1С 7.7 много внешних файлов, но всё равно нет ничего аналогичного.
5. Spring boot, Spring BOM - в основном контролирует чтоб версии разных компонент (старые и новые) не конфликтовали друг с другом, т.е. где-то в интернете хранится таблица совместимости разных версий компонент друг с другом.
6. Работа с базами данных - аналогично как в 1С "Внешние источники данных". Можно просто запросами вытягивать оттуда данные, а лучше сделать маппинг ORM т.е. превращение реляционных таблиц в объекты java - 1С это делает полностью автоматически, незаметно для программиста, в яве тоже полуавтоматически создаются классы типа "@Entity"
7. Запросы к базе данных - знание обычных TSQL запросов пригодится, но будет ещё язык HQL - специализированный язык запросов для превращения реляционных таблиц в объекты java, как и в 1С есть свой особый язык запросов.
8. Spring core - в основном для Dependency Injection - как бы для хранения глобальных переменных, которых нет в 1С версии 8, но есть в версии 7.7
9. Spring MVC - как веб сервисы в 1С. Например аннотация "@GetMapping("/page1")" означает что функция которая ниже выполнится когда откроется веб страница "page1"
10. XML и JSON - они итак есть в 1С, в яве ещё легче сериализовать объект т.е. превратить в строку.
11. RestFull, микросервисы - то же что в 1С галочка "Публиковать стандартный интерфейс Odata", который для всех объектов конфигурации автоматически создает интерфейс RestFull, в яве делают то же самое только для нужных объектов.
12. Тестирование - вручную как в 1С, и написание автоматических юнит-тестов.
13. Git - как хранилище конфигурации в 1С, для совместной работы нескольких программистов.
14. Deploy - обновление конфигурации, в яве это обычно просто скопировать куда-то файл, специально подготовленный.
По каждому пункту напишу отдельную статью, кратко, для общего понимания и сравнения как одно и то же делать на разных языках, и где легче.

Возникновение новых языков, языковые платформы

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

Текущее представление языков примерно выглядит так:

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

Следующая таблица демонстрирует, что несмотря на наличие существующих языков, решающих сходные задачи, известные ИТ компании создают собственные языки, а не переиспользуют готовые.

Таблица 1. Новые языки, появившиеся в последнем десятилетии от известных ИТ-компаний

язык общего назначения на замену Objective C

язык реализации веб-приложений

более надежная и производительная замена JavaScript

JetBrains (СПб, Россия)

простая и эффективная замена Java

«улучшенный» JavaScript (аннотация типов, классы)

язык реализации алгоритмов для многоядерных архитектур

Однако язык не может существовать сам по себе. Языку требуется активное сообщество, которое использует язык, популяризирует его, участвует в его развитии. В современных условиях язык без возможности интеграции с существующими библиотеками не имеет будущего. Действительно, никто не будет писать с нуля на новом языке, каков бы он не был хорош изначально, алгоритмы, которые уже написаны и проверены временем на других языках. Как минимум новый язык должен поддерживать вызов библиотечных функций, написанных в формате языка C.

С появлением таких языковых платформ как JVM и CLR задача интеграции библиотек кода на различных языках была решена на качественно новом уровне. Код, написанный на платформе, автоматически становится интегрированным в общую многоязычную среду. Платформа обеспечила не только интеграцию на этапе исполнения, но и переносимость как аппаратную, так и программную под различные операционные системы. Отладка и написание многоязычных проектов стала возможной в единой среде разработки. Последнее обстоятельство привело к новому видению использования различных языков в одном проекте - созданию многоязычных проектов.

Структурирование многоязычных приложений

Пирамида Ола Бини (Ola Bini)

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

Системный архитектор и разработчик Ола Бини (Ola Bini) интересуется языками программирования. В своей статье

Быстрая прикладная разработка

1С, SQL, XML, XAML, веб-шаблонизаторы

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

JavaScript, Python, Clojure

Стабильный, высокопроизводительный, хорошо протестированный функционал

Рисунок 1. Пирамида Бини

Разделение языков по уровню типизации

Системный архитектор и идейный вдохновитель компании

Рисунок 2. Языки по типизации: сильная-слабая, статическая-динамическая с выделением слоев Бини

Функциональное деление (будущее языков)

В развитии своей теории многоязычного программирования Нил Форд выдвинул идею того, что в классификации слоев Бини стабильные языки будут развиваться в сторону увеличения поддержки функционального стиля. Уже сейчас в моду входит функциональный стиль программирования и, хотя программы бухгалтерского учета пока еще не пишут на Haskell, многие языки начинают поддерживать операции с функциями высшего порядка. Такие понятия, как «декларативный», «чистые функции», «каррирование» потихоньку начинают проникать в лексикон все большего количества программистов.

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

В будущем по Форду типизация уже не будет играть такую большую роль, а определяющим будет чистота реализации функциональной парадигмы. Типизация останется, однако будет прерогативой самого программиста.

Форд также обращает внимание на распространение поддержки создания DSL средствами самого языка. В таких языках как Scala и Clojure встроенная поддержка создания собственных DSL позволяют просто и компактно формализовать важные концепции предметной области. По Форду языки будущего помимо мультипарадигмальности будут также поддерживать DSL во всех сло ях.

Мультипарадигмальные языки

Современные языки идут по пути поддержки мультипарадигмальности. Языки, исторически поддерживающие парадигму процедурного и ОО программирования, начинают вводить элементы поддержки парадигмы функционального стиля. Функциональные языки наоборот расширяют свои возможности, вводя поддержку ОО парадигмы.

Такое развитие имеет как свои плюсы, так и минусы. Если поддержка функционального стиля - это, как правило, расширение возможностей языка, то добавление в функциональный язык ОО парадигмы - это улучшение интеграции с другими языками с ОО парадигмой. Сравните: язык Scala - продвинутый язык Java с элементами функционального стиля и Clojure - чисто функциональный язык с поддержкой ОО парадигмы для совместимости с Java.

Мультипарадигмальность увеличивает мощь языка, но может и привести к проблемам. Так, когда один проект разрабатывается разными командами с использованием различных парадигм, то существует риск разработки несовместимых библиотек. Разработка в ОО парадигме стимулирует использование структур, а в функциональной - композицию и функции высшего порядка. В результате смешения парадигм могут получиться существенно различающиеся алгоритмы, которые не смогут работать без взаимной адаптации, а значит, внесения дополнительного усложнения в проект. Подобные проблемы команды разработчиков уже испытывали при переходе с Java на Ruby или с C на C++.

Рисунок 3. Распределение языков по слоям приложения по функциональному признаку

Выбор языков

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

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

В общем случае профессионально-ориентированному программисту необходимо владеть знаниями компьютерных наук, различных парадигм и быть в курсе последних тенденций развития языков. Можно рекомендовать знать несколько языков из различных слоев приложений (см. Слои Бини) или одного слоя - в количестве 3-4 языков. Ниже приведены варианты выбора языков исходя из целей.

Выбор для образования

Узнать, как устроен и работает компьютер

Научиться работать со сложными структурами данных

Научиться программировать эффективные алгоритмы работа с данными

Научиться строить большие и сложные сайты

Для цели определения какой язык стоит изучить можно использовать также исследование

Выбор для работы

Нужна быстрая и эффективная программа?

трудно писать; трудно поддерживать

Быстро написать и получить работающую программу или сайт?

JavaScript, Python, Ruby

работает медленно, часто ломается (зависает), пока происходит поиск ошибок

Быстро небольшой веб-сайт?

для дальнейшего улучшения веб-сайта может потребоваться много усилий

Выбор для проекта

Выбор языка в проекте зависит от множества факторов, вот некоторые из вопросов, которые могут помочь определиться с языком:
- какова кривая освоения языка?
- насколько эффективны существующие фреймворки?
- насколько развито сообщество языка?
- насколько быстро можно найти нужных разработчиков?
- насколько легко язык интегрируется в многоязычную среду?
Встроенный язык 1С как DSL

Несмотря на то, что в заголовке этого абзаца язык 1С обозначен как DSL, это утверждение не всеми разделяется. Действительно, на языке уже написана масса прикладных решений в самых разнообразных сценариях использования и это не только учетные задачи. В самом языке есть встроенные объекты для работы с файлами даже на уровне байтов. Все это может представляться как написанное на языке общего назначения. Сам Мартин Фаулер, который ввел понятие DSL, в своем труде отмечал, что порой очень сложно отнести возможности языка именно к DSL и существует тонкая грань, где язык выходит за рамки только одной предметной области и уже может рассматриваться как язык общего назначения. Но давайте рассмотрим, что же представляет собой встроенный язык платформы 1С.

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

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

Встроенный язык обладает множеством ограничений, которые не характерны для языков общего назначения. На этом языке нельзя построить эффективный веб-сервер или реализовать интерфейс, не поддерживаемый платформой (попробуйте изменить цвет выделения текущей строки табличного поля). С другой стороны, все необходимое для решения прикладных задач максимально реализовано в объектах платформы, которые доступны из языка. Семантика объектов определена на уровне платформы и благодаря этому обеспечивается их поддержка: целостность данных, расчет итогов, права доступа, представление в интерфейсе и т.д.

Из определения языка 1С как DSL следует вывод о возможном его развитии. Собственно, сам язык, начиная с версии 1С7, не сильно изменился. Все, что меняется для языка - это расширение встроенных объектов и появление дополнительных встроенных функций. И, скорее всего, так и будет продолжаться: в платформе продолжат появляться новые объекты, потребность в которых будет обозначена сложными реализациями на встроенном языке. Например, недавно появились объекты, с помощью которых можно работать с историей хранения, когда похожая функциональность была реализована ранее средствами встроенного языка и потребность в простом решении на уровне платформы назрела.

Заключение

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

В сложных приложениях найдут применение многоязычные проекты. Такие проекты в рамках одной платформы JVM или CLR будут включать алгоритмы, написанные на разных языках, однако на уровне байт-кода это будут единые приложения с разделяемыми данными.

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

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

Профессиональным программистам необходимо смириться с необходимостью знать несколько языков программирования. С одной стороны, знание нескольких языков может сильно увеличить умственную нагрузку на программиста, с другой - все языки обладают сходными синтаксическими конструкциями, а значительную трудность в освоении языков составляет семантика и стандартная библиотека языка.

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

Читайте также: