Многоязычное программирование: создание систем с использованием нескольких языков

09.01.19

Разработка - Математика и алгоритмы

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

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

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

  • Старые
    • Fortran, Cobol, PL\I, Basic, Pascal, Ada, Lisp, …
  • Мейнстримные
    • C, C++, Java, C#, JavaScript, Python, Ruby, PHP, …
  • Новые и будущие
    • Go, Swift, Hack, Rust, Kotlin, Scala, …
  • Нишевые
    • D, Clojure, OCaml, Haskell, …

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

  • Необходимость избавиться от архаичного наследия «старых» языков
  • Несоответствие существующих ЯП новым задачам и возросшим требованиям
  • Недостаточность уровня абстракции в существующих языках для уровня сложности решаемых задач
  • Желание сохранить контроль над эволюцией языка
  • Для обучения или проверки положений теории языков на практике
  • Маркетинг (например J#)
  • Энтузиазм отдельных разработчиков

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

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

Компания

Год

Язык

Описание

Apple

2014

Swift

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

Facebook

2014

Hack

замена PHP

Google

2009

Go

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

 

2011

Dart

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

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

2011

Kotlin

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

Microsoft

2012

TypeScript

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

Mozilla

2010

Rust

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

RedHat

2011

Ceylon

«упрощенный» Java

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

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

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

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

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

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

И, наконец, верхний слой, самый нестабильный, с низким уровнем ответственности. Языки этого слоя предъявляют невысокие требования к уровню знаний программиста и тем самым обеспечивают большую армию разработчиков. Основное назначение этого слоя - быстрая поставка ПО. К этому слою относится легкие языки без контроля типов для создания ПО типа front-end и, так называемые, DSL для создания прикладного ПО. Это языки переднего края, максимально приближенного к своим потребителям, настолько, что даже знаний непрограммиста может вполне хватать чтобы сделать свой веб-сайт или даже построить свою БД для личного учета. В этом слое разрабатывается самый значительный объем ПО и ему соответствует самая широкая часть пирамиды Бини.

Вступайте в нашу телеграмм-группу Инфостарт

Языки программирования DSL

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Математика и алгоритмы Программист 1С 8.3 Абонемент ($m)

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

1 стартмани

07.11.2025    6179    16    InFlach    17    

27

Математика и алгоритмы Запросы Программист 1С:Предприятие 8 Бесплатно (free)

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

08.07.2024    8000    ivanov660    9    

24

Математика и алгоритмы Программист 1С:Предприятие 8 1C:Бухгалтерия Россия Абонемент ($m)

На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.

1 стартмани

30.01.2024    15740    stopa85    12    

43

Математика и алгоритмы Бесплатно (free)

Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.

19.10.2023    23944    user1959478    57    

41

Математика и алгоритмы Разное 1С:Предприятие 8 1C:Бухгалтерия Россия Абонемент ($m)

Расширение (+ обработка) представляют собою математический тренажер. Ваш ребенок сможет проверить свои знание на математические вычисление до 100.

2 стартмани

29.09.2023    14724    maksa2005    8    

27

Математика и алгоритмы Инструментарий разработчика Программист 1С:Предприятие 8 Россия Абонемент ($m)

Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.

1 стартмани

09.06.2023    24072    11    SpaceOfMyHead    20    

65

Математика и алгоритмы Программист 1С:Предприятие 8 Бесплатно (free)

Три задачи - три идеи - три решения. Мало кода, много смысла. Мини-статья.

03.04.2023    16642    RustIG    10    

30

Механизмы платформы 1С Математика и алгоритмы Программист 1С:Предприятие 8 Россия Бесплатно (free)

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

23.11.2022    15597    gzharkoj    17    

27
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. brr 184 09.01.19 10:30 Сейчас в теме
Язык 1С не соответствует сложности разрабатываемых на нем программ
MotorBox; +1 Ответить
2. mkalimulin 1643 09.01.19 10:44 Сейчас в теме
(1) В смысле? Излишне сложен или излишне прост?
3. brr 184 09.01.19 10:50 Сейчас в теме
(2)Излишне прост
MotorBox; CyberCerber; Vladimir Litvinenko; +3 Ответить
4. Vladimir Litvinenko 2944 09.01.19 12:57 Сейчас в теме
(3) Много лет соответствовал, особенно тогда, когда был резкий крен в сторону языков в динамической типизацией. Но в последние годы стала наблюдаться обратная тенденция, так как при масштабировании проектов приходит понимание, что на больших масштабах управляемость не менее ценна, чем скорость. Динамические языки остаются во фронтэнде.

Ну и когда смотришь на стек из 20-30 вызовов в БСП и попытку сэмулировать переопределение методов в процедурном подходе и с помощью оператора "Выполнить" становится понятно, что ООП не хватает.

В России и СНГ это проблем не доставит, рост платформы "снизу" шёл вместе с компаниями и частые изменения в бухгалтерском учете и законодательстве поддерживают привязку компаний к типовым конфигурациям. А вот привлечь разработчиков в других странах и сформировать какое-то сообщество аналогичное русскоязычному при такой мировой тенденции будет проблематично.
CyberCerber; o.nikolaev; +2 Ответить
5. brr 184 09.01.19 14:23 Сейчас в теме
(4) Полностью согласен
30. prime9 1096 14.01.19 07:24 Сейчас в теме
29. kalyaka 1182 13.01.19 23:46 Сейчас в теме
(3) по идее встроенный язык и задумывался как очень простой. В идеале потребность в нем вообще не должна существовать: все должно решаться на уровне описания конфигурации.

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

Другое дело, что платформа не успевает за потребностями - вот и приходится "затыкать" эти потребности на встроенном языке. Пока часть функциональности не будет перенесена все-таки в платформу (из недавнего: "история изменений", разделенение строк, работа с двоичными данными).
Fox-trot; +1 Ответить
6. msfog 10.01.19 12:37 Сейчас в теме
1С достаточно мощный инструмент для создания приложений различной сложности.

Основные проблемы развития данного языка типизированные и труднонастраиваемые интерфейсы и недостаточно развитая система интеграции с другими платформами.
7. surikateg 11.01.19 09:32 Сейчас в теме
(6) Как насчет написания 3д игр на 1с? :)

