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

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

Это я к тому, что будущее за параллельным кодом. В той или иной форме. И чистый функциональный код это самая та тема. Про перспективность NDP уже сказали выше.

> Ужастики рассказываешь. Анализ задачи нельзя свести к одному

тестированию. «Тише едешь - дальше будешь!» (c)

Угу, когда тебя уволят у тебя будет много времени, поразмышлять над задачей ;)

Вообще, у меня был такой отдельный предмет: «Планирование эксперимента» (как-никак, а закончил кафедру экспериментальной физики), так что очень даже можно, а часто это вообще единственный приемлемый вариант движения вперёд.

> Это я к тому, что будущее за параллельным кодом.В той или иной форме.

И чистый функциональный код это самая та тема.

И не чистый функциональный, а просто чистый - без побочных эффектов.

Про перспективность NDP уже сказали выше.

Это можно легко сделать в библиотеках - на функциональщину тут ничего не завязано.

> И не чистый функциональный, а просто чистый - без побочных эффектов.

Purely functional functions (or expressions) have no memory or I/O side effects (unless the computation of the result in itself is counted as a side-effect).

Может Вам так понятнее?

> Вообще, у меня был такой отдельный предмет: «Планирование эксперимента» (как-никак, а закончил кафедру экспериментальной физики), так что очень даже можно, а часто это вообще единственный приемлемый вариант движения вперёд.

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

Может быть, у тебя достаточно высокая квалификация для REPL в динамическом языке. Но я боюсь даже представить, что будет, если твой стиль разработки станет массовым. Это же все полетит к черту! Нет уж, пусть их проверяет компилятор. C#, Java и точка. Хорошо бы к хаскелю приучить, но это настолько маловероятно. А питон с перлом давать строго дозировано и только для небольших проектов. :)

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

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

А зачем вообще нужно такое экспериментирование, если есть тесты? Оно нужно для одно-двухразовой проверки кода. И что значит «лёгкость»? Отсутствие компиляции в объектный код / интерпретатор? Это есть. Работа с частью системы? Это тоже есть, насколько я могу судить. Просто сделанные ошибки всплывут в виде ошибок типов, а не исключений или неверных значений, что даёт прямую информацию о источнике ошибки (и более того: о возможных ошибках в других частях системы, если вы их подключите). В то же время, типы на этапе трансляции означают полное отсутствие ошибок в плане выделения и комбинирования сущностей.

Вопрос в том, как соотносится покрытие кода тестами с реально существующими ошибками, и насколько полно система типов выражает наши намерения относительно кода.

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

Ну, первое — ­это настоящее проклятие, да. Впрочем, я всё равно не вижу конфликта.

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

А как потом с этим кодом работать другим, новым в команде (или за её пределами)? Всё-таки ключевые управляющие структуры надо описывать.

> Purely functional functions (or expressions) have no memory or I/O side effects (unless the computation of the result in itself is counted as a side-effect).

Замечательно, и что? Функции, в которых нет memory or I/O side effects могут быть совершенно не функциональными. А для параллелизма как раз больше важно отсутствие побочных эффектов, чем функциональность как таковая.

> Это можно легко сделать в библиотеках - на функциональщину тут ничего не завязано.

Завязано. Не намертво, но завязано.

И вообще, в чём преимущество референциально прозрачных языков?

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

> Средства должны быть пропорциональны трудозатратам.

Конечно.

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

Что такое «латентная типизация»? Динамическая aka duck typing, вывод типов, зависимые типы или еще что-то?

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

А какие проблемы есть у darcs?

Сейчас - не знаю, спроси архимага. В старые времена (darcs 1.0) временами жрал память в три горла и тормозил до полной непригодности.

> Замечательно, и что? Функции, в которых нет memory or I/O side effects могут быть совершенно не функциональными. А для параллелизма как раз больше важно отсутствие побочных эффектов, чем функциональность как таковая.

