Пруфа нет, личный опыт. Работаю над проектом, входящим в ТОП 25 посещаемости рунета. Шардированная БД не нужна и долго еще не понадобится. Постгрес отрабатывает где-то 10000 запросов в секунду. И это не предел. На морде где-то 500 rps отдается. Зато дохренища аналитических задач, которые легко решаются sql. Если бы тут был map-reduce, то все бы повесились.

>> SQL - это язык. «Плохо масштабируемым» его называют недоучки :)

К чему ёрничать? :) Ты же прекрасно понял, о чём шла речь (SQL-based DBMS).

Я не ёрничаю, я правда не понимаю, как люди могут писать запросы на JavaScript и считать, что это лучше SQL.

PS: А «недоучка» - это плохо? :)

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

Лично мне весь это NoSQL кажется накрашенной трупом из времен CODASYL (точнее, реплицированной толпой таких трупов), но кто сейчас помнит о CODASYL?

> как люди могут писать запросы на JavaScript и считать,

что это лучше SQL.

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

Лично мне весь это NoSQL кажется накрашенной трупом из времен CODASYL

Это называется косность мышления.

>> как люди могут писать запросы на JavaScript и считать, что это лучше SQL.

Мне тоже не понятно, как люди могу использовать хранимые процедуры вместо простого языка запросов

Причем тут хранимые процедуры и что в данном случае «простой язык запросов»?

> Работаю над проектом, входящим в ТОП 25 посещаемости рунета.

Шардированная БД не нужна и долго еще не понадобится.

Ну так наверно используется топовое железо? Это ведь дорого? Меня вот в последнее время больше интересует вопрос как получить максимальную производительность + необходимую надёжность на дешёвых съемных площадках и иметь возможность плавного наращивания мощности.

Если бы тут был map-reduce, то все бы повесились.

Почему?

> Почему?

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

Ну так наверно используется топовое железо?

Ну неплохой такой сервак самосборный. Примечателен большим количеством оперативки. Объем оперативки соизмерим с объемом самой базы.

иметь возможность плавного наращивания мощности.

Вот хз что дешевле в итоге - наращивать мощность сервера СУБД (оперативку добавлять, диски побыстрее,в перспективе ssd) или наращивать мощность кластера СУБД из простеньких машин. Но имхо все эти кластера очень капризны в обслуживании.

Почему?

Я хз как так насчет монговского map-reduce. Но я писал на хадупе, и там сильно не напишешся. Простенькая считалка, записанная 5 SQL-никами на хадупе вышле в где-то 20 пар map-reduce. Это слишком low level инструмент. Хотя я потом нашел прикольные обертки для map-reduce. Например cascading.org, если на чем-то таком писать, то пойдет, а голый map-reduce это онанизм сплошной.

Ну естественно потому что надо было изучать новую парадигму, а

Вборс не засчитан, там изучать нечего. SQL несоизмеримо сложнее и дает больше возможностей. Например все крутые хадуповские обертки над MapReduce подражают SQL, и это правильно.

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

> Вборс не засчитан, там изучать нечего. Ну разве что только для эффективного написания mapreduce нужно функциональную парадигму подучить, которая, да, у императивщиков вызывает приступы неконтролируемого панического страха.

SQL несоизмеримо сложнее и дает больше возможностей.

Это с какой это стати ограниченный узкоспецифичный DSL даёт больше возможностей чем полное множество какого-либо ЯП, используемое в map-reduce? Проще - соглашусь, сложнее - никак.

>Мне кажется на больших нагрузках MongoDb - это боченок с порохом.

Ну если работать с ним как с реляционкой и не задумываться как он устроен - то это точно.

> для эффективного написания mapreduce нужно функциональную парадигму подучить, которая, да, у императивщиков вызывает приступы неконтролируемого панического страха

Толстовато.

я - den73

Все знают греп. Но никто пока не написал греп, который бы понимал лексическую структуру языка программирования.

Для начала - такой, в котором «a * b» - это то же, что «a*b» и «a/*это а*/*b». Т.е., игнорируется whitespace и комментарии.

Параметры грепа - набор файлов, ЯП и искомое выражение. Греп лексит сначала выражение. Потом лексит каждый из набора файлов. Потом сопоставляет.

Жутко не хватает такой утилиты любому программеру (ну не знаю, как любому - мне точно не хватает). Мы тут с diglan-ом собирались такую написать уже года три как, но мне программировать надоело, diglan никак не напишет, поэтому пора уже опубликовать эту идею.

