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

I>А монада — что она такое? (я даже не могу идентифицировать, это структура данных, управляющий оператор или что-то еще?)

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

I>Вот есть допустим язык Си (специально не С++). Мы можем (пусть даже слегка изменив синтаксис языка) внедрить туда монады, что это будет и какая от них будет польза?

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

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

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

S>>На самом деле, самая крутая RDBMS — это DB2. Потом идёт MS SQL, потом Оракл, потом Postgres, а уж потом, с большим-большим отрывом, все остальные.
__>Как это вы "крутость" так опередили? Почему это MS SQL опередил oracle, а PostgreSQL отстает от оракла, а на вершине всего этого DB2 UDB?
Это мой личный рейтинг.
DB2 — за значительный вклад в развитие реляционных СУБД и несомненные успехи. На tpc-c они были последними, кто выиграл перформанс "честным" образом, а не тупо наращивая стоимость системы.
MS SQL — за минимальные потребности в обслуживании, высокую стабильность, и хороший фичесет. Например, в отличие от Оракла, он умеет и версионную конкурентность, и блокировочную.
Postgres — просто самый достойный из бесплатных движков, но, простите, я не верю, что некоммерческое решение может догнать полноценное коммерческое.

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

S>Postgres — просто самый достойный из бесплатных движков, но, простите, я не верю, что некоммерческое решение может догнать полноценное коммерческое.
Он не просто догоняет, а перегоняет.

Во-первых, по уровню обслуживания он ещё проще MSSQL — тупо воткнуть пакет и оно работает, всякий тюнинг обычно только ухудшает ситуацию.

Во-вторых, по общему уровню фич он уже лучше Оракла (скажем, есть транзакционный DML) и не хуже MSSQL. В некоторых областях Postgres вообще лучше всех — в GIS, например.

В-третьих, он нифига не некоммерческий. На продаже PostgreSQL и его разработке живут множество компаний. Мы сейчас занимаемся продажей Infrastructure As A Service и один из наших клиентов занимается запуском кластеров PostgreSQL на нашей инфраструктуре — за это они получают весьма неплохие деньги. На эти деньги они дописывают нужные им фичи.

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

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

В истории я профан, тут конечно мнение историков более важно чем мое.

S>DB2 — за значительный вклад в развитие реляционных СУБД и несомненные успехи. На tpc-c они были последними, кто выиграл перформанс "честным" образом, а не тупо наращивая стоимость системы.
А как выиграть "честным образом"? Напр. в тестах по производительности или произв./цена первое место занимает Oracle.

S>MS SQL — за минимальные потребности в обслуживании, высокую стабильность, и хороший фичесет. Например, в отличие от Оракла, он умеет и версионную конкурентность, и блокировочную.
А oracle умеет организовать версионную конкурентность быстро в отличии.
И вообще SQL Server почти всегда выступает в роли догоняющего по фичам относительно oracle. Хотя качество доставки фич для developers как правило выше (за что сильно ценю mssql).

C>Он не просто догоняет, а перегоняет.
Я бы все-таки сказал что все-таки уровень производительности PostgreSQL на уровне SQL Server (возможно выше/чуть выше — мое сравнение показывает примерно равные результаты). К тому же он показывает ровные результаты по perf на разных ОС (в моем случае на Windows и OS X) в отличие от Oracle который красиво работает только на линуксах и солярке (и желательно под спарк ).

C>В некоторых областях Postgres вообще лучше всех — в GIS, например.
postGIS и pgRouting действительно делают PostgreSQL лидером этого сегмента. В oracle тоже есть некоторая поддержка spatial data, но на мой взгялд не такая гибкая как в postgre.

C>В-третьих, он нифига не некоммерческий. На продаже PostgreSQL и его разработке живут множество компаний.
Главная EnterpriseDB, которая продает extended tools & платный саппорт. Они же собирают каждый новый релиз. Т.е. это не просто полузабытая народная система, есть компании где люди профессионально развивают систему.

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

Н>Возможно, в этих ваших хипстерских Руби и Питонах вместо интеллисенса канает банальное автодополнение

по сути да. если нет синтаксического оверхеда™, то от ide можно отказаться в пользу чего-то легковесного.

Н>но как-то меня гложут сомнения в том, что IDE может сколь-нибудь заметно влиять на скорость набора текста.

