Журнал что надо, а кто против тот просто завидует.

Кому и чему?

> Кому и чему?

Людям, которые могут применять в работе прикольные игрушки типа Ocaml :)

Статья по camlp4 явно намекает на то, что эти игрушки могут применять люди, пишущие на любом языке >:)

> Статья по camlp4 явно намекает на то, что эти игрушки могут применять люди, пишущие на любом языке >:)

Доо.

то есть ты что, хочешь сказать, будто любая задача не сводится к построению няшного dsl и написанию его компилятора в кудаугодно?? о_О

какие-то странные контрреволюционные намеки

> то есть ты что, хочешь сказать, будто любая задача не сводится к построению няшного dsl и написанию его компилятора в кудаугодно?? о_О

Вопрос в том, на чем писать компилятор. И надо ли его писать вообще, учитывая, что:

«Проект языка - это проект библиотеки» (с)

"...и наоборот" (с)

Кстати, формат «конкурса языков» по определению делает конкурсные решения неэффективными и непрактичными, так как существует жесткое условие - решить задачу на одном-единственном языке и без использования сторонних библиотек.

Вдумчивый архитектор провел бы декомпозицию задачи, и предложил бы гибридное многоязыковое решение (так называемый подход «polyglot programming»). Например, опытному проектировщику, будучи в здравом уме, никогда не придет в голову использовать «ленивый» язык для парсинга гигабайтного XML. Ну или, обобщая, использовать любой язык со слабо развитой runtime-библиотекой (чем грешат все классические ФЯП) для «грязных» задач типа разбора данных или отрисовки графики, а для числодробильни - интерпретируемый (или вообще динамический) язык.

Поясню на примере. В примере с картами можно было бы переложить разбор огромных XML на плечи тяжелой артиллерии (Cи), а вычисления - на OCaml/Scheme. В задаче с Ганттом - отрисовку графики реализовать при помощи XSL:FO и любого FO-процессора, а задачу оптимизации (NP-полную, на минуточку!) решить теми же Scheme/OCaml.

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

а «опытные проектировщики» могут чем-то аргументировать? а то народ не знает, и парсит гигабайтные XML'и на Haskell'е...

> Не могу не согласиться, что основной контент в журнале «ПРАКТИКА функционального программирования» к этой самой практике никакого отношения не имеет.

Последняя статья не завершена — там должен был быть пример того, что не укладывается в полиморфизм Хаскеля98, тогда она имела бы практический смысл («знайте, дети, тут нужны более мощные инструменты»). А в целом хорошая статья.

> а «опытные проектировщики» могут чем-то аргументировать? а то народ не знает, и парсит гигабайтные XML'и на Haskell'е...

Быстродействием и потреблением ресурсов.

Давайте возьмем простенький пример отсюда (преобразование XML в HTML по заданным правилам на Haskell, с использованием библиотеки HaXml). Сгенерируем тестовый XML на несколько гигабайт, и запустим этот примерчик, а потом - эквивалентное XSLT-преобразование с помощью xsltproc, и сравним.

Если Вам интересно, пускай это станет Вашим домашним заданием. Я же слишком дорожу своим временем, чтобы в который раз разжевывать давно известное. В этом мире есть дела и поважнее.

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

Фактически, Foo описывает объект «на момент создания» в том же смысле, в котором оператор присваивания описывает переменную «на момент выполнения».

ну вот и достигли консесуса :)

а кроме xml -> html никаких больше видов обработки xml нет? это как факториал считать...

> а кроме xml -> html никаких больше видов обработки xml нет? это как факториал считать...

Отнюдь.

Есть большой класс задач, предполагающий полную загрузку в память всей модели данных, сериализованной в XML, для последующего рандомного доступа к элементам. Домашнее задание №2: сравнить потребление памяти при загрузке гигабайтного XML а) при помощи HaXml в «родные» Haskell-типы, б) при помощи libxml2 в DOM-модель.

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

ну вот придумал себе домашние задания, давай и решай...

> парсинга гигабайтного XML

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

Для таких задач хорошо подходят memory mapped files. Библиотека для работы с ними в Хаскелле есть.

> Для таких задач хорошо подходят memory mapped files.

Вы не понимаете сути DOM. Речь идет о превращении XML-файла в связную модель данных (древовидную, а иногда и в виде общего графа - не забываем про entities) в оперативной памяти компьютера, в целях обеспечения быстрого произвольного доступа к элементам, обхода дерева, быстрого поиска и вычисления выражений.

Как здесь поможет отображение XML-файла в память?

