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

Слишком большие ограничение. Никакой возможности работать с «реальной» многопоточностью. Кучу всего придётся зашивать в язык. Некрасиво и не рационально.

Отдельные инструменты лучше. Каждый делает свою работу и делает её хорошо. Как тебя, любителя «целостных инструментов» занесло в *nix системы, где всегда была прямо противоположная философия?

eao197:>

кстати, так почему же

Почему мейнстримом стал C++, а не Eiffel?

так почему же??? где выводы???

я вот смотрю на нытьё, которое развели и ты, и eax.me в своих бложиках по поводу ржачины. и понимаю, что это retardness, и вообще вредная привычка — оправдывать свой любимый набор костылей: примочки, припарки и присыпки к С++ — не сравнивая технологии адекватно, рационально.

avoid-new-toys это не экономия усилий — это ленность ума.

вообще да, странно почему мейнстрЁмом стал Си с костылями, а не Эйфель в 80х и не Оберон-2 или BlackBox Component Pascal в 90-х. или там не ISLISP или Dylan из лиспов, ога.

наверное, причины 2 или даже три:

1. странная, стрёмная лицензия. например у BlackBox: вы нам напишите, что вы будете с этим делать, тогда мы так уж и быть, может быть и продадим. сейчас хоть одумались: открыли сорцы, и BSD. и результат: сборки энтузиастов на гитхабе заруливают по фичастости, да и на линакс или там MPICH из блекбокса — тоже сделали энтузиасты.

явно, пошло развитие. вот тут-то оно и попёрло.

2. цена, то есть, price tag. всё-таки очень важно. потому что когда у BlackBox Component Pascal в середине 90-х стоимость среды за 1500+ евро, и у Dylan примерно столько же — только *без* батареек — это многовато будет, и не понятно чем лучше того же Delphi с батарейками, например.

ну а ISE Eiffel за 7000 евро от Мейера или ISO ISLISP реализация OpenLisp от Кристиана — это «круто, дорого, офигенно». очень хорошо, очень качественно --- но чересчур, блин, дорого.

сложно рассуждать о качестве Эйфелей или там лиспов — если их не ел. и с таким конским ценником — широкие немытые народные массы их даже не пробовали.

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

ещё и потому что рационально никто ROI и затраты на проекты разработки никто не считает. действуют эмоционально, а не рационально — с костылями, подпорками, плясками с бубном и народными шествиями.

3. пока народ наш туп, ленив и безграмотен, важнейшим из искусств для нас является кино. а не театр и не книга. /В. И. Ленин/

существует два типа типа мышления: которые понимают двоичную систему, и которые не понимают паковщики и картостроители.

в смысле, механикусы, которым нужно пощупать руками, и магусы-теоретики в башнях из слоновой кости, выдумывающие метамодель своей «системы мира».

но вы, блин, придумали третий путь — уговариваете сами себя что даже «щупать руками» это ненужное ненужно.

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

вы ноете про функциональщину, типа это непрактичная и неведомая НЁХ, и продолжаете колбасить свой говнокод на С++ : «некогда думать, трясти надо». а потом кто-то ноет на форумах, типа геймдев застрял уже лет пять на одном уровне, и не приносит производительности в разы, на порядок ( в 10 раз, ога).

блин, глупые дети, включите уже мозг. он и не может приносить в 10 раз, потому что вы уткнулись в закон Амдала, в эти нижние 60-80% распараллеливаемого кода.

и функциональщина как раз позволяет повысить параллельность кода. а вы ноете: типа непонятная и ненужная НЁХ, и вообще, на фортране и коболе деды проще делали.

или там на с++.

Как тебя, любителя «целостных инструментов» занесло в *nix системы

через freebsd и plan9. там как-то оно более целостней чем в этом вашем линаксе. «очень, очень плохая музыка это вот всё».

ещё через literate programming и org-mode babel — что тоже и более целостней, и «каждый блок кода делает свою работу, делает её хорошо, а elisp wrapper в Емаксе и кусок SLIME cо стороны елиспа связывает вместе через метапеременные все эти метамодели и башню метаязыков в единое целое».

почти как в BlackBox Component Pascal «активные документы» — там было движение в нужном направлении, например складки в тексте, но в целом можно сказать что никто это и не понял, и воспринял их просто как ещё одну вариацию на тему compound documents, OLE, COM и прочего ёкселя, встроенного в ворд встроенного в аксесс, со всеми костылями этого подхода. а не в духе LP/RR подхода и org-mode babel.