ещё как влияет. например, java-код в ide набирается очень быстро за счёт хорошего автокомплита.
это достоинство ide и недостаток java.

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

I>>А монада — что она такое? (я даже не могу идентифицировать, это структура данных, управляющий оператор или что-то еще?)

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

I>>Вот есть допустим язык Си (специально не С++). Мы можем (пусть даже слегка изменив синтаксис языка) внедрить туда монады, что это будет и какая от них будет польза?

DM>Нужны хотя бы шаблоны, чтобы делать параметризованные типы. А чтобы в применении всего этого был толк, хорошо бы иметь средство абстрагирования еще одним уровнем выше, чтобы писать код "для любой переданной монады М сделать то-то", работающий с разными экземплярами монад. В терминах С++ — шаблон с параметром-шаблоном.

Да вот здесь например статья про монады и прочее. Можно понять как это работает.
Понять бы, зачем это нужно. Какие задачи они решают? Они полезны только для "чисто функциональных" языков или нет?
Помогут ли они чем-то программисту в "гибридном" языке программирования (т.е. в котором есть функциональное программирование, но при этом есть все императивные возможности)

Понимание "зачем" сразу проясняет очень многие "как".

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

G>Или не до конца понимаете в программировании? Для меня вот например Oracle это что-то типа пятого измерения В теории какбы понятно — деревья, логарифмические алгоритмы, интерпретаторы с перкомпиляцией, кэши разные. Но как оно все вместе так хитро собрано, и почему оно такое пц быстрое, и при этом устойчивое, и как работает его оптимизатор? Вообще не представляю.

Понимаю все, скорее не умею пользоваться. Сюда функциональное программирование (первым в голову всегда приходит императивное решение, которое потом в муках преобразуется в что-то функциональное). Сюда же чрезмерная шаблонная магия C++. Разобраться при желании можно, но уходит гораздо больше сил.

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

S>>DB2 — за значительный вклад в развитие реляционных СУБД и несомненные успехи. На tpc-c они были последними, кто выиграл перформанс "честным" образом, а не тупо наращивая стоимость системы.
__>А как выиграть "честным образом"? Напр. в тестах по производительности или произв./цена первое место занимает Oracle.
У DB2 офигенный оптимизатор над которым работали поколения академиков. Он реально крут.

Проблема в том, что продукты IBM никогда не отличались дешевизной.

__>И вообще SQL Server почти всегда выступает в роли догоняющего по фичам относительно oracle. Хотя качество доставки фич для developers как правило выше (за что сильно ценю mssql).
Это вряд ли. По фичам последний SQL Server и Oracle примерно одинаковы. Точнее, можно найти для большинства фич примерный аналог (не обязательно работающий так же).

И вообще, с SQL Server работать не в пример удобнее, чем с Oracle.

C>>Он не просто догоняет, а перегоняет.
__>Я бы все-таки сказал что все-таки уровень производительности PostgreSQL на уровне SQL Server (возможно выше/чуть выше — мое сравнение показывает примерно равные результаты). К тому же он показывает ровные результаты по perf на разных ОС (в моем случае на Windows и OS X) в отличие от Oracle который красиво работает только на линуксах и солярке (и желательно под спарк ).
Солярка и спарк — они уже давно слились...

Для Postgres вполне официально известно, что на Windows он работает заметно медленнее из-за особенностей ввода-вывода и расшареной памяти. Что для практических применений проблем не составляет — поставить любой бесплатный Линукс сейчас можно без всяких особых специальных знаний.

Насчёт скорости — у Postgres базовые запросы (типа взять строку таблицы по PK) выполняются быстрее, чем у Оракла. Причём очень заметно быстрее — у нас товарищи добиваются того, что опережают MongoDB по скорости работы с JSON'ом на слегка патченом (будет в следующей версии официально) Постргесе.

Со сложными запросами с кучей JOIN'ов всё сложнее — оптимизатор у Oracle никогда не славился особым умом и сообразительностью, так что Постгрес часто делает намного лучшие планы. С другой стороны, для Oracle можно в стратегические места поставить hint'ы и ускорить запросы, а с Postgres это существенно сложнее.

