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

dmz> Гораздо продуктивнее оказалось добавить логи

Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

DM>Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

Гы. Знал бы хаскелл — сказал. Из того, что я о нем знаю — это действительно может быть проблемой Кастую Summon thesz. Если получится — то он явится и разъяснит.

dmz>Гы. Знал бы хаскелл — сказал. Из того, что я о нем знаю — это действительно может быть проблемой Кастую Summon thesz. Если получится — то он явится и разъяснит.

Но наверное, он скажет, что логи тоже не нужны. А программы на хаскеле правильные в силу типизации и чистоты.

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

DM>Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

import Debug.Trace

-- trace :: String -> a -> a

foo = trace "foo" (sum [1..10])

dmz>> Гораздо продуктивнее оказалось добавить логи
DM>Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

Программы на Хаскеле чистые и в них ошибок быть не может.

Обязательная часть выполнена, переходим к произвольной.

Если разрабатываем и лень гонять много REPL, то Debug.Trace. Некоторые продвинутые делают что-то на основе unsafePerformIO, это когда логов много.

Я предпочитаю протягивать логи через типы. Была функция a -> b, стала a -> (b,String).

Видно, что к чему.

T>Я предпочитаю протягивать логи через типы. Была функция a -> b, стала a -> (b,String).

Я правильно понимаю, что сообщение лога возвращается вместо исходного значения?
Это же может повлечь затычки в других частях, которые ожидают что a -> b, а не a -> (b,String)

Посмотреть бы реальный пример какой-нибудь.

T>>Я предпочитаю протягивать логи через типы. Была функция a -> b, стала a -> (b,String).
dmz>Я правильно понимаю, что сообщение лога возвращается вместо исходного значения?

Вместе с исходным.

dmz>Это же может повлечь затычки в других частях, которые ожидают что a -> b, а не a -> (b,String)

Да! Именно!

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

dmz>Посмотреть бы реальный пример какой-нибудь.

Затруднюсь прямо сейчас.

dmz>Посмотреть бы реальный пример какой-нибудь.

#ifdef __LOGGING__
log :: a -> Log -> (a,Log)
log = (,)

addLog :: (a,Log) -> Log -> (a,Log)
addLog (a,l) l' = (a,l++l')

#define FROMLOG(v) v##logged(v,v##log)

#else
log :: a -> Log -> a
log = const

addLog :: a -> b -> a
addLog = const

#define FROMLOG(v) v##logged@v

#endif

...
f a b c = log r ["a" $$ a,"b" $$ b]
    where
        r = ...

g x y z = addLog blogged ["x" $$ x]
    where
        FROMLOG(b) = f a b c

Хак (плюс-минус, может не работать прям сразу, но идея, думаю, ясна).

Но работает.

Быстро работает, когда надо.

Практически, кусок практически настоящей системы.

dmz>>Посмотреть бы реальный пример какой-нибудь.

T>

T>#ifdef __LOGGING__
T>

Это сишный препроцессор, натравливаемый на исходники перед компиляцией настоящим компилятором?

dmz>>>Посмотреть бы реальный пример какой-нибудь.
T>>

T>>#ifdef __LOGGING__
T>>

dmz>Это сишный препроцессор, натравливаемый на исходники перед компиляцией настоящим компилятором?

Ага.

ghc -cpp -D__LOGGING__ -Iinclude -osuf log.o -hisuf log.hi ...
ghc -cpp -Iinclude ...

Такое требуется уже потом, когда нужна скорость. Я описал на случай, если потребуется.

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

DM>>Тут часто говорят про логи вместо отладчика. А вот как происходит добавление логов в программы на Хаскеле? Там же должно быть до фига чистых функций, которые для добавления одной строчки вывода в лог придется оборачивать в хламидомонады, т.е. менять их тип, т.е. переписывать почти всю программу. Или есть простое решение?

T>Программы на Хаскеле чистые и в них ошибок быть не может.

Да ладно, приоритеты операций можно перепутать где угодно и записать x*a+c вместо x*(a+c) на любом языке программирования. На функциональных, может быть, даже проще, т.к. функциональщики скобок не любят

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