1с нишевой язык для учета, в других сферах его использование больше похоже на мазохизм.
8. Неопределено 111 11.01.19 09:55 Сейчас в теме
(7)
Как насчет написания 3д игр на 1с?
А в чём сложность?
9. surikateg 11.01.19 10:15 Сейчас в теме
(8) Подскажите пожалуйста, где это описано в синтаксис-помощнике? Именно языком 1с без внешних компонент.
10. Неопределено 111 11.01.19 10:20 Сейчас в теме
(9) Описано что? Создание игр?
11. surikateg 11.01.19 10:21 Сейчас в теме
12. Неопределено 111 11.01.19 10:24 Сейчас в теме
(11) В синтаксис-помощнике ничего не написано и про вывод дебиторки, но это же не означает, что дебиторку в 1С смотреть нельзя. А про 3D без внешних компонент написано в этой статье https://infostart.ru/public/876783, например. Ещё есть эта https://infostart.ru/public/880140.
13. surikateg 11.01.19 10:49 Сейчас в теме
(12) Спасибо за ссылки, познавательно. Но для создания полноценного интерактивного 3д приложения в 1с придется приложить на порядок больше усилий чем в других языках, это будет издевательство над программистом. Есть там дебиторка:) Например: Прикладные объекты\Регистры бухгалтерского учета\РегистрБухгалтерииМенеджер.<Имя регистра бухгалтерии>\Методы\ОборотыДтКт
14. Неопределено 111 11.01.19 10:57 Сейчас в теме
(13) Не за что. Работа с табличными документами в СП тоже есть. Думаю, усилий потребуется не больше чем для создания 3D игр первого поколения.
16. msfog 11.01.19 22:57 Сейчас в теме
(7) Разве мы рассматриваем игровые движки?
36. for_sale 902 29.01.20 12:08 Сейчас в теме
(7)
Т.е. в мире больше нет больше сфер, кроме 3д и учёта? Кстати, а вы сможете написать 3д игру на питоне без библиотек? Питон - это же тоже нишевый язык, получается?
17. kalyaka 1182 12.01.19 23:30 Сейчас в теме
(6) у каждого инструмента есть свои ограничения

