Здравствуйте, Sinclair, Вы писали:

S>Надо читать вменяемую литературу, типа Гарсиа-Молина et al. Там подробно разжёвывается, как работает оптимизатор, и из каких кусочков он собирает план исполнения запроса.
Петров-Водкин Гарсиа-Молина? Есть совет попроще — сходить в гитхаб и посмотреть на исходники PostgreSQL. А потом задать полагающиеся вопросы джентельменам на форуме.

S>На самом деле, самая крутая RDBMS — это DB2. Потом идёт MS SQL, потом Оракл, потом Postgres, а уж потом, с большим-большим отрывом, все остальные.
Как это вы "крутость" так опередили? Почему это MS SQL опередил oracle, а PostgreSQL отстает от оракла, а на вершине всего этого DB2 UDB?

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, welltyped2, Вы писали:

W>>flatMap это только для списков. Если абстрагировать его на любой F[A] и добавить pure, то в итоге можно получить то что есть в scalaz

D>Прикольно, но опять возвращается вопрос: нафиг оно надо? Мне и flatMap-то раз в сто лет пригождается.
Оно нужено когда у вас для F[A] нужно использовать функцию А => F[B]
Если в сто лет нужен flatMap значит в сто лет у вас появляется функция вида A => List[B] применяемая к List[A]
Представте такую ситуация, есть три функции
getA:: Int => Option[A]
getB:: A => Option[B]
getC:: B => Option[C]
вам нужно получить C. Как вы запишите код с этими функциями?

Здравствуйте, dimgel, Вы писали:

D>>>И что с ними носятся как с писаной торбой?
F>>потому что всё есть монада
D>Звучит в духе этого, который "я есмь сущий", с которым тоже все носятся.

именно так оно и происходит

Здравствуйте, welltyped2, Вы писали:

W>Представте такую ситуация, есть три функции
W>getA:: Int => Option[A]
W>getB:: A => Option[B]
W>getC:: B => Option[C]
W>вам нужно получить C. Как вы запишите код с этими функциями?

в скале Option — тоже коллекция:

scala> class A; class B; class C
defined class A
defined class B
defined class C

scala> def getA(i: Int) = Some(new A)
getA: (i: Int)Some[A]

scala> def getB(a: A) = Some(new B)
getB: (a: A)Some[B]

scala> def getC(b: B) = Some(new C)
getC: (b: B)Some[C]

scala> def getA(i: Int): Option[A] = Some(new A)
getA: (i: Int)Option[A]

scala> def getB(a: A): Option[B] = Some(new B)
getB: (a: A)Option[B]

scala> def getC(b: B): Option[C] = Some(new C)
getC: (b: B)Option[C]

scala> getA(0).flatMap(a => getB(a).flatMap(b => getC(b)))
res0: Option[C] = Some(C@a87f680)

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, welltyped2, Вы писали:

W>>Представте такую ситуация, есть три функции
W>>getA:: Int => Option[A]
W>>getB:: A => Option[B]
W>>getC:: B => Option[C]
W>>вам нужно получить C. Как вы запишите код с этими функциями?

D>в скале Option — тоже коллекция:

D>

scala>> class A; class B; class C
D>defined class A
D>defined class B
D>defined class C

scala>> def getA(i: Int) = Some(new A)
D>getA: (i: Int)Some[A]

scala>> def getB(a: A) = Some(new B)
D>getB: (a: A)Some[B]

scala>> def getC(b: B) = Some(new C)
D>getC: (b: B)Some[C]

scala>> def getA(i: Int): Option[A] = Some(new A)
D>getA: (i: Int)Option[A]

scala>> def getB(a: A): Option[B] = Some(new B)
D>getB: (a: A)Option[B]

scala>> def getC(b: B): Option[C] = Some(new C)
D>getC: (b: B)Option[C]

scala>> getA(0).flatMap(a => getB(a).flatMap(b => getC(b)))
D>res0: Option[C] = Some(C@a87f680)
D>

