Что делает язык «оптимизированным» для конкретной задачи?

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

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

Я говорю о полных тьюринговых языках, эквивалентных по Тьюрингу.

Есть несколько вещей для рассмотрения:

• Абстракция: что язык воспринимает как «особый»? Являются ли матрицы первоклассными значениями, как в Matlab, или вы кодируете их, используя более простые типы, такие как массивы, как в C? C заставляет задуматься о том, как реализованы матрицы, а Matlab - нет.

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

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

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

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

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

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

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

Например, умножение использует различные случаи (см. GMP умножение .

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

Пожалуйста, взгляните на матричные вычисления рангов в Matlab, Mathematica и Maple (сейчас я не могу выполнить все тесты самостоятельно, но они соответствуют моим тестам). Все эти языки (среды) реализуют одну и ту же операцию более высокого уровня, но детали реализации отличаются, что дает разное время.

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

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

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

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

Это отличный вопрос, на который сложно ответить. Есть ли что-то в языке Erlang, которое делает его пригодным для телекоммуникационных приложений в реальном времени? Или это что-то про компилятор Erlang? Или это что-то о сообществе и экосистеме Эрланга? Возможно, это то, что люди, которые знают, как писать приложения для связи, являются экспертами в Erlang, а люди, которые знают Erlang, являются экспертами в приложениях для телекоммуникаций? Я подозреваю, что все эти факторы играют роль.

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

В других ответах упущен смысл оптимизации языка для конкретной задачи - дело не только в том, что ускоряет выполнение кода на данном оборудовании; речь идет о том, насколько четко и кратко конкретный язык позволяет выразить решение проблемы. Это очень сильно зависит от предметной области, и (наряду с рекламной шумихой, незнанием существующих решений и эгоизмом написания нового языка) у нас много языков - цель состоит в том, чтобы программист написал меньше кода, что это менее подвержено ошибкам и легче для следующего программиста читать / понимать / исправлять / улучшать.

Например, и C, и C ++ могут использоваться для объектно-ориентированного программирования - и действительно, библиотека GObject является хорошим примером OO C. AC-структура, содержащая указатели функций, может служить той же цели, что и виртуальные методы в классе C ++, и может выполнять лучше; Нарушением разработки является склеивание кода для выделения памяти, инициализации указателей функций и выбора стратегии для вызова «родительских» методов. В большинстве случаев печатать проще / безопаснее, Class klass * = new class()чем struct class *klass = malloc(sizeof(struct class));klass->fn1 = ...;klass->fnN = ....