> ну вот придумал себе домашние задания, давай и решай...

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

Если хотите, я могу заняться этим для Вас. Сообщите адрес, куда бы я смог выслать образец договора и расценки. На всякий случай - я привык к почасовой оплате.

> Как здесь поможет отображение XML-файла в память?

Попробуй подумать. ;)

> я привык к почасовой оплате.

Мне даже подумать не ловко, о какой профессии может идти речь...

числодробильня на интерпретируемом языке

Аффтар, отсыпь! Мне завидно.

alar

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

Аффтар, отсыпь! Мне завидно.

Что не так? Ocaml компилируется в эффективный машкод, для Схемы тоже есть эффективные компиляторы.

> Вы не понимаете сути DOM.

Только работодателю моему не говори. :D

Как здесь поможет отображение XML-файла в память?

Суть индексов понимаешь? :)

> Аффтар, отсыпь! Мне завидно.

Вообще, я с самого начала ждал появления улюлюкающих клоунов со словами «числодробильня на Scheme, ололо!»

Месье определенно не слышал о Stalin.

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

на интерпретируемом языке

на интерпретируемом

интерпретируемом

Что не так? Ocaml компилируется в эффективный машкод, для Схемы тоже есть эффективные компиляторы

Ocaml компилируется в эффективный машкод, для Схемы тоже есть эффективные компиляторы

Ocaml компилируется в эффективный машкод, для Схемы эффективные компиляторы

Ocaml компилируется, для Схемы компиляторы

компилируется, компиляторы

> Только работодателю моему не говори. :D

Хорошо, я ни словом не обмолвлюсь об этом перед Василием Петровичем Пупкиным, хозяином вебдваноль-стартапа «Pupkin Solutions, Inc».

Суть индексов понимаешь? :)

Насколько я понимаю, вы и ваш коллега по разуму LamerOk собираются держать в ОЗУ древовидную структуру, которая в своих узлах ссылалась бы на текст, «хранящийся» в mmap'нутой области.

А теперь попытайтесь представить, во что превратится многопроходная обработка такого крокодила, с постоянным шуршанием по диску, с кешированием и выкидыванием даннных из кеша. Ваш подход сработает только тогда, когда у вас достаточно рамы, чтобы закешировать весь XML-файл. Что по потреблению памяти и скорости работы шумно всасывает у однопроходного DOM-парсинга.

Онанимный разум решил задорно пошутить насчет «числодробилки на интерпретируемом языке», ошибочно полагая, что Scheme и OCaml - интерпретируемые.

Камрад tailgunner просветил онанимного разума в том, что для Scheme и OCaml есть эффективные канпеляторы.

А ты просто этого не понял.

// Ваш К.О.

> только тогда, когда у вас достаточно рамы, чтобы закешировать весь XML-файл.

Забавный ход мысли. Кэшмисс, надо полагать, приведет к немедленному сегфолту, бсоду и возгоранию процессора?

у однопроходного DOM-парсинга.

Ненене, Дэ^w Кука. Только что же было «многопроходная обработка такого крокодила»? А в изначальном посте «в целях обеспечения быстрого произвольного доступа к элементам, обхода дерева, быстрого поиска и вычисления выражений.»

Дэ^w Тьфу ты, Кука, давай ты как-нибудь будешь помнить хотя бы то, что пишешь сам? Я, конечно, безмерно рад твоим постам, оживляющим вечерний лор, но всё же надо придерживаться хоть каких-то минимальных рамок )))

> А ты просто этого не понял.

Да, верно. Анон половину поста засунул в тему, а они у меня идут мелким шрифтом и я их на автомате не читаю.

> Хорошо, я ни словом не обмолвлюсь об этом перед Василием Петровичем Пупкиным, хозяином вебдваноль-стартапа «Pupkin Solutions, Inc».

Ясновидящий из тебя херовый, но лучше, чем программист.

Ваш подход сработает только тогда, когда у вас достаточно рамы, чтобы закешировать весь XML-файл. Что по потреблению памяти и скорости работы шумно всасывает у однопроходного DOM-парсинга.

При том что DOM целиком туда поместился? Чудик, ты сам то суть ДОМа понимаешь?

P.S. Не говорите Куке раньше времени про «sucks» )))

Интересно это должно быть в первую очередь Вам - как желающему отстоять состоятельность Хаскелла в этой области.

Возможно, я ошибаюсь, но мне думается, что никому не интересно отстаивать что-либо перед вами.

> Возможно, я ошибаюсь, но мне думается, что никому не интересно, ляпнув фигню, аргументировать её перед вами.