C>>В некоторых областях Postgres вообще лучше всех — в GIS, например.
__>postGIS и pgRouting действительно делают PostgreSQL лидером этого сегмента. В oracle тоже есть некоторая поддержка spatial data, но на мой взгялд не такая гибкая как в postgre.
У Оракла есть отдельный пакет для geospatial баз, за кучубабла. Впрочем, он тоже сосёт. У SQL Server есть некоторые зайчатки GIS и есть пакеты третьих фирм, но по полноценности до PostGIS они не дотягивают.

C>>В-третьих, он нифига не некоммерческий. На продаже PostgreSQL и его разработке живут множество компаний.
__>Главная EnterpriseDB, которая продает extended tools & платный саппорт. Они же собирают каждый новый релиз. Т.е. это не просто полузабытая народная система, есть компании где люди профессионально развивают систему.
Контрибьюторов существенно больше. Вот можно для последнего спринта посмотреть список: https://commitfest.postgresql.org/action/commitfest_view?id=20

PostgreSQL удалось повторить модель Линукса, когда многим компаниям выгодно развивать общий продукт, чем делать своё местечковое дерьмо.

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

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

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

А как "в процессоре будет выполняться", например, массив?

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

I>А монада — что она такое? (я даже не могу идентифицировать, это структура данных, управляющий оператор или что-то еще?)

Тут есть два слоя понимания.
Первый — если не вдаваться в реализацию полиморфных функций хаскелла. Монада, как и любой другой класс — это этикетка, наклеенная на тип. "С данными этого типа можно делать то и это".
В случае монады — можно делать return, >>= и т.п. и использовать do-нотацию; с самим типом тоже кое-что можно и нужно делать: у него есть параметр.
Т.е.

class Show x where
  show :: x -> String -- тип и тип, ничего особенного

class Monad x where
  return :: y -> (x y)                    -- опа! тип x параметризуется типом y
  fail :: String -> x a                   -- пустая монада имеет неизвестно какой параметр, это будет уточнено при выводе типов, по месту использования
  (>>=) :: (x a) -> (a -> (x b)) -> (x b) -- параметр превращается... превращается...

-- тип Either l r - если его каррировать, то полученный Either l вполне может быть монадой
-- но для разных l будут разные монады
instance Monad (Either String) where -- это классика
  return r = Right r
  fail s = Left s
  ....
-- этого в Control.Monad.Instances, вроде бы, нет, но можно дописать руками:
instance Monad (Either ()) where -- левым типом может быть только такой, для которого существуют "дефолтные" значения
  ....
  fail s = Left ()
  ....
instance (Monad m) => Monad (Either (m x)) where
  ....
  fail s = Left (fail s)
  ....

Второй слой — это реализация полиморфизма.
Функция, принимающая и/или возвращающая "неизвестно какую монаду", или "неизвестно какое число", или "неизвестно какое Show-совместимое значение", — имеет неявный параметр: словарь функций соответствующего класса. Это как таблица виртуальных функций, только в отрыве от значения. Таким образом, мы можем полностью абстрагироваться от того, какой тип выступил в роли монады, — до тех пор, пока не станем дёргать функции, специфичные для данного типа.

multiplyAll xs ys = do -- (Monad m,  Num a) => m a -> m a -> m a
  x <- xs
  y <- ys
  return x*y

multiplyAll' xs ys = [x*y | x<-xs, y<-ys] -- (Num a) => [a] -> [a] -> [a], потому что дёрнули list comprehension

multiplySome' xs ys = do -- [Int] -> [Int] -> [Int], потому что length
  x <- xs
  y <- ys
  return x*y*(length xs)

I>Вот есть допустим язык Си (специально не С++). Мы можем (пусть даже слегка изменив синтаксис языка) внедрить туда монады, что это будет и какая от них будет польза?

В сях от монад толку не будет — слишком далеко система типов сей от системы типов хаскелла. А руками её воспроизводить — мрачное дело. Это на порядок громоздче, чем ООП. (Ком-серверы на сях видел? Умножь страхолюдность на десять).

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

I>Понять бы, зачем это нужно. Какие задачи они решают? Они полезны только для "чисто функциональных" языков или нет?
I>Помогут ли они чем-то программисту в "гибридном" языке программирования (т.е. в котором есть функциональное программирование, но при этом есть все императивные возможности)

