Написание программ на динамических языках, которые выходят за рамки того, что позволяет спецификация

Question

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

На мои мысли повлиял этот вопрос, когда я прочитал ответ Бобинса: Вопрос о методах среза и сращивания в JavaScript

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

Если кто-то не прочитает спецификацию и не решит ее придерживаться, я вполне уверен, что таких нарушений много.

Это проблема или естественное продолжение написания таких гибких языков? Или нам следует ожидать, что такие инструменты, как JSLint, помогут полиции спецификации?

Мне понравился один ответ в этом вопросе, что реализация python является спецификацией. Мне любопытно, если это на самом деле ближе к истине для этих типов языков, то, по сути, если язык позволяет вам что-то делать, то это в спецификации. Есть ли спецификация языка Python?

UPDATE:

Прочитав пару комментариев, я подумал, что я проверю метод сплайсинга в спецификации, и это то, что я нашел в нижней части страницы 104, http://www.mozilla.org/js/language/E262-3.pdf,, поэтому кажется, что я могу использовать сплайсинг на массив детей без нарушения спец. Я просто не хочу, чтобы люди увязли в моем примере, но надеюсь рассмотреть вопрос.

    The splice function is intentionally generic; it does not require that its this value be an Array object. 
Therefore it can be transferred to other kinds of objects for use as a method. Whether the splice function 
can be applied successfully to a host object is implementation-dependent.

ОБНОВЛЕНИЕ 2: Меня не интересует вопрос о javascript, но языковая гибкость и спецификации. Например, я ожидаю, что спецификация Java указывает, что вы не можете поместить код в интерфейс, но используя AspectJ, я делаю это часто. Это, вероятно, нарушение, но авторы не предсказывали AOP, и инструмент был достаточно гибким, чтобы его можно было использовать для этого, так же как JVM также достаточно гибок для Scala и Clojure.

Answer 1

Является ли язык статически или динамически типизированным, на самом деле небольшая часть проблемы здесь: статически типизированный может немного облегчить для кода применение его спецификаций, но ключевое слово здесь - маргинально, Только «проектирование по контракту» - язык, позволяющий вам явно указывать предварительные условия, постусловия и инварианты и принудительное их выполнение - может помочь защитить вас от пользователей ваших библиотек, эмпирически обнаружив, что именно библиотека позволит им получить покончить с этими открытиями и использовать их в своих интересах, чтобы выйти за рамки ваших дизайнерских замыслов (возможно, ограничить вашу будущую свободу в изменении дизайна или его реализации). И «дизайн по контракту» не поддерживается в основных языках - Eiffel является наиболее близким к этому, и в наше время мало кто назвал бы его «основным» - вероятно, потому, что его затраты (в основном неизбежно во время выполнения), по-видимому, не оправдано своими преимуществами. «Аргумент x должен быть простым числом», «метод A должен быть предварительно вызван до вызова метода B», «метод C не может быть вызван больше после вызова метода D» и т. Д. - типичные виды из ограничений, которые вы бы хотели бы заявить (и неукоснительно применяли, не тратя на них значительного времени программирования и энергии) просто не поддаются тому, чтобы их можно было подставить в контексте того, что мало компилятор статически типизированного языка может применять.

Answer 2

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

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

Answer 3

Мне кажется, что первоначальный вопрос немного не является разделителем. Если спецификация явно разрешает определенное поведение (как ДОЛЖНО, МОЖЕТ, ДОЛЖНО или ДОЛЖНО), тогда любой компилятор / интерпретатор, который разрешает / реализует поведение, по определению совместим с языком. Похоже, что это ситуация, предложенная ФП в разделе комментариев - спецификация JavaScript предположительно * говорит, что рассматриваемая функция МОЖЕТ использоваться в различных ситуациях, и, таким образом, она явно разрешена.

Если, с другой стороны, компилятор / интерпретатор реализует или разрешает поведение, которое явно запрещено спецификацией, то компилятор / интерпретатор по определению работает вне спецификации.

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

* "предположительно", потому что я сам не видел спецификацию. Я придерживаюсь сделанных выше заявлений.

Answer 4

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

Цель любого проекта языка высокого уровня должна состоять в том, чтобы уменьшить объем кода, который должен быть написан, чтобы выполнить работу, не нанося слишком большого вреда читаемости. Чем больше кода нужно написать, тем больше будет ошибок. Системы ограничительного типа могут быть (если не продуманными) в худшем случае распространенной ложью, в лучшем случае преждевременной оптимизацией. Я не думаю, что чрезмерно ограниченные системы типов помогают в написании правильных программ. Причина в том, что тип - это просто утверждение, необязательно основанное на доказательствах.

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