В чём плюсы image-based разработки?

В чём плюсы image-based разработки?

Для меня это интерактивная разработка.

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

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

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

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

По-моему, ты смешал image и «live REPL». Насколько я понял, по крайней мере ракетчики разделяют эти понятия.

Каникулы. Дни лиспа на ЛОРе.

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

Вот как у меня щас: два раза конпеляцию с деплойментом прогнал за день, всё, пора домой. И то, подзадержался.

Опа, спрыгнул с С-интерпрайза?

Как раз это ты и сказал.

Чем жирнее проект, тем быстрее скорость разработки в image-based среде. Фактически, перекомпилировать/перезапускать всё нужно, когда образ foobar (fucked up beyond all repair) оказался.

А что вообще подразумевается под «образом»? Если состояние интерпретатора - то он есть в любом ЯП с реплом. Если возможность скинуть состояние в файл - это просто не нужно, даже вредно.

Опа, спрыгнул с С-интерпрайза?

Нет, это про него. 2.5 часа собирается, 1.5 деплоится.

А что вообще подразумевается под «образом»?

Процесс (память + состояние).

Если состояние интерпретатора - то он есть в любом ЯП с реплом. Если возможность скинуть состояние в файл - это просто не нужно, даже вредно.

Это, считай, как core dump, только живой.

Процесс (память + состояние).

Ну то есть это есть везде, лисп тут совсем не уникален.

лисп тут совсем не уникален.

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

Точнее не так. Нет _удобной_ возможности. Просто подменять функции на ходу можно в erlang. Причём отсутствие явных циклов (только tail-recursive) позволяет менять выполняемую функцию. Закачал, применил, со следующей итерации уже новая версия. Можно в Java через classloader. Можно в том же Racket, если это функция текущего модуля.

Но вот исправить функцию в файле, ткнуть «перекомпилировать функцию» и не быть обязанным _перезапускать_ REPL иногда бывает удобно. Для экспериментов. Если с трудом представляешь, что должно попадать к ней на вход. Тогда можно в несколько итераций довести функцию до состояния «типа работает».

Можно в том же Racket, если это функция текущего модуля.

В Racket можно все так же как в CL, только надо сделать (enforce-module-constants #f). Гейзер так и работает.

Но вот исправить функцию в файле, ткнуть «перекомпилировать функцию» и не быть обязанным _перезапускать_ REPL

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

В Racket можно все так же как в CL

Там только (save-lisp-and-die) нету.

Гейзер так и работает.

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

По-моему, ты смешал image и «live REPL». Насколько я понял, по крайней мере ракетчики разделяют эти понятия.

Не только я один, но в lispworks тоже «смешали».

Кроме того, что image-based хреново работает со стандартными средствами командной строки — ничего.

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

Приведи подробный пример для Scala, пожалуйста. Что ты имеешь в виду под этим?

Автор делит языки программирования на «живые»

Интересно, кому-нибудь нужна живая стиральная машина?

кому-нибудь нужна живая стиральная машина

На linux.org.ru всем нужна _свободная_ стиральная машина :-) Пусть будет мёртвая, но свободная!

Штольман, Швабодка, Штирка!

Пусть будет мёртвая, но свободная!

Надо положить на неё учебник по квантовой механике. Information would set you free!

Information would set you free!

Arbeit macht frei!

Да. Но я не могу придумать для него ни одного юзйейса, так что нет - и не надо.

Гейзер не умеет перекомпилировать в точке останова.

Это да, чтобы умел - надо дебагер к нему прикручивать.

Приведи подробный пример для Scala, пожалуйста. Что ты имеешь в виду под этим?

Пишем в репле определение функции, потом пишем новое определение функции. Все работает же?

Даже в статически-типизированных типа хаскеля ...

Тут же говорят про ф-ию, или есть способ? А то ведь ":load" _для модуля_ (1). А важнее, что _состояние repl нарушается_ (2): let - привязки теряются.