Скажем так: в чистых ФЯ (особенно ленивых) они очень-очень нужны, чтобы структурировать код и не превращать его в месиво. В том же Clean, где монад нет, их недостаток весьма остро ощущается, когда пытаешься что-то делать.

В гибридных языках обычно можно обойтись без них, как показывает практика окамла и скалы. Но когда они есть (и особенно когда в языке есть их синтаксическая поддержка в виде do или for нотации), они позволяют в том числе вводить новые управляющие конструкции, вроде async, исключений, продолжений и т.д. Можно не ждать, пока авторы языка додумаются их включить в язык, а делать библиотечно. Например, основанные на монадах зеленые потоки с кооперативной многозадачностью применялись в окамле для создания неблокирующихся веб-серверов за много лет до того, как появилась Node.js и все стали дро возбуждаться на эту тему.

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

C>У DB2 офигенный оптимизатор над которым работали поколения академиков. Он реально крут.
Чем же он офигенный ? Каждый производитель это твердит. "У нас офигенный оптимизатор!!!".

C>Проблема в том, что продукты IBM никогда не отличались дешевизной.
40к за we, от 80k до 250k за ese. цены вполне сравнимые с oracle.

>Это вряд ли. По фичам последний SQL Server и Oracle примерно одинаковы. Точнее, можно найти для большинства фич примерный аналог (не обязательно работающий так же).
Да куда уж там "вряд ли". Напр. MINUS/EXCEPT. Насколько я помню EXCEPT появился в 2к5, а MINUS был уж не помню с какой версии (в 8-ке кажется точно был). Опять же всякие гриды/кластеринг, которые появились у ms сильно позже. И где кстати MS IMDB совместимая c mssql? Ее нет а у oracle timesten.

C>И вообще, с SQL Server работать не в пример удобнее, чем с Oracle.
С этим невозможно не согласиться.

C>Солярка и спарк — они уже давно слились...
Да посмотрите вы тесты TPC-C. Они живее всех живых и чемпионы производительности.

C>Для Postgres вполне официально известно, что на Windows он работает заметно медленнее из-за особенностей ввода-вывода и расшареной памяти. Что для практических применений проблем не составляет — поставить любой бесплатный Линукс сейчас можно без всяких особых специальных знаний.
Это не проблема PG, а ОС-производительности. Последние версии (с 9.1) на win могут работать так же быстро как и на linux если win имеет больше памяти.

C>Со сложными запросами с кучей JOIN'ов всё сложнее — оптимизатор у Oracle никогда не славился особым умом и сообразительностью, так что Постгрес часто делает намного лучшие планы. С другой стороны, для Oracle можно в стратегические места поставить hint'ы и ускорить запросы, а с Postgres это существенно сложнее.
Я все-таки вижу главное преимущества Postgres здесь не в скорости by design (все равно oracle придет первым к финишу при "правильной конфигурации"), а в открытом исходном коде и возможности "ускоряться" под свои задачи с помощью собственных модификаций.

C>У Оракла есть отдельный пакет для geospatial баз, за кучубабла. Впрочем, он тоже сосёт. У SQL Server есть некоторые зайчатки GIS и есть пакеты третьих фирм, но по полноценности до PostGIS они не дотягивают.
Нет не сосет. Вы похоже просто не пользовались им профессионально и не знаете его возможностей. А пользовался и пользуюсь и знаю. В любом случае PostGIS отличный package.

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

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

Мне помогло больше всего вот это
Brian Beckman Dont fear the Monads

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

I>Понять бы, зачем это нужно. Какие задачи они решают? Они полезны только для "чисто функциональных" языков или нет?
I>Помогут ли они чем-то программисту в "гибридном" языке программирования (т.е. в котором есть функциональное программирование, но при этом есть все императивные возможности)

Все императивные возможности есть в чистых ФЯ. Они отличаются от ФЯ императивных, не отсутствием возможностей, а тем, что упорядоченность действий является явной, а не неявной.
Монады для этой "явной упорядоченности" не обязательны.
Чистота функций гарантируется по построению. Начинается все с базовой иммутабельности. Однако, изменяемые ссылки нужны и мы добавляем в чистый язык соотвествующие функции:

readMutVar :: MutVar a -> a