в этом смысле, больше юникс-вейности было у старой Amiga.

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

а в этом вашем линаксе CPU весьма хреновый директор. а потом ботлнеки фон-неймана во все поля — внезапно так, ога.

у старой Amiga.

когда аппаратная многозадачность

У старой Amiga не было аппаратной многозадачности.

ботлнеки фон-неймана во все поля

Рыдал.

Без понятия. Слышал, что

от тебя в контексте эйфеля хотелось бы хотя бы более-менее адекватного сравнения SCOOP и твоего мультиагентного костыля, плюсы и минусы. а не «не слышал, но осуждаю».

У старой Amiga не было аппаратной многозадачности

была. man blitter, copper, обратный ход луча. man звуковуха, paula и т.п. вообще, почитай про устройство Kickstarter Exec для начала что-нибудь, да сорцы дёмок на blitter/copper — прежде чем такое говорить.

У старой Amiga не было аппаратной многозадачности

была. man blitter, copper, обратный ход луча. man звуковуха, paula и т.п.

В Amiga была уйма интеллектуальных (по тем временам) внешних устройств, но аппаратной многозадачности - не было. У T414 (и других транспьютеров) - была.

зависит от того, что понимать под «аппаратной многозадачностью». опять же, как это всё работало в целом, начиная с Exec, до библиотек с OpenLibrary/CloseLibrary, и собственно планировщика.

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

то есть, двухстадийная такая многозадачность: на CPU и на конкретных xPU.

зависит от того, что понимать под «аппаратной многозадачностью».

Поддержку многозадачности ЦП, естественно. Но это общепринятая терминология, а у тебя, похоже, своя личная.

то есть, двухстадийная такая многозадачность: на CPU и на конкретных xPU.

При желании, это можно назвать ASMP (но никто не называет).

от тебя в контексте эйфеля хотелось бы хотя бы более-менее адекватного сравнения SCOOP и твоего мультиагентного костыля, плюсы и минусы. а не «не слышал, но осуждаю».

Кто будет оплачивать написание такого сравнения? Вы? Ваш работодатель?

PS. Если выше по треду был ваш поток сознания, то осталось непонятно, вы что сказать-то хотели? Не нравится то, что пишу в своем блоге я или что пишет в своем блоге asfikon? Так не читайте. Если думаете, что можете сказать что-то более вменяемое, напишите и дайте почитать другим людям. Уверяю, узнаете много нового про себя, про свой стиль мышления, интеллектуальный уровень и т.д.

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

Кто будет оплачивать написание такого сравнения?

твой потенциальный клиент. который так и не станет потенциальным: развернётся и уйдёт. туда, где костылей меньше.

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

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

вам надо образ мышления менять, а вы скачете на дохлой лошади. ещё и нахваливаете, дескать, как всё привычно и удобно (потому что менять не надо).

Делайте то, что считаете нужным и не мешайте другим поступать так же.

да кто ж тебе мешает-то? просто вы тут устраиваете, как ты сам написал, «веселый бег по граблям C++», да ещё и нахваливате этот забег в мешках на ходулях в специальной олимпиаде.

может, надо не только задумываться, а ещё и поэкспериментировать?

до логического завершения свои задумки доводить? не только «пытаться найти приемлимую замену C++» — но и находить?

...«вот потому что вы делаете что не думаете, и думаете что не делаете — вы все в клетках с крестами и сидите. и вообще, весь этот горький катаклизм, который я тут наблюдаю»...

твой потенциальный клиент. который так и не станет потенциальным

Не владах ни с русским языком, ни с элементарной логикой?

налицо ухудшающий отбор. который вы все тут демонстрируете.

Мы пишем то, что считаем нужным. Не нравится, не читайте. Хотите продемонстрировать положительный отбор или воспрепятствовать отрицательному — заведите место, где вы сможете излагать свои мысли и вперед. Дерзайте, пробуйте. Может что-нибудь получится.

может, надо не только задумываться, а ещё и поэкспериментировать?

Кто вам сказал, что не было экспериментов?

до логического завершения свои задумки доводить? не только «пытаться найти приемлимую замену C++» — но и находить?

Не знаю, нашли ли вы для себя замену, но я таковой не нашел. Ни в 2007-ом, когда этим плотно занимался, ни сейчас, когда C++ за восемь прошедших лет, ушел очень и очень далеко вперед.

