LINUX.ORG.RU

Создатель Python разочарован в Scala

 , ,


2

0

Гвидо ван Россум, создатель Python, в своем блоге делится впечатлениями от изучения языка Scala: "К сожалению, я полностью разочарован в этом языке". Причиной является слишком сложная система типов Scala: "Если такая система необходима для корректной обработки разных типов данных во время компиляции, я однозначно предпочту динамическую типизацию".

>>> пост

anonymous

Проверено: maxcom ()

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

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

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

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

> Ты не отходи от темы, давай пруфлинки.

За ними далеко ходить не надо: данный тред просто пестрит ими. Бегло пройдитесь по нему взглядом, если Вам не жалко своего времени, и получите пруфлинки. Мне же своего времени жалко. К тому же, Вы начнёте доказывать, что "заявления вовсе не оголтелые", "понятие оголтелости не формализовано", а вступать с Вами в очередной раунд демагогической схватки мне не хочется.

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

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

Эдакий Лисп-бой, гитлер-югенд Лисп-гвардии, продукт слепой пропаганды.

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

> Веселье начинается, когда Лисп обламывается об отсутствие нативного типа int64 и автоматически начинает использовать arbitrary-precision integer, в то время как Си спокойно продолжает вычисления с int64 независимо от платформы.

Что не имеет вообще никакого отношения к скорости самих вычислений.

>и так далее.


Памятник уже себе отлил?

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

> За ними далеко ходить не надо: данный тред просто пестрит ими.

Значит будет нетрудно привести. Давай.

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

> Что не имеет вообще никакого отношения к скорости самих вычислений.

Это ложь; арифметика с arbitrary-precision integers в разы медленнее, чем с fixed-типами. Честно говоря, я был несколько удивлён подобной демонстрацией Вашего незнания столь элементарных вещей. Полагаю, Вы сами сможете написать test-case, подтверждающий это.

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

>то ложь; арифметика с arbitrary-precision integers в разы медленнее, чем с fixed-типами.

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

>Честно говоря, я был несколько удивлён подобной демонстрацией Вашего незнания столь элементарных вещей


Кто бы говорил - сравнил вычисления примитивных типаов с вычислениями на массивах и что-то пытается этим доказать.

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