writeMutVar :: MutVar a -> a -> ()

Так делается в SML и в этот момент эта "чистота по построению" теряется. Т.е. в случае "в основном иммутабельного" языка вроде ML это решение уровня библиотеки (по большому счету, некоторая модификация языка нужна — неявный runIO для main).
Мы же сейчас строим чистый язык, так что этот вариант для нас не подходит — нам нужна другая библиотека.
Делаем функции работы с изменяемыми ссылками чистыми:

readMutVar :: MutVar a -> State -> (State, a)

writeMutVar :: MutVar a -> a -> State -> State

Все, теперь сайд-эффект обозначен как "изменение" некоторого фиктивного параметра State — т.е. сайд-эффектом он быть перестал, ссылочная прозрачность не нарушается.
Но у нас все еще есть проблема: из таких функций можно собрать функцию, которая чистой не является, ссылочную прозрачность нарушает.
Как же быть? Если в языке есть уникальные типы — мы просто делаем State уникальным:

readMutVar :: MutVar a -> *State -> (*State, a)

writeMutVar :: MutVar a -> a -> *State -> *State

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

readMutVar :: MutVar a -> State -> (State, a)
-- слегка поправим сигнатуру:
writeMutVar :: MutVar a -> a -> State -> (State,())
-- теперь сходство становится очевидным:
newtype IO a = IO (State -> (State, a))

readMutVar :: MutVar a -> IO a
writeMutVar :: MutVar a -> a -> IO ()

Теперь реализуем комбинаторы для этих функций, которые сохраняют уникальность State, и экспортируем их, а конструктор IO не экспортируем.
Вот теперь любая функция у нас чистая по построению (пока мы не нарушим инкапсуляцию IO).

Как видите, мы обошлись без монад, поэтому я и говорил, что они не нужны. Но желательны. Для чего? Для уменьшения писанины.
Выше я упоминал "безопасные комбинаторы". Для удобства их нужно много, а минимальный их набор — две штуки. Так вот, набор удобных комбинаторов, выражаемых в терминах этих базовых двух — одинаков для всех монад. А описываемое выше протаскивание параметра-состояния — это монада state. Поэтому вместо отдельной инфраструктуры построения безопасных (с точки зрения ссылочной прозрачности) мутирующих функций нам нужно просто реализовать инстанс класса Monad для IO (две функции). Плюс к тому, для монад делается синтаксический сахар, который маскирует всю эту "обвязку" из комбинаторов.
Ну и класс Monad — это только одно из многих доступных решений для безопасного комбинирования действий. В хаскеле сейчас "из коробки" есть две иерархии таких интерфейсов для комбинации вычислений Functor/Applicative/Monad и (менее популярные) стрелки.

Т.е. смысл монад, во-первых, в повторном использовании кода. Одна и та же функция для монады IO выполнит список действий поочередно, вычислит декартово произведение списка списков для list, проверит успешность всех вычислений для maybe и т.д.
А во-вторых это средство для разделения кода на некие "основные действия" и "обвязку", от которой можно абстрагироваться.
В третьих, это способ уменьшить порог вхождения для встроенного языка.
Дело в том, что инстансы класса Monad должны выполнять законы.

return >=> f === f
f >=> return === f
(f >=> g) >=> h === f >=> (g >=> h)

Т.е. такие свойства комбинаций функций, которые выполняются независимо от того, что это за монада и, соответственно, что это за встроенный язык — для недетерминированных вычислений или для построения парсеров.
Таким образом, знающий монады знает не только большую часть функций из всех монадических встроенных языков (включая еще не написанные), но и какими свойствами обладают их комбинации, и как их можно переписать не меняя смысла, т.е. отрефакторить. В данном случае монады это ответ на часто обсуждаемую проблему встроенных языков: "встроенный язык нужно проектировать, реализовывать, поддерживать. Каждый встроенный язык программисту-пользователю нужно изучать заново". Тут большая часть первой работы (для разработчика встроенного языка) уже проделана теми, кто написал стандартную библиотеку, а большую часть работы по освоению языка нужно проделать только один раз для любого числа встроенных языков.
В-четвертых, монады позволяют модульным образом собирать комбинации из таких монадических языков, подключая нужные фичи и отключая ненужные с помощью трансформеров.

