5-й номер журнала «Практика функционального программирования»

> не умеешь пользоваться кастами — ССЗБ

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

твой коллега, которому ты не все успел объяснить,положит туда

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

как другие

И он это сделал не проверив работает или нет? Как он мог это пропустить? Впрочем, отладчик все быстро покажет. На самом деле, это проблема эфемерна - таких ситуаций просто не бывает в реальной разработке, я с такими не сталкивался.

> Т.е. мне надо было на основе этого указателя выяснить истинный тип объекта, привести указатель к этому типу и вызвать необходимый метод.

маппить на typeid функцию для dynamic_cast - делов то

А суть в том, что подобная проблема вообще невозможна в CL. В CL можно было бы просто брать и вызывать необходимые методы.

опять же путаем язык и реализацию, тот же COM вполне позволяет и кастить, и вызывать методы и много чего еще

меня интересует, как можно красивое решение.

тогда делаем все в статике, типа

template<class A, class B> struct Fight {};

template<> Fight<Cat, Ninja> {
    typedef Ninja Winner;
    void say() { std::cout << "ninja cuts cat. ninja wins.\n";}
};

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

завтра могу полностью изобразить

> завтра могу полностью изобразить

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

> Поэтому, собственно, и есть операторы приведения типов. Как подтверждение несовершенства всей системы.

нет

как возможность для ее расширения

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

Путь динамических языков - отказаться от подобных проверок вовсе, полагаясь на быстрое выявление всех ошибок и unit-тесты, и ведь это работает!

угу, работает

но таки написать 2 слова const MyType& быстрее и короче, чем писать 2 юнит-теста на проверку этого

Хм, а пример для draw будет, где нужна реальная диспетчерезация (не выражающаяся просто строкой) не только по типу объекта, но и по типу контекста? И не статическая, а динамическая? И что придётся делать с private секциями (которые есть в реальном коде)? И как распределять друзей? И как это потом расширять/сопровождать?

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

> в значительной степени они определяют сложность проектирования больших систем

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

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

зачем с ней бороться - ей надо пользоваться

> нет

как возможность для ее расширения

Да ладно, где такое написано? Насколько я помню Страуструпа приведение типов это зло, но без него многие задачи не решить.

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

а в пользовательском коде юзают его, а не касты

Так в стандарте написано? Нет? Ну так на практике будут юзать (и юзают) кто на что горазд.

но таки написать 2 слова const MyType& быстрее

и короче, чем писать 2 юнит-теста на проверку этого

У, ты не только в виртуальных функциях не разбираешься, но ещё и unit-тесты не понимаешь? ;) unit-тесты полезны в C++ не менее, чем в CL и их всё равно надо писать. Это товарищи с haskell могут рассказывать (байки), что их система типов может что-то там гарантировать, но код на С++ надо покрывать тестами чем больше, тем лучше, как бы доказано.

> что придётся делать с private секциями

не должно их быть - наружу отдаются интерфейсы + фабрики, а внутри использовать public/protected

И как распределять друзей?

их не должно быть

И как это потом расширять/сопровождать?

очень легко и просто

> код на С++ надо покрывать тестами чем больше, тем лучше, как бы доказано.

абсолютно согласен - я прикрываю тестами каждый метод + отдельные тесты для подзадач

> как раз без строгой типизации и четко прописанных

интерфейсов в большой системе будет туго

Ну уже давно известно, что нет. Строгая типизация это только один из вариантов, есть и другие.

зачем с ней бороться - ей надо пользоваться

Мне вот приходилось бороться многократно. Ибо приложения есть большие и старные, и заложенная в них система типов не учитывает новые потребности. Перепроектировать всю систему либо просто невозможно (как в случае с автокадов), либо очень дорого. Приходится что-то выдумывать. Т.е. в перспективе на много лет трудно заложить сразу правильную систему типов, а менять её потов может оказаться просто невозможным.

наружу отдаются интерфейсы + фабрики,

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

очень легко и просто

