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

15

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

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

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

esote
источник
1
Это энциклопедический вопрос. Я предлагаю вам как-то разбить его, сделать более конкретным.
Андре Соуза Лемос,
5
Было бы неправильно говорить «маркетинг»?
CorsiKa
2
@corsiKa Да, я думаю, что это больше, чем вопрос маркетинга.
Джереми Вест

Ответы:

18

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

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

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

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

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

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

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

jmite
источник
8

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

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

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

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

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

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

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

Зло
источник
9
Большинство языков по Тьюрингу полно по спецификации, так как не все из них указывают фиксированные размеры адресов в своей спецификации. И довольно ограниченно терять различие между такими вещами, как C, которые имеют размер адреса Turing Complete по модулю, и такими вещами, как Coq, Agda или System F, которые вообще не являются Turing Complete.
Jmite
1
@jmite спасибо. Я надеюсь, что это больше не скрывает различий
Зло
@ Evil: Ну, я думаю, что ваше утверждение о языках, которые не должны быть оптимизированы для задач, неверно. вы видите слово оптимизировать с точки зрения компьютера. Но некоторые языки предназначены для того, чтобы облегчить это только программисту, и разработчики могут понять, как заставить его работать.
Доктор
Это с точки зрения эффективности, так что это не так, я просто взял этот угол, вы могли бы рассмотреть другой (оптимизированный, что означает, что в него легче писать некоторые конкретные задачи). «Что касается языка, то он лучше подходит для конкретной задачи или конечной цели, чем другие языки [...]», я очень уверен, что: «легче писать, быстрее, дешевле и т. Д.» Может быть включено в «лучше». Автор не принял какой-либо ответ и не включил пояснения или комментарии о том, что любой из приведенных ответов не относится к тому, что было задано. Кроме того, это один из факторов, для некоторых людей более важных, чем для других
Зло
5

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

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

j_random_hacker
источник
4

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

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

Майкл Кей
источник
3

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

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

Фил Лелло
источник
Что ж, ответ jmite дает маркером то, чего вы не написали. Я писал о конкретных задачах, которые оптимизированы для этого вопроса. Мне нравится C, я знаю такие вещи, как OCC, но это не делает объектно-ориентированным C (компилятор не помогает с этим, и многие оптимизации предотвращаются, сборщик мусора и т. Д.). Вы не можете перегружать функции C, как в C ++, но, конечно, вы можете эмулировать любое поведение (jmite также писал об этом). Я не вижу, как это отвечает на поставленный вопрос.
Зло
2
@ Evil: объектно-ориентированное программирование и объектно-ориентированный язык программирования - это две разные концепции. Объектно-ориентированное программирование не требует объектно-ориентированного языка. Возможно, это просто требует наличия бумаги или доски, чтобы вы могли сделать свой дизайн UML.
Slebetman
@ Slebetman Я не ожидал этого. Возможно, вам не нужны бумага и белая доска, вы можете просто представлять объекты, и, по мнению некоторых людей, мы так думаем, но это не приближается к языковой поддержке концепций ООП. Извините, но это спор, я не хочу выбирать.
Зло
@Evil: я не уверен, что смогу все это мысленно отслеживать без какой-либо абстракции, чтобы помочь вам. Моей первой работой был большой кусок кода на C, который выглядел как все массивы с указателями на функции (мне потребовалось некоторое время, чтобы понять, что означает странный синтаксис - тогда не было Google), и я боролся с этим, пока не начал видеть шаблон и понял, что эти массивы являются объектами, а указатели на функции - методами. Купил себе маленькую доску и израсходовал много бумаги формата А4, но наконец мне удалось понять код
slebetman
1
@slebetman Учитывая, что объектно-ориентированное программирование предшествует UML как минимум на 20 лет, ваше утверждение о том, что UML-проекты необходимы для ориентации объектов, представляется полностью ложным.
Дэвид Ричерби