0. kalyaka 428 09.01.19 00:55 Сейчас в теме

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

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

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
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 можно что угодно написать...
Другое дело, что этих библиотек пока мало...
Среди причин появления новых языков можно еще выделить стремление корпораций формировать вокруг себя экосистемы, подсаживая программистов на свой язык... борьба идет за людей, не важно, пользователей или программистов, главное больше народу подсадить на свои технологии... т.е. причины не всегда технологические, причины могут быть экономические, психологические и т.д.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Москва
Полный день

Программист 1С
Видное
Полный день

Программист 1С
Москва
зарплата до 120 000 руб.
Полный день

Консультант-аналитик 1С
Москва
зарплата от 100 000 руб. до 170 000 руб.
Полный день