T>Некоторые продвинутые делают что-то на основе unsafePerformIO, это когда логов много.

Или когда они нестандартные. У нас на icfpc2008 был gtrace :: String -> DrawObject -> a -> a, который выводил графические примитивы на карту. Причём анимацию, карта не мусорилась. Тоже для чистых функций, разумеется.

T>>Программы на Хаскеле чистые и в них ошибок быть не может.
E>Да ладно, приоритеты операций можно перепутать где угодно и записать x*a+c вместо x*(a+c) на любом языке программирования. На функциональных, может быть, даже проще, т.к. функциональщики скобок не любят

Приоритеты операций на Хаскеле отлично разделены и упорядочены и с ними ошибок быть не может.

(прошу прощения, удержаться не мог)

T>>Некоторые продвинутые делают что-то на основе unsafePerformIO, это когда логов много.
L>Или когда они нестандартные. У нас на icfpc2008 был gtrace :: String -> DrawObject -> a -> a, который выводил графические примитивы на карту. Причём анимацию, карта не мусорилась. Тоже для чистых функций, разумеется.

*сидит, немо отупевши*

Хотя это могло иметь смысл.

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

E>Иногда отладчик очень серьезно экономит время и силы.

Отладчик по сути — мощная внешняя система логирования. Как и любое универсальное решение — не везде лучшее. Эффективность длительного сидения в отладчике крайне низкая, глаз замыливается, но это можно заметить со стороны, либо завтра. Это то и плохо, человек привыкает... Ошибки высших порядков в нём найти крайне сложно, тут и таится опасность: легко найти побочный эффект от другой ошибки и исправить не там.

Фразу "отладчик не нужен" я бы заменил на "им нужно уметь пользоваться настолько хорошо, что бы вообще не запускать".

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

Cтранно, вроде отвечал на это сообщение сразу же, "видимо что-то случилось" (C)

------------

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

Согласен, здесь "что-то не так" (используя печатные выражения).

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

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

T>"Размеры современных проектов"
T>Скажи лучше, плохая структуризация современных проектов. Ничего отрезать невозможно.

Т.е. наболело?
В своей команде вполне аргументировано ты можешь проталкивать необходимые улучшения модульной структуры, а здесь это суть гадание на кофейной куче и к процессу отладки относится мало. Большие размеры современных проектов — это объективная реальность, и эти размеры растут в последние годы очень быстро. Собс-но, для этого мы, программисты, и нужны, чтобы автоматизировать как можно больше аспектов человеческой деятельности.

Сам этот заметный рост сложности проектов стал возможен только благодаря высокоуровневой поддержке ср-в разработки.

T>Дорогой друг, какое конкретно количество строк написал ты или любой твой коллега на любом ФЯ?

На Схеме несколько тысяч в своё время, включая сам мини-интерпретатор Схемы.

T>Если это количество больше 100, я продолжу спор, но уже доказательно. Если меньше, то поверь мне на слово — ты не прав. Ты просто не в курсе, как нельзя накосячить на ФЯ.

Знаю, но ты не то называешь косяком. Т.н. "косяки", связанные с низкоуровневыми ошибками, типа проходу по памяти, — это самый низкий процент ошибок в современных проектах, к тому же, эти места легко вычисляемые. Большинство ошибок (по моему опыту) — это именно ошибки алгоритмического плана. Вообще, надо признать, что вообще само по себе кол-во ошибок стало смехотворным на единицу строк кода в последние годы, ИМХО это от всё меньшей доли самописных велосипедов в проектах, даже на С++. (Еще лет 10 назад каждый проект состоял примерно на 80% из самописанины библиотечно-фреймворкового уровня). Рождая по 300-500 строк кода в день, никакой разработчик не в состоянии помнить подробности даже собственных творений уже спустя пару месяцев. "Тупой" код-ревью на таких объёмах банально не прокатывает для задачи локализации ошибок, юнит-тесты на все случаи не напишешь (да и не надо), поэтому нужны эффективные ср-ва для целей этой самой локализации. У нас в проекте VoIP, где всё происходит в динамике и точу останова не везде поставишь таким ср-вом является многоуровневое логгирование (т.е. регулируется вербальность логов по мере уточнения локации косяка).