Это - только начало. Настоящий греп гораздо сложнее поставленнго ТЗ и такой, лексический греп тоже можно далеко развивать.

> Мне кажется на больших нагрузках MongoDb - это боченок с порохом.

И ещё один «почему?».

Я хз как так насчет монговского map-reduce

В монго использование map-reduce это достаточно крайний случай, там, в отличие от той же CouchDB, есть вменяемый простой язык запросов, который хорошо подходит для очень многих случаев.

Но я писал на хадупе

Ну нельзя же оценивать MongoDB по опыту работы с другими NoSQL решениями, они же все разные. Если сравнивать что-то с монго, то это couchdb, но различий достаточно много, включая производительность и наличие простого языка запросов.

> Если сравнивать что-то с монго, то это couchdb, но различий достаточно много, включая производительность и наличие простого языка запросов.

Ну вот, скоро там сделают свой маленький SQL :)

> Все знают греп. Но никто пока не написал греп, который бы понимал лексическую структуру языка программирования.

Многие «типа IDE» по идее имеют такое в загашнике. По крайней мере мне так кажется. Даже та штуковина которая по слухам делает IDE из emacs-а. Тем более что она написана на CL, хоть и в обрезаном emacs-овском диалекте.

Тем более что она написана на CL, хоть и в обрезаном emacs-овском диалекте.

Ты бы ещё паскаль диалектом си назвал. Общего у elisp и CL --- только скобочки.

> Тем более что она написана на CL, хоть и в обрезаном emacs-овском диалекте.

Да вы что? Emacs Lisp старше Common Lisp'а. На нём уже писали emacs, когда CL только на бумаге появлялся.

> Ты бы ещё паскаль диалектом си назвал. Общего у elisp и CL --- только скобочки.

Да вы что? Emacs Lisp старше Common Lisp'а. На нём уже писали emacs, когда CL только на бумаге появлялся.

У как забегали, зашумели:)

Просто для всеми нами любимого (и мной тоже:)) есть расширение elisp-а совместимое с CL за исключением CLOS. Вот на нем то эта штуковина, название которой у меня вышибло из памяти, и написана. Только всместо CLOS у них что-то свое саморазработаное.

Теоретик детектед.

$ man sgrep

см.раздел: EXAMPLES OF REGION EXPRESSIONS

?

я - den73

$ man sgrep

Возможно, это снимает актуальность задачи. Хотя, вот это определение define(IF_COND,( «if» not in (COMMENT or CTRLINE) .. ("(" .. ")")))

говорит о том, что этот sgrep может оказаться неудобен. Например, потому, что «not in (COMMENT or CTRLINE) должно быть по умолчанию. Кроме того, я не совсем понял, если if будет заключён в двойные кавычки, будет ли он понятен этому sgrep-у?

Всё же лексер ЯП - это довольно специфическая программа. Она проста, но её сложно эмулировать чем-то другим. Взять хотя бы вопрос о вложенных комментариях.

Нужно разбираться, что за зверь этот sgrep. Вам, в любом случае, спасибо, раньше мне он не попадался. Может быть, даже попробую его использовать в работе.

И ещё один «почему?».

Ну я же написал - не транзакционное оно. Если проект маленький, то можно все ручками отслеживать, делать типа-транзакции на атомарных операциях. А вот в большом приложении я бы предпочел написать begin; ... commit; и отключить мозг.

Ну нельзя же оценивать MongoDB по опыту работы с другими NoSQL решениями

А я не сравниваю их как NoSQL решения, я просто высказываю свое мнение насчет MapReduce и оно такое: это удобный базис не более того, в голом виде для решения прикладынх задач не годится.

den73, ты вроде на питон переходил. Чем все закончилось?

Я вот в свое время наваял за вечер такую фигню -> https://github.com/grouzen/cl-tetris3d . Код там конечно говно, но в качестве «хелловорлд» вполне ок.

«О! Обряд посвящения, мой любимый ритуал!» — «Нет, Ричи, ты ошибаешься, это чисто духовное…»

я - den73

Не перешёл на питон и об этом не жалею.

И вообще остыл к программированию. В настоящее время по работе автоматизирую книжный склад. Delphi+Firebird+Common Lisp. Lisp использую в качестве макропроцессора, сборщика серверной части Firebird и скриптового языка.

