Почему не написано больше приложений на нескольких языках?

Question

Даже 2 десятилетия назад можно было назвать код, написанный на одном языке, для вызова кода, написанного на другом; в школе мы называли ассемблерные графические процедуры из кода Ada для одного задания класса. Заметные исключения: запуск скомпилированного кода из сценариев или выполнение системной команды из скомпилированного кода; но редко мы пишем библиотеку на C ++ для использования в нашем приложении Java. Когда впервые появилась Java, и она все еще работала медленно, была возможность написать основное приложение на Java и переместить код узкого места в некоторую библиотеку C / C ++, которая будет вызываться с использованием JNI.

Итак, после всех этих лет, что мешает нам писать многоязычные приложения? Основной сценарий, который я имею в виду, - это когда язык считается хорошим выбором, если бы он не был узким местом для производительности (как в первые дни Java), поэтому он полностью написан на C, а не использует смесь двух языков.

Меня интересует это с точки зрения архитектуры, а также языкового дизайна. У вас есть хорошие примеры, истории успеха или цитаты?

[Изменить] Одним из лучших примеров этого была обратная реакция на Java из-за ее низкой производительности на ранних этапах. Несмотря на то, что JIT-компиляторы решили эту проблему, мой вопрос всегда был о написании программного обеспечения на языке, который облегчает написание, чтение и обслуживание. Если есть узкое место, напишите процедуру в сборке или C только для узкого места. Таким образом, вы должны получить лучшее из обоих миров, по крайней мере, теоретически.

Answer 1

Я думаю, что основная причина в том, что нет веских причин для этого. Если у языка есть особенность, достаточно привлекательная для использования (например, ориентация объекта), то, вероятно, она достаточно убедительна для использования для всего проекта. BITD, раньше было то, что вы переписывали части своего кода на ассемблере, если он был недостаточно быстрым, или писали адаптеры, чтобы вы могли вызывать статистический пакет FORTRAN из C. В настоящее время не возникает большого давления сделать это. Многие проблемы с производительностью не могут быть исправлены в коде (например, задержка в сети), и большинство компаний, которые предоставляют программные компоненты, предоставляют их в нескольких «вариантах» (например, файлы JAR Java или компоненты .NET). Как уже упоминали другие, среди многих разработчиков также наблюдается значительная инерция, которая не позволяет им изучать новый язык, особенно если он отличается. И, конечно, если язык не отличается от , то, вероятно, нет веских причин для его изучения.

Answer 2

В моих домашних проектах я вызываю процедуры на Фортране из C, или процедуры из C из C ++.

В моем рабочем коде мы смешиваем Java с небольшим количеством C.

Это все еще случается, но люди стараются избегать этого по веским причинам.

Answer 3

Даже будучи начинающим программистом, я чувствовал, что мне нужно использовать немного языка ассемблера в коде C, чтобы ускорить процесс. (Это было для отслеживания строки с помощью камеры, используя довольно медленную плату процессора для класса)

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

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

Answer 4

Я не уверен, в чем причина, но я думаю, что это во многом связано с менталитетом «language-du-jour», который у нас появился в конце 90-х годов. Я собираюсь начать сводящий с ума проект, который я хочу написать на C ++, но я хочу быть доступным на многих других языках. Я, вероятно, буду использовать комбинацию Swig и SpiderMonkey для этого.

Но многое из этого действительно сводится к тому, что никто не создает единый интерфейс объекта / повторного использования, за исключением .DLL. COM отлично работал на Windows. IDispatch сделал доступными все, что говорит IDispatch. Было здорово писать наши компоненты на C ++ и использовать их из VBScript в ASP. Но ничего подобного никогда не происходило переносимо. Конечно, попытки были предприняты через CORBA и полдюжины других полусгоревших и часто плохо получаемых технологий - но у них у всех есть проблема с сортировкой данных, проблемы с вызовами, проблемы с производительностью, проблемы с порядком байтов. Никто на самом деле не тратил время на его решение, и теперь индустрия развивается в направлении SOAP, чтобы заменить его там, где производительность не учитывается (и придерживается CORBA, где это происходит).