На мой взгляд, 1С очень сильна в автоматизации бизнес-процессов: ведения хоз деятельности, бух учет, расчет ЗП. Последнее можно поспорить, но с поправкой на частые изменения в законодательстве 1С выигрывает, а в стабильности - уступает. Так в крупных компаниях масштаба МТС (компания группы Система) 1С используется только в небольших дочерних предприятиях типа розничной торговли.

Однако в системах реального времени, в высоконагруженных системах 1С неэффективна. Неэффективна 1С также в сложных проектах, проигрывая в качестве систем. Так я не встречал решений 1С для банковской сферы, для бронирования билетов в ЖД или в Авиа, в билинговых системах - т.е. в сложных, нагруженных системах, цена ошибки ПО в которых очень высока.

1С erp тоже спорный продукт. По моему 1С так и не научилась в реальном режиме времени работать, снимая данные непосредственно с датчиков.

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

1С не используется во встроенных системах, например в автомобилях или, не дай бог, в самолетах. Здесь цена ошибки не только высока, но и производительность нужна реального времени.

Есть вариант использования 1С в связке с кассовым аппаратом, однако это не очень распространенный вариант. Скорее ПО кассы работает на своей системе, а 1С снимает кассу раз в день.

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

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

А вот система интеграции с другими платформами - эта задача 1С решается тоже на высоком уровне. В вашем распоряжении: XML, SOAP, HTTP, ODATA, JSON. Чего Вам еще не хватает?
31. surikateg 14.01.19 09:42 Сейчас в теме
(6)
1С достаточно мощный инструмент для создания приложений различной сложности.


Чем игры под данную Вами формулировку не подпадают?
Даже обычный калькулятор лучше писать не на 1с. Запуск одного экзешника и запуск платформы для пользователя это огромная разница.
34. ivanchai 26.11.19 22:21 Сейчас в теме
(6)1с хорош когда идет неспешная интерактивная работа пользователя с базой данных. Если масштабные многопоточные вычисления или машинное обучение как всегда рулит С++. Да что там говорить если 1с сама написана на С++
15. TODD22 20 11.01.19 12:10 Сейчас в теме
Или я не внимательно читал или заголовок не соответствует содержанию. Тут какой-то обзор языков. И тема разработки проекта с использованием нескольких языков не раскрыта.
18. kalyaka 1182 12.01.19 23:43 Сейчас в теме
(15) посыл статьи в том, что прошли времена, когда системы разрабатывались на каком-то одном языке. Современная тендеция такова, что языков становиться все больше, а системы строятся на программах, написанных на различных языках. Т.е. мы являемся свидетелями появления нового понятия "мультиязычное программирование", именно возникновению этого понятия и посвящена статья.

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

Еще отдельно в статье приведено место встроенного языка платформы 1С. Это понимание нужно, чтобы ориентироваться во всем многообразии возможностей языков программирования, если вы изначально программист 1С.
19. TODD22 20 13.01.19 00:04 Сейчас в теме
(18)
посыл статьи в том, что прошли времена, когда системы разрабатывались на каком-то одном языке.

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

Спасибо кэп.
20. kalyaka 1182 13.01.19 00:13 Сейчас в теме
(19) лет 20 появлялись только ростки: платформа JVM только для Java, CLM только для языков MS.

Лет 10 назад проявилась сила универсализации платформ: единая IDE, шаринг данных, порт различных языков под разные парадигмы на одной платформе.

Лет 5 назад появилось понимание, что один проект можно собирать на разных языках в пределах одной платформы и это необычайно эффективно. И вот сейчас уже идет процесс мультипарадигмальности уже в пределах языков общего назначения + возможные расширения DSL.
21. TODD22 20 13.01.19 00:40 Сейчас в теме
(20)
Лет 5 назад появилось понимание, что один проект можно собирать на разных языках в пределах одной платформы и это необычайно эффективно.