Кстати, всё ещё не опубликованы мои расширения для читалки Common Lisp. Когда мне надо определить хранимую процедуру, я пишу в лисповом файле примерно вот так:

(def-firebird-macro-1 M_MIN (x y) (fbody case when (~~x) < (~~y) then (~~x) else (~~y) end^))

(def-firebird-macro-1 M_конец_месяца (date-expr) 
  (fbody dateadd(day,-1,dateadd(month,1,M_начало_месяца(~~date-expr)))^))

(def-stored-procedure s_polu4it_ojidanie
 :doc "!1C.ПолучитьОжидание Добавлен новый параметр, чтобы можно было суммировать ож-е по холдингам. См. также fo_poluch_ozhid"
 :args '((ref_party d_upid)
         (data_per simple_date)
         (rej int :default 1)
         ; ...
         )
 :returns '((result money))
 :vars '((датаНач simple_date)
         ; ... 
         )
 :body 
 (fbody 
  M_ASSERT(датаНач is not null)
  data_kon=M_конец_месяца(data_per);
  датаНач=dateadd(day,-sr_opl,data_kon);
  датаНач=M_MIN(датаНач,M_начало_месяца(data_per));
  -- ...
  ^
  )

Макропроцессор расширяет M_MIN, M_конец_месяца, и заключает идентификаторы, набранные кириллицей, в двойные кавычки. На данный момент у меня 45 макросов M_ для файрбёрда.

Если кому интересно, как это сделано (переносимо по отношению к реализации CL), можете помочь в опубликовании. На данный момент поддерживается только лиспворкс, но в своё время тестировал на 4-5 разных реализациях лиспа - работало.

я - den73, contd

Некоторые другие приятности. [code=lisp]

here-documentc ~не$#'«уй мешаться со всякими кавычками~

„не$#'\„уй мешаться со всякими кавычками“ [/code] хотя этим в жизни я не пользуюсь. Потому что, когда надо сделать запрос к базе, я пишу просто в обычной подсказке лиспа: [code=lisp]

fse first 5 o.doc_number,ot.short_name from M_AS(operation,o) M_INNER_JOIN(o,ref_type,ot);

[/code] Лисп проглатывает все эти запятые, лезет в словарь, смотрит на связи между таблицами и генерирует запрос „select first 5 o.doc_number,ot.short_name from operation as o inner join OPERATION_TYPE as ot on ot.Id = o.ref_type“. Начальный запрос был 90 символов, на выходе - 121. Т.е., я сэкономил четверть нажатий на кнопки.

Сокращение обращения к ф-ям, имеющим префикс „тип-“: например, вместо (my-structure-x s), где s - типа my-structure, я обычно пишу (^ x s) или s^x и, если тип s был правильно задекларирован, то это превращается в (my-structure-x s) на этапе макрорасширения, а если нет, то в рантайме используется slot-value.

Макрос для борьбы с лишними скобками: там, где все пишут [code=lisp] (WITH-OPEN-FILE (A „a“) (WHEN A (LET ((B A)) B) )) [/code], я пишу [code=lisp] (PROGA (WITH-OPEN-FILE A „A“) (WHEN A (LET B A) B)) [/code] У меня на одно слово и на одну строчку больше, зато в полтора раза (sic!) меньше скобок и на один уровень вложенности меньше (тоже в полтора раза!)

Короче говоря, я сгладил почти все те вещи в лиспе, к-рые были мне наиболее противны. Всё это было на фоне воплей лисперов, что я всё делаю неправильно, зачем мне это надо и что я вообще не лиспер. Да, я не истинный лиспер, я не поклоняюсь скобкам и написание пары скобок для меня не эквивалентно произнесению мантры „ОМ“. Я считаю, что мешанина скобок - это полное дерьмо. Я просто пользуюсь лиспом, т.к. у него есть реальные достоинства (очень большие).

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

В общем, теперь мне в лиспе вполне комфортно, и, если дела пойдут так и дальше, я не планирую изучать больше никаких ЯП.

Хотя есть ещё одна задумка - сделать всё же синтаксис с разными скобками, не только круглыми, но и квадратными и фигурными. Чтобы в разных случаях были допустимы только определённые виды скобок. Это ещё несколько повысит читаемость, но, в целом, это - уже мелочь.

я - den73 (извините, формат...)

Некоторые другие приятности.

> here-documentc ~не$#'"уй мешаться со всякими кавычками~
"не$#'\"уй мешаться со всякими кавычками"

