Здравствуйте, <Аноним>, Вы писали:
А>Игрался неделю со scala, до этого читал статьи всяких проповедников ФП(один договорился до того что патnерны проектирования уже не нужны поскольку ФП самая замечательная вещь на свете). В результате пребываю в довольно странном состоянии — "И ЭТО ВСЕ? И ЧЕМ ЭТО ОТЛИЧАЕТСЯ ОТ ИП?".
Как-то однажды знаменитый учитель Кх Ан вышел на прогулку со учеником Антоном. Надеясь разговорить учителя, Антон спросил: "Учитель, слыхал я, что объекты — очень хорошая штука — правда ли это?" Кх Ан посмотрел на ученика с жалостью в глазах и ответил: "Глупый ученик! Объекты — всего лишь замыкания для бедных."
Пристыженный Антон простился с учителем и вернулся в свою комнату, горя желанием как можно скорее изучить замыкания. Он внимательно прочитал все статьи из серии "Lambda: The Ultimate", и родственные им статьи, и написал небольшой интерпретатор Scheme с объектно-ориентированной системой, основанной на замыканиях. Он многому научился, и с нетерпением ждал случая сообщить учителю о своих успехах.
Во время следующей прогулки с Кх Аном, Антон, пытаясь произвести хорошее впечатление, сказал: "Учитель, я прилежно изучил этот вопрос, и понимаю теперь, что объекты — воистину замыкания для бедных." Кх Ан в ответ ударил Антона палкой и воскликнул: "Когда же ты чему-то научишься? Замыкания — это объекты для бедных!" В эту секунду Антон обрел просветление.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
Дальше про Веб (который 2.0, ага )
У меня есть так называемый TabPanel. То есть это табы, которые открывают ту или иную панельку. Откпывается панелька, в ней записывается слово "Loading..." и выполняется AJAX запрос к серверу. Когда ответ с сервера приходит, вызывается callback функция,которая что-то там записывает в эту самую панельку.
Ключевое слова в AJAX — асинхронный. То есть, когда вызовется callback, эта панелька уже может не быть активной. Как же узнать, куда что писать?
/****************************************************
* callback функция выглядит так: *
* function callback(response) { *
* response - это пришедший с сервера ответ *
* } *
****************************************************/function createCallback(panel)
{
return function(response)
{
panel.innerHTML(response); // записываем ответ, пришедший с сервера
}
}
function createPanel(condition)
{
panel = new TabPanel //... и т.д. и т.п. создаем панель
$.ajax(
'/get/data', // запрос куда
{cond: condition}, // параметры
createCallback(panel) // callback
)
}
Таким образом callback будет всегда сам знать, в какую панель что писать. closures рулят Если честно, я же не представляю, как такое же сделать чисто ОО подходом.
Здравствуйте, konsoletyper, Вы писали:
K>Кто это такое говорил? Чтобы обойтись без паттернов проектирования, они либо должны быть зашиты в сам язык, либо язык должен иметь средства расширения, чтобы можно было реализовать паттерны в виде макробиблиотеки. Что касается первого, то тут есть маленький нюанс: многие современные ФЯ поддерживают паттерн-матчинг, который позволяет выкинуть паттерн посетитель. Остальные же паттерны приходится по-прежнему реализовывать ручками.
Мда.. Паттерн — это типичное решение типичной проблемы (в типичном языке ;-)).
Нет проблемы — нет необходимости в решении.
В ФП свои проблемы и свои паттерны. В языках без поддержки императивности — CPS/монады, без глобальных переменных — мемоизация, в ленивых — форсирование, с иммутабельными данными — Окасаки :-) куча паттернов для работы с функциями и т.д.
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, lomeo, Вы писали:
L>Мда.. Паттерн — это типичное решение типичной проблемы (в типичном языке ). L>Нет проблемы — нет необходимости в решении.
Нет проблем только у тех кто ничего не делает. Паттерны есть в любом языке. Это просто общие решения общих проблем. Все в язык не впихнешь. Так что Косолетайпер верно говорит, без макросредств паттерны один фиг нужны. Ну, есть правда один путь. Писать настолько тупо и не о чем не думать. Правда даже не очень большие программки будут рассыпаться, но зато будет чем гордиться.
L>В ФП свои проблемы и свои паттерны.
Чем это противоречит словам Косолетайпера?
L> В языках без поддержки императивности
А что такие есть в природе?
L> — CPS/монады,
А что монады уже не императивны?
L> без глобальных переменных — мемоизация, в ленивых — форсирование, с иммутабельными данными — Окасаки куча паттернов для работы с функциями и т.д.
Ага. Причем иногда так приходится извращаться, чтобы сэмулировать примитивен действия, что паттерны ООП, которые работают в основном на уровне проектирования, просто кажутся огромными абстракциями.
ЗЫ
Кстати, хочется задать один провакационный вопрос. Вот паттерны проектирвоания в ООП появились для облегчения проектирвоания больших и комплексных приложений. А что в этом плане придумано в ФП? Я вот сколько не гляжу, а все фишки ФП так или иначе крутятся вокруг микро-уровня. Собственно никто не спорит, что паттерн-матчинг вещь отличная, и красивая работа с фукнциями и замыканиями тоже очень удобно, но это все дает эффект только на довольно низктом (микро) уровне. А как насчет уровня приложения (и большого)?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>К сожалению, крупные примеры в функциональном стиле будут вряд ли интересны читателю, поэтому и ограничиваются примерами типа =take k . quicksort=.
А можно с этого места по подробнее. Мне почему-то все больше и больше кажется, что дело тут не в неинтересности "читателю", а в банальном отсуствии чего показать.
Стается мне, что эта отмазка (которую я слушу постоянно) такое же мошейничество как присловутый quicksort который может и красив, но никак не хочет работать с той же скоростью (даже близко), что императивный.
Другими словами — ФП отлично на микроуровне, когда нужно написать некий алгоритм, но вот средств композиции вепрхнего уровне у него нет. Модули не канают по сравненению с классами. Отсюда и появление такого количества гибридов ОО/Ф-языков.
LCR>Да, это закономерное впечатление. Более того сам Мартин утверждает, что в Скале лучше всего делать высокоуровневые объекты в соответствии с декомпозицией на объекты и обобщая классы до трейтов и миксинов, а их реализацию делать преимущественно в функциональном стиле. Примерно так и написан сам компилятор и стандартная библиотека — можешь глянуть исходники.
И что характерно — он не одинк. Эту точку зрения разделяет все больше и больше народу. Немерловцы тоже именно по такому пути проектировали свой компилятор. Интеграция тоже имеет такой же дизайн. Похоже это и есть сочетание лучших качеств двух миров.
LCR>Очень скользкая фраза... По причине выше, скорее всего на Скале будет мало чистых функциональных программ и всё ФП там представляет собой просто "сахарницу" средних размеров.
А кому нужны чистые фунциональные? Людям нужно писать программы проще, быстрее и удобнее.
LCR>В ФП паттерны часто являются просто ФВП. Ну вот fold — чем не паттерн? Или map-reduce? Или класс типов Monad?
Да, ничем не паттерны. Это библиотечные функции. Паттерн все же подразумевает не что больеше чем просто вызов фунции.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Я отвечк просто и коротко. ФП не панацея, но есть ряд задач (многие из которых встречаются постоянно во всех программах) в которых ФП (точнее его подходы и фишки в поддерживающих его языках) позволяет получить значительно более краткий и понятный код.
Объяснять это тому кто не освоил этот подход совершенно бесполезно. Почему? Тут как раз упоминали цитату главного проповедника Лиспа Пола Грэхема которую я приводил. Так вот она отлично объясняет этот феномен. Если интересно, ищи ее здесь
приведено два исходника идентичные с точки зрения решаемой задачи, но исходник написанный на языке поддерживающем ФП (аналог Скалы — язык Немерле) примерно в четверо короче и в 10 раз выразительнее. И это не маги, подтасовки или спецэффекты. Это просто грамотное применение того самого "сахара".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Курилка, Вы писали:
К>Просто суть в том, что функциональная композиция она выражает другую точку зрения на проблему, отличную от ООП, которая в GoF преподносится. Собственно об этом мамут уже написал
Скажи, а верующие в эту религию могут продемонстриовать отличия этого великого учения от проектировния с использованием структурной декомпозиции применявшейся в С и Паскале?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Косолетайпер верно говорит
Вообще-то, ник я придумывал не для того, чтобы его пытались зачитать вслух или перевести на русский. Может, специально для этих целей мне поменять ник на фамилию/имя?
PS: напоминает случай с Cyberax'ом
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
VD>А кому нужны чистые фунциональные? Людям нужно писать программы проще, быстрее и удобнее.
Ну как это кому? Я вот на Хаскеле обсчитываю задания по матстатистике. Там есть вещи, которые не под силу Excel. Люди говорят, что для этих целей лучше подходит J, а мне вот лень его изучать, тем более синтаксис у него жуткий.
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[2]: Так в чем же принципиальные отличия ФП от ИП?
приведено два исходника идентичные с точки зрения решаемой задачи, но исходник написанный на языке поддерживающем ФП (аналог Скалы — язык Немерле) примерно в четверо короче и в 10 раз выразительнее. И это не маги, подтасовки или спецэффекты. Это просто грамотное применение того самого "сахара".
Гхм... Ты на сахар-то эта, особо не налегай... Чему людей учишь? Али не наешь, что от сладкого зубы портятся?
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
L>>Мда.. Паттерн — это типичное решение типичной проблемы (в типичном языке ). L>>Нет проблемы — нет необходимости в решении.
VD>Нет проблем только у тех кто ничего не делает. Паттерны есть в любом языке. Это просто общие решения общих проблем. Все в язык не впихнешь. Так что Косолетайпер верно говорит, без макросредств паттерны один фиг нужны. Ну, есть правда один путь. Писать настолько тупо и не о чем не думать. Правда даже не очень большие программки будут рассыпаться, но зато будет чем гордиться.
Зачем ты мне это написал? Те паттерны, о которых, как я понял, шла речь, это не общие решения общих проблем. Это решения типичных проблем объектно-ориентированного проектирования.
L>>В ФП свои проблемы и свои паттерны.
VD>Чем это противоречит словам Косолетайпера?
А должно? Моя мысль была в том, что некоторые паттерны из GoF (о которых шла речь, "остальные кроме посетителя") просто не нужны в FP. В FP свои задачи и свои решения.
L>> В языках без поддержки императивности
VD>А что такие есть в природе?
Есть.
L>> — CPS/монады,
VD>А что монады уже не императивны?
Нет.
L>> без глобальных переменных — мемоизация, в ленивых — форсирование, с иммутабельными данными — Окасаки куча паттернов для работы с функциями и т.д.
VD>Ага. Причем иногда так приходится извращаться, чтобы сэмулировать примитивен действия, что паттерны ООП, которые работают в основном на уровне проектирования, просто кажутся огромными абстракциями.
Бывает. А бывает и наоборот
VD>ЗЫ
VD>Кстати, хочет задать один провакационный вопрос. Вот паттерны проектирвоания в ООП появились для облегчения проектирвоания больших и комплексных приложений. А что в этом плане придумано в ФП? Я вот сколько не гляжу, а все фишки ФП так или иначе крутятся вокруг макро-уровня. Собственно никто не спорит, что паттерн-матчинг ведь отличная, и красивая работа с фукнциями и замыканиями тоже очень удобно, но это все дает эффект только на довольно низктом (макро) уровне. А как насчет уровня приложения (и большого)?
На провакационные вопросы отвечать не хочется Интересно — посмотри для начала Why FP matters Хьюза. Дальше — катаморфизм, полиморфизм, генерики. Это то, что работает на уменьшение сложности программы. Есть паттерны и для композиции, low coupling и high cohension, но они обычно языко-зависимые, как например, умные конструкторы.
Кстати, насчёт терминов, я всегда думал, что макро-уровень — это когда ворочаешь большими блоками, а микро — когда работешь пинцетом под микроскопом.
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
LCR>>В ФП паттерны часто являются просто ФВП. Ну вот fold — чем не паттерн? Или map-reduce? Или класс типов Monad?
VD>Да, ничем не паттерны. Это библиотечные функции. Паттерн все же подразумевает не что больеше чем просто вызов фунции.
Это не библиотечные функции.
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
VladD2,
LCR>>К сожалению, крупные примеры в функциональном стиле будут вряд ли интересны читателю, поэтому и ограничиваются примерами типа =take k . quicksort=.
VD>А можно с этого места по подробнее. Мне почему-то все больше и больше кажется, что дело тут не в неинтересности "читателю", а в банальном отсуствии чего показать.
Ну например известный бенчмарк chameneos
public class chameneos {
private MeetingPlace mp;
public static final Colour[] COLOURS = { Colour.BLUE, Colour.RED, Colour.YELLOW, Colour.BLUE };
private Creature[] creatures = new Creature[COLOURS.length];
public enum Colour {
RED, BLUE, YELLOW, FADED
}
public class Creature extends Thread {
private MeetingPlace mp;
private Colour colour;
private int met = 0;
private Colour other;
public Creature(Colour c, MeetingPlace mp) {
this.colour = c;
this.mp = mp;
}
public void run() {
try {
while (colour != Colour.FADED) {
mp.meet(this);
if (other == Colour.FADED)
colour = Colour.FADED;
else {
met++;
colour = complement(other);
}
}
} catch (InterruptedException e) {
// Let the thread exit.
}
}
private Colour complement(Colour other) {
if (colour == other)
return colour;
switch (colour) {
case BLUE:
return other == Colour.RED ? Colour.YELLOW : Colour.RED;
case RED:
return other == Colour.BLUE ? Colour.YELLOW : Colour.BLUE;
case YELLOW:
return other == Colour.BLUE ? Colour.RED : Colour.BLUE;
default:
return colour;
}
}
public int getCreaturesMet() {
return met;
}
public Colour getColour() {
return colour;
}
public void setOther(Colour other) throws InterruptedException {
this.other = other;
}
}
public class MeetingPlace {
int n;
public MeetingPlace(int n) {
this.n = n;
}
Creature other = null;
public void meet(Creature c) throws InterruptedException {
synchronized (this) {
if (n > 0) {
if (other == null) {
other = c;
this.wait();
} else {
other.setOther(c.getColour());
c.setOther(other.getColour());
other = null;
n--;
this.notify();
}
} else {
c.setOther(Colour.FADED);
}
}
}
}
public chameneos(int n) throws InterruptedException {
int meetings = 0;
mp = new MeetingPlace(n);
for (int i = 0; i < COLOURS.length; i++) {
creatures[i] = new Creature(COLOURS[i], mp);
creatures[i].start();
}
// wait for all threads to completefor (int i = 0; i < COLOURS.length; i++)
creatures[i].join();
// sum all the meetingsfor (int i = 0; i < COLOURS.length; i++) {
meetings += creatures[i].getCreaturesMet();
}
System.out.println(meetings);
}
public static void main(String[] args) throws Exception {
if (args.length < 1)
throw new IllegalArgumentException();
new chameneos(Integer.parseInt(args[0]));
}
}
{- Written by Tom Pledger, 13 Nov 2006. modified by Don Stewart -}import Control.Concurrent
import Control.Monad
import System
data Colour = Blue | Red | Yellow
complement a b = case (a,b) of
(Red,Yellow) -> Blue
(Red,Blue) -> Yellow
(Red,Red) -> Red
(Yellow,Blue) -> Red
(Yellow,Red) -> Blue
(Yellow,Yellow) -> Yellow
(Blue,Red) -> Yellow
(Blue,Yellow) -> Red
(Blue,Blue) -> Blue
colors = [Blue, Red, Yellow]
data MP = MP !Int !(Maybe Colour) ![Int]
main = do n <- getArgs >>= readIO . head
waker <- newEmptyMVar
mpv <- newMVar $ MP n Nothing []
let arrive c t = do
MP q w d <- takeMVar mpv
case w of
_ | q == 0 -> if length d /= 3 then putMVar mpv $ MP 0 w (t:d)
else print $ t + sum d
Nothing -> do putMVar mpv $ MP q (Just c) d
c' <- takeMVar waker
arrive c' $! t+1
Just k -> do let c' = complement k c
putMVar waker $! c'
putMVar mpv $ MP (q-1) Nothing d
arrive c' $! t+1
mapM_ (forkIO . flip arrive 0) colors
arrive Blue 0
replicateM_ 3 yield
Если бы не погоня за скоростью, то код на Хаскеле был бы ещё короче и чище.
VD>Стается мне, что эта отмазка (которую я слушу постоянно) такое же мошейничество как присловутый quicksort который может и красив, но никак не хочет работать с той же скоростью (даже близко), что императивный.
В Хаскелл-комьюнити распространено выражение "sufficiently smart compiler", который принципиально может делать очень сильные оптимизации (и эти оптимизации описаны в научных работах и о них знают много людей), но пока практически такого компилятора нет. Поэтому на самом низком уровне (для выжимания битов из байтов) не вижу ничего криминального в том, чтобы для достижения необходимого перфоманса сделать "грязные дела".
VD>Другими словами — ФП отлично на макроуровне, когда нужно написать некий алгоритм, но вот средств композиции вепрхнего уровне у него нет. Модули не канают по сравненению с классами.
И в каком же аспекте они не канают? Статическая проверяемость? Сокрытие реализации? Разграничение области видимости? Приведи пример, плиз.
VD>Да, ничем не паттерны. Это библиотечные функции. Паттерн все же подразумевает не что больеше чем просто вызов фунции.
Этот баззворд фактически является синонимом термина "coding discipline", если абстракцию невозможно оформить в библиотеку. Что скорее говорит о слабости языка, а не о величии термина "паттерн".
приведено два исходника идентичные с точки зрения решаемой задачи, но исходник написанный на языке поддерживающем ФП (аналог Скалы — язык Немерле) примерно в четверо короче и в 10 раз выразительнее. И это не маги, подтасовки или спецэффекты. Это просто грамотное применение того самого "сахара".
G>Гхм... Ты на сахар-то эта, особо не налегай... Чему людей учишь? Али не наешь, что от сладкого зубы портятся?
Ну, можно было это назвать солью языка, но ведь от соли тоже разные органы страдают.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, konsoletyper, Вы писали:
K>Ну как это кому? Я вот на Хаскеле обсчитываю задания по матстатистике. Там есть вещи, которые не под силу Excel. Люди говорят, что для этих целей лучше подходит J, а мне вот лень его изучать, тем более синтаксис у него жуткий.
Синтаксис как раз не жуткий. А вот лексемы в нем .. непривычные это да.
Поченму-то мне кажется что основные понятия в J можно выучить в течении дня-двух. А вот научиться эффективно им пользоваться это займет некоторое время.
Лично я считаю J чем-то сродни математическому ассемблеру. Очень узкоспециализированный. Хотя теоретически на нем можно написать все что угодно.
... << RSDN@Home 1.2.0 alpha rev. 676>>
Re[4]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Ну например известный бенчмарк chameneos
... LCR>Если бы не погоня за скоростью, то код на Хаскеле был бы ещё короче и чище.
Демонстрации средств проектирования снова нет. Снова использование синтаксического сахара позволяющего уменьшить объем реализации. Другими словами, снова демонстрация приемуществ на микроуровне при полном игнорировании макроуровня.
Что и требовалось доказать! ФП просто не имеет средств абстрагирвоания уровня большого проекта. В нем есть исключительно средства оптимизации уровня отдельных алгоритмов.
Вот, собственно, по этому и имеет смысл использовать гибридные языки позвляющие использовать ООП для проектирования "в большом" и ФП для согращения кодирования и создания более понятного кода.
LCR>В Хаскелл-комьюнити распространено выражение "sufficiently smart compiler", который принципиально может делать очень сильные оптимизации (и эти оптимизации описаны в научных работах и о них знают много людей), но пока практически такого компилятора нет.
Сочувствую.
LCR> Поэтому на самом низком уровне (для выжимания битов из байтов) не вижу ничего криминального в том, чтобы для достижения необходимого перфоманса сделать "грязные дела".
Если устранить булшит про "умные компиляторя", то с радостью соглашусь. Вот только у меня выод другой выходит. Без императивного подхода нельзя точно уравлять ходом вычислений. По этому они блыи, есть и будут необходимой составляющей.
VD>>Другими словами — ФП отлично на микроуровне, когда нужно написать некий алгоритм, но вот средств композиции вепрхнего уровне у него нет. Модули не канают по сравненению с классами.
LCR>И в каком же аспекте они не канают?
В грануляности. Нет экземлпяров. Спроектировать большую систему в терминах модулей просто невозможно. В терминах функций можно, но очень сложно.
VD>>Да, ничем не паттерны. Это библиотечные функции. Паттерн все же подразумевает не что больеше чем просто вызов фунции.
LCR>Этот баззворд фактически является синонимом термина "coding discipline", если абстракцию невозможно оформить в библиотеку. Что скорее говорит о слабости языка, а не о величии термина "паттерн".
Треп это пустопорожний. Нет в природе языков включающих все и вся. И нельзя паттерны впихнуть в функции или классы. ФП тут вообще ничего не решает. Единственное универсальное средство превращения паттернов в декларативные конструкции — это макросы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, lomeo, Вы писали:
L>Зачем ты мне это написал?
За тем что надоелу слушать ничем не подкдепленную пропаганду.
L> Те паттерны, о которых, как я понял, шла речь, это не общие решения общих проблем. Это решения типичных проблем объектно-ориентированного проектирования.
Паттерны есть в любых языках в независимости от применяемой парадигмы.
L>А должно?
А зачем тогда было ему возражать?
L> Моя мысль была в том, что некоторые паттерны из GoF (о которых шла речь, "остальные кроме посетителя") просто не нужны в FP. В FP свои задачи и свои решения.
В ФП есть свои паттерны. А то что в нем "некоторые паттерны из GoF просто не нужны" — это следствие того, что в ФП просто не продуман вопрос проектирования крупных систем. В качетсве средств проектирования используются дедовские сдерства структурной декомпозиции, а подается все это с понтом новеших технологий.
L>>> В языках без поддержки императивности
VD>>А что такие есть в природе?
L>Есть.
Да, ну? Ну, как привиди пример хоть одного.
L>>> — CPS/монады,
VD>>А что монады уже не императивны?
L>Нет.
Во как? А темнеменее состояния держат и императивно программировать позволяют. Только раком.
VD>>Кстати, хочет задать один провакационный вопрос. Вот паттерны проектирвоания в ООП появились для облегчения проектирвоания больших и комплексных приложений. А что в этом плане придумано в ФП? Я вот сколько не гляжу, а все фишки ФП так или иначе крутятся вокруг макро-уровня. Собственно никто не спорит, что паттерн-матчинг ведь отличная, и красивая работа с фукнциями и замыканиями тоже очень удобно, но это все дает эффект только на довольно низктом (макро) уровне. А как насчет уровня приложения (и большого)?
L>На провакационные вопросы отвечать не хочется
Это потому что честный ответ банально тебя не устроит.
L> Интересно — посмотри для начала Why FP matters Хьюза.
Не интересно. Интересно получить прямой ответ, на прямо поставленный вопрос.
L> Дальше — катаморфизм, полиморфизм, генерики. Это то, что работает на уменьшение сложности программы.
Да, да. По больше базвородов. Это помогает уйти от ответа.
L>Есть паттерны и для композиции, low coupling и high cohension, но они обычно языко-зависимые, как например, умные конструкторы.
О, значит на счет наличия паттернов мы все же договорились. Уже сдвиг. Жаль, правда, что нет средств проектирвоать сложные системы.
L>Кстати, насчёт терминов, я всегда думал, что макро-уровень — это когда ворочаешь большими блоками, а микро — когда работешь пинцетом под микроскопом.
Я оговорился. Имелось в виду микро-уровенть, конечно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
L>>Зачем ты мне это написал?
VD>За тем что надоелу слушать ничем не подкдепленную пропаганду.
Я тут при чём?
L>> Те паттерны, о которых, как я понял, шла речь, это не общие решения общих проблем. Это решения типичных проблем объектно-ориентированного проектирования.
VD>Паттерны есть в любых языках в независимости от применяемой парадигмы.
Ежу ясно. Речь о GoF.
L>>А должно?
VD>А зачем тогда было ему возражать?
Я возражал не этому. Так что не в кассу.
L>> Моя мысль была в том, что некоторые паттерны из GoF (о которых шла речь, "остальные кроме посетителя") просто не нужны в FP. В FP свои задачи и свои решения.
VD>В ФП есть свои паттерны. А то что в нем "некоторые паттерны из GoF просто не нужны" — это следствие того, что в ФП просто не продуман вопрос проектирования крупных систем. В качетсве средств проектирования используются дедовские сдерства структурной декомпозиции, а подается все это с понтом новеших технологий.
-1
VD>Да, ну? Ну, как привиди пример хоть одного.
Не хочу. Ты до слов пытаешься докопаться, а мысль, которую я пытался донести, тебя не интересует. Спор мы начинаем вести совсем о другом. Мне это надо?
VD>Во как? А темнеменее состояния держат и императивно программировать позволяют. Только раком.
Мало ли что что-то там позволяет. Насквозь императивное железо позволяет нам программировать функционально. Так что? Оно функционально?
L>>На провакационные вопросы отвечать не хочется :-)
VD>Это потому что честный ответ банально тебя не устроит. ;)
Не угадал. Подумай ещё раз.
VD>Не интересно. Интересно получить прямой ответ, на прямо поставленный вопрос. VD>Да, да. По больше базвородов. Это помогает уйти от ответа. :) VD>О, значит на счет наличия паттернов мы все же договорились. Уже сдвиг. :) Жаль, правда, что нет средств проектирвоать сложные системы.
Так. Ты что хочешь узнать? Средства проектирования в ФП аналогичные по мощи паттернам GoF?
Ещё раз — задачи, решаемые этими паттернами или решаются так же, или по другому или не решаются, потому что такие задачи не встают.
Твои слова "все фишки ФП так или иначе крутятся вокруг макро-уровня. Собственно никто не спорит, что паттерн-матчинг ведь отличная", показывают твоё восхищение ПМ. Так вот когда я говорю, что ПМ не особо важная вещь, и что восхищение им на рсдн слишком сильно, то я имею в виду его малую роль при написании программ. Постоянно приводимый пример разбора АСТ замечательно рисуется без ПМ. Достаточно создать библиотеку комбинаторов парсинга. Более того, ПМ пригоден действительно только на микро-уровне, потому как его использование подразумевает, что внутренние данные не скрыты, что для больших систем чревато. В модульные интерфейсы выносят комбинаторы, а не структуры.
Я не хотел переходить на личности, а всего лишь пытался подчеркнуть — может ты вообще не на то внимание обращаешь, поэтому тебе кажется, что ФП для микроуровня? Да, действительно, фичи ФП производят сильное впечатление на этом уровне, но это не значит, что на макро-уровне они недостаточно мощны.
Если хочешь, давай перейдём к конкретике. Скажи что нибудь из области императива "проблема-решение на верхнем уровне", я попытаюсь найти аналогию в мире ФП. Возможно, я ошибаюсь, возможно, есть такие вещи, которые не решаются/гораздо тяжелее решаются в ФП. Но пока я таких вещей не видел. С другой стороны, у меня небольшой опыт, а некоторые уважаемые (и опытные) люди, например, Gaperton, считают, что декомпозицию на верхнем уровне надо делать в объектах.
Перекуём баги на фичи!
)
).
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
