Сложность языков программирования

Язык BNF является приблизительной мерой - просто на вкус: -)

Несколько примеров,

• C ++
• Схема
• Lua
• Ada
• Haskell

Как общее правило , чем динамичнее и абстрактнее синтаксис, семантика или реализация, тем сложнее язык (не для использования, как вы заявили).

Следовательно, Java - более сложный язык, чем C, потому что:

1. C имеет простые правила области видимости по сравнению с относительно сложными правилами Java
2. Типы более сложны, разрешение и перегрузка методов
3. Такие вещи, как наследование, перечисление и проверка аргументов, перегрузка методов, значительно усложняют процесс компиляции.

I На этом основании можно было бы утверждать, что Python проще, чем Java, потому что это объектная модель, хотя и сложная, но проста с точки зрения сведения к более простой форме. Легкость, с которой данный синтаксис может быть преобразован в более простую форму с точки зрения времени и вычислений, также может быть углом.

С другой стороны, такой язык, как lisp , некоторые утверждают, что сложно использовать , но очень просто. То же самое касается таких вещей, как Haskell.

Вы можете измерить сложность одним из следующих способов, но не полными:

1. Количество ключевых слов, строк кода и сложность семантики (например, разрешение идентификатора) для простая проблема. Вычисление Фибоначчи может быть одним из них. Сравнение довольно эффективной реализации общих алгоритмов.
2. Что происходит, когда? Связываются ли имена поздно во время выполнения, или они разрешаются во время компиляции?
3. Может ли данный фрагмент кода пониматься более чем одним способом, если не даны все факты идентификаторов, типов и внешний код?

Есть тонны способов . Вы можете измерить вычислительную сложность процесса компиляции для данного синтаксиса.

Не все эти примеры верны. Некоторые объектные модели очень сложные, но очень быстрые, потому что в них используется быстрый фундамент. Примером может служить «Я».

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

Что означает эта метрика - это совсем другой вопрос.

Я думаю, если вы посмотрите в области подтверждения правильности, вы найдете более подробный анализ семантической сложности. Такие системы, как CSP (и, в меньшей степени, Lambda Calculus), спроектированы так, чтобы их можно было обрабатывать с помощью анализа. Чем ближе язык к выражению лежащей в основе формальной системы, тем он проще с семантической точки зрения.

Контрпримером может быть что-то вроде языка программирования C. Это'

В версиях Maven до 2.1 нет средств для настройки клиента на тайм-аут, но вы можете настроить его на более редкую проверку обновлений, если вы установите политику обновления. Это частично решает проблему.

Например:

<repository>
  <id>myrepo</id>
  <url>http://maven.mycompany.com/m2</url>
  <releases>
    <enabled>true</enabled>
    <updatePolicy>daily</updatePolicy>
  </releases>
  <snapshots>
    <enabled>false</enabled>
    <updatePolicy>always</updatePolicy>
  </snapshots>
</repository>

Допустимые значения:

• всегда - всегда проверять, когда Maven запускается для новых версий моментальных снимков
• никогда - никогда не проверять наличие более новых удаленных версий. После выключения можно выполнять обновления вручную.
• ежедневно (по умолчанию) - проверять при первом запуске дня (местное время)
• интервал: XXX - проверять каждые XXX минут

Еще одно соображение - это программное обеспечение, которое вы используете для размещения вашего внутреннего репозитория. С помощью диспетчера репозитория, такого как Nexus , вы можете управлять всеми подключениями к внешним удаленным репозиториям через диспетчер и настраивать тайм-аут для этих удаленных подключений.

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

Мне нравится Project Euler за оценку этого. :)

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

Если под «объективным» вы подразумеваете «количественный», вы могли бы задать такие вопросы, как

• Насколько велика однозначная грамматика?

• Насколько велика рабочая грамматика yacc?

Поскольку почти ни в одном языке нет грамматики формальная семантика, количественные исследования провести сложно. Но вы можете спросить

• Насколько велик простейший интерпретатор для этого языка по сравнению с интерпретаторами для других языков, которые используют тот же метаязык (язык, на котором написан интерпретатор)? Эта мера в некоторой степени связана с колмогоровской сложностью.

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

Насколько сложен этот язык в использовании, в некоторой степени субъективно.

С другой стороны, на вопросы о том, насколько сложна семантика языка, можно ответить, но только по сравнению с другими языками. Однако они не обязательно полезны. Например, я бы дал Smalltalk семантическую сложность 1, а C ++ - 9. Однако я готов поспорить на все, что браузер, в котором вы это читаете, написан на C ++, а не на Smalltalk.

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

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