> fse first 5 o.doc_number,ot.short_name from M_AS(operation,o) M_INNER_JOIN(o,ref_type,ot);
                  

Сокращение обращения к ф-ям, имеющим префикс «тип-»: например, вместо (my-structure-x s), где s - типа my-structure, я обычно пишу (^ x s) или s^x и, если тип s был правильно задекларирован, то это превращается в (my-structure-x s) на этапе макрорасширения, а если нет, то в рантайме используется slot-value.

Макрос для борьбы с лишними скобками: там, где все пишут

(WITH-OPEN-FILE (A "a") 
  (WHEN A 
    (LET ((B A)) 
      B)
    ))

(PROGA
  (WITH-OPEN-FILE A "A")
  (WHEN A 
    (LET B A) 
    B))

Короче говоря, я сгладил почти все те вещи в лиспе, к-рые были мне наиболее противны. Всё это было на фоне воплей лисперов, что я всё делаю неправильно, зачем мне это надо и что я вообще не лиспер. Да, я не истинный лиспер, я не поклоняюсь скобкам и написание пары скобок для меня не эквивалентно произнесению мантры «ОМ». Я считаю, что мешанина скобок - это полное дерьмо. Я просто пользуюсь лиспом, т.к. у него есть реальные достоинства (очень большие).

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

В общем, теперь мне в лиспе вполне комфортно, и, если дела пойдут так и дальше, я не планирую изучать больше никаких ЯП.

Хотя есть ещё одна задумка - сделать всё же синтаксис с разными скобками, не только круглыми, но и квадратными и фигурными. Чтобы в разных случаях были допустимы только определённые виды скобок. Это ещё несколько повысит читаемость, но, в целом, это - уже мелочь.

На костёр.

> Начальный запрос был 90 символов, на выходе - 121. Т.е., я сэкономил четверть нажатий на кнопки.

Лучше б ты сэкономил на наркотиках.

Хотя есть ещё одна задумка - сделать всё же синтаксис с разными скобками, не только круглыми, но и квадратными и фигурными.

И купил бы лекарств.

Сделал бы лучше реализацию sweet-expressions с плюшками. И не макро-костылями, а с нормальным парсером-отбражением my-super-readable-syntax -> plain-cl. Literal style, опять же, можно прикрутить. Просто plain CL с уклоном оставляет довольно странное впечатление, а вот в области того как делать my-super-readable-syntax (типа эргономика) есть разные наработки. Короче, синтаксис должен быть консистентный и последовательный, полумеры тут не подходят.

в полтора раза (sic!) меньше скобок и на один уровень вложенности меньше

Тогда уж сразу нужно вводить макрос ssa и вообще всё писать в один (sic!) уровень.

Короче говоря, я сгладил почти все те вещи в лиспе, к-рые были мне наиболее противны.

И получился язык общего назначения с аудиторией в один человек :)

Я просто пользуюсь лиспом, т.к. у него есть реальные достоинства (очень большие).

очень большие

Какие например? Если на твой взляд. Возможность менять синтаксис и тем самым ломать совместимость это достоинство или нет?

sweet-expressions

Ах да, там же на скобочке нельзя дважды щёлкнуть. Тогда идёт лесом :)

> в полтора раза (sic!)

О какой ошибке идёт речь?

Короче говоря, я сгладил почти все те вещи в лиспе, к-рые были мне наиболее противны. Всё это было на фоне воплей лисперов, что я всё делаю неправильно, зачем мне это надо и что я вообще не лиспер.

Это вопящие - не настоящие лисперы. Если ты не планируешь ни с кем делиться своими наработками - делай как тебе удобно и никого не слушай.

Да, я не истинный лиспер, я не поклоняюсь скобкам и написание пары скобок для меня не эквивалентно произнесению мантры «ОМ».

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

Я считаю, что мешанина скобок - это полное дерьмо.

Поддерживаю.

Хотя есть ещё одна задумка - сделать всё же синтаксис с разными скобками, не только круглыми, но и квадратными и фигурными.

Вы же чуть выше сказали что мешанина скобок - дерьмо. Так зачем привносить её в Лисп?

я - den73

> Какие например? Если на твой взляд.
Если сравнивать с питоном на момент, когда я его смотрел - истинно динамическая разработка, компиляция в нативный код, возможность строгой типизации, макросы, треды, поддержка кириллицы. В остальном же - тема вообще не о том. Лучше предложите ещё какой-нибудь hello, world для топикстартера. Я свой уже предложил.