Но может есть другая команда / альтернатива ghci?

На игрушечных проектах... Этого мало.

Все работает же?

Сам по себе REPL (scala(1)) в смысле пригодности для monkey patchingа там не работает. Например:

scala> def a = 1
a: Int

scala> def b = a + 2
b: Int

scala> a
res0: Int = 1

scala> b
res1: Int = 3

scala> def a = 2
a: Int

scala> a
res2: Int = 2

scala> b
res3: Int = 3

аналогично если раскидать по файлам object A { def a = 1 } и object B { def b = A.a + 2 } — :load обновлённого A никак не влияет на зависящий от A объект B (есть правда хохма в виде :replay).

То есть как GHCi он себя ведёт.

В SBT для этих целей есть свой REPL — там изменения подхватываются автоматически и всё зависящее их учитывает. Но всё равно неудобно и монструозно по сравнению с CL (там изначально никаких проблем, так как символы).

В ruby, lua, node кажется можно. В R тоже должно. Про perl и php не уверен, но python точно нет.

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

2) для R он вообще основной режим. в режим, когда «реален исходный код а не объекты в репл», переключаются только когда нужно переключится на литературное программирование, или работа очень объемная и длительная.

а в чем проблема то? ведь лисп программа распространяется все равно в виде образа системы?

ведь лисп программа распространяется все равно в виде образа системы?

Ну если это самодостаточная программа (типа бинарник), то да. А так git/asdf-install/common-lisp.net

ведь лисп программа распространяется все равно в виде образа системы?

Кстати, ещё один интересный момент. Используем библиотеки под GPL. Сделали образ путем где-то компиляции функций, где-то подгонкой в REPL. Что теперь является исходником для получившегося образа? Из исходного кода его получить без ручной подгонки невозможно.

А так git/asdf-install/common-lisp.net

Из которых потом создается в памяти «running image» после компиляции кода... Точнее, этот код компилируется в текущий «running image», изменяя последний.

По (L)GPL этот образ распространять ты не имеешь права, т.к. его невозможно собрать из исходников.

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

Хм. То есть нельзя накладывать бинарные патчи на GPL программы? А GTK3 под windows распространять можно? Насколько я помню, билдскриптов под неё не существует.

в принципе он сам себе программа, причем как я понимаю все функции в нем разворачиваются в исходный их текст? :)

Исходники + список ручных действий. То бишь исходники в наболее пригодной форме.

причем как я понимаю все функции в нем разворачиваются в исходный их текст? :)

Нет как повезет. Для CL в общем случае этого не обещали.

Если она высонагруженная, то скорее всего на многих машинах? А тогда что делать?

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

Если она высонагруженная, то скорее всего на многих машинах?

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

Не модно )

Зато работает :)

Тогда будем руками ковыряться?

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

подгонкой в REPL

Зачем? Не делайте так и ваши волосы будут мягкими и шелковистымине будет проблем.

Как поможет эта утилита, если поменялся тип и нужно изменить логику. Была map стала list, что тут перекомпилировать? Из-за динамической типизации есть еще более высокая вероятность что ошибка проскочит как-то

Была map стала list, что тут перекомпилировать?

Везде, где используется тип проёдет перекомпиляция. Вылетят предупреждения о несоответствии типа. Будет сразу видно, где исправить

В результате тестовые случаи, проверяемые в REPL зачастую невоспроизводимы

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

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

И почему же не гарантирует? Работа именно через SLIME выгодно отличается от простого repl'а тем что код не только интерпретируется сразу но и записывается в файл. Соответственно при наличии навыка проблемы могут возникнуть исключительно в том случае когда ты что-то подправляешь непосредственно из repl'консольки минуя свой исходник. Но это вопрос практики.

В статически типизированном да, но в лиспе хоть и есть такие возможности, но их мало используют. И у тебя список полетит в функции обработки map