Ну да, ну да, я знаю, что «настоящие мужчины выбирают Windows» (с) и только хлюпики и нытики выбирают Common Lisp, гы :)

> Ну да, ну да, я знаю, что «настоящие мужчины выбирают Windows» (с) и только хлюпики и нытики выбирают Common Lisp, гы :)

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

П.С. лисперы почему-то всегда пытаются перейти к сравнениям - мухи, п%дики, хлюпики, ну что это еще за комплексы? :)

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

> Это товарищи с haskell могут рассказывать (байки), что их система типов может что-то там гарантировать

К чему удивления, что лиспербоев не любят?

> перейти к сравнениям - мухи, п%дики, хлюпики,

ну что это еще за комплексы? :)

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

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

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

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

Java пешком под стол ходила, когда в С++ использовались интерфейсы и фабрики :) и ничего подобного нет - я даже придумать не могу как тут можно наплодить код, который не относится к задаче, точнее можно конечно - но не могу придумать чем это обосновать

> C++ никогда не был «идеальной» системой

никто не спорит

справятся с задачей лучше, чем C++, и Common Lisp один из них.

реальная жизнь жестоко разбивает все иллюзии про «лучшие решения» на лиспе

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

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

> Это товарищи с haskell могут рассказывать (байки), что их система типов может что-то там гарантировать, но код на С++ надо покрывать тестами чем больше, тем лучше, как бы доказано.

Вообще-то может: изоморфизм Карри-Говарда. Правда, с IO сложнее, но даже для неё есть операционная семантика.

И вообще, система типов НЕ заменяет юнит-тесты, а дополняет. В идеале должно присутствовать и то, и другое. AFAIR, система типов как бы «доказывает теоремы» о выражениях, а тесты в стиле «QuickCheck» служат аксиоматической семантикой.

Неуверенность порождает потребность в защите

> Неуверенность порождает потребность в защите

Доктор?

> система типов НЕ заменяет юнит-тесты, а дополняет.

В идеале должно присутствовать и то, и другое.

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

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

> Просто непонятно, зачем много страниц защищать

самый совершенный язык программирования

Не защищать, а популяризировать ;) Одного технического превосходства как показывает практика (в том числе история юникс, как я писал выше) не достаточно.

> Одного технического превосходства как показывает практика (в том числе история юникс, как я писал выше) не достаточно.

О да, не впечатлило.

а популяризировать

Ну это хорошо

> Не защищать, а популяризировать ;)

Как-то ущербно получается. Читая комменты, писать на лиспе хочется всё меньше и меньше. Фейл как популяризатора.

> Читая комменты, писать на лиспе хочется всё меньше и меньше.

Наверное и раньше не очень и то хотелось? Впрочем, проффесиональным пиаром здесь никто не занимается, так что эффект может всякий, но, во всяком случае, ЛОР является крупнейшим (после поисковых систем) источником переходов на http://lisper.ru/. Так что, ещё раз, мне думается, что смысл в этом есть ;) Ну и наверное все понимаю, что ЛОР не то место, где принято вежливо и тактично обсуждать что либо.

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

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

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

Полезность же системы типов как минимум заключается в:

1) Ограниченной верификации программ (наряду с юнит-тестами). Преимущества первой заключаются в том, что это — практически математически точное и полное доказательство утверждений (за исключением «чёрных ходов» в систему типов: здесь надо убедиться в этом самостоятельно). Но она, конечно, не может проверить истинность предикатов на _значениях_ выражений. Вот тут-то и необходимы юнит-тесты. Конечно, есть и системы с зависимыми типами, но пока что использовать их в «обычном» программировании довольно сложно.

2) Дополнительной документации, актуальность которой проверяется машиной. Просто смотря на название функции и её тип, зачастую можно понять, что она делает. Кроме того, в референциально прозрачных системах, тип ещё и может указывать на побочный эффект, производимый функцией. Это очень важно, на мой взгляд, так как неконтролируемые сайд-эффекты становятся всё опаснее и опаснее (например, в параллельном программировании). SPJ в одном интервью говорил, что, вероятно, большая часть дальнейших разработок и исследований в области CS будут посвящены как раз системам эффектов. Хорошим примером здесь является модульная STM: её удалось сделать модульной именно за счёт явного её отделения от IO, а все мы знаем, какой это неблагодарный труд — отлаживать конкуррентные программы: здесь юнит-тесты — довольно скудное обеспечение надёжности (ввиду недетерминизма).