Делать весь проект на одном языке не менее удобно. Взять тот же JS и node. Общее владение кодом и инструментарием и тд. Зоопарк из языков на проекте то же имеет свои минусы и эффективность такого подхода иногда сильно сомнительна учитывая дефицит хороших программистов.
23. kalyaka 1182 13.01.19 00:53 Сейчас в теме
(21) в этом примере для JS расширили контекст исполнения (клиент, теперь и на сервере). Здесь язык, в терминах классификации Бони из статьи остался в том же слое. Это тот же динамически нестрогой типизации язык. Назначение у него тоже - быстрое создание приложений с небольшим сроком жизни или с низкой ответственностью.

На счет того, что программистам стало легче (раньше бэкэнд писался, например на Python, теперь это тот же язык - JS) - согласен. Это языки одного порядка, а небольшие отличия в семантике могут порождать ошибки при переключении контекста внимания с клиента на сервер. И специалистов легче найти - тоже верно.

Однако для сложных задач, где нужно комбинировать программы с высокой ответственностью исполнения с низкой, по любому потребуются программисты разных уровней и здесь идея многоязычных проектов как раз реализуется.
24. TODD22 20 13.01.19 02:13 Сейчас в теме
(23)
Это тот же динамически нестрогой типизации язык. Назначение у него тоже - быстрое создание приложений с небольшим сроком жизни или с низкой ответственностью.

Динамическая типизация это синоним небольшого срока жизни или низкой ответственности?
26. kalyaka 1182 13.01.19 16:13 Сейчас в теме
(24) Динамическая типизация не позволяет на этапе написания программы проконтролировать алгоритмы на верное использование типов. Ошибки такого рода коварны тем, что проявляются исключительно на этапе исполнения. Допустить ошибку с типом очень легко, например переставить местами аргументы функции или передать в функцию тип, с которым она работать не умеет.

Также динамическая типизация приводит к накладным расходам при исполнении, т.к. если тип заранее неизвестен, то в рантайме необходимо вычислить этот тип и возможные с ним преобразования. Это сказывается на производительности.

С другой стороны, если рассматривать языки статической типизации, работа с типами приводит к большему объему кодирования, ведь компилятору нужно объяснить подробно используемые типы и их ограничения. Это приводит к более объемному и сложному кодированию. Зато компилятор, зная о типах, просто не пропустит к исполнению программу с ошибками работы с ними. Кроме того в такой среде компилятор "с удовольствием" подсветит и подскажет все допустимые операции работы с типизированными переменными. Скомпилированный код в таких языках не будет содержать ошибок с типами и будет максимально оптимальным, т.к. в нем будут отсутствовать алгоритмы проверки типов.

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

Если, например, платформа 1с содержит полмиллиона классов, у них хотя бы по два метода - итого несколько миллионов функций со своими аргументами. Над созданием программы трудится несколько десятков программистов. Кто-то, где-то с какой-то степенью вероятности делает ошибки. Представляете масштаб? Если бы платформа разрабатывалась на динамическом языке, то количество ошибок бы просто не позволило выпустить рабочий вариант при таком объеме кода. Отсюда и ограничение на сложность создаваемой системы, на ее надежность и возможную ответственность.

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

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

По времени жизни могу привести такой пример. Скажем разработка современно игры класса ААА стоит десятки миллионов долларов может занимать до 10 лет. Разработка же прототипа такой игры может занять пару месяцев. В прототип нельзя будет играть и ошибок там может быть не меряно, но его можно быстро собрать и продемонстрировать предполагаемые игровые механики заинтересованным лицам.
Fox-trot; +1 Ответить
22. TODD22 20 13.01.19 00:42 Сейчас в теме
(20)
лет 20 появлялись только ростки: платформа JVM только для Java, CLM только для языков MS.

Это не единственные языки и технологии. И не факт что поддержка платформой нескольких языков продиктована "эффективностью"(чего? разработки?) может и чисто коммерческий интерес дать возможность работать на одной платформе разным программистам.

