Главная концепция common lisp

Примеры?

// Я не лиспер.

То есть фича не столько REPL, сколько SLIME.

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

Archimag имеет в виду не REPL, а возможность компилировать в рабочий REPL функции по отдельности.

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

Для других языков так делать тоже никто не мешает

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

http://benchmarksgame.alioth.debian.org/u32q/program.php?test=mandelbrot&...

Ух епт... Lisp-колдун 80 уровня детектед.

Чем REPL лиспа отличается от REPLа всех других языков? Python, Ruby, groovy, scala, etc?

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

То есть фича не столько REPL, сколько SLIME

Причём, как я уже указывал, разработчики xcvb (а также разработчики Racket) считают это вредной фичей. Потому как легко позволяет получать невоспроизводимые образы в стиле «3 функции скомпилированы со старой версией макроса и 2 с новой и это единственная рабочая комбинация».

Это не говоря уже про мелочи типа

(defpackage foo (:use cl))

(in-package foo)

(defun bar () 1)
(export '(bar))

На SBCL при повторной загрузке файла даёт warning, а если файл загружается через ASDF, то error

Нужен образ такой, как в Common Lisp или Smalltalk

Тогда и разработка должна быть не от файла, а от образа.

Примерно так: http://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/ibcl/

Там можно прямо код генерировать явно, а потом запускать?

Ну то что вы сказали хотя бы ответ, а не то что archmag голословно пишет

Lisp-колдун 80 уровня детектед.

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

Тем не менее стандартные 3-4 раза отставания по скорости от C++ тоже не так плохо

Там можно прямо код генерировать явно

Ага. #define и template

:-)

Ладно посмеялись и хватит. Главная концепция haskell и прочей функциональщины - в чем?
cast quasimoto

То, что archimag пишет, прямо подразумевает наличие живого образа, без которого невозможна по-настоящему интерактивная разработка. Тут нужен не просто динамический язык, а целая система с прямой поддержкой интерактивной разработки на уровне самого языка. Среди популярных платформ, насколько я знаю, такое есть только в Common Lisp и Smalltalk, причем последний ушел еще дальше, но на мой взгляд даже через чур.

Тут статически типизированные языки пролетают. REPL для них - просто игрушка.

И я думаю, что вы разговариваете с archimagom немного на разных языках, делая разные предположения об уровне знаний друг друга. Отсюда некоторое непонимание. Обычное дело.

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

А ныне популярные динамические языки нацелены преимущественно на скриптование (веб, системные утилиты), хотя встречаются и проекты-переростки на них. А раз скрипты, то работа с образом им не нужна, а значит, тоже нет настоящей интерактивной работы и нет настоящего REPL.

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

А образ-то зачем нужен? Его наличие/отсутствие никак на ход разработки не повлияет же. Отсутствие даже упростит - т.к. гарантирует от глупых ошибок.

Ты лучше вот сюда посмотри, да - http://www.youtube.com/watch?v=CsFUUELuUpY

медленно без него, но «рождённый ползать не поймет пилота» :)

Теперь тема забаненного петросяна восстановлена. Лоровцы на радостях продолжали пить на теле поверженного врага и глумиться. Development — сириус бизнес.

медленно без него

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

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

Development — сириус бизнес.

Спасибо за хорошее настроение.

Ну можно хотя бы 1 пример «работы с образом»?

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

писал уже 20 раз, любая сессия в R это работа с образом. ты работаешь не с кодом, а с реализациями кода в образе.

Ну ссылку можно на хотя бы 1 пример? Это должно быть описание вроде:

«в своем воркфлоу я делаю Х Y и Z и это удобно и круто. А без образа я бы не мог этого делать».

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

когда переходишь к подходу с запуском кода быстро понимаешь _насколько_ быстро.

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

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

А, ну то есть любой язык с реплом = язык с образом. Тогда ок.

замечу, еще как замечу.

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

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

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

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

еще раз --- разница в работе с образом и без достаточно значительна что бы ей пренебрегать.

... + он и сохраняется между сессиями. что весьма удобно.

А с Python проблема в том, что структура модулей там прибита к файловой системе.

Лучше не говорить о том, в чем не разбираешься.

Просветите тогда пожалуйста.