3) Возможности очень агрессивной оптимизации (в референциально прозрачной системе). То, что я выше писал про эффекты, скорее должно было пойти сюда. Вот, кстати, вспомнил ещё один недавний пример: Nested Data Paralellism.

> Наверное и раньше не очень и то хотелось?

В чём тогда смысл популяризации? Тот, кто хотел, и так будет писать.

> Ограниченной верификации программ

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

например, в параллельном программировании

А в данном случае, профит очевиден. Правда, реальная инженерная практика склоняется к тому, что необходимо изолировать разные потоки вычислений в различных адресных пространствах. Но это не всегда реалистично, поэтому действительно интересно (несколько лет назад помню была инфа, что это одна из причин интереса MS к haskell). Правда, систем где нужно реальное конкурентное программирование (веб-сервера я к таким не отношу) не так уж и много, а мнение о возрастающей важности параллельных вычислений кажется порождено рекламной компанией Intel ;)

> Впрочем, проффесиональным пиаром здесь никто не занимается, так что эффект может всякий, но, во всяком случае, ЛОР является крупнейшим (после поисковых систем) источником переходов на http://lisper.ru/. Так что, ещё раз, мне думается, что смысл в этом есть ;)

Вы неправильно пиарите. Не надо писать «виртуальные методы в C++ — ***» даже если это так. C++-программисты просто обидятся или обозлятся, и, так как слова исходили от пропагандиста LISP'а, они с пропагандируемым языком не захотят иметь ничего общего (по крайней мере, в ближайшее время). Конечно, неправильно переносить личное противостояние на собственно язык, но таковы люди...

Вы лучше приведите пример: аналог возможности X в лиспе (или развёрнуто покажите, что надобности в X нет, что для цели P здесь используется не X, а Y, расскажите о плюсах (и минусах!)). Вот тогда вас послушают.

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

А как именно Вы нарушаете корректность программы в процессе? Хотелось бы примеров (надеюсь, это не сложение коров и комплексных чисел, а то полтора землекопа в любом случае плохо :)

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

> А в данном случае, профит очевиден. Правда, реальная инженерная практика склоняется к тому, что необходимо изолировать разные потоки вычислений в различных адресных пространствах. Но это не всегда реалистично, поэтому действительно интересно (несколько лет назад помню была инфа, что это одна из причин интереса MS к haskell). Правда, систем где нужно реальное конкурентное программирование (веб-сервера я к таким не отношу) не так уж и много, а мнение о возрастающей важности параллельных вычислений кажется порождено рекламной компанией Intel ;)

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

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

систем где нужно реальное конкурентное программирование (веб-сервера я к таким не отношу) не так уж и много

А мне казалось, что это большинство интерактивных систем, а ведь их много.

> Эти ваши статические проверки дают только оптимизацию и больше ничего. Это давно известно на примере всех динамических языков. Ничего за последние 20 лет не пропустил?

Ты сейчас хаскеллистов здорово рассмешил ;)

Вот, что значит - не дочитать одну страницу :)

> Путь динамических языков - отказаться от подобных проверок вовсе, полагаясь на быстрое выявление всех ошибок и unit-тесты, и ведь это работает!

есть ещё срединное звено - бумеранг программирование

> А как именно Вы нарушаете корректность программы в процессе?