// fxd

в POET классов нет, там прототипное ООП. в Io где-то то же самое, да и вообще таких языков немало

*включил Whitesnake - Slow Poke Music*

в POET классов нет, там прототипное ООП. в Io где-то то же самое, да и вообще таких языков немало

Не думаю что по новой готов начать обсуждение сортов гов^WООП... мы достигли компромиса который нас всех (?) устроил... читайте тред :)

*включил Cannibal Corpse - Hammer Smashed Face* ;)

читайте тред

раньше, раньше надо было это говорить :)

раньше, раньше надо было это говорить :)

ой, извините, libbabawanga.so опять отвалился :)

> Насколько я понимаю, вы и ваш коллега по разуму LamerOk собираются держать в ОЗУ древовидную структуру, которая в своих узлах ссылалась бы на текст, «хранящийся» в mmap'нутой области.

А теперь попытайтесь представить, во что превратится многопроходная обработка такого крокодила, с постоянным шуршанием по диску, с кешированием и выкидыванием даннных из кеша. Ваш подход сработает только тогда, когда у вас достаточно рамы, чтобы закешировать весь XML-файл.

Ты дурак? Если не достаточно RAM, для того, чтоб закешировать весь XML-файл, то ты его не сможешь держать всю распарсенную структуру в памяти.

> Ты дурак? Если не достаточно RAM, для того, чтоб закешировать весь XML-файл, то ты его не сможешь держать всю распарсенную структуру в памяти.

Мде. Ты про виртуальную память слышал? Не торопись называть других дураками...

> Мде. Ты про виртуальную память слышал? Не торопись называть других дураками...

Ты видел, что в посте было написанно RAM? Кука сначала написал, что если распарсить XML и держать в памяти DOM-модель, то это позволит уменьшить время для рандомного доступа, а предложении рядом написал, что для подгрузки в RAM XML файла не хватит места. Я пытаюсь намекнуть, что затраты по памяти на эти две задачи одного порядка. Т.е. если для одной задачи не хватит, то и для другой.

> Мде. Ты про виртуальную память слышал? Не торопись называть других дураками...

Дискуссию перечитай.

> А теперь попытайтесь представить, во что превратится многопроходная обработка такого крокодила, с постоянным шуршанием по диску, с кешированием и выкидыванием даннных из кеша. Ваш подход сработает только тогда, когда у вас достаточно рамы, чтобы закешировать весь XML-файл. Что по потреблению памяти и скорости работы шумно всасывает у однопроходного DOM-парсинга.

Если твой гигабайтный XML меняестся значительно реже, чем читается, то индексы можно один раз создать и хранить на диске. А парсить свой DOM ты будешь каждый раз. И если тебе из XML надо 3 значения получить, то нахрен его весь в память тянуть?

P.S. Кука, это ты меня в игнор добавил? Ранимые критики такие ранимые.

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

Но дураком ты назвал только Куку :) Крепко он вас задел :D

P.S. для протокола - в задачах парсинга многогиговых XML-файлов не разбираюсь, и не хочу.

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

Но дураком ты назвал только Куку :) Крепко он вас задел :D

А что, если дурь пишет один только Кука, надо было и всех остальных дураками назвать ради политкорректности? Оригинальный подход.

> А что, если дурь пишет один только Кука

О, еще один чувствительный. Анонимный брат сказал:

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

что тебе непонятно?

Ты серьёзно или притворяешься? Кука утверждает, что построить DOM в _памяти_ — это мол-де пафосно и правильно, а заммапить в _память_ xml-файло — памяти не хватит и всё будет тормозить, шурша диском.

Альтернативная одарённость расцветает бурным цветом, нечувствительные к логике вы наши.

> Ты серьёзно или притворяешься?

А ты тролль или дислектик? А то с дислектиком троллить неинтересно.

Таки не притворяешься. Даже название своего заболевания не способен запомнить? 8)) На, пользуйся плодами прогресса, попробуй читать по буквам или попроси старших прочесть вслух: http://ru.wikipedia.org/wiki/Дислексия

Ещё раз, для альтернативно-одарённых, медленно и печально: дурак Кука дурак не потому, что DOM может в ОЗУ не влезть. Дурак Кука дурак потому, что считает, будто невлезшее в ОЗУ DOM-дерево — это фигня и никаких проблем, а невлезший в ОЗУ отммапленный файл — ужос-ужос-ужос и тормоза, шуршащие винтом. На что вам уже не раз заметили, что между этими двумя случами принципиальной разницы нет.