T>За более, чем 10 лет использования Хаскеля, я столкнулся всего с двумя ошибками: проблемы рантайма под windows в ghc 6.6 (ограничение сверху на хип) и, недавно, совершенно не критичная ошибка с отсутствие поддержки семейств типов в template haskell.

Поражает даже не кол-во багов на треккере GHC, а их характер. Можешь объяснить наличие большого кол-ва низкоуровневых багов в треккере, учитывая, что сам компилятор написан на Хаскеле?

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

А помогать им с отладкой... было бы ради чего — там помимо низкоуровневых, куча ошибок и логического плана и даже вывода типов. Вообще, кол-во багов поражает. Я как-то нашёл баг для библиотеки ADO.Net под MS SQL CE, запостил, мне сказали спасибо, дык баг был единственный (!!!) на всю либу. Просто сценарий у нас был, прямо скажем, далеко не рядовой (выжималка процессорных тиков для около-ИИ-темы). И вот я со своими далеко не рядовыми сценариями (где надо выжимать максимум из железки) полезу в Хаскель, начну его "выжимать" и он однозначно начнёт сыпаться. В общём, серьёзнее быть надо. Увлечение-увлечением, а дело надо делать сегодня на сегодняшних инструментах... Я даже любимый когда-то С/С++ не очень в критических местах юзал, ибо еще в 92-м нарвался подряд на 3 встроенных в Борландовский С++ бага в первом же более-менее крупном проекте, дособирали на ваткоме, но без IDE это было не то... После чего забросил C++ до 97-го года примерно, до выхода IDE от MS. Дальше рассказывать? На чём приличное кол-во внутренних тулзов у нас было сделано? На Форте и на VB for DOS. Про последний надо подробно, ибо к VB приклеился определённый образ у рунета. Так вот, вначале его использования я любил просматривать ассемблерный лог компиляции VB-программы (есть такая опция у компилятора), и должен сказать, что компилятор генерил прекрасный код. Мне, как ассемблерщику со стажем, по крайней мере очень нравилось. Везде, где раньше бы применялся Фортран (много было расчётных задач), мы юзали VB for DOS, благо и формы с кнопками быстро накидать можно было. В общем, рабочая лошадка, в которой нечему ломаться (и ни разу так ничего и не сломалось за 3 года плотного использования). Так что, к выбору инструментария у меня подход весьма прямолинейный — необходимо чтобы сам инструментарий не веселил своими причудами, ибо не до него.

T>>"Размеры современных проектов"
T>>Скажи лучше, плохая структуризация современных проектов. Ничего отрезать невозможно.
V>Т.е. наболело?
V>В своей команде вполне аргументировано ты можешь проталкивать необходимые улучшения модульной структуры, а здесь это суть гадание на кофейной куче и к процессу отладки относится мало. Большие размеры современных проектов — это объективная реальность, и эти размеры растут в последние годы очень быстро. Собс-но, для этого мы, программисты, и нужны, чтобы автоматизировать как можно больше аспектов человеческой деятельности.

Все они сравнимы по сложности с Emacs.

V>Сам этот заметный рост сложности проектов стал возможен только благодаря высокоуровневой поддержке ср-в разработки.

Да, разработка Emacs стала возможной благодаря Emacs.

T>>Дорогой друг, какое конкретно количество строк написал ты или любой твой коллега на любом ФЯ?
V>На Схеме несколько тысяч в своё время, включая сам мини-интерпретатор Схемы.
T>>Если это количество больше 100, я продолжу спор, но уже доказательно. Если меньше, то поверь мне на слово — ты не прав. Ты просто не в курсе, как нельзя накосячить на ФЯ.
V>Знаю, но ты не то называешь косяком. Т.н. "косяки", связанные с низкоуровневыми ошибками, типа проходу по памяти, — это самый низкий процент ошибок в современных проектах, к тому же, эти места легко вычисляемые.

Нет. Это ошибки типа "в этом if надо было проверить ещё и это условие".

Вот так в современном ФЯ (OCaml, Haskell, Clean) накосячить очень тяжело.

