Как соединить два языка программирования в одной программе
Я недавно учился в аспирантуре и собираюсь получить степень магистра компьютерных наук. Я сталкивался с несколькими проектами с открытым исходным кодом, которые действительно меня заинтриговывают и побуждают меня вносить в них свой вклад (CloudStack, OpenStack, moby и Kubernetes и многие другие). Одна вещь, которую я обнаружил, что у большинства из них есть общее, - это использование нескольких языков программирования (таких как Java + Python + Go или Python + C ++ + Ruby). Я уже рассмотрел этот другой вопрос, который касается того, как создаются несколько языков программирования для взаимодействия друг с другом: как взаимодействовать два разных программирования с двумя разными языками?
Я хочу понять требование, которое побуждает предприятия использовать несколько языков программирования. Какое требование или тип требования заставляет разработчика программного обеспечения или руководителя проекта сказать: «Я предлагаю использовать язык X для задачи 1 и язык Y для задачи 2»? Я не могу понять причину, почему несколько языков программирования используются в одном продукте или программном обеспечении.
Как аспирант в области компьютерной инженерии, я добавлю, что для исследовательского кода, в частности, часто возникает вопрос о том, «какой язык автор (студент) знал лучше всего, когда начинал». Исследовательские проекты, особенно одноразовые, которые не приводят к большим исследовательским проектам, имеют тенденцию оценивать результаты по сравнению с «правильностью» (по моему опыту).
@tonysdg: Я бы сказал, что «правильность» имеет тенденцию быть более актуальной в научных кругах, а не меньше. Что обычно не имеет значения, так это удобство обслуживания, пользовательский опыт и / или документация. В частности, смешивание языков влияет на удобство обслуживания; это ограничивает количество квалифицированных сопровождающих.
@MSalters: ремонтопригодность - это слово, которое я искал в то время - я согласен со всем, что вы написали!
Разные инструменты для разных задач. Вы заметите, что строительные архитекторы и инженеры используют разные инструменты для строительства одного дома.
Когда вы отправляетесь в отпуск, из вашего дома в аэропорт, затем в иностранный аэропорт, затем в отель, а затем на пляж, вы используете один и тот же вид транспорта для каждого этапа поездки?
Этот ответ имеет превосходное освещение и ссылки на то, почему разные языки могут обеспечить различные преимущества для проекта. Тем не менее, существует несколько больше, чем просто языковая пригодность, связанная с тем, почему проекты заканчиваются использованием нескольких языков.
Проекты заканчиваются использованием нескольких языков по шести основным причинам:
- Экономическая выгода повторного использования кода, написанного на других языках;
- Необходимость включать и учитывать устаревший код;
- Наличие кодеров для конкретных языков;
- Потребность в специальных языках для специальных нужд;
- Унаследованные языковые предубеждения; а также
- Плохое управление проектом (незапланированное многоязычное использование).
Причины 1-4 являются положительными причинами в том смысле, что непосредственное обращение к ним может помочь проекту быстрее, эффективнее, с более качественным продуктом и более легкой долгосрочной поддержкой. Причины 5 и 6 являются отрицательными, симптомы сопротивления необходимым изменениям, плохое планирование, неэффективное управление или некоторая комбинация всех этих факторов. К сожалению, эти негативные факторы являются частыми причинами «случайного» многоязычного использования.
Причина 1 , экономическая выгода от повторного использования, становится все более веской причиной, позволяющей использовать в проекте несколько языков, как из-за большей роли программного обеспечения с открытым исходным кодом, так и улучшенных возможностей поиска нужных компонентов кода в сети. Философия прошлых десятилетий «давайте все это закодируем» продолжает исчезать перед лицом экономических реалий и, по сути, никогда не является наиболее экономически эффективным подходом для любого нового проекта. Это, в свою очередь, делает менее строгими возможности для строгого применения единого языка в проекте.
Особенно в случае, когда в проекте многократно используются хорошо управляемые компоненты с открытым исходным кодом, использование нескольких языков может обеспечить огромные общие затраты, поскольку повторно используемые компоненты скрыты за хорошо спроектированными интерфейсами и независимо поддерживаются внешними группами с нулевой стоимостью. В наилучших сценариях смешивание языков посредством такого повторного использования обходится проекту не дороже, чем использование компонентов операционной системы. Я не знаю лучшего примера ценности этого подхода, чем широкомасштабное принятие Microsoft программного обеспечения с открытым исходным кодом в своих браузерах.
Причина 2 , необходимость размещения устаревшего кода, игнорируется в опасности любого крупного проекта. Как бы много проблем ни создавал устаревший код, наивно полагать, что его можно легко заменить новым кодом на новом языке, может быть невероятно рискованно. Устаревший код, даже плохой унаследованный код, часто включает в себя то, что составляет неявный «контракт» функций, ожидаемых сообществом, использующим унаследованный продукт. Это сообщество довольно часто является основным источником дохода для компании или основной целью поддержки правительственного программного обеспечения. Просто отказ от этого подразумеваемого контракта может преследовать осведомленных клиентов в массовом порядке и может обанкротить компанию в одночасье, если другие варианты будут легко доступны.
В то же время, не заменять старый код на старом языке так же опасно, как и заменять его оптом. Наихудшим примером является Администрация ветеранов США, которая имеет большое количество жизненно важных систем, закодированных на языке MUMPS (без шуток), который был разработан врачами, а не учеными-компьютерщиками. Никто не хочет изучать MUMPS, и те, кто знает это, буквально отмирают. Поэтому программисты должны приспосабливать MUMPS даже тогда, когда они пытаются перейти на использование других более распространенных, более мощных и лучше поддерживаемых языков.
Этот тип многоязычного использования требует тщательного планирования. Это планирование должно ориентироваться на грань между потерей десятилетий знаний клиентов, с одной стороны, и потерей способности поддерживать программное обеспечение, с другой. Могут помочь методы, которые изолируют старый код за четко определенными интерфейсами и позволяют новому более мощному коду заменить старый код после того, как его поведение было хорошо задокументировано. Но этот унаследованный сценарий никогда не бывает легким и был (и будет) причиной гибели многих компаний и организаций в широком спектре размеров.
Причина 3 , доступность кодеров для различных языков, является прагматическим фактором, который проекты игнорируют на свой страх и риск. Несмотря на то, что организаторы проекта могут чувствовать (правильно или неправильно), что конкретный язык лучше всего подходит для их целей, если этот язык находится в противоречии с имеющимся у них языковым опытом, как расписание, так и качество продукта пострадают от обучения. изогнутые программисты пытаются выучить новый язык.
Более рациональный подход заключается в анализе языковых потребностей проекта на основе функциональных областей. Например, внимательный взгляд на проект может показать, что существует только небольшая «вершина» ценного кода, например, для реализации какого-то запатентованного алгоритма, который требует опыта кодирования на менее распространенном языке. Другие части любого крупного проекта часто легко приспосабливаются более распространенными языками или (что еще лучше) хорошо управляемыми продуктами с открытым исходным кодом. Таким образом, анализ проекта по языковым потребностям может обеспечить гораздо более реалистичный и экономически эффективный подход к найму или аренде специальных знаний по специальным языкам, а также может помочь улучшить взаимодействие между языками в рамках одного проекта.
Причина 4 , использующая разные языки для разных нужд, немедленно и безошибочно вытекает из такого анализа потребностей проекта. В этом также следует проявлять осторожность, поскольку выбор слишком большого количества языков для поддержки в рамках одного проекта может вызвать комбинаторный взрыв сложности как в поддержке, так и в интерфейсах между компонентами. Самый безопасный путь с точки зрения затрат - всегда сначала найти максимальные возможности для повторного использования, особенно если существуют хорошие пакеты, которые могут удовлетворить потребности проекта с помощью всего лишь настройки. Затем следует принять какое-то решение относительно небольшого числа языков, которые могут удовлетворить большинство выявленных потребностей. В разработке, требующей интенсивного повторного использования, это часто будет своего рода клейким кодом.
Как правило, не стоит выбирать несколько языков с очень похожими возможностями только потому, что некоторым участникам проекта нравится один, а другим - другой. Однако, если есть четко идентифицированные, четко определенные подмножества возможностей, которые могли бы получить пользу от специальных языковых навыков, это может быть хорошей причиной для использования нескольких языков для разработки нового кода.
Причина 5 , устойчивость к необходимым изменениям в используемых языках, может быть причиной серьезного нарушения проекта и внутренних раздоров. Как пользователь DaveoКак отмечается в комментарии к этому ответу, изменения могут быть очень сложными для некоторых сотрудников проекта. В то же время, сопротивление переменам никогда не бывает простым вопросом, и именно поэтому оно может вызвать много раздоров. Использование унаследованных языковых навыков может стать мощным стимулом для повышения производительности проекта, если унаследованный язык достаточно мощный и может привести к продукту с отличным качеством в команде, которая работает бесперебойно и уважает качество. Тем не менее, унаследованные языковые навыки должны быть сбалансированы с тем фактом, что многие более старые языки больше не могут дополнять более поздние языки с точки зрения расширенных функций, доступности компонентов, опций с открытым исходным кодом и поддержки интеллектуального набора инструментов.
И тогда, и сейчас единственным наиболее распространенным (и по иронии судьбы, наиболее часто правильным) аргументом для продолжения использования более слабого, менее читаемого или менее производительного унаследованного языка было то, что более старый язык позволяет создавать более эффективный код. Это старый аргумент, который восходит к 1950-м годам, когда пользователи языка ассемблера возмущались, часто с горечью, появлением программирования на FORTRAN и LISP. Пример, в котором даже сейчас аргумент эффективности кода может иметь достоверность, можно увидеть в интенсивно обрабатывающем коде, таком как ядро операционной системы, где C остается языком выбора по сравнению с C ++ (хотя по причинам, которые выходят за рамки простой эффективности).
Однако в глобальных сетевых и мощно поддерживаемых машинами проектных средах нового тысячелетия эффективность кода в качестве основного аргумента для выбора языка проекта стала еще слабее. Тот же взрыв вычислительного и сетевого оборудования, который позволил массово продвигать приложения для искусственного интеллекта, также означает, что затраты на человеческое программирование могут легко превзойти затраты на неэффективное выполнение относительного кода на невероятно дешевом оборудовании и облачном программном обеспечении. Когда это сочетается с большей доступностью для более поздних языков библиотек компонентов, опций с открытым исходным кодом и расширенных наборов интеллектуальных инструментов, число случаев, когда сохранение языка только по причинам эффективности становится очень узким. Даже в тех случаях, когда это применимо,
Более веская причина для того, чтобы проект оставался на устаревших языках, возникает, когда по тем или иным причинам у проекта мало или нет вариантов смены персонала. Это может случиться, например, когда основная линейка продуктов полностью написана на языке, которым владеет только существующий персонал. В таких случаях проект должен либо идти по пути попыток программирования на старом языке, либо пытаться обучить существующий персонал тому, как использовать новый язык.
Обучение сотрудников языкового наследия на новом языке само по себе может представлять опасность. Я до сих пор вспоминаю случай, когда участник проекта, который только что прошел обучение и перешел с C на C ++, искренне жаловался мне на то, что он просто не понимает преимуществ объектно-ориентированных методов. Когда я посмотрел на его код, он преобразовал свои более ранние 103 C-функции в 103 метода для одного класса объектов C ++ . и по праву не видел, как это помогло.
Более глубокий вывод заключается в том, что, когда люди программируют на одном языке и языковом стиле в течение многих лет или десятилетий, трудности с тем, чтобы заставить их «мыслить» по-новому, могут стать почти непреодолимыми, даже при наличии хороших программ обучения. В некоторых случаях не может быть никакого другого выбора, кроме как привлечь молодых дизайнеров и программистов, которые в большей степени соответствуют современным тенденциям и методам.
Причина 6 , плохое управление проектами, говорит само за себя. Выбор и использование языка в проекте всегда следует рассматривать и оценивать в явном виде, а не допускать случайности. По крайней мере, выбор языка может иметь огромное значение для долгосрочной судьбы и стоимости поддержки проекта, и поэтому всегда должен учитываться и планироваться. Не становись MUMPS!
На сегодняшний день существует несколько тысяч языков программирования, каждый из которых создавался с определенной целью, пытаясь изменить и улучшить недостатки своих предшественников. Так, например, появился язык Kotlin, который был нацелен на замену Java в мобильной разработке. В 2010 году увидел свет язык Rust, разработчики которого пытались создать быстрый и безопасный язык, который закрывал бы многие недостатки C/C++.
Сейчас практически никто не ставит цели создать универсальный язык для всех задач и всех платформ, так как в каждой области есть свои потребности и нюансы для языка. Например, если в системной разработке требуется следить за памятью, то в местах, где нужно написать простой рабочий продукт, можно пренебречь тем, сколько памяти использует язык для своей работы.
Но что делать, если необходимо использовать несколько языков программирования в одном проекте?
Можно попробовать объединить все эти наработки в одно приложение. Благо на сегодняшний день уже реализовано много библиотек, которые позволят без лишних проблем это сделать.
Цель статьи: попробовать написать одно приложение, где будет использоваться код, написанный на 5 разных языках программирования.
P.s. примеры собраны очень примитивные, так как цель проекта - показать, как можно объединить несколько кусков кода вместе.
Для того, чтобы запустить код Java из Python необходимо создать maven java проект (я пользуюсь IntellIJ). В нем создать модуль (я назвал его pkg_java) и в нем создать класс (название: JavaPrime) с логикой проверки числа на простоту методом Ферма:
Далее необходимо создать .jar файл из данного модуля, для этого в File->Project Structure необходимо создать новый Jar артефакт:
Создание jar-артефакта
После чего выполнить Build->Build Artifacts, высветится список всех доступных артефактов, необходимо выбрать только что созданный и нажать build, в итоге будет создан .jar файл модуля.
Путь к .jar файлу
Теперь необходимо подключить .jar файл к Python. Для этого первым делом нужно установить библиотеку JPype1, выполнив pip install jpype1 , и подключить созданный .jar к проекту:
Модуль Java был успешно загружен, теперь можно пользоваться тестом Ферма.
Назовем проект is_prime_csharp (данный проект в будущем будет импортироваться в Python с таким же названием). Реализуем логику алгоритма Милера-Рабин:
Кладем все .dll в проект python
Для связи С с Python сначала реализуем алгоритм квадратного корня для проверки числа на простоту:
Теперь создадим .dll из сишного кода. Для этого в папке с файлом is_prime_c.c через командную строку выполним:
gcc -c -DBUILD_DLL is_prime_c.c
gcc -shared -o is_prime_c.dll is_prime_c.o -Wl,--add-stdcall-alias
После чего в папке появится файл .dll, который так же необходимо поместить в Python проект и подключить:
Модуль C успешно загружен.
JavaScript
Связь Python и JS будет идти через библиотеку EEL, для этого сначала установим её в Python, выполнив pip install eel . Далее создадим HTML документ и JS файл, в HTML файле добавим eel.js и js файл с логикой суммы ряда (см подробнее проект на github). В js файле реализуем логику суммы ряда и обернем функцию дополнительно в eel.expose для того, чтобы эту функцию можно было вызвать из Python:
В main.py пропишем логику запуска программы:
С такой структурой программы:
структура Python проекта
И вызовем метод JS из Python:
Python
Для начала реализуем метод факторизации чисел:
В файле logic.py соберем все проверки в одной функции , чтобы данную функцию можно было вызвать из JS обернем её в eel.expose:
Результат
Программа имеет простой графический интерфейс:
интерфейс итоговой программы
Необходимо ввести число в поле “Число” и нажать кнопку “выполнить”. После чего через JS обработать нажатие данной кнопки и вызвать метод из Python:
Теперь можно запустить программу и проверить, будет ли всё вместе работать:
Тест программы простым число 12421 Тест программы составным числом 12879
Вывод
Связать несколько языков программирования вместе в одной программе возможно, но это не совсем хорошая идея, так как при запуске программы на стороннем ПК надо быть уверенным, что у пользователя установлены нужные сервисы/зависимости/ПО, например, стоит ли JVM. Для быстрой проверки работоспособности каких-то идей, модулей, логики можно попробовать использовать подход, описанный в статье. Данный способ позволяет экономить кучу времени, вместо того, чтобы мучаться и переписывать код на другой язык в надежде, что всё будет работать как надо. Этот способ может подойти в тех случаях, когда нет возможности разработать адекватную микросервисную архитектуру приложения, а нужно использовать несколько разных кусков кода/модулей.
Я молодой, поэтому мне нужно многому научиться:)
Вопрос, который застрял у меня в голове : я слышал, что некоторые люди программируют на нескольких языках в одном проекте.Я не могу представить, как языки взаимодействуют друг с другом.
Я имею в виду, что нет метода Java, такого как
никогда не бывает .. или я ошибаюсь ? :)
наличие нескольких языков в одном проекте на самом деле довольно распространено, однако принципы не всегда просты.
становится сложнее, если языки / компиляторы используют систему разных типов. Может быть много разных способы, основные типы данных, такие как integer, float и doubles представлены внутри, и есть еще больше способов представления строк. При передаче типов между разными языками необходимо убедиться, что обе стороны интерпретируют один и тот же тип или - если нет - типы правильно сопоставлены. Этот вид отображения типов также известен как упорядочить.
классические примеры взаимодействия между различными языками программ (в основном из Windows мир):
Как правило, любой веб-проект приличного размера будет использовать около пяти языков: HTML, CSS, Javascript, какой-то серверный язык "getting things done" (ASP, JSP, CGI-скрипты с Perl, PHP и т. д.), и некоторый вариант SQL для подключения к базе данных.
(Это, конечно, рука, отмахивающаяся от аргумента о том, считаются ли HTML и CSS языками программирования – я" они, но просто не полные языки Тьюринга", но это целый другой нитка.)
некоторые примеры того, как все это работает вместе:
Если вы идете по маршруту лучших практик, структура веб-страницы находится в HTML, а инструкции по ее отображению – в CSS, которые могут быть в том же файле, но не должны быть. CSS содержит кучу классов, на которые ссылается HTML, и браузер должен выяснить, как щелкнуть их вместе.
принимая все это на шаг дальше, любые сценарии javascript на этом страница может изменить любой из HTML / CSS, который присутствует (изменить содержимое HTML-сущностей, поменять один класс CSS на другой, изменить поведение CSS и так далее.) Он делает это с помощью чего-то, называемого объектной моделью документа, которая по существу является независимым от языка и платформы API для управления HTML-страницами объектно-подобным образом (в этот момент я медленно отступлю и просто предоставлю ссылку на соответствующая статья wiki.)
но тогда, где же все HTML / CSS / Javascript пришли? Это то, что делает серверный язык. В простейшей форме язык serer-side-это программа, которая возвращает гигантскую строку, содержащую HTML-страницу в качестве ее вывода. Это, очевидно, может стать намного сложнее: HTML-формы и параметры строки запроса могут использоваться в качестве входных данных для нашей серверной программы, а затем у вас есть вся вещь AJAX, где javascript получает возможность отправлять данные непосредственно на серверный язык. Вы также можете получить фантазии, где сервер язык может настроить HTML, CSS и Javascript, который выплевывается – по сути, у вас есть программа на одном языке, пишущая программу на другом языке.
серверный язык для подключения SQL работает почти так же. Есть много способов сделать его более сложным и безопасным, но самый простой способ для вашего языка сервера-динамически создавать строку с командой SQL в ней, передавать ее в базу данных через какой-то соединитель и возвращать результирующий набор. (Этот это случай, когда у вас действительно есть функция, которая сводится к someValue = database.executeThisSQLCommand( SQLString ). )
Итак, чтобы обернуть это, разные языки в этом случае либо общаются, фактически написав программы друг в друге, либо передавая данные в очень простых, легко разбираемых форматах, которые каждый может понять. (В основном струны.)
несколько языков в использовании называется "совместимость " или" взаимодействие " для краткости.
ваш пример неправильный. Java может вызывать функции C.
язык обеспечивает механизм взаимодействия.
и я могу вызвать его из Python (IronPython)
и получить ожидаемый результат.
вообще говоря, некоторые языки взаимодействуют лучше, чем другие, особенно если авторы языка специально сделали взаимодействие особенностью языка.
несколько языков могут взаимодействовать с:
- Piped вход-выход (любой язык может сделать это потому что вход и выход должны быть обязательно реализованы в каждой не-игрушке язык)
- наличие кода на одном языке компилируется в родную библиотеку в то время как другой поддерживает вызов собственного кода.
- связь по закольцованной сети. Вы можете таким образом, возникают трудности с вмешательством брандмауэра.
- базы данных. Это может быть мыслится как "универсальные" данные формат хранения, и, следовательно, могут быть доступны на большинстве языков с расширениями базы данных. Это вообще требуется одна программа для завершения работы перед следующей программой доступ к базе данных. Кроме того, все "коммуникации" являются обычно записывается на диск.
- Если языков работать на том же времени (т. е. .Чистая, JVM), то вы вообще можете передавать объектные данные с одного языка прямо к другому с небольшим импеданс.
У вас может быть приложение, где основная часть работы выполняется на Java, но может быть какая-то ее часть, например, парсер данных или что-то написано на Python или что у вас есть. Почти два отдельных приложения на самом деле, возможно, парсер просто делает некоторую работу над файлами, а затем ваше основное приложение на Java использует их для чего-то. Если бы кто-то спросил меня, что я использовал в этом проекте, я бы сказал "Java и Python."
существует много разных способов использования разных языков в одном проекте Существует две основные категории, которые приходят на ум
- использование разных языков вместе для создания одного приложения. Например, используя Java для создания GUI и используя JNI для доступа к API C (поэтому, отвечая на ваш вопрос, вы можете вызвать функции C из Java ;))
- совместное использование разных языков в одном проекте, но они не являются частью одного и того же приложения. Например. Я в настоящее время работает на iphone приложение, которое использует большое количество текста. В настоящее время я использую три языка Python (для работы с исходными источниками текста), SQL (чтобы поместить результаты приложения python в формат, легко доступный из api iphone sqlite3) и Objectiv C для создания фактического приложения. Несмотря на то, что конечный продукт будет только объективным C, я использовал два других языка, чтобы добраться до конечного продукта
существуют различные способы использования нескольких языков в одном проекте. Некоторые примеры:
- вы можете написать DLL, скажем, в C, а затем использовать эту библиотеку, скажем, из программы VB.
- вы можете написать серверную программу, скажем, на C++, и иметь много разных языковых реализаций клиента.
- веб-проект часто использует множество языков; например, серверная программа, написанная, скажем, на Java( языке программирования), которая извлекает данные из базы данных, использующей SQL (язык запросов), отправляет результат в браузер в формате HTML (язык разметки), с которым пользователь может взаимодействовать с помощью Javascript (язык сценариев).
существует несколько способов, которыми код на языках может взаимодействовать напрямую. Пока данные передаются между кодом в правильном формате, на уровне битов и байтов, нет причин, по которым разные языки не могут взаимодействовать. Этот подход используется в традиционной разработке DLL windows. Даже на разных платформах, если вы можете получить правильный формат (посмотрите на big / little endian, если это интересно), он будет работать до тех пор, пока ваш компоновщик (не компилятор) знает, как присоединиться к коду вместе.
плохо. Если нет срочной необходимости, придерживайтесь одного языка. Вы увеличиваете зависимость и сложность. Но когда у вас есть существующий код, обеспечивающий интересную функциональность,его легче склеить, чем воссоздать.
чтобы добавить в список примеров, довольно часто оптимизируют код Python на C или C++ или пишут библиотеку C для привязки другой библиотеки к Python.
В мире существует несколько тысяч языков программирования. Несмотря на то, что многие из них крайне непопулярны, очень специфичны или уже созданы очень давно, они продолжают существовать, а новые языки продолжают появляться. Похоже, нет оснований полагать, что количество языков когда-нибудь начнет уменьшаться и в конечном счете будет создан один универсальный язык программирования. Большое количество языков может пугать своей необъятностью, но новое понимание идеи многоязычных проектов позволяет не только ориентироваться в этом разнообразии, но и видеть очевидную выгоду для всех.
Содержание
Возникновение новых языков, языковые платформы
До сих пор не создано такого языка программирования, который бы одинаково хорошо решал все задачи программных систем. Уже существует большое количество языков и новые продолжают появляться. Устаревшие языки не спешат уйти со сцены, на них написаны программы, и они продолжают работать, а значит, по ним нужны специалисты для сопровождения и развития существующих программ. Возможно, не стоит ориентироваться на устаревшие или не получившие достаточного распространения языки, но, например, если вы вдруг надумаете устроиться программистом в компанию Боинг, то вам придется изучить язык достаточно прогрессивный для своего времени и не очень распространенный в наше - язык Ада.
Текущее представление языков примерно выглядит так:
Есть множество причин, по которым создаются новые языки. Самая общая из них заключается в появлении новых задач, требованиям которых не удовлетворяют в полной мере существующие языки. Вот несколько причин возникновения новых языков:
Следующая таблица демонстрирует, что несмотря на наличие существующих языков, решающих сходные задачи, известные ИТ компании создают собственные языки, а не переиспользуют готовые.
Таблица 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 как самые приближенные к предметной области языки. Эти языки будут иметь самый низкий порог вхождения и будут доступны даже для непрограммистов.
Профессиональным программистам необходимо смириться с необходимостью знать несколько языков программирования. С одной стороны, знание нескольких языков может сильно увеличить умственную нагрузку на программиста, с другой - все языки обладают сходными синтаксическими конструкциями, а значительную трудность в освоении языков составляет семантика и стандартная библиотека языка.
Материал этой статьи был представлен ранее в сокращенном варианте новостного формата. Там же есть опросник "Сколько языков программирования вы знаете?". Новость получила живой отклик. Тема мне показалась интересной, и я решил выложить полный вариант статьи, получившейся в результате моего исследования.
Я программировал некоторое время, я написал несколько элементарных программ и хочу продолжать учиться. Я достиг той точки, когда вы просто не знаете, чему учиться дальше, и я хотел бы задать вопрос для моего собственного любопытства.
Вопрос в двух словах: можно ли объединить несколько языков программирования в один результат? Например, может ли этот код быть возможным?
Это похоже на глупый вопрос, но я не могу знать, возможно это или нет, поэтому я и задаю его. В этом вопросе я замечаю, что он использует код Python в html-коде, если мой приведенный выше пример невозможен, что он сделал?
Чтобы это работало (не делая людей безумными), нужны как минимум строгие правила относительно того, как они взаимодействуют и какие части должны обрабатываться на каком языке.
@Brian Lua встроен в то, что интерпретатор связан с некоторым кодом C или C ++ и используется для запуска кода Lua, хранящегося в строках или внешних файлах, возможно, подвергая объекты C / C ++ коду Lua. Lua не (не часто, если вообще) не «встроен» в смысле этого вопроса.
Это все равно, что сделать пять алфавитов, каждый с разными символами для 26 букв, и смешать их в одной книге: бессмысленно, раздражающе и излишне.
Я думаю, что люди явно забывают о наиболее распространенном (и единственно допустимом из реальной жизни, который я могу придумать) случае использования «объединения языков» - фрагментов ASM в программах на C / C ++ , обычно по соображениям производительности.
Ваш первый пример является своего рода возможным. Обычно такие вещи случаются в PHP (и других связанных языках веб-программирования), например:
Несколько важных моментов, на которые следует обратить внимание в этом примере:
- HTML НЕ является языком программирования, это язык разметки.
- PHP и HTML и не выполняются / интерпретируются в одном месте: код PHP выполняется интерпретатором PHP, работающим на сервере, и результат «внедряется» в окружающий HTML. Затем весь этот большой двоичный объект отправляется клиенту / браузеру, который отображает полный HTML-код.
Ваш второй пример выглядит как некое сочетание C ++ и Java. Возможно, что скомпилированные модули, написанные на разных языках, общаются друг с другом, но объединить Java и C ++ в одном исходном файле было бы крайне запутанным и трудным: как бы компилятор узнал, какие операторы являются Java, а какие - C ++?
Полагаю, теоретически вы могли бы написать специальный компилятор / препроцессор с такими «языковыми» индикаторами, как:
Но я, честно говоря, не уверен, что ты получишь что-нибудь полезное, сделав это.
Кроме того, как эта гибридная языковая среда будет обрабатывать языковые функции, которые несовместимы между ними?
Пример все забыли о (включая меня), поэтому , пожалуйста , не стесняйтесь , чтобы добавить его в свой ответ: CUDA . Это смесь двух совершенно разных языков Си, с некоторыми функциями, скомпилированными для устройства (GPU), а некоторые остаются на хосте, с выводом уровня связи.
На самом деле, нет.
Вложение
Как правило, один исходный файл содержит код точно для одного языка программирования. Нередко объединение нескольких языков в одном файле по нескольким причинам:
- Парсинг нескольких синтаксически разных языков одновременно чрезвычайно труден (если не невозможен).
- Разные языки относятся к программированию по-разному . Понятие функции в Haskell отличается от понятия C ++.
соединение
Различные языки программирования, которые совместно используют общий двоичный интерфейс приложения, могут быть объединены в единый исполняемый файл или библиотеку. Получение подписей двух языков внутри друг друга часто требует небольшой работы, но существуют инструменты, облегчающие этот процесс.
полиглотов
Код полиглота действителен и эквивалентен на нескольких языках. На странице 404 Stack Overflow есть одна такая программа:
Это печатает «404» на Python, Perl, Ruby, C, Brainfuck и Befunge.
Вывод
Языки редко смешиваются в файлах, и когда они есть, это для смеха . Люди даже стараются избегать смешения языков в проектах из-за дополнительных хлопот, которые он создает. Таким образом, хотя это технически возможно, смешивание разных языков не является ни распространенным, ни прагматичным.
Языки не всегда смешаны для смеха. Большинство компиляторов C позволяют смешивать ассемблер и C, как и многие Forths. В восьмидесятые годы один из лучших диалектов BASIC в игре, Acorn BBC Basic, позволял вам смешивать сборку 6502, и тогда это была очень желательная особенность. Это, конечно, заставляло пользователей BBC смеяться, но почти все остальные плакали, особенно те, кому приходилось собирать машинный код 6502 вручную и вставлять необработанные коды операций в свои программы в DATA операторах. Не то чтобы я горький или что-то в этом роде. Noooo.
Одна из печальных вещей в современной разработке программного обеспечения состоит в том, что многоязычные приложения стали намного сложнее. В прежние времена DOS почти все компилировалось в один и тот же объектный файл и использовало те же соглашения о передаче параметров. Было очень легко просто связать их вместе. В наше время не так много .
Да, это действительно возможно. Конечно, не так, как вы себе это представляли. Есть несколько языков , созданных специально для этой цели.
Это часто называют кодом полиглота - есть несколько забавных / безумных примеров, если вы переходите по ссылке или в других местах в Интернете. Большинство из них просто для развлечения / доказать, что это возможно.
Более серьезно, есть различные примеры из реальной жизни, где два или более разных языка могут быть с пользой объединены:
- Веб-шаблоны - языки, такие как файлы PHP или JSP, смешивают код в HTML. Мнения сильно различаются по поводу того, хорошая это идея или нет.
- Языки макросов - часто язык макросов смешивается с исходным файлом, таким как макросы препроцессора C / C ++. Есть также интересные случаи, такие как Lisp, где язык макросов сам по себе является Lisp (единственное отличие состоит в том, выполняется ли код во время компиляции или во время выполнения)
- DSL - часто определяется язык, специфичный для предметной области, чтобы помочь эффективно решить конкретную проблему, которая встроена в исходный код другого языка. Вот пример прекрасного DSL для SQL, который может быть встроен в код Clojure.
- Сценарии - некоторые динамические языки особенно полезны для коротких сценариев и предназначены для встраивания в программное обеспечение, написанное на другом языке. Например, скрипты Groovy очень легко внедрить в Java-приложение.
- Проекты Polyglot - иногда имеет смысл использовать несколько языков только для того, чтобы использовать различные возможности каждого из них. Например, JVM поддерживает несколько языков, которые могут прозрачно взаимодействовать, поэтому вы можете смешивать Java (для скорости и статически типизированного ООП) с Clojure (для интерактивной разработки, параллелизма и функционального программирования). Такие проекты, как правило, по-прежнему разделяют разные языки на отдельные исходные файлы / папки, но они компилируются одновременно для создания одного приложения.
Можно использовать некоторую комбинацию языков, используя Perl Inline, которая позволяет писать Perl-скрипт и вставлять фрагменты кода, написанные на другом языке:
Inline поддерживает C, C ++, Java, Python, Ruby, Tcl, Assembler, Basic, Guile, Befunge, Octave, Awk, BC, TT (Template Toolkit), WebChat и даже PERL.
Я никогда не слышал о Perl Inline. Это интересная идея, но дает ли она какое-либо преимущество по сравнению с тем, что, вероятно, является обычным подходом иметь отдельные модули для не-PERL-кода?
@FrustratedWithFormsDesigner: Inline Perl - отличный модуль, но у него есть некоторые недостатки. Это работает хорошо, но только в объеме довольно простого кода. Несмотря на то, что над ним какое-то время работали, я бы не стал его использовать в любом виде производства.
Встроенный SQL был распространенным способом встраивания операторов SQL в программы других языков.
В наши дни его почти полностью заменил более простой для компиляции доступ к базе данных на основе API, который не требует изменения языка хоста, но вместо этого использует его обычные возможности.
@ SK-логика: как LINQ похож на встроенный SQL? Это не другой язык, это просто применение дополнительных языковых конструкций на языке хоста.
LINQ - это очень типичный встроенный DSL, семантически чуждый языку хоста. И, в случае LINQ2SQL, он ведет себя точно так же, как старый встроенный SQL, он буквально переводится в SQL.
Но встроенный SQL не «переводится на SQL». Вы пишете литеральный SQL внутри вашего C-кода (и обычно не внутри строковых констант). Несмотря на то, что LINQ использует языковые функции, которые (насколько я знаю) были разработаны специально для LINQ, это «всего лишь» API в пределах его основного языка.
Pro C и Pro Fortran немного переводили операторы SQL. И LINQ - это не просто API, это API с синтаксическим сахаром и набором взаимозаменяемых внутренних компонентов компилятора. Что делает его идеальным примером полноценного встроенного DSL.
Несколько языков программирования могут быть использованы для формирования 1 exe. Одним из способов является использование DLL. Конечно, есть различные опасения по этому поводу. Например, параметр совместимости, COM-совместимость и тому подобное. Фактически, если вы думаете о том, как вы называете систему баз данных для своей работы, вы можете обнаружить, что СУБД не всегда написана на языке, который вы знаете. Возможно, вам даже все равно, если интерфейс известен.
Эта концепция получает дальнейшее развитие, когда ваше решение использует веб-сервисы, что является еще более чистым способом объединения нескольких программных компонентов.
В мире UNIX одно время мы использовали скрипты KShell для запуска программ на C ++ и COBOL, чтобы решение могло работать.
Я думаю, что здесь стоит упомянуть Cython . Это расширенный набор Python для написания расширений C, и хотя он сам по себе является уникальным языком, он в значительной степени позволяет использовать код C в коде Python, если вы соответствуете синтаксису стиля Python в Python
Примеры объединения языков: Jython (python в Java), Cog (python используется как генератор встроенного кода практически во всем). Я часто использовал Perl-код для генерации C ++, если вы считаете генерацию кода.
Я не думаю, что это означало оригинальный постер. Полученный байт-код имеет очень мало общего с тем, как он был написан на языке, с которого он был скомпилирован.
Я не думаю, что вы поняли вопрос. Автор говорит о объединении нескольких языков в один непонятный файл.
Очень сложно, очень некрасиво и часто бесполезно объединять несколько языков программирования в один файл.
Однако возможно иметь большой проект, написанный на более чем 1 языке. Например, и Mozilla Firefox, и MySQL содержат код на C и C ++. Когда речь идет о больших проектах, эта практика часто используется, потому что определенный язык предоставляет некоторые функции, а другой нет. Например, в PHP вы можете запросить выполнение двоичного исполняемого файла, взять его результат и использовать его в своем PHP-коде с этого момента.
Вы можете «смешивать» языки в HTML. На самом деле важно, как много веб-сайтов работают, чтобы вы могли встраивать javascript в html. Но, конечно, HTML - это разметка, а не язык программирования.
Я думаю, что делать то, что вы предлагаете, повлечет за собой написание нового языка в любом случае. Либо вам нужно будет создать интерпретатор / компилятор, который бы говорил на всех этих языках и мог бы согласовывать их последовательно, либо вам понадобился бы какой-то способ явной поэтапной оценки на том, что будет метаязыком. Эти два варианта в основном одинаковы, за исключением того, что программист должен сделать, чтобы языки работали вместе.
+1 о смешивании языков в HTML, но я лично считаю, что лучше разделить HTML / CSS и JS. Веб-дизайнеры могут делать свое дело, не пытаясь пробираться сквозь неровный JavaScript, встроенный в сайт.
Вы можете смешивать языки в HTML, но не многие из них являются языками программирования , о чем и идет речь.
А? Javascript не является языком программирования? PHP? Я также видел инъекции perl и python, хотя это было с модулями Apache.
Язык - это инструмент. Перед тем, как выбрать инструмент (более того, сделать какую-нибудь странную комбинацию Хаммер-ПК-спектроскоп), следует спросить себя - что именно я хочу сделать ?? Как только ответ будет дан, вы обнаружите, что такое смешение языков редко требуется.
Однако смешивание языков может затруднить чтение и модификацию кода, поэтому делать это следует осторожно. Одним из способов решения этой проблемы является создание отдельных файлов для кода на языке, который вам нужно вызывать, и его импорт, а не встраивание.
Читайте также: