OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Суббота, 16 Ноябрь, 2019 01:31

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 94 ]  На страницу 1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 15 Январь, 2009 16:23 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Наткнулся на интересную статейку:
http://sun.mmcs.rsu.ru/~ulysses/IT/Strong_Typing_vs._Strong_Testing_(ru).htm


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 18:27 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
Факты излагаются известные, по отдельности справедливые - вся картинка нелогичная.
Особенно противопоставление разных средств.

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

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 18:40 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Ну и, конечно, потрясающий перл в конце: "единственной гарантией правиль­ности является прохождение всех тестов, определяющих правильность програм­мы". Аж десять раз )


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 18:52 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 19:38 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Да
"наши переводчики часто отличаются нежеланием понимать переводимое." Гребенщиков.
Илья Ермаков писал(а):
Ну и, конечно, потрясающий перл в конце: "единственной гарантией правиль­ности является прохождение всех тестов, определяющих правильность програм­мы". Аж десять раз )
и это вы называете перлом? вот перл
Цитата:
Ага! – скажете вы. – В этом все дело: отсутствие необходимой проверки на стадии компиляции позволяет гарантировать правильность программы


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 20:06 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Оригинал тут: http://mindview.net/WebLog/log-0025


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 20:22 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
Илья Ермаков писал(а):
единственной гарантией правиль­ности является прохождение всех тестов, определяющих правильность програм­мы

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 20:26 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Статика с динамикой может отлично сочетаться. Например, в Обероне я перейду на типизированные сообщения в тех местах, где мне нужна гибкость, как они называют, "утиной типизации". Но я знаю, что у меня не будет просадки на операциях с атомарными типами и т.п.

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

Илья Ермаков писал(а):
Про тестирование тоже какие-то банальности - нашли панацею. :)

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 20:47 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
Alexey Veselovsky писал(а):
Насколько я понимаю, утиная типизация в Обероне и Яве либо очень громоздка и через поддержку рантайма (через рефлекшн и другие метопрограмминговые штучки), либо невозможна, когда оный рантайм это не позволяет.

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

Код:
PROCEDURE (obj: SomeObject) HandleMsg (msg: ANYREC);
BEGIN
  WITH msg: ...
END HandleMsg;

...
someObj.HandleMsg(saySomething)

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 20:55 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Илья Ермаков писал(а):
Alexey Veselovsky писал(а):
Насколько я понимаю, утиная типизация в Обероне и Яве либо очень громоздка и через поддержку рантайма (через рефлекшн и другие метопрограмминговые штучки), либо невозможна, когда оный рантайм это не позволяет.

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

Код:
PROCEDURE (obj: SomeObject) HandleMsg (msg: ANYREC);
BEGIN
  WITH msg: ...
END HandleMsg;

...
someObj.HandleMsg(saySomething)

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

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

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


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 21:11 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
Цитата:
Это просто не утиная типизация.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 21:30 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Alexey Veselovsky писал(а):
Это просто не утиная типизация.


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 22:08 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
Почему вручную? Суть прозрачна и наглядна. Явно фигуриет объект, сообщение, его отправка и обработка. Естественная модель.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Январь, 2009 23:32 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Почему вручную? Суть прозрачна и наглядна. Явно фигуриет объект, сообщение, его отправка и обработка. Естественная модель.


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

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


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Январь, 2009 01:20 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9154
Откуда: Россия, Орёл
Цитата:
Естественная модель - это obj.message().

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Январь, 2009 08:12 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2932
Откуда: г. Ярославль
Vlad писал(а):
Естественная модель - это obj.message()
Да, особенно естественно это выглядит на питоне: обращаясь к "домашнему животному" pet.speak(), получаем "человеческую" речь "hello, welcome to the neighborhood!". :)
"Я спросил у ясеня, я спросил у тополя".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Январь, 2009 08:32 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2932
Откуда: г. Ярославль
В статье есть ссылка на блог "упертого сишника", воззрения которого перековались на "динамическую типизацию". Там есть такие слова:
Цитата:
I also realized that the flexibility of dynamically typed langauges makes writing code significantly easier. Modules are easier to write, and easier to change. There are no build time issues at all. Life in a dynamically typed world is fundamentally simpler.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Январь, 2009 10:18 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2316
Откуда: Россия, Томск
Иван Кузьмицкий писал(а):
Понятное дело, если модуль можно бросать в дело мгновенно после редактирования исходного текста, то для сишников это будет откровением.
Кстати, отличная догадка! Автор статьи тоже немало восторга испытывает именно от скорости прототипирования.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Январь, 2009 10:50 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Александр Ильин писал(а):
Иван Кузьмицкий писал(а):
Понятное дело, если модуль можно бросать в дело мгновенно после редактирования исходного текста, то для сишников это будет откровением.
Кстати, отличная догадка! Автор статьи тоже немало восторга испытывает именно от скорости прототипирования.


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Январь, 2009 11:07 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Кстати, ещё по поводу модулей. То, что написано в статье будет работать только в скриптовых языках. По крайней мере, я за два дня так и не придумал способа хотя бы откомпилировать command(pet) в случае использования нескольких модулей и раздельной компиляции (чтобы не было необходимости проверять принадлежность pet соответствующему классу).

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

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

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


Последний раз редактировалось Valery Solovey Пятница, 16 Январь, 2009 12:13, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 94 ]  На страницу 1, 2, 3, 4, 5  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB