LINUX.ORG.RU

Lisp решение оказалось самым быстрым в ПФП2009


0

0

Из корректно отработавших программ Lisp решение самое быстрое --- 74с.

Ближайший конкурент на C# 153 с.

При этом решение написано полностью в духе Lisp --- стек eDSL.

Увы но жюри не осилившее по всей видимости такой подход к решению не присудило заслуженного I места :( Всех отправить на пересдачу SICP :)

Характерна строчка из таблицы (из обсуждения на форуме журнала) характеризующей Lisp решение среди прочих: «Lisp --- ХЗ какая логика».

Там же (в обсуждении) муссируется некое решение на питоне которое якобы быстрое «но вот беда некорректно решает примеры» :) Думаю что довести его до ума это задача, в ходе решения которой станет ясно почему подход с порождением цепочки eDSL является более продуктивным.

http://community.livejournal.com/fprog/11783.html

★★★★★
Ответ на: комментарий от lester

>есть задача - распарсить XML в 100Мб, причем сделать это быстро и без использования дополнительной памяти - покажите решение не на С/С++

уточню - быстро распаристь или быстро написать? Подозреваю первое, но так, на всякий случай =) Опять же: что вам надо - дом или что-то другое? Но в любом случае: конкретных предложений у меня нет, но, с учётом «жестких требований» по скорости/памяти, боюсь ничего и не будет, ибо появление любой более быстрой/маложрущей программы на «высокоуровневом» языке будет говорить о недостатках алгоритма сишной проги. И да: скорость+память важны, но это далеко не достаточные (а иногда и не совсем необходимые) условия при выборе «на чём писать»

yyk ★★★★★
()
Ответ на: комментарий от mv

>Если бы на хаскелле или лиспе программа получилась в 10 строчек и при этом ещё и работала корректно, то выиграла бы она.

Это похоже на конкурс однострочников «any vs. perl»: условия если не «дурацкие», то попахивают ангажированностью (хотя есть ещё APL семейство, не к ночи будь помянуто...)

yyk ★★★★★
()
Ответ на: комментарий от yyk

> уточню - быстро распаристь или быстро написать? Подозреваю первое, но так, на всякий случай =)

да - первое

И да: скорость+память важны, но это далеко не достаточные (а иногда и не совсем необходимые) условия при выборе «на чём писать»


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

lester ★★★★
()
Ответ на: комментарий от psv1967

> Ну не знаю, введение eDSL всегда упрощает работу с задачей

На чём основано подобное утверждение? Разных баек про eDSL я видел уже много, а вот практических примеров, демонстрирующих реальную эффективность подобного подхода, совсем мало.

Решение на СL по моему и продемонстрировало эффективность

такого фундаментального подхода к решению задач.



Хм, каким это образом, если у большинства возникли проблемы с его понимнием? Введение eDSL должно упрощать задачу, а на деле оказалось наоборот.

Да это именно «индустриальный» подход не для традиционной

«галеры с рабами»



В чём заключается его «индустриальность»?

Вопрос только в рынке задач такой сложности


Да задача ведь не сказать, что сложная.

Сейчас вся ИТ на уровне паровоза какого то работает.


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

archimag ★★★
()
Ответ на: комментарий от archimag

Введение eDSL должно упрощать задачу

почему-то распространено мнение, что использование стека eDSL автомагически делает жизнь проще. современный вариант религии ООП

jtootf ★★★★★
()
Ответ на: комментарий от archimag

>Как при чём? Если язык Common Lisp является более выразительным, чем VB (а это так), то и решение на Common Lisp должно быть более выразительным, ясным и простым.

Должно? ДОЛЖНО?!!!! Иди ты знаешь куда со своими долгами?....

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


ВОООТ. Золотые слова! =) Нашли лучшего. Заставьте его выучить ваш любимый язык и написать ту-же программу на нём. Или пишите теперь только на VB!

Языки создаются для людей: что бы одни писали, а другие читали и модифицировали, а не существуют сами по себе в вакууме.


Может всё-же признаем, что распространённость языка зависит от многих факторов, и далеко не все из необходимых являются техническими+простота использования?

Так вся претензия - мало используется?

Блин, не заипало рассказывать про количество мух, если сам в говне, при этом корчить из себя «илиту», если численный перевес на другой стороне?

Т.е. фактор человека является ключевым.


угу, для промывки мозгов

yyk ★★★★★
()
Ответ на: комментарий от lester

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

Отлично! Так что вы для себя вынесли из результатов оговариваемого конкурса в отношении тех или иных языков? Если вообще хоть что-то вынесли =)

yyk ★★★★★
()
Ответ на: комментарий от yyk

Спасибо!...

не за что

С этого места потерял к конкурсу последний интерес

ну, не стоит принимать мои слова так близко к сердцу :)

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

>современный вариант религии ООП

для тех кто в это верует - да =) Вот только верующих этих - единицы. А так - всему своё место.

И при том при всём, по-моему, вреда от _недораспространённости_ eDSL если и меньше, чем от _засилья_ ООП, то не намного

почему-то распространено мнение, что использование стека eDSL автомагически делает жизнь проще.


как всегда - в некоторых условиях. Другое дело, что границы эти [пока] чётко не очерчены (что уж про eDSL говорить, если границы применения ООП у каждого свои, а у иных их нет вовсе ;))

yyk ★★★★★
()
Ответ на: комментарий от archimag

> Хм, каким это образом, если у большинства возникли проблемы с его понимнием? Введение eDSL должно упрощать задачу, а на деле оказалось наоборот.

Упрощать задачу или её решение? Вы в самом деле к «понятности» apply-eval претензии будите иметь? То есть любой взаимный рекурсивный вызов для вас это «не понятный алгоритм»?

Если Вами написан для задачи интерпретатор или компилятор DSL то описанная данными задача на DSL должна в результате эффективно решаться. Какая разница что из логики в интерпретаторе, а что в DSL?

Более того этот процесс как было продемонстрировано можно производить этапами. Ну не пытаться сразу монолитный кирпич родить :) Ведь не все задачи примитивны как конкурсная.

В чём заключается его «индустриальность»?

В том что было не отквочено Вами далее по тексту. Не меняя продемонстрированного стиля можно любую практическую задачу решать силами одного - двух человек. Поясню: галера не нужна. Но её требуют, бо без нее «не понятно как все устроено» и «проблемы с пониманием» :)

Да задача ведь не сказать, что сложная.

Речь не о задаче из примера, а о продемонстрированном эффективном стиле решения задач на CL.

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

Это Вы о числе кнопочек настройки в какой то панельке КДЕ? :) И какие это «задачи» решают _программы_? Решает задачи программист пишущий программы. Ну и пользователь, если ему в руки хоть какой то DSL соизволили вручить.

psv1967 ★★★★★
() автор топика
Ответ на: комментарий от dave

Значит многое еще успеет. А недостаток увы быстро пройдёт.

psv1967 ★★★★★
() автор топика
Ответ на: комментарий от yyk

> Так вся претензия - мало используется?

Претензия к чему? Мало используется решение swizard? Или что мало используется?

Блин, не заипало рассказывать про количество мух


Я кажется про мух вообще никогда не заикаюсь. Вы о чём?

Т.е. фактор человека является ключевым.

угу, для промывки мозгов


Извините, так ещё в SICP написано, что программы пишутся в первую очередь для того, что бы их читали другие люди. У вас другое мнение?

archimag ★★★
()
Ответ на: комментарий от yyk

всему своё место

дело даже не в том, что всему своё место - если задача хорошо разбивается по уровням абстракции, то стек eDSL'ей там так или иначе будет уместен,- сколько в том, что спроектировать этот стек можно очень по разному. можно хорошо и прозрачно, а можно плохо и непонятно

jtootf ★★★★★
()
Ответ на: комментарий от archimag

>Извините, так ещё в SICP написано, что программы пишутся в первую очередь для того, что бы их читали другие люди. У вас другое мнение?

Нет, но нераспространённость лисп-языков мне _ничего_ не говорит об их «плохой читабельности». Это и к «мало используется» и к мухам в кучу.

yyk ★★★★★
()
Ответ на: комментарий от psv1967

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

dave ★★★★★
()
Ответ на: комментарий от archimag

У вас другое мнение?

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

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

>что спроектировать этот стек можно очень по разному. можно хорошо и прозрачно, а можно плохо и непонятно

замените «стек eDSL'ей» на «библиотека», «фреймворк» или ещё какой «баззворд» - что изменится?

Т.е. претензии не к «технологии», а к вероятному исполнению/исполнителю?

yyk ★★★★★
()
Ответ на: комментарий от psv1967

> Упрощать задачу или её решение?

Решение, конечно.

Вы в самом деле к «понятности» apply-eval претензии будите иметь?

То есть любой взаимный рекурсивный вызов для вас это


«не понятный алгоритм»?



Не понял фразу. Как и в каком контексте её надо понимать? У меня есть мнение о конкретном решении, при чём тут apply-eval и взаимная рекурсия?

В чём заключается его «индустриальность»?

В том что было не отквочено Вами далее по тексту.


Хм, мы с вами на одном языке разговариваем? Что означает слово «отквочено»? я не понял :(

Не меняя продемонстрированного стиля можно любую практическую задачу

решать силами одного - двух человек.



Из чего это следует? Вот решение на VB было короче и проще. Из этого следует, что на VB нельзя любую задачу решить силами одного-двух человек? Я честно не понимаю логики.

продемонстрированном эффективном стиле решения задач на CL.


Вообще-то, его эффективность как раз и не была продемонстрирована (если мы не о скорости говорим, конечно).

Это Вы о числе кнопочек настройки в какой то панельке КДЕ? :)