Ну а раз я остался в C++, то смысла плакаться и говорить, что C++ говно, но вынужден на нем писать, потому, что за это платят, не вижу. И этим, похоже, сильно отличаюсь от многих форумчан, которые программируют на С и C++ за зарплату, но плачутся, что вынуждены работать на говняных языках и технологиях.

Не знаю, нашли ли вы для себя замену, но я таковой не нашел. Ни в 2007-ом, когда этим плотно занимался, ни сейчас, когда C++ за восемь прошедших лет, ушел очень и очень далеко вперед.

Ты занимаешься написанием низкоуровневого софта, где крайне важен маленький memory footprint, гарантированное время отклика (читай, отсутствие задержек от gc) или отсутствие жирного рантайма? В противном случае, не вижу смысла использовать C++.

Ты занимаешься написанием низкоуровневого софта, где крайне важен маленький memory footprint, гарантированное время отклика (читай, отсутствие задержек от gc) или отсутствие жирного рантайма?

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

В противном случае, не вижу смысла использовать C++.

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

Широта вашего кругозора вызывает у меня подозрения.

Наличие мозга у тебя в голове вызывает у меня (и не только у меня) сомнения. Но, раз уж мы начали о кругозоре, я бы хотел комментарий к вот этому: http://eao197.blogspot.com/2015/05/progidiotic-lor_21.html

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

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

Ну вы прямо таки добровольно демонстрируете свой кругозор. Как и здравый смысл. То, что вы видели множество проектов, написанных и внедренных одним разработчиком, не может опровергнуть наличие проектов масштаба IBM 360. Это уже почти 50 лет как. И ведь OS для IBM 360 была не единственной большой программной системой, превосходящей возможности отдельных разработчиков, в то время. И до того времени. Т.к. языки высокого уровня, вроде Fortran и Lisp, появились не от хорошей жизни. Да что там языки высокого уровня. Даже ассемблеры появились из-за ограниченных возможностей отдельных разработчиков.

Ok, спасибо. Ещё вопрос: ты случайно не родственник anonimous?

Ну вы прямо таки добровольно демонстрируете свой кругозор. Как и здравый смысл. То, что вы видели множество проектов, написанных и внедренных одним разработчиком, не может опровергнуть наличие проектов масштаба IBM 360.

А как наличие проектов масштаба IBM 360 может опровергнуть наличие написанных и внедренных одним разработчиком проектов?

А как наличие проектов масштаба IBM 360 может опровергнуть наличие написанных и внедренных одним разработчиком проектов?

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

Речь шла о том, что программные проекты очень и очень давно достигли объемов и сложности, превзошедших возможности отдельного разработчика. Проект IBM 360 является хорошим тому доказательством.

проблему валидности контрактов можно свести к проблеме останова

проблему 2+2 тоже можно свести к проблеме останова. so what?

проблему 2+2 тоже можно свести к проблеме останова. so what?

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

Никто и не говорил, что оно разрешимо. Просто полноценный прувер на fol гораздо удобнее по целому ряду причин, чем костыльные dependent-types.

Нет, нельзя.

Можно.

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

«не требуется» - не значит что его нет в принципе.

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

Речь шла о том, что программные проекты очень и очень давно достигли объемов и сложности, превзошедших возможности отдельного разработчика

Ты забыл слово «некоторые».

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

у тебя проблема с модальными глаголами

«не требуется» не означает «нельзя»

проблему 2+2 тоже можно свести к проблеме останова

printf("2 + 2 = %d\n",
        HALTS("int main() {return 0;}") ? 4 : 4);

BlackBox Component Pascal

Маргинальщики разбушевались!

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

Поясни.

Ты забыл слово «некоторые».

А во фразе «в ХХ-ом веке автомобили достигли и превысили скорость в 300 км/ч» слово «некоторые» должно обязательно присутствовать? И без слова «некоторые» данная фраза перестает быть актуальной?

Или во фразе «в XX-ом веке люди покорили Северный и Южный полюса Земли, достигли дна Марианской впадины, побывали на Луне, произвели атомные бомбардировки...» так же нужно обязательно подчеркивать, что это сделали некоторые люди, но не вообще все?

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

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

Я имел ввиду более приземленное пояснение, а именно, как ты сведешь проблему останова к проблеме доказательства выполнимости контрактов?

а пробовали например голимый одинэс за три копейки, хотя тот же блэкбокс умеет всё то же самое

Это чего за убийца 1С такой, о котором никто не знает? :)

