я категорически не понимаю смысла туториалов(всяких кружек, капель и вёдер) типа «а вот это дети тип данных»…
во-первых, более качественных туториалов обычно наличествует полный интернет (плюс тележка книг).
во-вторых, имхо, единственный внятный способ изучить язык это начать на нём писать какие-то реальные велосипеды. чтение отвлеченных упражнений (а давай-те как сложим числа из списка) пользы приносит пренебрежительно мало…
ну это много где нынче успешно применяется… собственно мой point в том и состоит, что вот такие гибриды (функциональщина + императивщина) таки являются оптимумом с практической точки зрения…
субъективное утверждение требует хотя бы статистического доказательства…
Вот кстати в соседнем посте человек привёл достаточно интересный факт о том, что GHCшники отказались от darcs, о котором я не знал… Если бы он был проще, так darcs давно бы взяли бы и допилили бы… А так они взяли и пересели на git, который суть C + bash (и никакой функциональщины). Получается продукт написанный на «небезопасном и отсталом» языке качественней чем проект написанный на «безопасном языке будущего»? В чем причина?
а в чистых функциональных «ленту и прибамбасы» приходится приделывать обратно (монады там всяческие, unsafePerformIO), разве нет?
никакой theorem prover не сможет проанализировать типичный императивный mess, где память рандомно пишется-читается из десятков потоков
аналогичное, как мы уже поняли, верно и для FP. Никакой анализатор не справится с полноценным языком… Эта истина, которую я высказал в самом начале трэда…
Осталось лишь понять, насколько практически полезны и удобны «неполноценные» языки…
не-не-не! вы же говорите «могу». Вы говорите «Haskell — панацея». Вы говорите «profit и работает как часы». Я не просто так вцепился…
они допустимы только там, где можно доказать их завершимость
если доказать нельзя — рефакторим код так, чтобы доказывалось
В чем отличие от императивного кода? Для него тоже самое верно… Можно рефакторить, пока prover не прожуёт… Можно выделять подможества, для которых разрешима задача проверки корректности… Всё можно.
и тут у меня возникает вопрос… а причем здесь вообще FP? =)
Разве вы не видите, что все те же рассуждения можно привести и для императивных языков программирования?
Вообщем, я не вижу убедительных доказательств в пользу того факта, что Haskell как бы снижает стоимость разработки/поддержки и при этом не привносит дополнительных издержек.
во-первых, более качественных туториалов обычно наличествует полный интернет (плюс тележка книг).
во-вторых, имхо, единственный внятный способ изучить язык это начать на нём писать какие-то реальные велосипеды. чтение отвлеченных упражнений (а давай-те как сложим числа из списка) пользы приносит пренебрежительно мало…
еще Миранда =)
Я не спрашивал, почему пересели.
Я спрашивал, почему менее качественный.
Ну некоторое чистое подмножество лучше поддаётся анализу, этого я и не отрицаю.
Только ведь и в императивных языках такие подмножество выделять можно.
Например, у нас в ИСИ СО РАН есть лаборатория, в которой весьма успешно занимаются верификацией подмножества C#.
Однако, Scheme не чист, не ленив и не статически типизирован =)
у вас есть доказательство сего факта?
Вот кстати в соседнем посте человек привёл достаточно интересный факт о том, что GHCшники отказались от darcs, о котором я не знал… Если бы он был проще, так darcs давно бы взяли бы и допилили бы… А так они взяли и пересели на git, который суть C + bash (и никакой функциональщины). Получается продукт написанный на «небезопасном и отсталом» языке качественней чем проект написанный на «безопасном языке будущего»? В чем причина?
аналогичное, как мы уже поняли, верно и для FP. Никакой анализатор не справится с полноценным языком… Эта истина, которую я высказал в самом начале трэда…
Осталось лишь понять, насколько практически полезны и удобны «неполноценные» языки…
не-не-не! вы же говорите «могу». Вы говорите «Haskell — панацея». Вы говорите «profit и работает как часы». Я не просто так вцепился…
В чем отличие от императивного кода? Для него тоже самое верно… Можно рефакторить, пока prover не прожуёт… Можно выделять подможества, для которых разрешима задача проверки корректности… Всё можно.
В чем же реальный, практический profit FP?
никто же не говорит, что их не должно быть
я думаю так
они допустимы только там, где можно доказать их завершимост
и тут у меня возникает вопрос… а причем здесь вообще FP? =)
Разве вы не видите, что все те же рассуждения можно привести и для императивных языков программирования?
Вообщем, я не вижу убедительных доказательств в пользу того факта, что Haskell как бы снижает стоимость разработки/поддержки и при этом не привносит дополнительных издержек.