Схема не современный ФЯ.

T>>За более, чем 10 лет использования Хаскеля, я столкнулся всего с двумя ошибками: проблемы рантайма под windows в ghc 6.6 (ограничение сверху на хип) и, недавно, совершенно не критичная ошибка с отсутствие поддержки семейств типов в template haskell.
V>Поражает даже не кол-во багов на треккере GHC, а их характер. Можешь объяснить наличие большого кол-ва низкоуровневых багов в треккере, учитывая, что сам компилятор написан на Хаскеле?

Нет.

V>Т.е. ситуация такова, что сам этот момент у меня пока в голове не укладывается... Сам язык получился неплох, но от задумки до реализации, как известно...

Я пользуюсь, и ничего.

V>А помогать им с отладкой... было бы ради чего — там помимо низкоуровневых, куча ошибок и логического плана и даже вывода типов. Вообще, кол-во багов поражает. Я как-то нашёл баг для библиотеки ADO.Net под MS SQL CE, запостил, мне сказали спасибо, дык баг был единственный (!!!) на всю либу. Просто сценарий у нас был, прямо скажем, далеко не рядовой (выжималка процессорных тиков для около-ИИ-темы). И вот я со своими далеко не рядовыми сценариями (где надо выжимать максимум из железки) полезу в Хаскель, начну его "выжимать" и он однозначно начнёт сыпаться.

Алгоритмы надо выжимать, не железку.

V>Так что, к выбору инструментария у меня подход весьма прямолинейный — необходимо чтобы сам инструментарий не веселил своими причудами, ибо не до него.

Мы от разного хохочем.

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

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

T>Да, разработка Emacs стала возможной благодаря Emacs.

Да ради бога, хоть Emacs, хоть Eclipse, хоть VS. (Не принципиально, хотя, нормального context-sensitive intellicense я в Emacs ни разу не видел, или что-то изменилось за последние лет 8?)


T>Нет. Это ошибки типа "в этом if надо было проверить ещё и это условие".
T>Вот так в современном ФЯ (OCaml, Haskell, Clean) накосячить очень тяжело.

Опять намёк на алгебраические типы?
Понимаешь, там где в ФЯ используют алгебраические типы и паттерн-матчинг, в ООП юзают гомоморфные иерархии (в случае compile-time для C++ уже показывал). Так что, если придеживаться принципу Лисков, никаких "забытых" if быть не может в принципе, ибо нету в проекте этих if, относящихся к логике системы типов. Есть только те if, которые относятся к значениям данных, но тут нам ФП ничем не поможет.

V>>Поражает даже не кол-во багов на треккере GHC, а их характер. Можешь объяснить наличие большого кол-ва низкоуровневых багов в треккере, учитывая, что сам компилятор написан на Хаскеле?

T>Нет.

Зря, вопрос про низкоуровневость багов — ключевой. И я знаю на него ответ, но он тебе не понравится.

Есть такая наука о кач-ве ПО, так вот, ей глубоко плевать на ФП и на прочие технологии. Что характерно для аппологетов хаскеля на этом форуме, так это шапкозакидательсво и пренедрежительное отношение к коллегам. Некоторых даже банили за откровенное хамство. В реальной жизни поручить что-нибудь действительно важное разработчику, склонному к шапкозакидательству, это 100 раз подумать стоит. Если разработчик не понимает, что этапы анализа задачи и подходы, обеспечивающие кач-во ПО вообще не оперируют никакими технологиями, то такой разработчик, мягко говоря, под стол пешком еще ходит. Твоя реплика про "круги разводимых рук" была просто в точку, дальше можно было ничего не обсуждать.


V>>Сам язык получился неплох, но от задумки до реализации, как известно...
T>Я пользуюсь, и ничего.

Я не уверен, что ты используешь 100% возможностей языка, если, как ты сам говорил, ты его используешь в основном для утилит/экспериментов и т.д.

T>Алгоритмы надо выжимать, не железку.

А уже открыт другой способ выжимания?

Замечу лишь, что алгоритмы неотделимы от структуры данных. Иногда банальное уменьшение коссвенности вдвое даёт прирост вчетверо. Упомянутое особенно стало заметно последние несколько лет, всвязи с резким увеличением собственной выч. мощности процов относительно скорости внешней памяти. Как насчёт fixed-size arrays в Хаскель? Никак? А ты портируй, скажем, encoder speex на Хаскель (там сплошная математика, к тому же, тебе это небось пару вечеров) и замерь, что получилось. Обязательно сравни хотя бы на 4-х сотнях одновременно работающих этих кодеков, ибо вопрос использования памяти так же интересен (необязательно в разных тредах, просто по очереди чанки данных подавай для одновременно созданных объектов).

Мне даже его С-версию оптимизировать пришлось, ибо жрут кодировщики процессорные тики, это их фундаментальная природа.
Заодно мне интересно, сколько строк кода в итоге ты сэкономишь. А то сдаётся, что мы10%-20% при наилучшем раскладе, за счёт понижения производительности в разы. ИМХО, неприемлима пока эта цена в промышленных разработках.

ФП будет развиваться, это неплохая парадигма, которая (как и все прочие) хороша лишь на своём месте, а не в каждой дыре. Удачным станет тот подход, который в рамках проекта позволит гладко совмещать технологии (проекта с т.з. IT, а не компилятора). Предложенный сегодня способ безопасного совмещения — это интероперабельность на основе платформ Java и .Net. Хаскелю надо ветвиться в эту сторону, чтобы обрести возможность общение с внешним миром и стать полезным.

T>>Да, разработка Emacs стала возможной благодаря Emacs.
V>Да ради бога, хоть Emacs, хоть Eclipse, хоть VS. (Не принципиально, хотя, нормального context-sensitive intellicense я в Emacs ни разу не видел, или что-то изменилось за последние лет 8?)

Я тоже. Но я не видел его ни в какой другой среде.

T>>Нет. Это ошибки типа "в этом if надо было проверить ещё и это условие".
T>>Вот так в современном ФЯ (OCaml, Haskell, Clean) накосячить очень тяжело.
V>Опять намёк на алгебраические типы?
V>Понимаешь, там где в ФЯ используют алгебраические типы и паттерн-матчинг, в ООП юзают гомоморфные иерархии (в случае compile-time для C++ уже показывал). Так что, если придеживаться принципу Лисков, никаких "забытых" if быть не может в принципе, ибо нету в проекте этих if, относящихся к логике системы типов. Есть только те if, которые относятся к значениям данных, но тут нам ФП ничем не поможет.

Да брось ты!

При написании кода с глубоким заглядыванием наподобие нижеприведённого:

esimp (EMul a b) = case (esimp a, esimp b) of
    (EConst a,EMul (EConst b) c) -> esimp $ EMul (EConst $ a*b) c
    (EConst a,EMul b (EConst c)) -> esimp $ EMul (EConst $ a*c) b
    (a,b)
        | iszero a -> ezero
        | iszero b -> ezero
        | isone a -> b
        | isone b -> a
        | otherwise -> EMul a b

Ты замучаешься описывать это дело на системе типов C++. Либо жизнь на это положишь, либо будешь делать это в рантайме. И будешь ловить ошибки.

Или вот другой пример:

-------------------------------------------------------------------------------
-- Balin's pipelined sum acc.

balinF :: Maybe i -> Maybe i -> Maybe i -> (Maybe i,Maybe (i,i))
balinF oldAcc input loopback = (newAcc,output)
    where
        (newAcc,output) = case (oldAcc,input,loopback) of
            (acc,Just inp,Just lb) -> (acc,Just (inp,lb))
            (Just acc,Nothing,Just lb) -> (Nothing,Just (acc,lb))
            (Just acc,Just inp,Nothing) -> (Nothing,Just (acc,inp))
            (acc,Nothing,Nothing) -> (acc,Nothing)
            (_,inp,Nothing) -> (inp,Nothing)
            (_,_,lb) -> (lb,Nothing)

Сумматор имени Влада Балина aka Gaperton, функция автомата Мили. Что, сможешь сделать такую же таблицу решений? А в такое же количество строк?