Могу дополнить задание: чтобы к каждому найденному вхождению отображался контекст - имя функции/метода/класса, в к-ром данная ф-я, метод, класс определены. Тогда, небось, будет уже лучше, чем sgrep?

> Вы же чуть выше сказали что мешанина скобок - дерьмо
Имелось в виду - одинаковых скобок.

Если ты не планируешь ни с кем делиться своими наработками

Я готов делиться всем, но некогда оформлять. Оформлять - это значит, ещё и отделять мой специфический код, который в библиотеке общего назначения будет только мешать. Разделять файлы с кириллицей и без. И т.п.

> Имелось в виду - одинаковых скобок.

Мешанина *разных* скобок куда опаснее и читаемость только снизит. Именно потому что разные скобки несут семантическую информацию, а одинаковые - нет.

И, извините, но уточню ещё раз:

У меня на одно слово и на одну строчку больше, зато в полтора раза (sic!) меньше скобок и на один уровень вложенности меньше (тоже в полтора раза!)

Таки о какой ошибке здесь идёт речь?

возможность строгой типизации

Только немного не так - типизация там всегда строгая (динамическая по умолчанию, статическая по требованию, ill в обоих случаях).

чтобы к каждому найденному вхождению отображался контекст - имя функции/метода/класса

Ну это уже будет что-то вроде cedet.

> Таки о какой ошибке здесь идёт речь?
Ни о какой, насколько я понимаю, sic применено корректно, поскольку можно удивляться, до чего же избыточен синтаксис лиспа в плане скобок, и как нетрудно на самом деле от этого избавиться.

http://en.wikipedia.org/wiki/Sic

Вне цитат оно не имеет смысла.

Не очень хочется связываться с гуем, максимум на что я согласен - это веб.

Можно сделать «try CL in your browser» сервис. С точки зрения веба - взять websocket-ы, а для песочницы переписать REPL и eval.

> Мешанина *разных* скобок куда опаснее и читаемость только снизит.

Странно слышать, когда утверждают, что добавление информации снижает читаемость. Впрочем, спорить не буду, уже спорил. Эту мысль почему-то трудно понять. Подумайте над этим хотя бы до вторника, не спеша. Для начала, учтите, что компилятор зачастую вполне в силах определить, в каком контексте используется та или иная скобка и обругаться. Т.е., в определённых контекстах может быть применён только один-единственный вид скобки. Если не забуду, зайду сюда во вторник ещё разок.

про sic: http://ru.wikipedia.org/wiki/Sic , мы же пользуемся Русским языком, а не Английским.

Ну это уже будет что-то вроде cedet.

Ну, не как весь, а как часть, касающаяся поиска ссылок. Весь cedet - слишком большой для ПриветМира и вообще про другое. Или ткните носом в конкретное место. На самом деле, я описАлся. Имелось в виду, не «контекст, где определена данная функция», а «контекст, где найден искомый фрагмент».

den73

Ещё одна несложная и условно-полезная задачка с гуем: kdiff3 для cons-деревьев. Или, может быть, kdiff3 для исходников лиспа, учитывающая структуру лисп-выражений и синтаксис языка (#+, #. пакеты, readtable-case).

Хотя, может это уже не ново.

> мы же пользуемся Русским языком, а не Английским.

Это не Ты тот Чувак, который Пользовался разным Регистром букв, Потому что Ему так Казалось правильней?

Весь cedet - слишком большой для ПриветМира и вообще про другое.

В любом случае такой синтаксический греп должен уметь String -> AST для большинства языков - вот у CEDET с CTAGS есть поддержка (http://cedet.sourceforge.net/languagesupport.shtml) некоторых.

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

То, что эта избыточность введена _намеренно_, месье и в голову не приходило?

собственно элементарный пример, два варианта let-формы:

(let ((id value) ...) body ...) и

(let (id value id2 value2 ...) body ...)

теперь напишите макрос, в котором следует

1. распарсить let-форму

2. скодогенерировать let-форму c набором биндингов

> Для начала, учтите, что компилятор зачастую вполне в силах определить, в каком контексте используется та или иная скобка и обругаться. Т.е., в определённых контекстах может быть применён только один-единственный вид скобки.

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

Этот тред — подобие детектора. Из каментов складывается впечатление что лисп слабо применим на практике, узковат круг решаемых им задач.

> Из каментов складывается впечатление что лисп слабо применим

на практике, узковат круг решаемых им задач.

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