Lisp: с чего начать?

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

я не знаю. Зависит от задачи. И да, оно может на низком уровне тебе массив сделать, который ты будешь считать списком. Потому такая говносинтетика как на говнохабре может показывать удивительные и парадоксальные результаты. Например поиск в списке за O(1). Кнут писал, что это невозможно. И был прав, потому-что то, что ты видишь как «список» на самом деле никакой не список.

В итоге, я-бы очень НЕ рекомендовал доверять синтетике, особенно на говнохабре. В сишечке можно ещё objdump сделать, и посмотреть, а вот тут — в клубе лордов верят на слово.

Хмм. А что-нибудь известное, кроме емакса, на лиспе есть?

Ну и что это меняет?

это меняет только то, что твой тестовый пример из 10 чисел будет работать 100мс, а реальный на 1000 чисел будет работать три часа.

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

для gcc нет тут никакой разницы. Я в цикле считаю, так оно понятнее. А мой компилятор это из цикла выносит, так оно быстрее.

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

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

А что-нибудь известное, кроме емакса, на лиспе есть?

конечно! Over9000 разных лиспов.

Все зависит от объема данных. Чтобы массив у тебя начал сливать дереву даже для вставки - надо постараться. А вот время доступа вполне ощутимо в любом случае. Так что таки все зависит от задачи и нужны разные структуры данных...

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

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

А вот время доступа вполне ощутимо в любом случае.

не в любом. Очень часто достаточно последовательного доступа. А для этого все структуры хороши. Но вот на вставках массив часто тупит.

Так что таки все зависит от задачи и нужны разные структуры данных...

с этим глупо спорить.

а что сейчас вообще пишут на лиспе?

Факториал. Числа Фибоначчи. Еще, говорят, некоторые пытались «Hello, World» написать, но что-то у них не вышло.

Я скачал и установил. И что?

: (* 10.5 2) -> 22

В общем, оказалось там есть только целочисленные бигнумы.

RTFM:

: (scl 2 )
-> 2
: (format (* 10.5 2) 2)
-> "21.00"

PicoLisp - это не числодробилка, а очень продуманный и современный лисп. Я думаю, что для Computer Aided Translation он будет весьма удобен. Но увы, для того чтобы оценить его нужно довольно долго с ним поиграться. Если тебе для CAT нужна плавающая запятая ?!? - возьми схемку или CL.

То что автор идиот тут ясно. Сделал свою реализацию лиспа в школе - отлично.

В общем правильно, только:

• не свою - а сделал форк лиспа разработанного для Apple Macintosh в 1980-х годах;
• и не в школе, а во время исследований, начиная с 1988 года;
• и разоблачениями в статье даже не пахнет;
• и идиот не автор, а тот кто, не осилив заглянуть в документацию или википедию, лжет на лоре, без малейшего повода оскорбляя уважаемых людей, приносящих пользу сообществу

В SBCL невозможно выкинуть ту часть рантайма, которая не используется. Можно только сделать образ всего лиспа и указать функцию, которая будет вызвана при запуске. При этом бинарник можно сделать меньше каким-нибудь gzexe

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

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

Чтобы распознать что в файле строка не последняя делаю сдвиг - первая итерация проверяет на конец, вторая - парсит и collect.

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

Не помню, есть ли там проверка на конец файла, но как минимум это можно сделать 2 способами, не двигая курсор:

(peek-char nil *stream* nil :eof)

(= (file-position *stream*) (file-length *stream*))

emacs на C вроде. А может на C++

Как это? Печатающий Привет мир! машкод так сильно привинчен к рантайму?

Если sbcl дизассемблирует, то может, наверно, и блоб подать. От блоба без рантайма вообще никакого толка?

Давай по порядку.

PicoLisp - это не числодробилка, а очень продуманный и современный лисп.

Но увы, для того чтобы оценить его нужно довольно долго с ним поиграться. Если тебе для CAT нужна плавающая запятая ?!?