У меня нет ни малейшего желания (ни, тем более, времени) перелопачивать все шестнадцать страниц этого треда плюс три треда-сателлита ("Знатокам Лиспа-{1,2,3}), наполненные демагогией, провокациями, оскорблениями, пафосом, уходами от тем, подменами понятий, некорректными сравнениями и так далее. Сомнительное удовольствие.

К тому же, за вашими с mv дружными требованиями стоит очередная провокационная попытка уйти от темы обсуждения (в которой ваш лагерь терпит поражение) и вовлечь меня в очередные демагогические распри. Я на эту попытку поддаваться не намерен. Если Вам так надо пруфлинков, Вы найдёте их самостоятельно в достаточном количестве; это несложно, но потребует времени.

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

> Кто бы говорил - сравнил вычисления примитивных типаов с вычислениями на массивах и что-то пытается этим доказать.

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

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

На Си задача решается эффективно. На Лиспе - нет.

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

>У меня нет ни малейшего желания

По твоему заявлению:

> За ними далеко ходить не надо: данный тред просто пестрит ими.


И тут же ты заявляешь что надо перечитать все 16 страниц этого треда и еще три треда чтобы найти хоть одно - как-то эти два заявления неклеятся.

> К тому же, за вашими с mv дружными требованиями стоит очередная провокационная попытка уйти от темы обсуждения


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

Стиль твоей речи - безосновательная гипербола. Ты как персонаж анекдота: рыбонька дай пройти. "Если рыбонька значит щука -> если щука -> кусается -> значит собака, если собака значит сука -> "люди он меня проституткой обозвал!".


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

>Перестаньте, в конце концов, подменять понятия.

Вы в своем уме? http://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic

>и у Вас пропадёт и так уже небольшой шанс хоть как-то реабилитировать Лисп в глазах наблюдателей.


Лиспу не надо реаболитироваться в глазах наблюдателей - еще чуть-чуть тут вообще никто вас в серьез воспринимать не будет (если такие вообще остались).

>Сравнивалась эффективность решения _задачи_. Внутренние механизмы (примитивы, массивы и т.п.) в этом контексте никого не интересуют.


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

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

> совершенно естественно требовать потверждение данного заявления.

Как Вы сами заявили не так давно, "никто вам ничем тут не обязан доказывать". (http://www.linux.org.ru/jump-message.jsp?msgid=3285539&cid=3287549)

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

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

"В реальных практических задачах лиспер ВСЕГДА уделывает сишника, обратного за всю историю человечества не наблюдалось ни разу."
(источник: http://www.linux.org.ru/jump-message.jsp?msgid=3271707&cid=3277142)
"В соответствии с доктриной лиспа, другие языки не нужны." (http://www.linux.org.ru/jump-message.jsp?msgid=3271707&cid=3279709)
Краткий цитатник лисп-адептов: http://www.linux.org.ru/jump-message.jsp?msgid=3271707&cid=3281540

Но действия некоторых камрадов бывают почище слов. Чего стоит безрассудное ввязывание mv в вычислительный бенчмаркинг? Лично я расцениваю это как слепую попытку доказать превосходство Лиспа в области HPC. И это самый крайний, абсурдный вариант. Если бы речь зашла не о HPC, а о КИС, о веб-приложениях, о том же XML - на амбразуру бросились бы грудью десятки mv, и точно так же свернули бы себе шеи.

Кстати, то, что Вы начали интересоваться мотивами, и перестали интересоваться собственно предметом, само по себе интересно. Можно ли это рассматривать как признание того, что Лисп несостоятелен как язык для высокопроизводительных вычислений?

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

> если сейчас задачу решат одним вызовом нативного кода на лиспе - все будет в порядке?

Ради Бога. Но это будет означать, что сам по себе, без костылей, Лисп ничего не стоит.

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

Условия задачи подразумевались такими. Привести реализацию заданного алгоритма средствами языка, без использования специальных библиотек. Как, например, в данном случае запрещено было бы использовать библиотеку для статистических расчётов. А в случае бенчмаркинга на линейной алгебре - запрещены были бы вещи типа UBLAS и т.п.

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

>Условия задачи подразумевались такими.

Ах подразумевались. Кем подразумевались? Это что - такой метод построения тестов "я подразумеваю"? Как насчет границ? Поскольку тестируется вычислительная скорость языка - вполне разумно ограничится тестом который меряет исключительно эту скорость - овефрфлов значения это сравнение размеров примитивных типов - то есть посторонний фактор повлиявший на тест. Наличие unsigned long long - это просто частный фактор конкретного языка который отсутствует в 32битном лиспе - проводить сравнения не по единым принципам (а вычислительный тест должен быть реализован на примитивах в обоих случаях - с целью тестирования именно вычислительной скорости) это ж додуматься надо было до такой глупости.

r ★★★★★
()

Извините, что ввязываюсь в вашу высокопарую дискуссию. Разве это действительно важно, чтобы ВСЕ части проекта писались на одном языке? Это ведь бред хромой блохи. Сложная задача с высоким уровнем абстракции решается на Лиспе очень элегантно. Я не профессиональный программист и занят совершенно в другой области (реклама), но читать программы на Лиспе - одно удовольствие. Для меня одинаково непривычны, что Лисп, что Си, что Бреинфак. Но Лисп читается естественно и непринужденно.

А там, где он сливает по производительности Си и Ассемблеру, почему бы не использовать ассемблерные вставки? Или не дерьгать специальную библиотеку Си извне? Модобным же образом пишутся например веб-проекты на Питоне. Вся логика на питоне, где нужна оптимизация - Си.

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

Пишем DSL на Лиспе, бизнес-логику на написанном DSL. Когда это необходимо, пишем и оптимизируем отдельные участки (вычислительные, XML, работа с железом) на предназначенных для этого инструментах, технологиях и языках.

Поправьте, где я неправ.

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

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

Хреновй телепат - предупреждал даже не пытайся. А проблемы у тебя с русским языком. Ты заявил буквально следующее:

> ...оголтелыми заявлениями о тотальном практическом превосходстве Лиспа во всех областях программирования


>"В реальных практических задачах лиспер ВСЕГДА уделывает сишника, обратного за всю историю человечества не наблюдалось ни разу."


Между лиспом и лиспером разницу видим? Хреново что не видим.

>"В соответствии с доктриной лиспа, другие языки не нужны."


И что? Вполне здравая доктрина имеющая право на жизнь. Что в ней не так?

Третий линк - цитата себя любимого. Сам себя осуждаешь?

>Лично я расцениваю это как слепую попытку доказать превосходство Лиспа в области HPC.


Он тебе услугу оказал реализовал на лиспе предложенную задачу потому что у тебя самого знаний не хватает иначе бы ты не лез с такими вопросами. Так что расценивай это как услугу человека который _может_ человеку который _не может_.

>Можно ли это рассматривать как признание того, что Лисп несостоятелен как язык для высокопроизводительных вычислений?


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

dixi.

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

>Поправьте, где я неправ.

Ты везде прав.

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

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

> Третий линк - цитата себя любимого. Сам себя осуждаешь?


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

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


Вы же сами только что призывали не телепатствовать. Давайте дождёмся mv и спросим его самого, зачем он с таким упорством решал эту задачу, да не просто решал, а тщательно и долго добивался улучшения результатов.

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


То есть Вы де-факто признаёте, что решать сложную инженерную задачу на одном языке - абсурд и признак непрофессионализма?

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

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

Я сходил по ссылке - цитат о тотальном превосходстве не нашел. Опять вспомним анектот?

>Давайте дождёмся mv и спросим его самого, зачем он с таким упорством решал эту задачу, да не просто решал, а тщательно и долго добивался улучшения результатов.


Окаам ответит - потому что это перформанс тест?

> То есть Вы де-факто признаёте, что решать сложную инженерную задачу на одном языке - абсурд и признак непрофессионализма?


Нет. Я фактически утвеждаю, что _требование_ единственного языка для сложной инженерной задачи....

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

> Вы же сами только что призывали не телепатствовать. Давайте дождёмся mv и спросим его самого, зачем он с таким упорством решал эту задачу, да не просто решал, а тщательно и долго добивался улучшения результатов.

Исходя из своего опыта общения с sbcl, я знаю, что код он генерирует не слишком хуже сишного (потому что поддерживает очень много performance hint'ов из интеловского мануала по оптимизации), плюс довольно скромно работает с памятью. Вы с момента своего появления в этом топике и в его сателлитах в talks, взялись утверждать обратное. Возможно, мы вас все тут неправильно поняли, но это уже ваша проблема, что вас не так понимают окружающие.

Согласитесь, что для конкретной реализации языка сверхвысокого уровня 50 процентов разницы в скорости по сравнению с голым Си - это очень лестная характеристика? В реальной практике это означает мало того, что на Common Lisp можно в принципе решить очень сложную задачу, либо просто и без заморочек решить задачу обычной сложности, так полученная программа ещё и работать быстро будет.

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

> То есть Вы уже сами открещиваетесь от этих заявлений, и готовы признать, что Лисп не годится для чего-либо, отличного от написания DSL?

Ты, лопух, не понял главного - в свою очередь DSL-и годятся для всего. Соответственно, и Лисп годится для всего.

Я уже говорил, как должно выглядеть идеоматическое решение твоей дебильной задача на Лиспе - этот код должен генерить код на Фортране (или сразу на ассемблере) и исполнять его. А на входе - DSL, аналогичный тому же S+, например.

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

> Использование кодогенерации Си решит задачу, но ещё раз подчеркнёт несостоятельность Лиспа per se, и необходимость костылей.

Ты дебил. Именно такое применение Лиспа и является наиболее Ъ-пгавославным. Лисп - это метаязык.

> Вы бы ещё предложили ассемблерные вставки использовать.

Ты MuLisp видел (оно ещё на pc жило, под досом)? Там можно было раскрывать макры сразу в ассемблер. Оно и работало в результате быстрее тогдашнего борландовского си, при всей высокоуровневости Лиспа.

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

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

Во первых, Лиспов много разных, во вторых, отсутствие синтаксиса там не с просто так, а по делу - оно небходимо для метапрограммирования. Синтаксис - это вообще херня, его всегда при желании можно добавить в самый последний момент. То есть, нормальное применение Лиспа - это разработка DSL полностью в Лиспе, и как самый последний этап - прикручивание к этому DSL человекочитабельного синтаксиса.

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

> то насколько сложно сделать компилятор лиспа или может макроса достаточно (сам с лиспом не знаком, не знаю как лучше делать :) ), чтобы решение той задачи использовало int64?

Это и было бы единственно пгавославным решением, собственно. Задача Лиспа - генерить код, а не исполнять его.

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

> Оно и работало в результате быстрее тогдашнего борландовского си, при всей высокоуровневости Лиспа.

Ну ты и шутник :) У компиляторов фирмы Борланд/Инпрайз качество генерируемого кода - невообразимо ужасное говно, хоть топор вешай. Пожалуй, даже у байткодового лиспа есть шанс обогнать их по скорости.

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

Вставлю две копейки:

Честно говоря, я вообще не понимаю в чем спор --- в частном случае Lisp сливает в 6 раз, т.е. меньше чем на порядок. Все что меньше, чем на порядок --- полная фигня :)

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

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

А Джордано Бруно -- да :) Развеивает мифы, которых ни у кого нет :P

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

> Я полагаю, что Вы лжёте.

А я полагаю, что ты очень неграмотен и неопытен, деточка.

> Потому что "унаследованный код на Фортране" - это, как правило, вычислительные алгоритмы (числодробильня),

Много ты, деточка, знаешь, про унаследованный код. Значительная часть этого кода - это вообще Pro*Fortran оракловый (кто видел Pro*C поймёт, что это за отвратная гадость). Ничего вычислительного там нет вообще. Это код с тех времён, когда на Фортране писали вообще всё. Это сейчас он гордо занял полагающуюся ему нишу, в которой он рвёт в пух и прах всех, а раньше всё было гораздо запущеннее.

> Пристойно он себя показывает только в одной-единственной области - написании DSL- и eDSL-языков, но вряд ли в чью-то больную голову пришло бы создавать DSL'и на Фортране.

Не, ну разве не ламер? Этих DSLей на Фортране - вагон и маленькая тележка. Ну да откуда сявке знать, сявка варится в какой либо уебдевёлопёрской быдлоконторке, и думает, что имеет представление о том, как индустрия работает.

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

Мне так же приходилось (лет где-то пятнадцать назад) переписывать, не поверите, CAS, написанную на Фортране. Весьма мощный язык там был, кстати.

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

В то время особо альтернатив не было под досом. Экстендеров ещё не было (да и на кой они на 286?), ваткома не было, симантековский компилятор был ещё большим говном.

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

> одна - создание DSL/eDSL, что "элитарность" лисперов - дутая

Только вот DSL/eDSL делает как раз таки элита. И это - самый мощный подход к разработке софта, рядом с которым всякие там ООП сливают по полной.

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

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

> В то время особо альтернатив не было под досом. Экстендеров ещё не было (да и на кой они на 286?), ваткома не было, симантековский компилятор был ещё большим говном.

Да я не про то время (когда я в детсад ходил ;), а про практически наши дни. Довелось пару лет назад реверсить протокол, изучая бинарник, выплюнутый делфями. Это ужас, ужас... Там, например, для приведения dword->char вызывалась функция! И эта функция везде была заинлайнена для скорости... Досовый борланд си код генерировал даже хуже турбопаскаля. Полагаю, что в виндовой версии эта тенденция сохранилась. Не порвать такую гадость на перформанс тестах - это нужно постараться.

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

> В общем случае проигрыш в 6 раз и более.

А в моих задачах - выигрыш в 6 раз и более не редкость. И, что дальше?

> Это ложь. "Лисперы", отметившиеся в данном топике, настаивали на обратном - на превосходстве Лиспа в абсолютно всех областях программирования.

А так и есть. Просто ты, сявка, не понимаешь, как именно Лисп применяется. Не понимаешь, что это не просто язык, а метаязык.

> По-настоящему умный и интеллигентный человек никогда не заявит о себе такого.

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

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

> Довелось пару лет назад реверсить протокол, изучая бинарник, выплюнутый делфями.

А, ну так они с того времени деградировали, кстати. Раньше было не так плохо, как сейчас. Кстати, TC++ доступен бесплатно, под dosbox работает - если хочешь, можешь посмотреть, как тогда нам, бедным, тяжко жить было.

> Досовый борланд си код генерировал даже хуже турбопаскаля.

Да нет, так же - на сопоставимом коде, конечно же. Специфичные для Си приколы он иногда транслировал паршиво, но их можно и не использовать.

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

> Я полагаю, что дело в Вашей некомпетентности в Java и OCaml.

На Жабе я пишу с тех пор, как она стала называться Жабой. На SML, Caml и в последствии OCaml - ещё дольше. И вообще на любом языке я всегда напишу наиболее корректный с точки зрения культуры этого языка код.

> Либо Вы решаете исключительно задачи из того узкого класса, где Лисп проявляет себя хорошо (DSL/eDSL).

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

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

Что ты по этим примерам поймешь? На хеллоу ворлдах, быстрых сортировках и реализациях красночёрных деревьев все языки одинаковы. Разница в соотношении функциональности к объёму кода начинается на куда как более значительных масштабах.

Типичная для Лиспа архитектура - это реализация небольшого eDSL для конкретной задачи и описание решения задачи на этом eDSL. Я как-то не очень могу себе представить eDSL для хеллоуворлда или для быстрой сортировки (ну, последняя хорошо выглядит при наличии list comprehensions, так эта хрень на Лиспе делается тривиально, тогда как в других языках оно или есть из коробки, железно вшитое, или же его нет и не будет никогда).

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

> А, ну так они с того времени деградировали, кстати. Раньше было не так плохо, как сейчас. Кстати, TC++ доступен бесплатно, под dosbox работает - если хочешь, можешь посмотреть, как тогда нам, бедным, тяжко жить было.

Да что я, не видел, что ли? :) Винда у меня в жизни как-то эпизодически получилась, года на 2. Первый хлам с помойки даже 95-ю не тянул, а на новом, более-менее нормальном железе линукс быстро обосновался.

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

