OberonCore

Наткнулся на интересную статейку:
http://sun.mmcs.rsu.ru/~ulysses/IT/Strong_Typing_vs._Strong_Testing_(ru).htm

Факты излагаются известные, по отдельности справедливые - вся картинка нелогичная.
Особенно противопоставление разных средств.

Про хорошее качество результата в динамических языках типа Smalltalk хорошо известно. Это позволяет только утверждать, что перенос проверок на runtime кардинально не бьёт по надёжности, при прочих равных (нормальный язык и т.п.) Что типизация не позволяет гарантировать правильность - банальность, и ежу понятно

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

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

Про тестирование тоже какие-то банальности - нашли панацею. В первую бы очередь о контрактах и неотключаемых ассертах поговорили - вот пример нужнейших поздних проверок! - поверх чего и гонять бы уже "модульные тесты"...

Ну и, конечно, потрясающий перл в конце: "единственной гарантией правиль­ности является прохождение всех тестов, определяющих правильность програм­мы". Аж десять раз )

Если вместо слов "единственной гарантией" (интересно, как в оригинале?) поставить слова "необходимым условием", то получится вполне осмысленное утверждение.

Да, но ведь это очень разные слова в данном случае! Никаких корректирующих впечатление оговорок не было. Представьте себе новичка, жадно поглощающего знания - он после прочтения этого будет забивать направо и налево на все средства обеспечения качества, кроме модульных тестов
Или человек пишет (ПЕРЕВОДИТ?) статьи левой пяткой спросонок в бреду горячечном?

Да
"наши переводчики часто отличаются нежеланием понимать переводимое." Гребенщиков.
и это вы называете перлом? вот перл

Оригинал тут: http://mindview.net/WebLog/log-0025

Что интересно, в этой фразе не один ляп.

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

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


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


Поковырял давеча немного Eiffel. Там контракты, инварианты и проч. в полный рост. Так вот, там как раз для релизов РЕКОМЕНДУЕТСЯ отключать ВСЕ динамические проверки.

Т.е. фактически предлагается делать именно то что пишет Эккель -- писать юнит-тесты с полным покрытием, в дебаг-версии их делать прогон. Убедившись что всё ок. Иварианты, контракты и проч. не нарушаются, откючить все проверки и собрать релиз, которым и пользоваться.

Ну что же тут громоздкого?


Это - базовый механизм языка. Как Вы думаете, составные документы работают, чтобы что угодно вкладывалось во что угодно?
Динамическая проверка типа - это не метапрограмминговые штучки, а необходимейшая конструкция современного языка. В Обероне выполняется ценой трёх косвенных обращений и одного сравнения, независимо от глубины иерархии.


Ну, это старые предрассудки, всё за проценты быстродействия боремся ))

Это просто не утиная типизация.



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

Да, компилируется Eiffel в разы медленее того же C++. Даже если C++ с шаблонами

Именно она. Конечно, она не на уровне любых объектов, но в выделенном "секторе" - сколько угодно.
Имеем базовый DuckObject с методом HandleMsg. От него строим любые расширения типов - хоть плоскую двухуровневую иерархию (как часто и бывает в системных задачах).

Потом я любому объекту шлю любое сообщение. Он его обрабатывает, если умеет.
Имеем семантику Смоллтока.

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

Почему вручную? Суть прозрачна и наглядна. Явно фигуриет объект, сообщение, его отправка и обработка. Естественная модель.

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

Естественная модель - это obj.message(). А вы эту модель эмулируете введением иерархии типов с последующей проверкой. Все вручную. И все только ради того, чтобы ублажить компилятор, который ничего не хочет знать о duck typing Да, реализовывать саму проверку типов вручную не надо, и на том спасибо Хуже было бы только в C (без плюсов), там и это бы пришлось делать вручную, после чего можно было бы сказать, что и на C можно делать duck typing



Да, любую программу можно напсать на фортране. Без всяких бирюлек

P.S. Попишите на питоне. Серьезно. После этого на оберон будете смотреть как на нечто с ненужными "бирюльками" в виде никому не нужной проверкой типов на этапе компиляции

Ну, в моём понимании естественная модель - это близкая к устройству систем реального мира... Это моя точка зрения, конечно.

Да, особенно естественно это выглядит на питоне: обращаясь к "домашнему животному" pet.speak(), получаем "человеческую" речь "hello, welcome to the neighborhood!".
"Я спросил у ясеня, я спросил у тополя".

В статье есть ссылка на блог "упертого сишника", воззрения которого перековались на "динамическую типизацию". Там есть такие слова:

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

Кстати, отличная догадка! Автор статьи тоже немало восторга испытывает именно от скорости прототипирования.

Не стоит сводить скорость прототипирования к скорости компиляции. "С" очень быстро компилируется.

С++ медленней. Но для прототипирования скорости всё равно с лихвой хватает. Ибо прототип обычно содержит на порядки меньше кода чем боевая система. Кстати, я никогда не понимал стонов насчет медленной компиляции... пока не попробовал Eiffel Вот там, да. Там действительно МЕДЛЕННО. И хочется заменить на что-то другое. Хоть на питон Хотя, справедливости ради, реально медленно оно собирается, только в релизе. Для дебага собирается быстро (сравнимо со скоростью сборки С++). Но медленно работает

Кстати, ещё по поводу модулей. То, что написано в статье будет работать только в скриптовых языках. По крайней мере, я за два дня так и не придумал способа хотя бы откомпилировать command(pet) в случае использования нескольких модулей и раздельной компиляции (чтобы не было необходимости проверять принадлежность pet соответствующему классу).

Допустим, при компиляции создаётся sym-файл, чтобы можно было готовить смежные модули. Если мы захотим использовать процедуры данного модуля, то нам будет необходимо знать устройство типа (а точнее - часть устройства класса) объекта, принимаемого в качестве параметра. На первый взгляд, это не является проблемой для синтаксического анализатора, пример тому - работающий python. Но для компиляции требуется реализовать процедуру полностью, поскольку интерфейс может меняться в зависимости от того, как широко используются методы объекта-параметра. То есть, параллельно разрабатывать модули не получится, поскольку для импортёра весь импорт должен быть уже реализован. Реализация и горячая замена модулей-импортёров не пострадает.

Но при замене модуля-экспортёра автоматом заменится и его интерфейс, следовательно, его импорт во многих случаях может стать некорректным для всё тех же импортёров. А значит, такие конструкции, как MVC или CRM, станут проблематичными. Попирается инкапсуляция - а это важная составляющая для ООП, - причём, уже и в случае компиляции, и в случае интерпретации.

Если один и тот же объект передаётся в разные процедуры модуля, то он должен реализовывать несколько интерфейсов, что может порождать конфликты.