Для обработки параллельных данных нужна только информация о способе их обработки. Всё остальное будет связывать эту обработку.

Функции, в которых «нет memory or I/O side effects» и есть функции из ФП по определению. sin(x) из C — это тоже «чистая» функция, и неважно, что под крышкой там ассемблерный код.

> Замечательно, и что? Функции, в которых нет memory or I/O side effects могут быть совершенно не функциональными. А для параллелизма как раз больше важно отсутствие побочных эффектов, чем функциональность как таковая.

Erm, Я так подозреваю, что функция, не имеющая побочных эффектов и есть чистая функция ;) Но Вы можете продолжать цепляться за то, что можно все оформить в императивном виде. Можно. Но не нужно.

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

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

«Сразу вылезет»? Unit-тесты покажут? Тоньше надо, тоньше. Или ты хочешь сказать, что у тебя код покрыт unit-тестами на 100%, включая процедуры обработки ошибок?

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

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

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

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

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

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

И?

И надо сознавать, что твой опыт ограничен, и слушать, что говорят другие.

> Завязано. Не намертво, но завязано.

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

И вообще, в чём преимущество референциально прозрачных языков?

Мы знаем, в чем их преимущества :). Но также знаем в чем недостатки.

Все знают, как бурно развивается (почти) любая наука после её математизации

Не все знают, роль математики сильно преувеличена, можете по этому поводу почитать зализняка. И удостовериться на примере экономики.

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

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

математика и программирование настолько несовместимы?

Да, математика - это наука, на грани искусства, а программирование - это суровая инженерия. Разница очень велика.

> Что такое «латентная типизация»? Динамическая aka duck typing, вывод типов, зависимые типы или еще что-то?

Вытяжка из r6rs:

Scheme has latent as opposed to manifest types. Types are associated with objects (also called values) rather than with variables. (Some authors refer to languages with la- tent types as untyped, weakly typed or dynamically typed languages.) Other languages with latent types are Python, Ruby, Smalltalk, and other dialects of Lisp. Languages with manifest types (sometimes referred to as strongly typed or statically typed languages) include Algol 60, C, C#, Java, Haskell, and ML.

Короче, динамическая.

Средства должны быть пропорциональны трудозатратам.

Конечно.

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

Сейчас - не знаю, спроси архимага. В старые времена (darcs 1.0) временами жрал память в три горла и тормозил до полной непригодности.

Я тоже слышал о проблемах в 1-ой ветке. Говорили, что во 2-ой всё поправлено.

>> И вообще, в чём преимущество референциально прозрачных языков?

Мы знаем, в чем их преимущества :). Но также знаем в чем недостатки.

Кстати, в чем?

> Кстати, в чем?

Простая задача - словарь, в который параллельно пишет несколько потоков. Как сделать это не через задницу в референциально прозрачном языке? И не стоит приводить тут решение олега :)

Кстати, почему scheme сделали не референциально прозрачной - написано в SICP.

> Erm, Я так подозреваю, что функция, не имеющая побочных эффектов и есть чистая функция ;) Но Вы можете продолжать цепляться за то, что можно все оформить в императивном виде. Можно. Но не нужно.

Разница в том, что можно пользоваться полностью императивным языком и использовать параллелизм одновременно, как простейший пример OpenMP.

> Мы знаем, в чем их преимущества :). Но также знаем в чем недостатки.

Я надеюсь, это решат кдобные и выразительные системы эффектов. В Haskell одна только IO. Это уже что-то, но очень мало.

Не все знают, роль математики сильно преувеличена, можете по этому поводу почитать зализняка. И удостовериться на примере экономики.

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

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

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

Да, математика - это наука, на грани искусства, а программирование - это суровая инженерия. Разница очень велика.

Програмирование ­— тоже искусство :) Ну так развитие математики тоже влияет на инженерию. Кроме того, компьютер намного ... «математичнее» реального мира, здесь уже можно с некоторого порога применять больше матметоды, нежели эксперимент (потому что компьютер создаём мы сами).