>Как и любой пгавославный лиспер, я глубоко убеждён, что DSL обязаны быть подмножеством eDSL

Дык все дело-то в том, что на лиспе абсолютно однохренственно DSL это или eDSL. Деревья, мать их, рулят. Да и к любому eDSL можно влегкую присобачить транслятор с DSL хоть с самым извращенным синтаксисом. Резултат-то будет один: дерево в памяти. В этом и есть самое кардинальное преимущество лиспа.

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

> в сфере high-performance computing не работал несколько лет

тогда почему вы ищете CL с fixnum'ами и тегами, а не возьмёте например LUSH http://lush.sf.net со встраиваемым Си и компилируемым Си-компилятором лиспом? Там и BLAS, и FFT, ЕМНИП, есть.

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

> Так и запишем: Лисп без ассемблерных вставок - пшик.

посмотри в исходники sbcl. Есть там ассемблерные вставки, генерируются всё тем же лиспом.

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

> Сравнивалась эффективность решения _задачи_. Внутренние механизмы (примитивы, массивы и т.п.) в этом контексте никого не интересуют.

чудовищнейшая чушь. Тогда самый крутой язык -- это H9Q+, потому что он "из коробки" одним символом решает самые распространённые задачи вроде хелловордов, квинов, и т.п. Ведь это так эффективно (или эффектно?), одним символом-то.
Вы решаете задачу, говорите об эффективности -- потрудитесь определить эту самую эффективность. Потрудитесь в решении отразить это требование к эффективности, которое потребует от вас (сюрприз, да?) понимания некоторых принципов, как устроена среда, в которой вы предлагаете решение. Без понимания этих принципов, как вы собираетесь обеспечивать эффективность? Чем именно?

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

