Последние полтора — два года тихо фанатею от возможностей функциональных языков.
Бывает приятно посидеть вечерком на работе, поделать простенькие программки, почитать баталии ООП vs ФЯ. Достаточно продолжительное время пробовал использовать фвп в коде на c#, но, как бы это сказать, запал стал проподать.
Причин две:
1. Насущные задачи замечательно решаются на простой, как три копейки, java с её немудрёным ооп.
2. Какие бы фя не были хорошие за меня она задачу не решат А это значит, что уменьшение количества строчек кода не сильно сократит общее время потраченное на решение задачи.
Призадумался над этим и решил, что я, наверное, не правильные задачи пытаюсь решить на функциональных языках и потому не вижу стратегического выйгрыша от их использания.
Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?
Написать на этих языках интерпретатор брейнфака в тьюринг полном виде (с бесконечной памятью), а потом на любом из полученных брейнфаков все исходные языки.
Здравствуйте, mini_root_2, Вы писали:
__>Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>>Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?
__>Написать на этих языках интерпретатор брейнфака в тьюринг полном виде (с бесконечной памятью), а потом на любом из полученных брейнфаков все исходные языки.
зачем?
__>>Написать на этих языках интерпретатор брейнфака в тьюринг полном виде (с бесконечной памятью), а потом на любом из полученных брейнфаков все исходные языки. I>зачем?
Здравствуйте, mini_root_2, Вы писали: __>Написать на этих языках интерпретатор брейнфака в тьюринг полном виде (с бесконечной памятью), а потом на любом из полученных брейнфаков все исходные языки.
Получится сильно проще, чем сделать тот же самый интерпретатор на java?
У меня была мысль сделать плагин для редактирования java байткода, но проблемы с интеграцией полученного кода с IDE делают эту задачу черезмерно усложнённой.
NGG>Причин две: NGG>1. Насущные задачи замечательно решаются на простой, как три копейки, java с её немудрёным ооп.
Замечательно — это как?
NGG>2. Какие бы фя не были хорошие за меня она задачу не решат А это значит, что уменьшение количества строчек кода не сильно сократит общее время потраченное на решение задачи.
Полное решение задачи бьется на три этапа — дизайн, кодирование и отладка. ФЯ могут существенно сократить тебе две последних. С первой тоже не все так плохо: http://en.wikipedia.org/wiki/Z_notation
Из Z растут ноги алгебраических типов.
NGG>Призадумался над этим и решил, что я, наверное, не правильные задачи пытаюсь решить на функциональных языках и потому не вижу стратегического выйгрыша от их использания.
NGG>Может посоветуюте такую задачку, чтобы решив её на java и на, скажем, lisp или scala удалось постичь дао?
Например, библиотеку комбинаторов разборщиков (parser combinators).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Замечательно — это как?
Это значит решаются и кодирование не приносит головной боли. Естественно, я говорил не о задачах вообще, а о задачах, с которыми сталкиваюсь я лично.
T>Например, библиотеку комбинаторов разборщиков (parser combinators).
T>Полное решение задачи бьется на три этапа — дизайн, кодирование и отладка. ФЯ могут существенно сократить тебе две последних.
parser combinators — похожая библиотека, кажется, есть на haskell? Да, на java это будет страшновато Но, опять-таки, хочется увидеть преимущества на задаче близкой к "реальной" жизни. Если задача хорошо формулируется на языке математики, то преписав формулировку почти в 1 к 1 на тот же хаскел можно "быстро" получить решение — здесь плюсы "очевидны".
А если такой формулировки нет? Если постановка задачи меняется на этапе кодирования?
Фазы "дизайн", "кодирование" и "отладка" начнут скакать из одной в другую. Где гарантия, что изменния в постановке задачи не разрушит львиную долю работы уже проделланной на этапе кодирования? ООП + техника рефакторинга + юнит тестирование — предлагает не плохой способ сохранять "код" при подобных изменениях. Существуют ли аналогичные приёмы в функциональном мире? Там же даже IDE привычных нет
Здравствуйте, NotGonnaGetUs, Вы писали:
NGG>Фазы "дизайн", "кодирование" и "отладка" начнут скакать из одной в другую. Где гарантия, что изменния в постановке задачи не разрушит львиную долю работы уже проделланной на этапе кодирования? ООП + техника рефакторинга + юнит тестирование — предлагает не плохой способ сохранять "код" при подобных изменениях. Существуют ли аналогичные приёмы в функциональном мире? Там же даже IDE привычных нет
В гибридах типа Немерле ФП используется на уровне методов, где собственно говоря и даёт максимальный эффект. При этом ООП, рефакторинг, тесты остаются на месте.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, thesz, Вы писали:
NGG>>Причин две: NGG>>1. Насущные задачи замечательно решаются на простой, как три копейки, java с её немудрёным ооп.
T>Замечательно — это как?
NGG>>2. Какие бы фя не были хорошие за меня она задачу не решат А это значит, что уменьшение количества строчек кода не сильно сократит общее время потраченное на решение задачи.
T>Полное решение задачи бьется на три этапа — дизайн, кодирование и отладка. ФЯ могут существенно сократить тебе две последних. С первой тоже не все так плохо: http://en.wikipedia.org/wiki/Z_notation
Дизайн тоже существенно сократит. У ФЯ меньше semantic gap между постановкой и реализацией. Элментарно, дизайнить надо меньше, потому что программа более декларативна, ближе к спецификации, определению. По сути, это основной источник экономии времени разработки. Кодирование + отладка строго кореллируют по времени с объемом кода — но суммарно могут занимать около трети всего времени разработки у опытного программера. Или даже меньше.
Вот возьмем скажем квиксорт. На С мне надо задизайнить технику управления памятью, а на хаскеле я просто дам рекурсивное определение отсортированному массиву, и все. Кстати, читал мою статью "что такое ФЯ" — скомбинированную из переводов плюс приправленную авторскими добавками?
NGG>>Фазы "дизайн", "кодирование" и "отладка" начнут скакать из одной в другую. Где гарантия, что изменния в постановке задачи не разрушит львиную долю работы уже проделланной на этапе кодирования? ООП + техника рефакторинга + юнит тестирование — предлагает не плохой способ сохранять "код" при подобных изменениях. Существуют ли аналогичные приёмы в функциональном мире? Там же даже IDE привычных нет
IT>В гибридах типа Немерле ФП используется на уровне методов, где собственно говоря и даёт максимальный эффект. При этом ООП, рефакторинг, тесты остаются на месте.
Define максимальный эффект.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Замечательно — это как? NGG>Это значит решаются и кодирование не приносит головной боли. Естественно, я говорил не о задачах вообще, а о задачах, с которыми сталкиваюсь я лично.
T>>Например, библиотеку комбинаторов разборщиков (parser combinators). T>>Полное решение задачи бьется на три этапа — дизайн, кодирование и отладка. ФЯ могут существенно сократить тебе две последних. NGG>parser combinators — похожая библиотека, кажется, есть на haskell? Да, на java это будет страшновато Но, опять-таки, хочется увидеть преимущества на задаче близкой к "реальной" жизни. Если задача хорошо формулируется на языке математики, то преписав формулировку почти в 1 к 1 на тот же хаскел можно "быстро" получить решение — здесь плюсы "очевидны". NGG>А если такой формулировки нет? Если постановка задачи меняется на этапе кодирования?
Нормалек.
У меня такое было.
Я в модель процессора добавлял штуку под названием bypass. Про нее вспомнили уже в середине.
Справились, именно кодирование заняло около двух недель с сохранением всех предыдущих фич (их было уже довольно много).
Но это то, что буржуи называют anecdotical experience. Вернемся к теории.
Если ты умеешь переводить предметную область в область математики, то тогда Хаскель и ничто другое.
А математика умеет описывать уже очень много интересных областей.
NGG>Фазы "дизайн", "кодирование" и "отладка" начнут скакать из одной в другую. Где гарантия, что изменния в постановке задачи не разрушит львиную долю работы уже проделланной на этапе кодирования? ООП + техника рефакторинга + юнит тестирование — предлагает не плохой способ сохранять "код" при подобных изменениях. Существуют ли аналогичные приёмы в функциональном мире? Там же даже IDE привычных нет
Вопрос об IDE мы оставим за кадром.
Сила в языке, не в IDE, IDE ее только немного увеличивает, поэтому вернемся к языку.
perser combinators я использовал в реальной задаче — надо было сделать инструмент для оценки трудоемкости создания узлов инженерами-электронщиками.
Есть аналоги на VHDL и (или) Verilog (на opencores), надо оценить трудозатраты инженера на написание своего такого же по количеству строк кода в доступном исходнике.
Стиль оформления меняется сильно, штуки наподобие indent нет, я решил написать свой разборщик (после того, как в скрипте на тикле получилось более десятка регулярных выражений).
Написал разбор Verilog и VHDL за две недели. Если что, он ругался и пытался продолжить подсчет, пропуская непонятное.
Ошибка подсчета составляла <5%.
Что у меня было.
У меня был лексер с одним вариантом комбинаторов. Из этого набора комбинаторов я собрал вариант для парсера, с произвольным откатом (копирование + изменения первого варианта). Еще через некоторое время я добавил ко второму варианту указание точного места ошибки путем небольшого изменения данных внутри монады. Внешне интерфейс общения с библиотекой остался прежним. Это показывает высокий уровень абстракции.
Разбор кусков синтаксиса языка я тестировал с помощью REPL. Поэтому юнит-тестов у меня, практически, не было, поскольку изменения часто были объемными, было подобие regression tests (просто набор исходников на двух V и в них каждый раз должно было быть все меньше ошибок. Соответственно, 99% кода пошло в готовый продукт, а не на проверку отсутствия ошибок.
Делал я это все в Far commander + mingw + ghci.
IDE не пользуюсь по принципиальным соображениям уже года два (тогда использовал полгода — gamedev, — и до этого не использовал тоже лет восемь.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Define максимальный эффект.
По сути ФП — это программирование в выражениях. То есть программа есть одно большое выражение производящее вычисление без побочных эффектов (форумала).
Языки вроде Немерле или Скалы позволяют использовать все рпиемущества ФП внтури методов, но при этом сама программа является ОО.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, thesz, Вы писали:
T> Вопрос об IDE мы оставим за кадром. T> Сила в языке, не в IDE, IDE ее только немного увеличивает, поэтому вернемся к языку. T> ... T> IDE не пользуюсь по принципиальным соображениям уже года два (тогда использовал полгода — gamedev, — и до этого не использовал тоже лет восемь.
Не согласен. Когда я изучал F# (правда, я его уже почти забыл , то очень хорошо прочувствовал, как F#-плагин к студии помогает экономить время. Не надо было тратить время на поиски и вспоминания, где какие типы, у кого какие методы и допустимые параметры...
Другое дело, что сам F# неудобен по сравнению с Хаскеллем... Приходилось тратить время на рефакторинги, которые в Хаскелле просто не возникли бы...
T>>Define максимальный эффект. VD>По сути ФП — это программирование в выражениях. То есть программа есть одно большое выражение производящее вычисление без побочных эффектов (форумала). VD>Языки вроде Немерле или Скалы позволяют использовать все рпиемущества ФП внтури методов, но при этом сама программа является ОО.
Хорошо.
Слабо логически связать "преимущества ФП" и тот факт, что "сама программа является ОО?"
(третья версия ответа. Две первых были очень грубы)
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
G>Дизайн тоже существенно сократит. У ФЯ меньше semantic gap между постановкой и реализацией. Элментарно, дизайнить надо меньше, потому что программа более декларативна, ближе к спецификации, определению. По сути, это основной источник экономии времени разработки. Кодирование + отладка строго кореллируют по времени с объемом кода — но суммарно могут занимать около трети всего времени разработки у опытного программера. Или даже меньше.
Пожалуй, я понял, что можно добавить.
Кодирование — это получение готового продукта.
Дизайн — подготовка (preproduction).
Отладка — доводка (postproduction).
Уменьшая время на дизайн и отладку, мы улучшаем общее использование времени, у нас больше времени (относительно) уходит на получение этих самых deliverables.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Define максимальный эффект. IT>Что именно тебе не понятно в этом выражении: максимальный или эффект?
Словосочетание.
Во-первых, эффект, он положительный или?
Во-вторых, что за сам эффект, в чем проявляется.
В-третьих, определи "степень," чтобы было понятно, что за максимальность.
После чего мы вернемся к применимости этого дела в программе в целом.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, IT, Вы писали:
IT>В гибридах типа Немерле ФП используется на уровне методов, где собственно говоря и даёт максимальный эффект. При этом ООП, рефакторинг, тесты остаются на месте.
Да, безусловно, использование функциональных фич на уровне методов даёт свои плюсы. Но, как мне кажется, эти плюсы скорее синтаксический сахар. С ними приятнее, но их использование быстрее программу не сделают, скорее наоборот (из-за неявного создания классов обёрток для методов).
Поясню на примере: В с# у класса лист есть методы ака map, filter, etc создающие новые листы. В "чисто" функциональном языке компилятор/рантайм могут позаботиться о том, чтобы новый лист не создавался, если старый уже никому не будет нужен. Как добиться подобного в с#? Компилятор немерле умеет делать такое?
Если нам не помогут, то мы тоже никого не пощадим.