Вот за этим и нужен flatMap. Представте теперь что все функции возвращают не Option а Future, ваш код получения C при этом не измненится.

Здравствуйте, Нахлобуч, Вы писали:

Н>Не совсем программирование, но все же. Не могу понять, в чем такая прелесть vi/emacs (если пользователи не врут).
Всё просто. Они работают, а другие ИДЕ посто жрут процессорное время.

Здравствуйте, welltyped2, Вы писали:

W>Представте теперь что все функции возвращают не Option а Future, ваш код получения C при этом не измненится.

Future — тоже хороший пример. А ещё какой-нибудь есть?

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, welltyped2, Вы писали:

W>>Представте теперь что все функции возвращают не Option а Future, ваш код получения C при этом не измненится.

D>Future — тоже хороший пример. А ещё какой-нибудь есть?
Например можно посмотреть какие монады есть в haskell. Логирование, побочные эффекты, парсеры и т.д.

Здравствуйте, dimgel, Вы писали:

D>Монады. Несколько раз подкатывал, без толку.

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

Практические фичи для пользователя

1) Тип-обёртка — позволяет изолировать данные, чтобы случайно что-нибудь неправильное не сделать. Самый яркий пример — IO. Внутри всё сводится к unsafePerformIO, но это секрет!

2) Унифицированный контейнер — работа с содержимым выполняется через map и filter (foreach и if, говоря императивно).
2а) Не надо специально отслеживать пустые контейнеры; не надо придумывать сигнальные значения — достаточно вернуть пустой или единичный контейнер
2б) Некоторые алгоритмы выглядят одинаково для разных контейнеров (foreach же!)

3) Специфичные функции (чтение-запись состояния, например) укладываются в этот же синтаксис
3а) Это позволяет писать код в разном сахаре — set comprehension (в хаскелле — только list comprehension, а в гофре и идрисе и внезапно питоне — для любых типов), do-нотация, конвееры
3б) А также легко сочетать монады, применяя трансформеры
лунапарк — исходная монада
лбс = сБлекджеком(соШлюхами(лунапарк))
блекджек(лбс) — доступ к специфике верхнего уровня
шлюхи(безБлекджека(лбс)) — доступ к специфике внутреннего уровня
аттракцион <- лбс
аттракцион <- безБлекджека(лбс)
аттракцион <- безШлюх(безБлекджека(лбс))
аттракцион <- лунапарк

А моноиды и эндофункторы — это теоретический базис и гарантия того, что 0*X = X*0 = 0, 1*X = X*1 = 1, X*Y*Z = X*Y*Z (скобки расставьте по вкусу)

Здравствуйте, dimgel, Вы писали:

D>Прикольно, но опять возвращается вопрос: нафиг оно надо? Мне и flatMap-то раз в сто лет пригождается.

А не надо мыслить в терминах flatMap. Надо в терминах for each.

for x in xs :
  for y in foo(x) :
    for z in bar(y) :
      # вот тебе, бабушка, и флэтмап!

Здравствуйте, Кодт, Вы писали:

К>Самый яркий пример — IO. Внутри всё сводится к unsafePerformIO, но это секрет!

т.е. я порчу себе карму и даже не знаю об этом?!

Здравствуйте, Kernan, Вы писали:

K>Всё просто. Они работают, а другие ИДЕ посто жрут процессорное время.

Я не представляю, как они там работают. Возможно, в этих ваших хипстерских Руби и Питонах вместо интеллисенса канает банальное автодополнение с выбором из списка всех идентификаторов в файле/проекте и скорость работы находится в прямой зависимости от умения виртуозно перемещать строки и писать макросы, но как-то меня гложут сомнения в том, что IDE может сколь-нибудь заметно влиять на скорость набора текста.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, welltyped2, Вы писали:

W>>Представте теперь что все функции возвращают не Option а Future, ваш код получения C при этом не измненится.

D>Future — тоже хороший пример. А ещё какой-нибудь есть?

Option\Maybe
Lazy
Exception
List
Parser