Поскольку контракт пишется на том же ЯП, то проверка контрактов (статическая) должна по умолчанию содержать проверку соответствующих предикатов на разрешимость.

В Eiffel нет статических контрактов, только через внешние пруверы, но это не в счёт. Опять же, я не вижу как ты в этом утверждении сводишь проблему останова к проблеме вычислимости контрактов (скорее уж наоборот).

У тебя шизофазия?

В Eiffel нет статических контрактов

И?

Опять же, я не вижу как ты в этом утверждении сводишь проблему останова к проблеме вычислимости контрактов

Если я умею статически гарантировать выполнимость предиката, то я умею доказывать его завершимость.

Дело не в разрешимости или нет, а в том, что нужно доказывать соответствие программы контракту. В зависимых типах программа таскает с собой все доказательства — их нужно предоставлять, иначе внешний прувер должен автоматически проверять модель поиском доказательств (SAT/SMT), а там где его не хватает — опять нужно предоставлять (http://toccata.lri.fr/gallery/coq.en.html, http://alt-ergo.lri.fr/#Certification).

В зависимых типах программа таскает с собой все доказательства

Ну так это и есть основной недостаток зависимых типов. Куча мусора +доказательства приходиться преобразовывать постоянно.

иначе внешний прувер должен автоматически проверять модель поиском доказательств (SAT/SMT), а там где его не хватает — опять нужно предоставлять.

Ну да. Это и есть нормальный способ доказательства корректности.

Таскать это сознательный выбор же — сказали используем сигму, значит используем. Ну и как я выше писал — если контексты неявные (implicit/instance arguments) и есть подтипирование утверждений (решётка, как с refinement, https://www.cs.cmu.edu/~fp/papers/pldi91.pdf), то явно таскать тоже ничего не нужно (даже в нынешней agda можно писать xs[index] без явной передачи пруфа index < length xs, только там подтипирования нет и писать что-то «обычное» на ней никто не будет, разумеется).

А если выбирать писать «обычно», то вопрос — можно ли про это дело «необычно» что-то доказать?

http://adam.chlipala.net/cpdt/html/StackMachine.html

https://github.com/AbsInt/CompCert/blob/master/backend/Tailcall.v

https://github.com/AbsInt/CompCert/blob/master/backend/Tailcallproof.v

и т.п.

Таскать это сознательный выбор же

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

А если выбирать писать «обычно», то вопрос — можно ли про это дело «необычно» что-то доказать?

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

Кто вам сказал, что не было экспериментов?

какие-то странные они, твои эксперименты (вот эти, например):

* микробенчмарки

* вкусовщина (в стиле «здесь делают не так, как в С++»)

* отсутствие выводов по каждому отдельному «эксперименту» и вообще, по языку, и далее — по системе, что впрочем, логичное следствие отсутствия

* критериев сравнения

* преимуществ и недостатков того или иного подхода, языка, метода

* воспроизводимости — по идее, такие «эксперименты» нужно было бы с каким-то интервалом периодичности перезапускать, чтобы определить что изменилось с языком за последние полгода/год/семь лет

* более общо: отсутствие гипотез, которые должны были эти твои эксперименты проверять — и в целом, хреновая постановка экспериментов.

а в итоге, ощущение от этой твоей «работы» как от хреново пересказанного анекдота — то ли выиграл, то ли проиграл, то ли машину, то ли квартиру. в общем, ложечки нашлись, а осадок остался. и вообще, певец так себе — мне рабинович на кухне напел, хреновый у него голосок. в общем, агенство ОБС и субъективщина и вкусовщина во все поля.

в итоге выводы которые из этих статеек можно сделать: «чего именно не понимает» в альтернативных технологиях и языках конкретный С++ программист Евгений. может, это симптоматично для большинства С++ программистов, и они не понимают одних и тех же вещей, не знаю (экстраполировать по двум наугад выбранным, хотя и довольно типичным С++ программистам, это всё-таки слишком грубо).

даже странно: если покопать чуть глубже, на тему того же Eiffel: не говоря уже об оффсайте EiffelStudio, а из тарболла SmartEiffel и его дальнейшего форка на LLVM, Liberty Eiffel (сайт блог гитхаб).

то и у SmartEiffel и у Liberty Eiffel есть те самые бенчмарки с шутаута, которые любой и каждый может сам собрать, запустить и проверить.

я вот не знаю как надо было копать, чтобы на это не нактнуться. по-моему, даже в EiffelStudio что-то такое начинает появляться.

Не знаю, нашли ли вы для себя замену, но я таковой не нашел. Ни в 2007-ом, когда этим плотно занимался, ни сейчас, когда C++ за восемь прошедших лет, ушел очень и очень далеко вперед.

ну так и технологии за эти восемь лет тоже далеко ушли. во-первых, всё в целом стало получше со стабильностью и инфраструктурой. например, в D2 уже только Phobos, нет таких breaking changes, есть dconf и обсуждение в ньюсах, развитие на гитхабе.

есть пакетный менеджер dub и понятный способ развития «батареек».

аналогично и в Eiffel.com : есть понятное сообщество с примерами и документацией, блоги с обсуждением и библиотеки. есть IRON, пакетный менеджер и «батарейки»). есть понятные книги (те же книги от Мейера), методики моделирования типа метод BON , обучающие курсы (например, на intuit.ru, не говоря уже о Eiffel.com)

в общем, жизнь и развитие идёт. за восемь лет ситуация немного изменилась.

странно, что вот во всех твоих «исследованиях» ты так и не уловил саму суть этих подходов, технологий:

* CTFE подход в D (например, CTFE реализация регэкспов в Phobos D2, или JIT-компилятор JavaScript на D2 с dconf, или «интерактивность» — см. Manu с dconf про gamedev (да собственно и 3д шутер от h3r3tic активно использовал CTFE ещё во времена D1))

* метод важнее нотации, в Eiffel. поэтому логично, что изучать Eiffel надо было «правильно» — начиная с книжки и продолжая Bon-book, сравнивая с RUP/UML и обращая внимание на seamlessness и reversability (обратно из модели восстановить код — возможно в BON, невозможно (кодогенерируются лишь заглушки) в UML).

или, например, CTFE (времени компиляции) proof engine для Eiffel

в общем, сделал бы пару проектов чтобы «почувствовать разницу» — и ты бы сам понял «в чём профит от языка Х и его подхода».

а так это разговор ниачом и о вкусовщине.

И этим, похоже, сильно отличаюсь от многих форумчан, которые программируют на С и C++ за зарплату, но плачутся, что вынуждены работать на говняных языках и технологиях.

нормальные люди не плачутся, и не «продолжают жрать кактус, обмазываться С++ и нахваливать».

а ищут новые подходы, и развивают новые технологии. стараются их применять в своих pet projects, и делают адекватные выводы: эта фича с вот этой совместно работает, а вот эта с этой — совместно не работает. а не ищут золотой молоток или серебрянную пулю.

если уж и нужно вынужденно работать с С++, то заслуживает внимания такой вот подход ( обучающее видео )

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

а то вот прошел по ссылке с нытья eax.me вот сюда — там просто душераздирающее, умопотрясающее зрелище, в комментах. ему Manu вот говорит: слышь, чувак, я вот про этот самый livecoding доклад на dconf делал, зайди и посмотри, как всё просто и практично.

а он всё сомневается и не верит — вместо того чтобы взять и проверить самому. это так типично для программистов на С++, ога.

анон там в комментах годный совет даёт: C is like chess - you don't need to «improve» on it, you need to *build* on it.

впрочем там необязательно может быть С как язык — скорее как Си-машина. а подобным ему, изоморфным языком может быть и LLVM, и Clasp + Clang ASTmatcher и Rust + макросы плагинами компилятору и D2 + LDC + CTFE + нормальные шаблоны, концепты, миксины, рефлексия.

или даже какой-то Emacs + org-mode babel + метаязык на «блоках кода» с метапеременными.

даже странно: уже лет 35 как существует подход Literate Programming и метапрограммирования, лет 15 как существует org-mode, лет пять как альтернативные технологии становятся всё более зрелыми и более годными.

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

в общем, это что-то религиозное: крестоносцы против растаманов, ога. :)