Иерархию пакетов можно колбасить в рантайме не говоря уж о http://www.python.org/dev/peps/pep-0302/

Ты бы прежде чем глупости говорить вникал что ли о чём идет речь.

структура модулей там прибита к файловой системе.

Ы?

Не мычи. Попробуй сконцентрироваться и выразить свою мысль на русском языке.

https://github.com/xando/github_import

http://benchmarksgame.alioth.debian.org/u32q/program.php?test=mandelbrot&...

Лол, вот это эпик. Три страницы нечитаемой маргинальной лапши vs. одна страница ясного, понятного кода на Си. И при этом слив в 3 раза по времени!

В этом весь лисп.

Главная концепция haskell и прочей функциональщины - в чем?

Функциональное программирование — это: типы как объекты, каррированные функции как стрелки, HOFs как экспоненциалы, чистота, ссылочная прозрачность, аппликативность и свободные (при совпадении доменов-кодоменов) композиции, equational theory settings / reasoning как следствие, в терминах ТК, в том числе, начальные алгебры / финальные ко-алгебры как фреймворк для описания индуктивных рекурсивных данных (как выход - результаты, значения) и ко-индуктивных ко-рекурсивных потоков данных (как вход); функторы, монады, Kleisli категории - многие индуктивные [возможно] рекурсивные типы данных которые функторы (начиная с Identity, Maybe и List), также, обычные суммы, произведения и степени, то есть кортежи/записи, объединения/варианты и функции - writer, error и reader/environment, для функций более специального вида - prompt, parser, state и cont, par/conc/async как cont для fork/join/io/done языка; функторы, ко-монады, coKleisli категории - ко-индуктивные ко-рекурсивные типы данных которые функторы (простейшие потоки и деревья, например), те же произведения и степени (суммы?), указатели и изменяемые подструктуры (линзы, как функции в), зипперы; свободные монады вокруг типов данных которые функторы - iteratees (которые сами по себе потоки, то есть финальные коалгебры для соответвующих (строго-позитивных таки) функторов), разные языки (eDSL на ADT) и их интерпретаторы; ко-свободные ко-монады для типов данных которые функторы - ?; (под)категории и стрелки - линзы (категория, тензор, но не вполне стрелка), обычные функции, Kleisli стрелки, coKleisli стрелки, стрелки biKleisli категорий, функции ограниченные типом - списки-в-списки, потоки-в-потоки, деревья-в-деревья, сигналы-в-сигналы и поведения-в-поведения (как оно применяется в FRP) и т.п., автоматы, симуляции, преобразователи, некоторые языки-eDSL-на-ADT, опять же; монадические трансформеры как определённого вида натуральные трансформации для определённого вида функторов над разными монадами - WriterT, ErrorT, ReaderT, StateT, ContT, MaybeT, ListT и т.д., например, ReaderT (ConstEnvironment, MutableScope, Resources) IO - эффекты, injectable read-only / write окружение, список ресурсов пополняемый их захватами по мере выполнения и автоматически освобождаемый в конце; полугруппы, моноиды, сворачиваемые и обходимые типы и т.п. категорные и алгебраические типы и классы как «паттерны» и средства декомпозиции.

Ну продолжай строить из себя дурачка, ок.

Он сегодня в неадеквате. Сейчас тебя спросит к чему эта ссылка.

Да забей ты на этого упоротого. Смысл спорить с фанатиками?

Смысл спорить с фанатиками?

С фанатиками чего? Смысл утверждения был в том, что например для Ruby можно создать полезный REPL, а для Python его возможности в любом случае сильно ограниченны.

Почему-то почти всегда, когда я вижу в трекере Лора тему про лисп, то ник ее автора зачеркнут.

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

А зачем это делать?

образ + репл снимают нагрузку с мозга и позволяют вести инкрементальную разработку,

Так зачем образ-то?

еще раз --- разница в работе с образом и без достаточно значительна что бы ей пренебрегать.

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

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

Для инкриментальной разработки нужен репл. А образ - нет.

... + он и сохраняется между сессиями. что весьма удобно.

Так есть исходники, которые полностью синхронизированы с образом.

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

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

тебе сказали, генерить все из исходников слишком _долго_.

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

вообщем господин теретик теоретизируйте о вкусах апельсинов дальше...

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