В 1996 году пытались сделать серверный JS уже тогда хотели программировать в браузере и на сервере на одном языке, но не взлетело у них.
27. kalyaka 1182 13.01.19 16:30 Сейчас в теме
(22)
Это не единственные языки и технологии
Приведите, пожалуйста, примеры.
И не факт что поддержка платформой нескольких языков продиктована "эффективностью"(чего? разработки?) может и чисто коммерческий интерес дать возможность работать на одной платформе разным программистам
Платформы, как я понимаю, разрабатывались для унификации среды разработки и переносимости под разные ОС и процессоры. Переносимость одних и тех же программ без изменений - это пытались решить в первую очередь. С появлением среды разработки выяснилось, что другим разработчикам языков программирования можно не тратить свои усилия на создание помимо нового языка еще и полноценной среды разработки под него. Далее выяснилось, что программы, написанные на разных языках под одну платформу в конечном варианте представляются на языке псевдокода, общего для всех языков. Последнее означало, что у программ на одной платформе автоматически появился общий интерфейс для взаимодействия (вызова методов классов и функций). Более того, можно в одной программе смешивать код на разных языках и, скажем, создавать класс на одном языке, а использовать вызовы его методов на других языках.

Далее, если учесть, что у каждого языка есть свои преимущества и ограничения, то можно для различных задач разрабатываемой системы использовать те языки, которые оптимальным образом отвечают задачам данной функциональности.
25. jt3k 13.01.19 02:27 Сейчас в теме
Так ведь это не в последнее время появилась мультиязычность. Не секрет что многие програмы в критических местах используют ассемблерные вставки.
Опен офис вcю жизнь писали на си++ и джаве, а также вкропления на пайтоне и lua.
В том же excal активно используют бейсик, хотя сам редактор явно на си++
Xchat писан на си/gtk а внутри использует python perl lua скрипты
Список можно продолжать бесконечно.

У меня ощущение что автор решил профорсить тему с функциональщиной, что якобы она для мультипроцессорности удобней. Но где брать этих
чудо-разработчиков на скале и кложе, и кто будет валидировать их работу -- не говнокодеры-ли? Ведь поддержка уже написанного кода это не менее важная задача.
28. kalyaka 1182 13.01.19 17:34 Сейчас в теме
(25)
Не секрет что многие програмы в критических местах используют ассемблерные вставки
Насколько я знаю это относится только к компилируемым языкам низкого уровня, например в C++.
Опен офис вcю жизнь писали на си++ и джаве, а также вкропления на пайтоне и lua.
Скорее всего вы имеете в виду взаимодействие через формат С (библиотека dll). При таком взаимодействии можно выполнять вызовы в формате С, однако создать объект и передать его при вызове или вернуть - не удастся. В многоязычных проектах взаимодействие на уровне данных происходит без таких проблем.
У меня ощущение что автор решил профорсить тему с функциональщиной, что якобы она для мультипроцессорности удобней
Вы имели в виду, что я высказал очевидную вещь, но не раскрыл проблему с разработчиками, знающие функциональные языки? Если так, то я и не собирался это раскрывать, тут уж рынок труда должен соориентироваться. В параграфе "Выбор языка для проекта" я лишь упоминул один из критериев - наличие разработчиков.
32. Vovan1975 13 14.01.19 12:00 Сейчас в теме
автор привел бредовую классификацию языков программирования и объявил динамическую типизацию корнем всех бед.

Автор бредит.
33. Perfolenta 207 15.01.19 12:46 Сейчас в теме
Я считаю, что с тех пор, как появился OneScript, можно считать язык 1С языком общего назначения... да, простым, но все же пригодным для написания самых разнообразных по назначению программ... Python без библиотек тоже мало на что годиться, а с библиотеками и на OneScript можно что угодно написать...
Другое дело, что этих библиотек пока мало...
Среди причин появления новых языков можно еще выделить стремление корпораций формировать вокруг себя экосистемы, подсаживая программистов на свой язык... борьба идет за людей, не важно, пользователей или программистов, главное больше народу подсадить на свои технологии... т.е. причины не всегда технологические, причины могут быть экономические, психологические и т.д.
Fox-trot; sikuda; +2 Ответить
35. ivanchai 26.11.19 22:25 Сейчас в теме
С++, Java и Python Rulezzz
Еще были бы они так востребованы как 1с в глубинке, было бы счастье для российских программистов
Для отправки сообщения требуется регистрация/авторизация