> Простая задача - словарь, в который параллельно пишет несколько потоков. Как сделать это не через задницу в референциально прозрачном языке?

STM?

может кому будет интересно http://www.cs.auckland.ac.nz/~chaitin/lm.html

> А зачем вообще нужно такое экспериментирование, если есть тесты?

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

Фактическое отсутствие постановки задачи

Ну, первое — это настоящее проклятие, да

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

А как потом с этим кодом работать другим, новым в команде (или за её

пределами)? Всё-таки ключевые управляющие структуры надо описывать.

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

> Просто экономика, как и любая сложная система, требует либо

огромных выч. мощностей, либо какого-то прорыва в математике.

Я таки не понял, программирование оно намного проще экономики, или по какой причине от «математизации» программирования должен вдруг взяться положительный профит?

Ну так развитие математики тоже влияет на инженерию.

С какими инженерными областями вам приходилось сталкиваться?

компьютер намного ... «математичнее» реального мира

потому что компьютер создаём мы сами

Я не знаю, чем занимаетесь вы, но я создаю программы для решения проблем из этого самого реального мира.

> Не все знают, роль математики сильно преувеличена, можете по этому поводу почитать зализняка. И удостовериться на примере экономики.

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

Да, математика - это наука, на грани искусства, а программирование - это суровая инженерия. Разница очень велика.

а как же быть с http://www.geocities.com/tablizer/science.htm ? это мысли не последнего человека в области доказуемого программирования

> STM?

Оно про блокировки, а не про писать в несколько потоков в общий словарь.

> Фактически, это стандартная ситуация при разработке бизнес-приложений

на люблю Java - но опытные жаберы тут заткнут любого лиспера по скорости и качеству разработки

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

включая процедуры обработки ошибок?

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

И надо сознавать, что твой опыт ограничен, и слушать,

что говорят другие.

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

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

Обычно в системах типов не ищут ошибки. Разработчик часто начинает с сигнатуры типа как с постановки задачи для функции — что дано и что найти. И если есть ошибка в типах — значит, построение спецификации (или реализации) было неправильным. Конечно, типы могут меняться, просто важно отметить ключевые функции. Кстати, такой подход применялся в занятной книжке «How To Design Programs» по Scheme.

Если есть желание ознакомиться с таким процессом разработки, то рекомендую < http://www.cs.chalmers.se/~rjmh/Papers/pretty.ps >. Там вроде бы неплохо описывается процесс: от спецефикации до программы.

О нет, это не проклятие, это самая обычная ситуация.

Как хотите, а мне комфортнее с хотя бы каким-то намёком на то, что вообще они от нас хотят ;)

> В случае ошибок в моём софте ядерный реактор не взорвётся, а вот время разработки является совершенно критическим.

переходите на Delphi, епт

> Програмирование ­— тоже искусство :) Ну так развитие математики тоже влияет на инженерию. Кроме того, компьютер намного ... «математичнее» реального мира, здесь уже можно с некоторого порога применять больше матметоды, нежели эксперимент (потому что компьютер создаём мы сами).

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

> В случае ошибок в моём софте ядерный реактор не взорвётся, а вот время разработки является совершенно критическим.

Вот. У тебя такие trade-off'ы, а у других - другие.

Например система менеджмента качества (СМК) учит нас, что качество является следствием качественных процессов, а вовсе не инструментов.

Главное, чтобы ты радио «Радонеж» не слушал :)

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

Ахренеть %) Есои ты еще не заметил, то твои unit-тесты - это как раз «инструмент, который может что-то проверять» :D Только вот проверка unit-тестами - специфическая и в некотором смысле слабая и нетехнологичная (не проверяют гарантированно всю кодовую базу и требуют непонятного времени на исполнение).

P.S. unit-тесты - полезный инструмент, независимо от модели типизации.

> на люблю Java - но опытные жаберы тут заткнут любого лиспера