Смешно. При чём тут КДЕ? Или КДЕ это самый сложный известный вам проект?

И какие это «задачи» решают _программы_?


Все программы бесполезный мусор (вроде КДЕ)?

archimag ★★★
()
Ответ на: комментарий от yyk

> Нет, но нераспространённость лисп-языков мне _ничего_ не говорит

об их «плохой читабельности». Это и к «мало используется»

и к мухам в кучу



А зачем вы мне это рассказываете? Я что-то говорил о плохой читабельности лисп-языков? И при чём здесь опять мухи?

archimag ★★★
()
Ответ на: комментарий от jtootf

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

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

yyk ★★★★★
()
Ответ на: комментарий от yyk

претензии не к «технологии», а к вероятному исполнению

естественно. иными словами, CL имеет преимущество в задаче построения стека eDSL'ей, однако отсюда не следует преимущества в проектировании сложных систем

jtootf ★★★★★
()
Ответ на: комментарий от archimag

>А зачем вы мне это рассказываете?

да пытаюсь самым нелепым образом сказать, что

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


единственное, что должно остаться в этом топике ;) И без всяких «НО»! =)

yyk ★★★★★
()
Ответ на: комментарий от jtootf

>>редлагаю в цикле «на первый/второй расчитайсь» и вторым устраивать этот самый...

первый!


хм, если в итерациях не менять «порядок расчёта», то можно смело сказать, что «расчёт окончен» =)

yyk ★★★★★
()
Ответ на: комментарий от yyk

> да пытаюсь самым нелепым образом сказать, что

единственное, что должно остаться в этом топике ;)

И без всяких «НО»! =)



Ну так это ещё и редакция журнала отметила. Очевидная вроде вещь. Странная у вас манера общаться.

archimag ★★★
()
Ответ на: комментарий от dave

:-| да обозначает юмор, всем смеятсо 5 минут :-)

psv1967 ★★★★★
() автор топика
Ответ на: комментарий от archimag

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

В общем я сегодня еще не покушал свою порцию гороха, поэтому (согласно классике) продолжать просто не в силах (:

значение поразившего Вас термина читать здесь http://sp-computer.ru/glossary/fido/detail.php?ID=8383

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

psv1967 ★★★★★
() автор топика
Ответ на: комментарий от psv1967

Извините, мы с вами действительно на разных языках разговариваем, потому что чем больше вы говорите, тем труднее мне улавливать какой-либо смысл, увы :(

archimag ★★★
()
Ответ на: комментарий от archimag

я полностью разделяю Ваше мнение (и надеюсь что все слова в этом предложении понятны)

psv1967 ★★★★★
() автор топика
Ответ на: комментарий от archimag

>Ну так это ещё и редакция журнала отметила. Очевидная вроде вещь.

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

yyk ★★★★★
()
Ответ на: комментарий от yyk

> что не помешало вам сделать ряд «заявлений»,

которые многие могут сочти за провокационные.


Хм, и в чём их провокационность? Мне казалось, что я просто прокомментировал конкретное решение и указал, что согласен с редакцией журнала в оценке данного решения.

archimag ★★★
()
Ответ на: комментарий от lester

> есть задача - распарсить XML в 100Мб, причем сделать это быстро и без использования дополнительной памяти - покажите решение не на С/С++

http://www.dsource.org/projects/tango/docs/stable/tango.text.xml.Document.html

http://www.dsource.org/projects/tango/docs/stable/tango.text.xml.SaxParser.html

naryl ★★★★★
()
Ответ на: комментарий от naryl

Конечно, есть вариант, что за два года RapidXML допилили :)

naryl ★★★★★
()
Ответ на: комментарий от naryl

> Кстати, этот бенчмарк показывает, что RapidXML дох** лишней памяти потребляет.

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

lester ★★★★
()

А было ли представлено решение на BrainFuck?

proud_anon ★★★★★
()

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

WTF?

unnamed
()

Извиняйте, за то, что врываюсь в тред, а где можно почитать (кроме комментариев на ЛОРе) про eDSL и почему это так ДИКО КРУТО? SICP прошу не предлогать, если не отдельные главы.

oh
()
Ответ на: комментарий от lester

и без использования дополнительной памяти


Што это значит? JVM или .NET используют по-любому дополнительную память под свою машину

Karapuz ★★★★★
()
Ответ на: комментарий от oh

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

anonymous
()
Ответ на: комментарий от Karapuz

А, спасибо, я просто гуглом попал на educational DSL, что меня смутило несколько.

oh
()
Ответ на: комментарий от psv1967

после такой простыни вспоминается цитата из SICP про вопрос кандидату на должность о длине метода...

korvin_ ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.