Comments 41
Посмотреть бы пример проектирования корпоративного ПО, а лучше и прямо бухгалтерского…
Для этого можно было бы наняться в банк Bank of America Merril Lynch. Не совсем бухгалтерия, но все же о деньгах.
Как уж построена их система, мы можем только догадываться…
Как уж построена их система, мы можем только догадываться…
UFO just landed and posted this here
Pattern matching, это больше про удобный доступ к составным данным, деструктурирование.
Основная идея ФП, в отсутствии состояний и иммутабельности данных, с этой точки зрения ФП и ООП сильно отличаются.
Основная идея ФП, в отсутствии состояний и иммутабельности данных, с этой точки зрения ФП и ООП сильно отличаются.
UFO just landed and posted this here
Вы забываете, что в ФП граница между данными и кодом почти отсутствует. Понимая данные как то, что можно паттерн-матчить, вы упускаете возможность создавать, напимер, список функций-мутаторов, который позднее может быть применен к данным, или даже модифицирован в другой список, или даже модифицирован в одну функцию, которая уже и будет работать с данными…
UFO just landed and posted this here
Что, простите, является тонкостью дизайна конкретного языка? Каррирование? Или отсутствие границы между кодом и данными? Это неотъемлемая часть Любого ФЯ и лямбда-исчисления. А JS, кстати, весьма «функционален». Я полагаю, разговора с вами не получится, так как вы не разбираетесь в теме.
UFO just landed and posted this here
Отсутствие между кодом и данными характерно для Лиспо-подобных языков и для языков семейства ML, к которым относится Haskell.
И опять вы нарушаете законы логики. На этот раз вы сделали прямую логическую ошибку. Вы смысл фразы «весьма функциональный» вы приравняли к смыслу фразы «является функциональным», присвоили данное неверное заключение мне и опровергли его, очевидным фактом.
Чтобы разговаривать по существу, необходимо избегать подобных ошибок.
Функции как данные
module Main where
import System.Random as R
import qualified Data.List as L
alg1 [] = []
alg1 (p:xs) = alg1 [ x | x <- xs, x < p]
++ [p]
++ alg1 [x | x <- xs, x >= p ]
alg2 [] = []
alg2 (p:xs) = (alg2 lesser) ++ [p] ++ (alg2 greater)
where
lesser = filter (< p) xs
greater = filter (>= p) xs
quicksorts = [alg1, alg2]
testData = take 10 $ R.randomRs (1, 100) (mkStdGen 10) :: [Int]
expectedData = L.sort testData
test = all (== expectedData) $ map ($ testData) quicksorts
main = do
putStrLn $ "Test result: " ++ show test
print $ alg1 testData
print $ alg2 testData
И опять вы нарушаете законы логики. На этот раз вы сделали прямую логическую ошибку. Вы смысл фразы «весьма функциональный» вы приравняли к смыслу фразы «является функциональным», присвоили данное неверное заключение мне и опровергли его, очевидным фактом.
Чтобы разговаривать по существу, необходимо избегать подобных ошибок.
UFO just landed and posted this here
Haskell не является динамическим языком, а то, что вы просите, как раз можно сделать только на динамическом языке.
Однако, если вам хочется видеть абстрактное синтаксическое дерево Haskell-кода, можно воспользоваться функциями модуля «Language.Haskell.Parser» из состава «haskell-src», и скормить функции parseModule ваш код.
Либо можно построить quicksort на вычислительном AST, которое потом выполнить самостоятельно. А напечатать AST очень просто.
P.S. Это не спекуляции.
Дано:
Существует множество D (языки с динамической типизацией).
x принадлежит D.
Существует множество F (функциональные языки).
По определению, F != D.
Ваше рассуждение:
«Если для вас весьма функционален JS» -> Предположим, x имеет свойство f (весьма функционален).
«то любой язык с динамической типизацией» -> Следовательно, для любого l из D: l имеет свойство f.
«В действительности они не являются функциональными» -> Противоречие. Все l из D не принадлежат F.
Однако, последнее заключение не является противоречием первому, так как подобного условия не было. Следовательно, последнее заключение не относится к цепочке рассуждений, а значит, не является корректным доказательством.
Однако, если вам хочется видеть абстрактное синтаксическое дерево Haskell-кода, можно воспользоваться функциями модуля «Language.Haskell.Parser» из состава «haskell-src», и скормить функции parseModule ваш код.
Либо можно построить quicksort на вычислительном AST, которое потом выполнить самостоятельно. А напечатать AST очень просто.
P.S. Это не спекуляции.
Дано:
Существует множество D (языки с динамической типизацией).
x принадлежит D.
Существует множество F (функциональные языки).
По определению, F != D.
Ваше рассуждение:
«Если для вас весьма функционален JS» -> Предположим, x имеет свойство f (весьма функционален).
«то любой язык с динамической типизацией» -> Следовательно, для любого l из D: l имеет свойство f.
«В действительности они не являются функциональными» -> Противоречие. Все l из D не принадлежат F.
Однако, последнее заключение не является противоречием первому, так как подобного условия не было. Следовательно, последнее заключение не относится к цепочке рассуждений, а значит, не является корректным доказательством.
UFO just landed and posted this here
О ссылке: да, лисповая реализация именно такая, а у Haskell иная реализация, и обе имеют право на существование. Но эти две реализации в равной мере иллюстрируют концепцию «code == data», и нет оснований говорить, что существование одной реализации автоматически делает другую ущербной.
Спорить больше не буду.
И да, я сегодня несговорчив, приношу извинения.
Спорить больше не буду.
И да, я сегодня несговорчив, приношу извинения.
Боюсь, что подобная трактовка паттерн-матчинга слишком притянута за уши. И к наследованию не имеет отношения. ФП от ООП действительно отличается. Если не принять это как аксиому, у вас будет получаться снова то же ООП на функциональном языке, только выглядеть и работать будет ужасно. Знаете, в чем еще отличие? В ФП позволительно и даже важно работать с, гм, «недоопределенными» функциями, когда n-Арной функции дадены n-k аргументов. Это ведет к гораздо большей гибкости, нежели любой ООП-механизм. Код получается совершенно иной, с иным дизайном, с другой основопей идеей.
А законыв ФП, действительно, есть, и они о другом.
А законыв ФП, действительно, есть, и они о другом.
UFO just landed and posted this here
Нет. Цель проектирования — получить результат за приемлемые потраченные ресурсы с приемлемой сложностью поддержки и доработки. А «high cohesion low coupling» — лишь важный способ этого добиться.
Про самообман вы передергиваете. Только что вы присвоили мне придуманную формулировку «списки и кортежи автоматически решат проблемы проектирования» и, как водится, смело с ней разобрались. Этот прием называется «Чучело».
Если бы списки и кортежи решили все мои проблемы, этой статьи бы не было.
А названные принципы нигде и не отвергаются, читайте внимательнее. Вот только их недостаточно для проектирования. Говоря вашими словами, эти принципы не решают автоматически проблемы проектирования.
Про самообман вы передергиваете. Только что вы присвоили мне придуманную формулировку «списки и кортежи автоматически решат проблемы проектирования» и, как водится, смело с ней разобрались. Этот прием называется «Чучело».
Если бы списки и кортежи решили все мои проблемы, этой статьи бы не было.
А названные принципы нигде и не отвергаются, читайте внимательнее. Вот только их недостаточно для проектирования. Говоря вашими словами, эти принципы не решают автоматически проблемы проектирования.
UFO just landed and posted this here
Ваша подозрительность не является аргументом.
Отсутствие этих слов в статье не приравнивает статью автоматически к разряду плохих.
Классические паттерны упоминались, но не назывались поименно.
Хорошая статья о паттернах, действительно, хорошая. Вот только появилась она буквально вчера.
У моей статьи будет продолжение. Но я не предполагаю переносить все или часть классиеских паттернов в мир, где они по большей части не нужны, и к тому же, это уже обсуждалось.
Отсутствие этих слов в статье не приравнивает статью автоматически к разряду плохих.
Классические паттерны упоминались, но не назывались поименно.
Хорошая статья о паттернах, действительно, хорошая. Вот только появилась она буквально вчера.
У моей статьи будет продолжение. Но я не предполагаю переносить все или часть классиеских паттернов в мир, где они по большей части не нужны, и к тому же, это уже обсуждалось.
Если бы вы сделали что-то подобное на Haskell, то я бы был первым кто плюсанул вам в карму.
Есть старая, но хорошая и краткая статья:
blog.ezyang.com/2010/05/design-patterns-in-haskel/
UFO just landed and posted this here
Я, кажется, понял, откуда у вас такое желание натянуть ООП на Хаскель и другие ФЯ. Ваш опыт родом из Erlang, который сформировал у вас неверное представление об ФП, и вы пытаетесь всё подогнать под это представление. Это неверный подход. ФП имеет с ООП мало общего, и не важно, что в Erlang эти понятия имеют свою реализацию. Вот, например, Scala: и функциональный язык, и ООП-язык; Haskell — чистый функциональный язык; но что Erlang? Ответ вы найдете в статье, которую я нахожу очень точной и правдивой.
На счёт Синглтонов — в Хаскеле это совершенно другое.
Из той ссылки, что вы дали:
Это типы с единственным значением, а не единственный экземпляр типа.
Согласен, несколько наивная статья, что я дал.
Из той ссылки, что вы дали:
Singleton types are a technique for “faking” dependent types in non-dependent languages, such as Haskell. ... A singleton type is a type with exactly one value. Это типы с единственным значением, а не единственный экземпляр типа.
Согласен, несколько наивная статья, что я дал.
UFO just landed and posted this here
Я думаю паттерны тем и хороши, что они не привязаны к языку.
Думаю, правильнее сказать, разные паттерны разной силой привязаны к парадигмам программирования.
Тот же MCV никак не связан с языками и даже парадигмами.
Если мы говорим о Синглтоне, то этот паттерн имеет место в языках с общим пространством данных, где мы хотим получить единственное значение переменной.
Применяя это на Хаскель: возможность иметь Одиночку возможна лишь в монадах состояний
State, таких как IO, ST, IORef, STRef. Вне контекста состояний, ни одна функция не делит «общее пространство данных», а значит, шаблон Одиночка бессмысленен вне состояний в Хаскеле. Сорри, промахнулся уровнем.
Ответил вам чуьть ниже (промахнулся).
Будьте добры, по обмену опытом.
1. Какую конкретно реализацию FRP используете и как она в деле?
2. Я хочу простенький сервер для мультиплейер. Насколько трудоемко набросать на Haskell набело, вместо допиливания warp? Скажем несложный UDP сервер? Ну да, я читал в RWH, но то в книжке. А в деле?
3. Известна доктрина максимально разносить, еще на стадии дизайна, чистую и побочно-эффективную компоненты с целью изжить последнюю. Ваше мнение? Например Michael Snoyman, на мой взгляд, такой подход не разделяет. Yesod просто весь соткан из монад и трансформеров.
4. Persistent? STM это хорошо, но недостаточно. Вы бы рекомендовали природный Acid-State, или кондуктор к чему нибудь более SQL классичному?
Спасибо.
1. Какую конкретно реализацию FRP используете и как она в деле?
2. Я хочу простенький сервер для мультиплейер. Насколько трудоемко набросать на Haskell набело, вместо допиливания warp? Скажем несложный UDP сервер? Ну да, я читал в RWH, но то в книжке. А в деле?
3. Известна доктрина максимально разносить, еще на стадии дизайна, чистую и побочно-эффективную компоненты с целью изжить последнюю. Ваше мнение? Например Michael Snoyman, на мой взгляд, такой подход не разделяет. Yesod просто весь соткан из монад и трансформеров.
4. Persistent? STM это хорошо, но недостаточно. Вы бы рекомендовали природный Acid-State, или кондуктор к чему нибудь более SQL классичному?
Спасибо.
1. Использую Netwire в качестве FRP- основы нечистой части программы. Мне нравятся два аргумента в пользу этой библиотеки: стрелочный интерфейс как вариант, и нацеленность на игры. Из-за последнего, например, там есть работа с таймером. В простых примерах библиотека ведет себя хорошо, пользоваться удобно. Правда, другие я не испытывал, только читал о них.
2. Точно не скажу. Если простенький, без претензий на красивости, то, думаю, пару дней, — при условии, что вы знаете, как работают UDP серверы. У меня ушло бы неделя или около того, но посылающий и принимающий сообщения сервер на коленке можно сделать быстро. Я как-то делал сервер визуализации Хаскелля, там ничего сверъестественного не было в сетевом коде… Разве что я использовал MVar для разделяемого доступа.
3. И да, и нет. Если совсем не разделять, будет обычный императивный код. Но если воспользоваться тем же ФРП, то это будет очень даже хороший код.
4. Шут его знает… Действительно, синхронизироваться с персистентным хранилищем надо, иначе можно многое потерять при сбое. Я бы выбрал что-нибудь нереляционное, no-sql-ное, но в этом я не спец вообще. Видится, что для игры SQL неудобен. Думаю, надо читать лучшие практики и писать прототип.
2. Точно не скажу. Если простенький, без претензий на красивости, то, думаю, пару дней, — при условии, что вы знаете, как работают UDP серверы. У меня ушло бы неделя или около того, но посылающий и принимающий сообщения сервер на коленке можно сделать быстро. Я как-то делал сервер визуализации Хаскелля, там ничего сверъестественного не было в сетевом коде… Разве что я использовал MVar для разделяемого доступа.
3. И да, и нет. Если совсем не разделять, будет обычный императивный код. Но если воспользоваться тем же ФРП, то это будет очень даже хороший код.
4. Шут его знает… Действительно, синхронизироваться с персистентным хранилищем надо, иначе можно многое потерять при сбое. Я бы выбрал что-нибудь нереляционное, no-sql-ное, но в этом я не спец вообще. Видится, что для игры SQL неудобен. Думаю, надо читать лучшие практики и писать прототип.
Плюс к 3-му пункту. Монады не являются с необходимостью побочными эффектами. Это механизм абстракции, которым можно обрабатывать и побочные эффекты тоже. Например, монады Maybe и Either не являются «монадами для побочных эффектов». Но они являются структурами поведения со свойством обработки «пустых» данных (Nothing) и обработки данных с возможностью fail-сценария (Left). Монады != побочные эффекты. Побочные эффекты, в основном, сосредоточены в IO.
… но покамест мне не известно ни одной книги, аналогичной книге Банды Четырех
Знаю пару книжек:
functional-programming-patterns-in-scala-and-clojure — GOF через скалу/clojure + функциональные паттерны.
clojure-for-domain-specific-languages DSL на кложуре
Я пришел к похожим выводам на более низком уровне проектирования.
leventov.livejournal.com/14662.html
leventov.livejournal.com/14662.html
UFO just landed and posted this here
Sign up to leave a comment.
Дизайн и архитектура в ФП. Введение и Часть 1