>Краткий цитатник лисп-адептов: http://www.linux.org.ru/jump-message.jsp?msgid=3271707&cid=3281540

ну и что за самоквотирование вы тут привели? Что дескать, нет под лисп "графической отладки в исходных текстах, с историей команд и дополнением" ? Есть, SLIME. "Рефакторинг, профайлинг, тестирование" -- есть это всё. Пример простого юнит-тестирования есть в PCL. Есть и аналоги xTest. Что под лисп нет XML парсеров и XSLT/XPath/XQuery? Они есть, но не очень-то и нужны, как в Рефале не нужен отдельный парсер ибо Р-выражения, в лиспе аналогично S-выражения. А в узлах могут стоять не просто значения, а функции -- вот вам и язык запросов вроде XQuery. Не стоят гроша ломаного ваши ссылки и заблуждения.

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

> Как насчет границ? Поскольку тестируется вычислительная скорость языка - вполне разумно ограничится тестом который меряет исключительно эту скорость - овефрфлов значения это сравнение размеров примитивных типов - то есть посторонний фактор повлиявший на тест.

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

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

> взять исходники того же CERNlib, и подивиться на написанный на Фортране интерпретатор Фортрана.

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

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

> ой.. а там деревья разбора в массивах хранят?

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

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

> что на лиспе абсолютно однохренственно DSL это или eDSL