По разному. Точнее, я не пытаюсь её сохранять. Типично программы делятся на различные компоненты, между которыми есть связи. Вот довольно надуманный и пафосный пример. Есть некая система 3-х мерного проектирования, позволяющая проектировать подвесные мосты. Она имеет некий центральный модуль, обеспечивающий модель и несколько дополнительных: 3D-визуализация, модуль автоматической генерации чертежей, и модуль рассчитывающий уровни механических напряжений в материалах конструкции. Работая над расчётным модулем для проверки какой-либо идеи может потребоваться внести изменения в основную модель, но тогда окажутся скомпрометированными другие модули и в языках со статической проверкой типов может потребоваться вносить заметные изменения во все компоненты системы только для того, что бы система скомпилировалась. А не факт, что идея была верной и тогда придётся откатываться назад. Как результат, было проделано много работы по уговариванию компилятора, в которой совершенно не было никакого смысла.

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

Если бы мои идеи всегда были верными, то смысла в таком подходе не было бы: можно было бы садиться и сразу делать правильно. Но, увы, я так не умею, а вы?

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

Ещё один момент: поскольку система постоянно и довольно хаотично изменяется, то её дизайн изначально ориентирован на изменения, в полном соответствии с практиками XP.

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

«Тестирование доказывает наличие ошибок, но не их отсуствие» (с) Э.Дейкстра

и ведь это работает!

Ненавижу эту фразу. Ей можно оправдать любой говнокод, кривую архитектуру и нежелание понять чужую точку зрения.

таких ситуаций просто не бывает в реальной разработке, я с такими не сталкивался.

Ты не сталкивался.

> «Тестирование доказывает наличие ошибок,

но не их отсуствие» (с) Э.Дейкстра

Хм, что может доказать отсутствие ошибок? Более действенного способа для борьбы с ошибками, чем автоматические тесты я не встречал. Программ без ошибок, как известно, не бывает. Или что ты предлагаешь?

Ей можно оправдать любой говнокод, кривую архитектуру

Что такое говнокод? Результат - единственный возможный критерий. Если код работает и соответствует требования, то это не говнокод. Говнокод, это darcs, который может красивый и правильный, но только не работает.

Ты не сталкивался.

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

> «Тестирование доказывает наличие ошибок, но не их отсуствие» (с) Э.Дейкстра

К сожалению, отсутствие ошибок показать не сможет ничего.

> Поэтому, полезность системы типов, скажем так, совсем не очевидна.

LOL

> Хм, что может доказать отсутствие ошибок?

Зависит от ошибки. Например, от ошибок вида «no such attribute» статическая проверка спасает в 100% случаев. От деления на 0 - обвчно не спасает.

Программ без ошибок, как известно, не бывает. Или что ты предлагаешь?

Я предлагаю не выбрасывать никаких средств обнаружения ошибок.

Результат - единственный возможный критерий. Если код работает и соответствует требования, то это не говнокод.

А ты точно прогер? Правильная работа - это то, без чего код просто не рассматривается, он тупо не нужен. А дальше встают вопросы о модифицируемости и понимаемости. Прочитай http://www.linux.org.ru/jump-message.jsp?msgid=4911022&cid=4924387 , анонимный брат всё четко изложил.

Говнокод, это darcs, который может красивый и правильный, но только не работает.

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

Воевать с проблемами, которых нет, противоречит моим представлениям о разработке.

Ага, но пропагандировать свою точку зрения как единственно верную - это ты готов.

А проблемы есть, ты с ними не сталкивался просто.

> а мнение о возрастающей важности параллельных вычислений кажется порождено рекламной компанией Intel ;)

Производительность отдельно взятого ядра по сути уже не растет (в основном проблема с частотой). Количество вычислительных блоков может смело расти. Сложность задач повышается с каждым годом. Сможете ли Вы на одном ядре, с той же по сути производительностью, увеличивать скорость решения задачи? VFX, CAD/CAM/CAE как пример отраслей, где все упирается в скорость решения. Я уже не говорю про физиков и прочих астрономов.