То есть ты называешь язык, где нет floating point современным? Напомню, что стандарт IEEE 754-1985 вышел, как ни странно, в 1985 году. И поддержка floating point есть с тех пор в каждой железке (кроме некоторых микроконтроллеров).

Я думаю, что для Computer Aided Translation он будет весьма удобен.

На языке, для которого нет даже обертки для GTK, и в котором предлагают использовать некую приблуду gtk-server

и разоблачениями в статье даже не пахнет;

Как иначе назвать весь тот бред, который наш исследователь там понаписал:

1)

Но мы утверждаем, что в повседневной жизни хорошо спроектированный «интерпретатор» часто может превзойти скомпилированную систему.

2) Использование clisp (пожалуй, самой медленной из хорошо известных реализаций CL) как некоторого «эталона» для сравнения и делание каких-то выводов из этого

3)

Предыдущие версии Pico Lisp экспериментировали с хэш-таблицами и самобалансирующимися двоичными деревьями для хранения свойств, но мы обнаружили, что обычные списки более эффективны.

Да, когда свойств 3. Или 5. Тут уже было вызвано опасение, что и сами символы хранятся в списках. Я не удивился бы

3) Оправдание отсутствия lexical scope «мощью динамического связывания». Введение транзитных символов как лишней сущности

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

Уважаемых кем? О каком сообществе идет речь? Я вижу только 3.5 анонимусов в собственном соку

лжет на лоре

Автор лжет без зазрений совести, почему мне нельзя?

От блоба без рантайма вообще никакого толка?

Там есть функция sb-ext:save-lisp-and-die. Она делает образ (причем может делать его запускаемым как stand-alone исполняемый файл), но образ этот содержит sbcl «как есть», а не только твою функцию. В принципе можно сделать так, чтобы запустить там какой-нибудь swank сервер и работать через него с твоим образом как с полноценным лиспом.

Как это? Печатающий Привет мир! машкод так сильно привинчен к рантайму?

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

Как это? Печатающий Привет мир! машкод так сильно привинчен к рантайму?

Применительно к ПМ уже делали с уменьшением размера до килобайтов (по слухам). Но к внутреностям SBCL нет стабильного, описаного интерфейса и они время от времени меняются. И понять глядя извне куда именно нужно лезть сложновато.

Да ну горячая замена.

Наверно что-то более насущное, типа сборщика мусора.

Горячая замена и уборка сами по себе не мешают. Вопрос в неописаности внутреностей кода инициализации и загрузки.

Начни с выбора IDE, хотя и выбирать не из чего...

Сборщик оттуда никак не отделить и он маленький

Применительно к ПМ уже делали с уменьшением размера до килобайтов (по слухам)

Информ-агенство «Одна бабка сказала»?

Код tree-shaker-а для SBCL до сих пор лежит в сети. Завязан на старую версию. Если есть какая-то собственая конкретика то я буду рад ее выслушать.

Оно и в контрибах лежит:

* a too-alpha-to-be-supported-yet tree shaker

По слухам, это именно тот инструмент, который даст вам килобайты

Хотя это с initial revision в README. Не факт, что сам tree shaker там есть.

Ну в той степени в которой я понимаю его исходники это он и есть.

Его там нет.

Зато вот, что я нашел:

http://jsnell.iki.fi/blog/archive/2005-07-06.html

Был не прав - сжать ему удалось, но то что рабочего tree shaker'а под SBCL как не было, так и нет, это не отменяет, увы.

То есть ты называешь язык, где нет floating point современным? Напомню, что стандарт IEEE 754-1985 вышел, как ни странно, в 1985 году. И поддержка floating point есть с тех пор в каждой железке (кроме некоторых микроконтроллеров).

Тебя не удивляет что на ни на одной новейшей ракете нет колес, которые человечество придумало лет так тысяч 20 назад? Если недостаточно десятичных дробей с практически любой точностью, вызови внешнюю библиотеку или возьми с/фортран/схемку