митьки никого не хотят победить — просто сначала и не замечают, потом смеются, потом пытаются бороться. а потом, ВНЕЗАПНО, они побеждают. :)))

Объемы проектов привысили возможности отдельных разработчиков уже очень и очень давно. Как раз лет 30-40 назад, когда был очередной кризис разработки ПО, и создавались языки вроде C++, Ada и Eiffel. Продолжением которых стали появившиеся чуть позже Java, C# и Scala.

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

вот и странно это весьма: уже 30-40 лет назад было понятно, что основная проблема в программировании — это метод и способы структурирования сложности.

для чего предлагались:

1) дисциплина программирования, Дейкстрой

2) умение формулировать мысли и писать «исполняемые эссе», Кнутом

3) сознательный минимализм, послушание и дисциплина — Виртом в Оберонах и далее. чтобы сложность отсекать на входе. собственно, так как это было принято в разработке железа.

4) software circuits Бреда Кокса в Objective-C

5) толстый, человекопонятный кобол язык Ада — с богатыми фичами в языке.

6) формальный подход и верификация спецификаций — в ML, Haskel и т.п. как апофеоз — ОС seL4 и unikernel MirageOS

7) системный подход, на основе холистичной «системной инженерии» и холархий; понятных описаний жизненного цикла. то есть, попытка применения инженерии систем к инженерии софтвера.