Поэтому монады имеют смысл в языке вне зависимости от того, чистый (декларативный) это язык или императивный.
Однако, в большинстве гибридных языков, монадами пользоваться неудобно (из-за слабости реализации функциональных фич и/или системы типов), так что используются они ограниченно либо вовсе не используются.

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

C>>У DB2 офигенный оптимизатор над которым работали поколения академиков. Он реально крут.
__>Чем же он офигенный ? Каждый производитель это твердит. "У нас офигенный оптимизатор!!!".
Я видел примеры, когда DB2 делал запросы во много раз эффективнее Оракуловых.

C>>Проблема в том, что продукты IBM никогда не отличались дешевизной.
__>40к за we, от 80k до 250k за ese. цены вполне сравнимые с oracle.
Её ещё нужен AIX и POWER

>>Это вряд ли. По фичам последний SQL Server и Oracle примерно одинаковы. Точнее, можно найти для большинства фич примерный аналог (не обязательно работающий так же).
__>Да куда уж там "вряд ли". Напр. MINUS/EXCEPT. Насколько я помню EXCEPT появился в 2к5, а MINUS был уж не помню с какой версии (в 8-ке кажется точно был). Опять же всякие гриды/кластеринг, которые появились у ms сильно позже. И где кстати MS IMDB совместимая c mssql? Ее нет а у oracle timesten.
Так ещё MSSQL 2000 вспомни. Понятно, что многие фичи у МС позднее появились, но таки появились. Насчёт IMDB — есть xVelocity.

C>>Солярка и спарк — они уже давно слились...
__>Да посмотрите вы тесты TPC-C. Они живее всех живых и чемпионы производительности.
В морг, в морг. Тесты TPC-C нынче вообще нерелевантны.

C>>Со сложными запросами с кучей JOIN'ов всё сложнее — оптимизатор у Oracle никогда не славился особым умом и сообразительностью, так что Постгрес часто делает намного лучшие планы. С другой стороны, для Oracle можно в стратегические места поставить hint'ы и ускорить запросы, а с Postgres это существенно сложнее.
__>Я все-таки вижу главное преимущества Postgres здесь не в скорости by design (все равно oracle придет первым к финишу при "правильной конфигурации"), а в открытом исходном коде и возможности "ускоряться" под свои задачи с помощью собственных модификаций.
Модификации обычно делать — это последняя возможность. Хотя расширяемость с помощью плугинов у PSQL сильно неплохая.

C>>У Оракла есть отдельный пакет для geospatial баз, за кучубабла. Впрочем, он тоже сосёт. У SQL Server есть некоторые зайчатки GIS и есть пакеты третьих фирм, но по полноценности до PostGIS они не дотягивают.
__>Нет не сосет. Вы похоже просто не пользовались им профессионально и не знаете его возможностей. А пользовался и пользуюсь и знаю. В любом случае PostGIS отличный package.
Пользовался, плевался, перешёл на PostGIS. Оракл не мог нормально даже пересечения фигур делать — sdo_intersection тормозил минутами на таблицах с сотнями записей

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

DM>Т.е. это все же safePerformIO, а не unsafe.
Ну так внутри кондома-то всегда находится весьма небезопасный х. Это не делает секс в кондоме небезопасным.

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

Для того, чтобы понять что Вы хотели сказать, нужно сначала понять что Вы хотели сказать...

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

I>Для того, чтобы понять что Вы хотели сказать, нужно сначала понять что Вы хотели сказать...

Ну, я готов дать разъяснения, если есть конкретные вопросы.

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

S>Ну так внутри кондома-то всегда находится весьма небезопасный х. Это не делает секс в кондоме небезопасным.

Вот то же самое хотел сказать! Но постеснялся.

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

K>Ну, я готов дать разъяснения, если есть конкретные вопросы.

Для этого нужно знать (и судя по всему весьма неплохо знать) SML, Haskell и т.д. Причем, как я понимаю, мало прочитать книжку — нужно на нем что-то написать реальное.

Вы можете объяснить что такое монады, используя базовую терминологию языков типа C++/C#/Java? (можно вводить новые понятия, но каждое понятие должно быть подкреплено реальными практическими примерами)

ЗЫ. можно даже создать отдельную тему здесь. Вопрос-то как видим популярный.