LINUX.ORG.RU

В чём профит от Eiffel...

 ,


2

4

...и, в частности, от design by contract? Чем эта фича принципиально отличается от ассертов в других языках?

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

Мой интерес вызван тем, что Бертран Мейер - автор языка Eiffel - возглавляет (возглавлял?) кафедру программной инженерии и верификации программ в СПбНИУ ИТМО (http://sel.ifmo.ru/), и используют они в основном Eiffel.

★★★★★

Последнее исправление: hateyoufeel (всего исправлений: 3)
Ответ на: комментарий от eao197

Таки никто не мешает использовать унарный оператор для обозначения Optional и будет то же самое, только не костыльно.

Ну раз здесь все такие умные, то объясните, почему 30 лет назад языках, которые стали широкоиспользуемыми, ничего подобного не сделали?

ad hominem к языку, это аргумент, ога. язык программирования не имеет срока годности — потому что это способ выражения мыслей, идиом, парадигм.

Может тому были объективные причины?

скорее, субъективные. субъективно: развиваются не столько языки программирования, как абстрактные, платоновы идеи  — а языки программирования как виртуальные машины реализации этого языка (Си-машина, о-код и BCPL-машина, раст-машина или xVM), тысячи их.

кстати, платон тут довольно годно всё понимал, это уже потом после него извратили — есть эйдос, или идея вещи, или программа не скомпилированная; есть воплощение вещи, или рантайм скомплированной программы; есть пространство, или песочница виртуальной машины или Си-машины или УМТ машины с архитектурой фон-неймана.

а есть УММ, а не УМТ.

объективных причин не развивать это направление мысли не было, субъективщина во все поля: когда Аристотелю понадобилось научить школоту (Александра Македонскова, если чо) — он решил его не грузить, и дать лишь то, что он сможет и осилит взять.

то есть: всё метапрограммирование он задвинул за полку и обозвал «метафизикой».

И может взгляд ФП-шников на то, как нужно программировать, всего лишь один из возможных?

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

но он интуитивно понятный, ога. потому что дуги и петли — и запоминается луше всего то, на что делает акцент игровая механика (а не «идея сути игры»).

anonymous
()
Ответ на: комментарий от eao197

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

Как по мне, то нифига не избавляемся. Просто начинаем работать с ними чуть иначе.

конечно иначе — так как монады разные , Жизненные Циклы разные, то и морфизмы будут разные.

anonymous
()
Ответ на: комментарий от anonymous

сравни накладные расходы: в рантайме и в CTFE. и разницу между математическими объектам, понятиями множества и категории.

Да, разница прям существенная:

if attached A as B then
   ...
end
И
A match {
  case Some(B) => ...
  case None
}
Сразу же переходим от run-time в compile-time... Одной лишь силой мысли анонимных LOR-овских экспертов.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

множество: нужны рантайм проверки. в компайлтайм — не нужно никакого кода.

категория: не нужны рантайм проверки. в компайлтайм — синтезируется нужный объект (из категории, а не из множества), и задаются морфизмы, эндофункторы в категории.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.