собственно, ISE: институт софтверной инженерии, метод BON, метод Эйфель, метод ОО проектирования и разработки (и ОО не означает здесь С++, а означает «наиболее reusable тип данных»).

и затем: софтверная инжерения, ISE Eiffel, ISE -> Eiffel.com и ISE Eiffel -> EiffelStudio.

книги Бертрана Мейера, о дисциплине и методике софтверной инженерии.

сейчас вот движуха с Якобсоном, OMG Essense и альфами системной инженерии, гибкая разработка методик по типу Agile, на основе Essense kernel, ЖЦ софтвернной разработки, международные стандарты качества и ЖЦ и т.п.

однако же: программисты на С++ продолжают жрать кактус, делать вид, что всего этого не было, костылять свой велосипед и придумывать отговорки «мощности типы были другие, да и мозги тоже».

вместо того чтобы адекватно изучить и применять уже изобретённое мировой наукой.

> Но это не менее разумный подход, и из него тоже раскручиваются все нужные юзкейсы.

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

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

ты прав: это фундаментальное значение, понятие как в математике: группа, кольцо, тело, моноиды и монады.

в статье Инкрементальные регулярные выражения, в самом начале приводятся примеры таких моноидов:

* нейтральный элемент - 0 и операция сложения (единица моноида и «умножение» моноида)

* нейтральный элемент 1 и операция умножения

* строки и конкатенация строк; числа и минимум, максимум; интервалы

* композиция моноидов — тоже моноид.

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

у него есть жизненный цикл, то есть:

* конструктор; постусловия конструктора и предусловия конструктора (ссылка void)

* методы; инвариант объекта; инвариант класса; пред- и постусловия методов

* деструктор, постусловия деструктора (ссылка void)

поскольку композиция моноидов — тоже моноид, то и в свойствах ссылок это тоже отражается. (или не отражается, если есть сборщик мусора, ЖЦ ограниченный и ссылки ограниченные)

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

вообще, составление программы можно понимать как решение управнения в морфизмах — какие морфизмы нужно применить к уравнению, описывающему систему в состоянии гомеостаза на каждом этапе ЖЦ это систем, чтобы это решение реализовывало комплияцию из языка требований через язык ТЗ в язык сценарий использования и UI пользователя (на стороне клиента), а затем и в данные и типы данных, категории типов данных (на стороне сервера) ???

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

как доказать «решение обладает нужными свойствами» — нужен прувер.

интереснее вопрос не верификации, а синтеза таких решений, by design правильно.

Соответственно, решать это можно, как минимум, двумя способами:

1. Сделать void/null валидным значением для ссылок, но на уровне языка контролировать наличие проверок на void/null перед обращением по ссылке.

2. Считать ссылкой только валидную ссылку на объект. Для указания отсутствия валидной ссылки использовать какой-то другой объект (например, None в Optional[T]).

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

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

и возможность синтезировать сразу правильно сразу нужный объект.

какие-то странные они, твои эксперименты (вот эти, например):

Если вам что-то не нравится, вы всегда можете сделать что-то свое. То что нужно было лично мне, я проделал почти восемь лет назад, что хотел рассказал, выводы сделал. И не вижу никаких причин сомневаться в том, что был неправ отказавшись от выбора Eiffel-я в качестве основного языка для разработки софта вместо C++.

Насколько я помню, ТЗ на то, что вы называете «работой», вы мне не выдавали, денег за выполнение «работы» не платили. Посему можете смело засовывать свое непонимание и недоумение себе куда-нибудь поглубже, т.к. мне оно не интересно.

в общем, сделал бы пару проектов чтобы «почувствовать разницу» — и ты бы сам понял «в чём профит от языка Х и его подхода».

Товарищ лектор, скажите честно, сколько коммерческих проектов вы лично сделали не Eiffel-е?