V>>>Поражает даже не кол-во багов на треккере GHC, а их характер. Можешь объяснить наличие большого кол-ва низкоуровневых багов в треккере, учитывая, что сам компилятор написан на Хаскеле?
T>>Нет.
V>Зря, вопрос про низкоуровневость багов — ключевой. И я знаю на него ответ, но он тебе не понравится.
V>Есть такая наука о кач-ве ПО, так вот, ей глубоко плевать на ФП и на прочие технологии. Что характерно для аппологетов хаскеля на этом форуме, так это шапкозакидательсво и пренедрежительное отношение к коллегам. Некоторых даже банили за откровенное хамство. В реальной жизни поручить что-нибудь действительно важное разработчику, склонному к шапкозакидательству, это 100 раз подумать стоит. Если разработчик не понимает, что этапы анализа задачи и подходы, обеспечивающие кач-во ПО вообще не оперируют никакими технологиями, то такой разработчик, мягко говоря, под стол пешком еще ходит. Твоя реплика про "круги разводимых рук" была просто в точку, дальше можно было ничего не обсуждать.

Я не понял твоего абзаца практически совсем.

Он не несёт никакой информации. Что за наука? Что за шапкозакидательство? Бред какой-то.

Переведи его на нормальный язык.

V>>>Сам язык получился неплох, но от задумки до реализации, как известно...
T>>Я пользуюсь, и ничего.
V>Я не уверен, что ты используешь 100% возможностей языка, если, как ты сам говорил, ты его используешь в основном для утилит/экспериментов и т.д.

Да,я использую примерно 10-15% от всех возможностей Хаскеля. Языковых возможностей, конечно.

Сдались мне эти 100%. Мне ещё на что время потратить хочется.

T>>Алгоритмы надо выжимать, не железку.
V>А уже открыт другой способ выжимания?

Я не понял вопроса.

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

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

V>Замечу лишь, что алгоритмы неотделимы от структуры данных. Иногда банальное уменьшение коссвенности вдвое даёт прирост вчетверо. Упомянутое особенно стало заметно последние несколько лет, всвязи с резким увеличением собственной выч. мощности процов относительно скорости внешней памяти. Как насчёт fixed-size arrays в Хаскель? Никак? А ты портируй, скажем, encoder speex на Хаскель (там сплошная математика, к тому же, тебе это небось пару вечеров) и замерь, что получилось.

Нет, там не сплошная математика. Там математики всего ничего, в районе lsp.c. В том файле есть места практически квадратичные относительно lpcrdr (порядка lpcrdr*lpcrdr/2), да ещё и рекурсивно определённые, как я понимаю. Оный lpcrdr = 10 (lpcSize).

Для плавающей запятой это получается порядка 500 операций. Или ~3000 тактов. Параллелить смысла не имеет. Без распараллеливания Хаскель отстанет.

Я справился быстрее, чем за пару выходных. Но медленней, чем мне бы хотелось. И узнал о реализации speex больше, чем это нужно здоровому человеку. Ну, и ладно.

Вообще, speex написан плохо. Например, for (i=0;i<6;i++) без комментариев, объясняющих, что такое это 6. Функции длиной в 500-700 строк это не хорошо.

V>ФП будет развиваться, это неплохая парадигма, которая (как и все прочие) хороша лишь на своём месте, а не в каждой дыре. Удачным станет тот подход, который в рамках проекта позволит гладко совмещать технологии (проекта с т.з. IT, а не компилятора). Предложенный сегодня способ безопасного совмещения — это интероперабельность на основе платформ Java и .Net. Хаскелю надо ветвиться в эту сторону, чтобы обрести возможность общение с внешним миром и стать полезным.

Aye aye, sir!

Хаскель взял под козырёк и пошёл выполнять.

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

T>>>Да, разработка Emacs стала возможной благодаря Emacs.
V>>Да ради бога, хоть Emacs, хоть Eclipse, хоть VS. (Не принципиально, хотя, нормального context-sensitive intellicense я в Emacs ни разу не видел, или что-то изменилось за последние лет 8?)

T>Я тоже. Но я не видел его ни в какой другой среде.

А IntelliJ Idea ты видел?

http://www.jetbrains.com/idea/features/code_assistance.html