> Есть некая система 3-х мерного проектирования, позволяющая проектировать подвесные мосты. Она имеет некий центральный модуль, обеспечивающий модель и несколько дополнительных: 3D-визуализация, модуль автоматической генерации чертежей, и модуль рассчитывающий уровни механических напряжений в материалах конструкции. Работая над расчётным модулем для проверки какой-либо идеи может потребоваться внести изменения в основную модель, но тогда окажутся скомпрометированными другие модули и в языках со статической проверкой типов может потребоваться вносить заметные изменения во все компоненты системы только для того, что бы система скомпилировалась. А не факт, что идея была верной и тогда придётся откатываться назад. Как результат, было проделано много работы по уговариванию компилятора, в которой совершенно не было никакого смысла.

I see. Вот только я всегда старался проектировать модули как можно более изолированными друг от друга (за исключением специально связанных). Я так понял, что центральный модуль представляет «движок» программы, а остальные модули пользуются его услугами для выполнения своих функций. Если так, то, IMHO, изменения в переферийном модуле в любом случае не должны отражаться на центральном модуле.

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

Я могу вызвать проблемый код непосредственно в REPL и таким образом корректность всей программы в данный момент мне вообще не нужна.

Интерпретаторы есть и для статики. Правда, это не совсем то, что сегодня можно найти в лиспе, но, может, я просто не знаю. По крайней мере, работать в стиле REPL можно.

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

Да, но результаты этих экспериментов Вы ведь всё равно обрабатываете сами, не так ли? В это время, ошибки на уровне типов («настоящих» полиморфных типов, да ещё с контекстами) вам сразу же скажут о _ваших_ ошибках. Мы здесь понимаем несовершенство разработчика вот так :)

Ещё один момент: поскольку система постоянно и довольно хаотично изменяется, то её дизайн изначально ориентирован на изменения, в полном соответствии с практиками XP.

А каковы причины непостоянности? By design, или какие-то внешние факторы? И да, XP, IMHO — довольно неоднозначная методология: говорят, там запрещают комментировать код! :)

> Я предлагаю не выбрасывать никаких средств обнаружения ошибок.

Ну уж нет. Средства должны быть пропорциональны трудозатратам. Я вот могу понять программистов на языках с латентной типизацией, приходящих туда с C++ или даже Java (хотя последняя стала ощутимо лучше).

Говнокод, это darcs, который может красивый и правильный, но только не работает.

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

А какие проблемы есть у darcs? Я просто действетельно не в курсе.

> А какие проблемы есть у darcs? Я просто действетельно не в курсе.

То же самое хотелось бы узнать. Работает, есть не просит.

> от ошибок вида «no such attribute» статическая проверка

спасает в 100% случаев.

В чем профит, если эта ошибка всё равно сразу велезет и unit-тесты её покажут?

Я предлагаю не выбрасывать никаких средств обнаружения ошибок.

Даже если они мешают вести нормальную разработку?

но пропагандировать свою точку зрения как единственно верную

- это ты готов.

И где я говорил, что моя точка зрения единственная верная?

А проблемы есть, ты с ними не сталкивался просто.

И?

> VFX, CAD/CAM/CAE как пример отраслей, где все упирается в скорость решения. Я уже не говорю про физиков и прочих астрономов.

Автоматическое распараллеливание (т.е. без аннотаций) пока плохо работает ибо пытается параллелить то, что не надо. А физики и прочие астрономы спокойно себе живут на сях и фортранах.

> изменения в переферийном модуле в любом случае не должны

отражаться на центральном модуле.

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

Ведь можно поменять «центр» отдельно и одну «переферию» отдельно,

а остальное просто не трогать

Возможность этого сильно зависит от степени зрелости проекта.

В это время, ошибки на уровне типов («настоящих» полиморфных типов,

да ещё с контекстами) вам сразу же скажут о _ваших_ ошибках.

Выполнение кода в REPL также сразу покажет ошибки. Т.е. с одной стороны есть unit-тесты, как долговременный фактор, и есть постоянно экспериментирование в REPL. Ключевым фактором является лёгкость выполнения кода в REPL.

А каковы причины непостоянности? By design,

или какие-то внешние факторы?

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

говорят, там запрещают комментировать код!

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

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

Ужастики рассказываешь. Анализ задачи нельзя свести к одному тестированию. «Тише едешь - дальше будешь!» (c)