Дык. Разница только в том, есть ли у eDSL парсер для внешнего синтаксиса, а внутри они одинаковые.

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

Стек вообще может оказаться лучшим для исполнения. Взять тот же стековый байткод .NET или HTML, разобранный Stackish в форт-код.

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

> Стек вообще может оказаться лучшим для исполнения.

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

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

>>...а в шесть. http://s1.ipicture.ru/uploads/081127/vMOdAPU4Rf.png

>Ну я лично перепроверил, и выяснил, что тестирование либо просто проведено неправильно, либо намерянно сфальсифицированно. Я не только привёл свои замеры времени, но и дизассемблировал нужные куски кода, глядя на которые ясно, почему разница в 1.6 раз - это реально, а 6 - нет.

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

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

Господа-товарищи! Вы это... того... всех троллей распугаете таким своим поведением. Нельзя же так :)

anonymous
()

Что-то моё хаскелевское решение получилось медленнее сишного в 15 раз О_О
к сожалению, хаскель только начинаю изучать, поэтому не представляю пути ускорения программы 

module Main where 

import qualified Data.ByteString as B 
import Data.Word 
import System.IO 

size = 20 * 1048576 

bsum :: B.ByteString -> Word64
bsum = B.foldl' (\ a b -> a + (fromIntegral b)) 0 

countThings handle = do 
        ar <- B.hGet handle size
        let med = fromIntegral $ (bsum ar) `div` (fromIntegral size)
        let newar = B.map (\x -> x - med) ar
        B.hPut stdout newar 

main = withFile "/dev/random" ReadMode countThings

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

А Хаскель и не быстр. Быстр окамль.

http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=ghc&...

Похоже, у Хаскеля и с масштабируемостью тоже проблемы, судя по количеству тестов, которые "failed". И вообще, тут вроде обсуждалось "lisp vs другие языки". Хотя что-то после этого флуда мне и обсуждать-то стало неинтересно.

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