по скорости и качеству разработки

Пруфлинк будет?

переходите на Delphi, епт

При чём тут дельфи? По вашему бизнес-приложений это морды к базе лепить?

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

Системная динамика. В общем, тоже математика. Но там сами дифф.уры не так важны. Это больше теория о сложных системах. Стоки, потоки, обратные связи. Понятие о сопротивлении системы. Лично я считаю, что в этом всем очень много математики. Поддерживаю.

> И если есть ошибка в типах — значит, построение спецификации (или реализации) было неправильным.

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

Если есть желание ознакомиться с таким процессом разработки, то рекомендую < http://www.cs.chalmers.se/~rjmh/Papers/pretty.ps >. Там вроде бы неплохо описывается процесс: от спецефикации до программы.

Рекомендую ознакомится с «No silver bullet» Brooks и «The limits of correctness» Brian Smith, чтобы распрощатся с иллюзиями.

> Пруфлинк будет?

на статистику и программы? гугль вам сразу все покажет

При чём тут дельфи? По вашему бизнес-приложений это морды к базе лепить?

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

Проектирование самолетов. Сплошная математика (если не касаться технологии изготовления).

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

:) у вас есть степень в экономике, или хотя бы экономическое во?

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

на статистику и программы? гугль вам сразу все покажет

Ну вот, опять... А ты даже не знаешь, что у жаверов уже генетически толстые жопы, неразвитый плечевой пояс и ФГМ :)

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

Спецификация может быть и в голове.

Рекомендую ознакомится с «No silver bullet» Brooks и «The limits of correctness» Brian Smith, чтобы распрощатся с иллюзиями.

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

> Проектирование самолетов. Сплошная математика

(если не касаться технологии изготовления).

Хм, я работал в отделе, большинство сотрудников которого ранее работало конструкторами в авиационных конструкторских бюро. Что-то математики я у них не замечал (у некоторых то с арифметикой не всё было хорошо).

> Вы не так поняли. Я говорил не о конкретной области математики,

а о математике вообще, как способе думать о проблемах.

Хм, и в чём смысл? Программирование по своей сути значительно более близко к литературе, чем к математике.

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

> Ну вот, опять... А ты даже не знаешь, что у жаверов уже генетически толстые жопы, неразвитый плечевой пояс и ФГМ :)

по-моему это больше относится к маргинальщикам :)

>относится к маргинальщикам

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

> миллионы мух не ошибаются, 90% всегда правы, нужно следовать за ними, уже все решено, думать не нужно.

mv залогиньтесь и перестаньте защищать п%дарасов

> Проектирование самолетов. Сплошная математика (если не касаться технологии изготовления).

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

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

а самолет только недавно начали
пытаться моделировать.
а так в ЦАГИ в три смены обдувались
и комлектующие и модельки.

> Хм, я работал в отделе, большинство сотрудников которого ранее работало конструкторами в авиационных конструкторских бюро. Что-то математики я у них не замечал (у некоторых то с арифметикой не всё было хорошо).

Некоторые «программисты» только и умеют, что жать на кнопку «Любая_кнопка». Не судите по не пойми кому ;) Матанализ, дискретная математика, вычислительная математика, аналитическая геометрия, статистика и прочее. Это только те разделы математики, которые изучают студенты авиационных институтов по второй курс включительно. Потом все значительно хуже - гидравлика (не думайте, что это «переливание жидкостей из пустого в порожнее», это куча уравнений), сопромат, теоретическая механика, пластичность, упругость (конечные елементы, тензоры напряжений и прочее). И так далее и тому подобное. Много всего и в основе всего математика.

> Дело в том, что мат.модель не всегда может быть адекватна реальности

Мат модель часто можно получить только опираясь на результаты экспериментов. Но факта это никак не отменяет (а обработка результатов эксперимента - это снова математика :)) )

>залогиньтесь и перестаньте защищать п%дарасов

да у тебя с головой просто проблемы.