Почему вы или не внедряете решения с использованием полиглотов?

Question

Решения Polyglot, или многоязычные, позволяют применять языки к задачам, для которых они лучше всего подходят. Тем не менее, по моему опыту, магазины программного обеспечения стремятся применять «супер» язык ко всем аспектам проблемы, которую они пытаются решить. Придерживаться этого языка придет «ад или высокая вода», даже если доступен другой язык, который решает проблему просто и естественно. Почему вы или не внедряете решения с использованием полиглота?

Answer 1

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

Преимущества многоязычности сводятся к «правильному инструменту для работы».

Существуют законные недостатки:

• Сложнее иметь коллективное владение кодом (не каждый разбирается во всех языках)
• Проблемы интеграции (уменьшено на управляемых платформах)
• Увеличение времени выполнения библиотек инфраструктуры (это часто имеет значение)
• Увеличение затрат на инструмент (IDE, инструменты анализа и т. Д.)
• Когнитивные "шишки" при переключении с одного на другое. Это обоюдоострый меч: для тех, кто хорошо разбирается, разные парадигмы дополняют друг друга, и когда возникает проблема в одной, часто возникает «но в X я бы решил это с помощью Z!» и проблемы решаются быстро. Тем не менее, для тех, кто не совсем понимает парадигмы, может быть реальное замедление при попытке понять «Что это?»

---

Я также думаю, что следует сказать, что если вы собираетесь использовать много языков, то, по моему мнению, вы должны использовать языки с совершенно разными подходами. Я не думаю, что вы много выигрываете в решении проблем, если, скажем, и C #, и VB работаете над проектом. Я думаю, что в дополнение к основному языку вы хотите иметь язык сценариев (высокая производительность для небольших и одноразовых задач) и язык с серьезно отличающимся когнитивным стилем (Haskell, Prolog, Lisp и т. Д.).

Answer 2

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

Это означало, что когда мы нашли несколько полезных Perl модулей (например, тот, который реализует «закон Бенфорда», Statistics::Benford), мне пришлось научиться использовать PDK ActiveState.

Когда мы решили добавить интервальную математику в наш проект, мне пришлось изучить Аду и узнать, как использовать GNAT и ObjectAda.

Когда была запрошена высокоскоростная библиотека строк, мне пришлось заново изучать ассемблер и привыкнуть к MASM32 и WinAsm.

Когда мы хотели получить COM-библиотеку libiconv (основанную на коде Delphi Inspiration), я снова познакомился с Delphi.

Когда мы хотели использовать libuninum доктора Билла Позера, мне пришлось заново изучать C, и как использовать IDE Visual C++ 6.

Мы все еще создаем прототипы вещей в VB6 и VBScript, потому что они хороши в этом.

Может быть, когда-нибудь в будущем я закончу делать что-то в Форт, или Эйфелевой, или Ди, или, черт возьми, помоги мне, Хаскелл (у меня нет ничего против языка как такового, это просто очень другая парадигма.)

Answer 3

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

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

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

Практически весь мой профессиональный опыт программирования был в вышеуказанной категории. Обычно на периферии есть основной язык (C или C ++), SQL различной степени, сценарии оболочки и, возможно, некоторый код на perl или python.

Answer 4

Мне повезло работать в небольших проектах с возможностью предложить подходящий язык для моей задачи. Например, C как язык низкого уровня, расширение Lua для высокоуровневого / прототипирования очень хорошо послужило, быстро набирая скорость на новой встроенной платформе. Я всегда предпочел бы два языка для любого более крупного проекта, один для конкретного домена, подходящий для этого конкретного проекта. Это добавляет много выразительности для быстрого опробования новых функций.

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

Answer 5

Ну, теперь весь интернет - это полиглот с Java / PHP / Ruby сзади и JavaScript впереди ... Другие примеры, которые приходят на ум - гибкая сложная система, написанная на языке низкого уровня (C или C ++) со встроенным языком высокого уровня (Python, Lua, Scheme) для обеспечения интерфейса настройки и сценариев. Microsoft Office и VBA, Blender и Python.

Проект, который может быть выполнен на языке сценариев, таком как Python, с критическими для производительности или зависящими от ОС частями, выполненными на C.

И JVM, и CLR получают много новых совместимых языков сценариев. Java + Groovy, C # + IRonPython и т. Д.

Answer 6

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

Я подозреваю, что главная причина, однако, заключается в том, что переключение между разными языками приводит к неэффективности программиста. В этом есть доля правды: я постоянно переключаюсь между JavaScript, C #, VBScript и VB.NET и теряю немного времени, когда переключаюсь с одного языка на другой, немного смешивая синтаксис.

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