Я думаю, что для Computer Aided Translation он будет весьма удобен.

На языке, для которого нет даже обертки для GTK, и в котором предлагают использовать некую приблуду gtk-server

А каким образом обертка для gtk поможет в написании автоматического переводчика? Тут нужна как минимум приличная база данных (+ ORM), наверное не помешает иметь что то типа встроенного пролога и удобной IPC. У PicoLisp все это реализовано средствами языка. А гуеый клиент можешь хоть на дельфях или кутях минут за 15 сваять. Или вообше www-браузер использовать.

Оправдание отсутствия lexical scope «мощью динамического связывания». Введение транзитных символов как лишней сущности

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

Как иначе назвать весь тот бред, который наш исследователь там понаписал

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

Но мы утверждаем, что в повседневной жизни хорошо спроектированный «интерпретатор» часто может превзойти скомпилированную систему.

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

Но, наверное, тобой имеется ввиду скорость? Тогда посмотри сюда: Функциональная языкометрия (комментарий)

Здесь медленный PicoLisp+gmp уделал по скорости связку С+gmp в 4 (четыре) раза на классическом вычислении факториала.

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

Ты прав. Так оно и есть. Более того все объекты языка - списки (более точно cons-пары). Так что о проблемах сегментации динамической памяти можно спокойно забыть.

Уважаемых кем?

Почитай отзывы коллег http://www.mail-archive.com/picolisp@software-lab.de/

О каком сообществе идет речь?

Open source community. Или, как минимум. сообшество лисперов.

Автор лжет без зазрений совести, почему мне нельзя?

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

Тебя не удивляет что на ни на одной новейшей ракете нет колес, которые человечество придумало лет так тысяч 20 назад?

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

колесо != подшипник

колесо != велосипед

С этим поспорить трудно.

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

Ты заврался, баран. Никто не мешает компилятору так же иметь полный доступ к коду. Смотри на HotSpot или на v8 - они одну и ту же функцию могут много раз по разному перекомпилировать.

А каким образом обертка для gtk поможет в написании автоматического переводчика? Тут нужна как минимум приличная база данных (+ ORM), наверное не помешает иметь что то типа встроенного пролога и удобной IPC. У PicoLisp все это реализовано средствами языка. А гуеый клиент можешь хоть на дельфях или кутях минут за 15 сваять. Или вообше www-браузер использовать.

Ололо. CAT без гуя, фотошоп без гуя, браузер без гуя. Все это можно сделать на picolisp!

Тебя не удивляет что на ни на одной новейшей ракете нет колес, которые человечество придумало лет так тысяч 20 назад? Если недостаточно десятичных дробей с практически любой точностью, вызови внешнюю библиотеку или возьми с/фортран/схемку

Только почему-то на большинстве процов тратятся миллионы транзисторов именно под floating point.

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

Как будто в CL нельзя в строку документации записать любой код к любой функции.

PicoLisp+gmp

Напомнить тебе, что gmp написана не на picolisp?

Более того все объекты языка - списки (более точно cons-пары). Так что о проблемах сегментации динамической памяти можно спокойно забыть.

Ну-ка растолкуй связь.

Ты прав. Так оно и есть.

Ну приехали.

Open source community. Или, как минимум. сообшество лисперов.

Я считаю, сообществу лисперов класть на ваш пиколисп

Как будто в CL нельзя в строку документации записать любой код к любой функции.

Именно в CL есть более удобные средства. А все подряд в стрку документации пихают схемщики.

А какие? Мне просто никогда не надо было, и я не интересовался

Выкинь все из молодой головы и пиши на С.

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

Ты заврался, баран.

Если нет аргументов переходим на личности?

Тьфу, блин. Я думал ты мне хочешь про реальный инструмент сказать, а ты про property list'ы. Открыл Америку

Ты дурак? Про slime не слыхивал? Открыл исходник, правишь и заменяешь

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

