Существует объективная мера сложности программирования с точки зрения синтаксиса и семантики, а не как сложный язык должен использовать?Сложность программирования на языке программирования
Я читал много субъективных комментариев, но мало тщательного анализа.
Посмотрите Denotational semantics и operational semantics:
Денотационной семантика является подходом к формализации значения языков программирования с помощью построения математических объектов (называемых денота-), которые описывают значение выражений из языков.
В семантика для языка программирования описывает, как действует программа интерпретируется как последовательность вычислительных шагов. Затем эти последовательности означают значение программы. В контексте функциональных программ конечный шаг в завершающей последовательности возвращает значение программы. (В общем случае может быть много значений возврата для одной программы, потому что программа может быть недетерминированной, и даже для детерминированной программы может быть много вычислительных последовательностей, поскольку семантика не может точно указать, какая последовательность операций поступает на это значение.)
Насколько сложным является использование языка, является полностью субъективным.
С другой стороны, вопросы о том, насколько сложна семантика языка, могут быть получены, но только по сравнению с другими языками. Однако это необязательно полезно. Например, я бы дал Smalltalk семантическую сложность 1 и C++ сложности 9. Тем не менее, я поставил все, что браузер, который вы читаете, написан в на C++, а не Smalltalk.
Если существует такая объективная мера, это, вероятно, почти бесполезно для оценки полезности или стоимости использования данного языка для данной цели. Это поможет вам исключить пробелы или мозги, но это можно сделать так же легко, не тратя ресурсы на такую объективную меру - субъективно наблюдая исходный код и понимая, что вы никогда не захотите с ним серьезно работать.
Большинство языков будут иметь множество положительных и отрицательных факторов, которые вам нужно взвесить против цели, которую вы пытаетесь достичь, и условий, которые необходимо выполнить.
Не забудьте INTERCAL. –
Я уверен, пожелал, чтобы SO требовал комментариев к downvote. Люди, если вам не нравится ответ, объясните, почему. – eyelidlessness
Лучшая мера, которую я видел в языке, - это вероятность того, что случайная строка будет действительной программой. Perl - это язык, который занимает высокое место в этом масштабе, Ada занимает довольно низкое место.
Что это показатель означает - это еще одна проблема.
Ужасно похвастаться редактором TECO было то, что любая строка символов, когда будет рассматриваться как команда, что-то сделает. Это одна из многих причин, по которым вы не видите много пользователей TECO в эти дни. – 2009-07-22 21:45:24
Причина этого в том, что первый (или один из первых?) Токенов __END__, после чего НИЧЕГО производится после того, как это действительная программа Perl. Это само по себе лидирует в Perl за то, что у него есть кусочек бесконечных последовательностей, которые являются действительными программами. –
@Neil: Emacs начал свою жизнь как front-end TECO, поэтому он живет духом. –
Мне не ясно, что сложность - это даже четко определенный термин применительно к языку программирования.
Если по «объективным» вы имеете в виду «количественный», вы можете задавать такие вопросы, как
Насколько велика однозначная грамматика?
Насколько велика работающая грамматика yacc?
Поскольку язык почти не имеет формальной семантики, трудно провести количественные исследования. Но вы могли бы задать вопрос
За исключением любопытства, мне непонятно, что этот вопрос стоит задать — трудно представить полезные ответы.
Вы можете добавить количество требуемых обходов AST и другие показатели перевода. –
Как общему правилу, тем более динамичный и реферировать синтаксис или семантика или реализации, тем более сложный язык (не использовать, как вы заявили).
Следовательно, Java является более сложным языком, чем C, потому что:
Я бы сказал, что на этой основе Python проще, чем Java, потому что это объектная модель, в то время как сложная, простая с точки зрения сокращения в более простую форму. Легкость, с которой данный синтаксис может быть переведен в более простой форме с точки зрения времени и расчета, также может быть углом.
Язык, такие как LISP с другой стороны, некоторые утверждают, является комплекс использовать, но очень просто. То же самое касается таких вещей, как Haskell.
Вы могли бы измерить сложность в одном из следующих способов, но не являются полными:
Есть тонны способов. Вы можете измерить вычислительную сложность процесса компиляции для заданного синтаксиса.
Не все эти примеры верны. Некоторые объектные модели очень сложны, но очень быстры, потому что они используют быстрый фундамент. Я мог бы стать примером.
Это хорошо. Есть ли где-то читаемый Haskell? –
Кеннеди, ознакомьтесь с этим сайтом http://www.hck.sk/users/peter/HaskellEx.htm –
Добавлен Ada's. Не стесняйтесь взять его обратно, если вы не хотите, чтобы ваш список вырос, Ник. –
Мне нравится Project Euler для оценки этого. :)
Простейшими двумя объектами, которые можно было бы рассмотреть, было бы количество словесных определенных символов и ключевых слов/зарезервированных слов, а также количество произведений в его BNF.
Еще одна вещь, на которую вы могли бы обратить внимание, для тех языков, которые у них есть, - относительные размеры их документов стандартов. Некоторые утверждают, что не все стандартные документы написаны на одном уровне.
Я думаю, что если вы посмотрите в области проверки правильности, вы найдете более подробный анализ смысловой сложности. Такие системы, как CSP (и, в меньшей степени, Lambda Calculus), предназначены для анализа посредством анализа. Чем ближе язык к выражению базовой формальной системы, тем проще она с семантической точки зрения.
Контр-пример будет чем-то вроде языка программирования C. Невозможно определить, что делает программа на самом деле, не зная, на какой ОС и аппаратном обеспечении она будет работать.
Как и другие пользователи, ключевые слова являются объективной мерой того, насколько сложным может быть язык программирования. Грамматика/синтаксис будет описывать, насколько сложна структура кода (допустимые комбинации ключевых слов). Существуют метрики кода качества, связанные с качеством программного обеспечения, чтобы определить, насколько сложна часть кода.
Семантическая сложность представляется мне сложнее измерить. Это связано с выразительной способностью (чем выше уровень языка программирования, тем более выразительная сила). Я не вижу смысла пытаться сравнивать различные решения, реализованные на разных языках, чтобы измерить их выразительную силу (например, с помощью реализации решений проекта Euler = решений). Сама проблема и каждая парадигма языка программирования могут смещать сравнение.
В случае языков программирования высокого уровня, я предполагаю, что количество возможных реализаций для конкретной задачи (с абстрактной точки зрения) является хорошей мерой семантической сложности.
В случае языков программирования низкого уровня может быть интересно посмотреть, как языки спецификации генерируют код (найти реализацию = решение для данной проблемы). Независимо от этого из-за ограниченной абстракции эта мера, по-видимому, тесно связана с метрикой кода качества программного обеспечения.
Как вы можете видеть, абстракция и семантическая сложность сложнее автоматизировать (сгенерировать реализацию = решение с учетом спецификации). Там, где появляются знания программиста, интеллект и психология (AI не достиг этого момента).
Вы должны сначала определить «сложность языка». –
Я угадываю сложность реализации, а не использую –
Я написал Q/A в cstheory SE по этой теме (если я правильно прочитал). Поиск Kolmogorov Quotient для измерения языка программирования элегантности или лаконичности - способность языка программирования упростить комплекс. – theDoctor