Здравствуйте, dimgel, Вы писали:

D>Прикольно, но опять возвращается вопрос: нафиг оно надо? Мне и flatMap-то раз в сто лет пригождается.

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

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

Вот задачи:
есть два числа который надо сложить
решение
c = a + b.

есть три числа, два есть сейчас и одно принесет резиновая Зина, их надо сложить
решение
d = a + b + c.

есть четыре числа, два есть сейчас, одно принесет резиновая Зина, одно может через год, а может быть, через два, может быть подскажет тётя Зина из магазина, их надо сложить
решение
r = a + b + c + d

есть пять чисел, два есть сейчас, одно принесет резиновая Зина, одно может через год, а может быть, через два, может быть подскажет тётя Зина из магазина, одно это сумма потерь какой нибудь разини, их надо сложить
решение
r = a + b + c + d

Если добавить типы, то окажется ,что в первом случае числа просто инты, во втором добавляется M<int>, в третьем M1<int>, в четвертом M2<int>

В с++ ты вспотеешь описывать классы и перегрузку операторов для всех возможных комбинаций типов. Если в лоб, то в императивной реализации надо будет понавыдумать целый вагон способов диспетчерзации для случаев " может через год, а может быть, через два, может быть".

Для чего ?
Для того, что бы по прежнему сложить два числа.

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

Итого: "Monad — just works"

Т.е. экземпляр монадического типа это не само значение, а способ его получения.

Здравствуйте, neFormal, Вы писали:

К>>Самый яркий пример — IO. Внутри всё сводится к unsafePerformIO, но это секрет!
F>т.е. я порчу себе карму и даже не знаю об этом?!

Ты не портишь себе карму, потому что операции ввода-вывода совершаются в должное время в должном месте в должном порядке.
За должный порядок отвечает реализация монады IO, не позволяющая компилятору ни пропускать, ни дублировать, ни перетасовывать операции.

Здравствуйте, Кодт, Вы писали:

D>>Монады. Несколько раз подкатывал, без толку.
К>А что там понимать... Абстрактная алгебра и немножко теоркат. (Тот самый моноид в эндофункторах).

Я вот тоже пытался их понять, читал разные статьи, но все равно не понимаю. С практической, низкоуровневой такой точки зрения... (что уж поделаешь, я начинал с Си и Ассемблера, и мышление заточено именно на то — а как оно в процессоре-то будет выполняться?)

Если говорить об ФП, то я понимаю что такое функция высшего порядка, это легко. Зачем нужно функцию передавать в другую функцию. Что такое частичное применение функций. Как работают замыкания. Как функция может возвратить другую функцию. Это простые концепции, с ними все ок, причем достаточно ясно как оно реализуется на низком уровне.

А монада — что она такое? (я даже не могу идентифицировать, это структура данных, управляющий оператор или что-то еще?)
Вот есть допустим язык Си (специально не С++). Мы можем (пусть даже слегка изменив синтаксис языка) внедрить туда монады, что это будет и какая от них будет польза?

СТО

Здравствуйте, Sinclair, Вы писали:

S>На самом деле, самая крутая RDBMS — это DB2.

В этом её беда. Она прощает столько тупости и с успехом нивелирует самые кривые руки. Но в конце концов безнаказанная тупость и бесконечная кривизна берут своё.

Здравствуйте, welltyped2, Вы писали:

D>>Future — тоже хороший пример. А ещё какой-нибудь есть?
W>Например можно посмотреть какие монады есть в haskell. Логирование, побочные эффекты, парсеры и т.д.

Спасибо, вот теперь понял, зачем оно.

Здравствуйте, Кодт, Вы писали:

К>>>Самый яркий пример — IO. Внутри всё сводится к unsafePerformIO, но это секрет!
F>>т.е. я порчу себе карму и даже не знаю об этом?!
К>Ты не портишь себе карму, потому что операции ввода-вывода совершаются в должное время в должном месте в должном порядке.

Т.е. это все же safePerformIO, а не unsafe.