Бла-бла-бла. А что-то умное сказать слабО?

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

Тебя еблом ткнули в два ну очень не-редких примера, где именно так и делается: JVM и v8.

Всяко лучше чем совать все подряд в строку документации вместо это й самой документации

Верно

Ололо. CAT без гуя, фотошоп без гуя, браузер без гуя

Деление на клиент и сервер в твоем вузе еще не давали?

Только почему-то на большинстве процов тратятся миллионы транзисторов именно под floating point.

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

Как будто в CL нельзя в строку документации записать любой код к любой функции.

Теоретик? Забыл что компилятор выкинет комментарии?

Напомнить тебе, что gmp написана не на picolisp?

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

Более того все объекты языка - списки (более точно cons-пары). Так что о проблемах сегментации динамической памяти можно спокойно забыть.

Ну-ка растолкуй связь.

Если ты выделишь много раз память для объектов размером Х байт, потом удалишь парочку из этих объектов в произвольном месте, то хоть у тебя и останется 2*X свободного места, но разместить там объект размером 2*X ты не сможешь. У PicoLisp все объекты одинаковой длины и эта проблема не может возникнуть в принципе.

Я считаю, сообществу лисперов класть на ваш пиколисп

К счастью, ты пока не принадлежишь к онному и твое мнение, увы, не слишком весомо.

Ты прав, слово редкое здесь излишне

Деление на клиент и сервер в твоем вузе еще не давали?

Очень умный комментарий.

вузе

Вот таких идиотов там и делают.

Процессоров без этой радости более чем достаточно, стоят они копейки и производят их тоннами

Ну да, только они не для ПК, лол.

Кстати, тебя не удивляет, что в ядре floating point не видать?

На нафига оно там сдалось, обмудок (ой, прости, вырвалось)?

Теоретик? Забыл что компилятор выкинет комментарии?

Я практик, а ты эталонный идиот.

http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node229.html

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

Расчеты ведет программа (библиотека) на C. Время исполнения кода на пиколишп примерно 5% от общего. Значит, си должен быть настолько медленнее пиколишп, что это прям открытие. Там, случайно, sleep не было?

Если ты выделишь много раз память для объектов размером Х байт, потом удалишь парочку из этих объектов в произвольном месте, то хоть у тебя и останется 2*X свободного места, но разместить там объект размером 2*X ты не сможешь. У PicoLisp все объекты одинаковой длины и эта проблема не может возникнуть в принципе.

Пиколисп предлагает здесь революционное решение. Он как бы говорит нам: «Я размещу первую ячейку в начале кучи, а вторую - в конце. Локальность данных? Не, не слышали.» Остаётся только удивляться, зачем придумывали всякие buddy memory allocation, вёдра, перемещающие GC

К счастью, ты пока не принадлежишь к онному и твое мнение, увы, не слишком весомо.

Да я, бля, мог бы считаться его центром за то, что несу просвещение таким невеждам как ты. (Эк меня понесло)

Твоё предложение грамматически похоже на

«Водить машину славно всем забавно»

Просто удивительно, практически в каждой строке ругань. Слабо через слово мат лепить?

не для ПК,

Ты утверждал про большинство процессоров. Про ПК речи не было

На нафига оно там сдалось

Рад что до тебя дошла моя мысль

Расчеты ведет программа (библиотека) на C. Время исполнения кода на пиколишп примерно 5% от общего. Значит, си должен быть настолько медленнее пиколишп, что это прям открытие. Там, случайно, sleep не было?

Ты ж у нас Практик! Ссылку тебе дали. Там код для обоих языков приведен. Сверху обисание задачи. Вот и разберись в десятке строк, что да как. Это для твоего продвинутого интеллекта не сложнее, чем на форумах ругаться. Удачи.

Сорри, пропустил кавычки вокруг «редкое»

Пиколисп предлагает здесь революционное решение.

Ну так и статья называлась «Radical approach» :-)