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

Программирование - Теория программирования

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

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

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

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

  • Старые
    • 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 для создания прикладного ПО. Это языки переднего края, максимально приближенного к своим потребителям, настолько, что даже знаний непрограммиста может вполне хватать чтобы сделать свой веб-сайт или даже построить свою БД для личного учета. В этом слое разрабатывается самый значительный объем ПО и ему соответствует самая широкая часть пирамиды Бини.

Слой

Описание

Языки

Предметный слой

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

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

Динамический слой

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

JavaScript, Python, Clojure

Стабильный слой

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

Java, C#, Scala

 

 

 

 

 

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

Системный архитектор и идейный вдохновитель компании ThoughtWorks Нил Форд (Neal Ford) предложил разделить языки по признаку типизации: сильная-слабая, статическая-динамическая. Такое разделение позволяет понять, как можно соотнести языки по слоям приложения Бини.

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

К динамическому слою относятся языки с динамической сильной типизацией. Отличительной чертой языков этого слоя является высокая скорость создания качественных программ. ПО этого слоя: скрипты автоматизации, администрирования и создания тестов, веб-разработка (бэк-енд), прототипирование.

На последнем верхнем слое располагаются предметно-ориентированные языки с динамической слабой типизацией. Это языки, на которых пишется ПО прикладного уровня: системы учета, скрипты с упрощенным синтаксисом для программирования формул или встроенной техники, DevOps, моделирование бизнес-правил и интеграции. Для них характерно отсутствие контроля типов, неявные приведения и динамическое определение типов.

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

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

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

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

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

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

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

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

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

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

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

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

Одна и та же синтаксическая конструкция «ТКласс Класс» в языке C++ будет означать конструирование объекта, а в языках Java/C# - неинициализированный объект типа null. В 1-ом случае можно продолжать работать с объектом, а во 2-ом попытка работать с неинициализированным объектом приведет к краху программы.

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

Цель

Язык

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

C

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

C#, Java

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

C++

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

JavaScript

Для цели определения какой язык стоит изучить можно использовать также исследование организации IEEE Spectrum «Первые 10 языков программирования»:

creenshot of the top ten programming languages app

Рисунок 4. Интегральный рейтинг языков программирования 2018 IEEE Spectrum

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

Цель

Язык

Недостатки

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

C, C++

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

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

JavaScript, Python, Ruby

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

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

PHP

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

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

  • какова кривая освоения языка?
  • насколько эффективны существующие фреймворки?
  • насколько развито сообщество языка?
  • насколько быстро можно найти нужных разработчиков?
  • насколько легко язык интегрируется в многоязычную среду?

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

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

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

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

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

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

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

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

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

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

Зачастую технологии, изначально созданные для решения одной задачи, являются ключом к качественно новым решениям в других. Так, среда JVM, CLR изначально создавались для решения задачи переносимости и унификации моделей программирования (последнее изначально закладывалось в CLR для двух языков: C# и VB). В последствии оказалось, что существование таких сред позволяет в принципе поменять отношение к разработке: если раньше преимущество в разработке отдавалось какому-то одному языку, а трудные аспекты языка решались на уровне поставки компонентов и библиотек среды или даже расширении языка, то теперь открылась возможность в принципе в одном проекте совмещать решения на разных языках программирования, используя преимущество каждого из них для конкретного рода задач. Подводя итог, можно утверждать, что идея создания одного универсального языка на данном этапе развития не оправдала надежд, и мир ИТ идет по пути многоязычного программирования.

PS

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

14

См. также

Специальные предложения

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

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

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

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

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

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

1с нишевой язык для учета, в других сферах его использование больше похоже на мазохизм.
8. Неопределено 40 11.01.19 09:55 Сейчас в теме
(7)
Как насчет написания 3д игр на 1с?
А в чём сложность?
9. surikateg 11.01.19 10:15 Сейчас в теме
(8) Подскажите пожалуйста, где это описано в синтаксис-помощнике? Именно языком 1с без внешних компонент.
10. Неопределено 40 11.01.19 10:20 Сейчас в теме
(9) Описано что? Создание игр?
11. surikateg 11.01.19 10:21 Сейчас в теме
12. Неопределено 40 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. Неопределено 40 11.01.19 10:57 Сейчас в теме
(13) Не за что. Работа с табличными документами в СП тоже есть. Думаю, усилий потребуется не больше чем для создания 3D игр первого поколения.
16. m.s.fog 11.01.19 22:57 Сейчас в теме
(7) Разве мы рассматриваем игровые движки?
17. kalyaka 428 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с. Запуск одного экзешника и запуск платформы для пользователя это огромная разница.
15. TODD22 17 11.01.19 12:10 Сейчас в теме
Или я не внимательно читал или заголовок не соответствует содержанию. Тут какой-то обзор языков. И тема разработки проекта с использованием нескольких языков не раскрыта.
18. kalyaka 428 12.01.19 23:43 Сейчас в теме
(15) посыл статьи в том, что прошли времена, когда системы разрабатывались на каком-то одном языке. Современная тендеция такова, что языков становиться все больше, а системы строятся на программах, написанных на различных языках. Т.е. мы являемся свидетелями появления нового понятия "мультиязычное программирование", именно возникновению этого понятия и посвящена статья.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор бредит.
33. Peleng 19 15.01.19 12:46 Сейчас в теме
Я считаю, что с тех пор, как появился OneScript, можно считать язык 1С языком общего назначения... да, простым, но все же пригодным для написания самых разнообразных по назначению программ... Python без библиотек тоже мало на что годиться, а с библиотеками и на OneScript можно что угодно написать...
Другое дело, что этих библиотек пока мало...
Среди причин появления новых языков можно еще выделить стремление корпораций формировать вокруг себя экосистемы, подсаживая программистов на свой язык... борьба идет за людей, не важно, пользователей или программистов, главное больше народу подсадить на свои технологии... т.е. причины не всегда технологические, причины могут быть экономические, психологические и т.д.
Оставьте свое сообщение