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

Зачем ты делишь image-based и file-based? Здесь нет четкой градации.

Даже в Smalltalk, например, в VisualWorks, можно код сохранять в файлах, а потом загружать оттуда.

Я рад, что мой вброс не пропал даром.

Ну а что мешает писать в код файл, потом вычислять регион/блок в slime, тем самым поддерживая синхронность между тем, что у тебя в образе и тем, что на диске?

archimag сказал, что image-based разработка 
для него основное достоинство Common Lisp

Я такого не договорил, это ты что-то уже самостоятельно домыслил.

ЗЫ, раз никто не хочет бороться с засилием стимоигр на ЛОР, нет смысла скрываться, поставлю Штефана опять на юзерпик

Не важно, кто что сказал в том тупом треде, но как бы вот:

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

Ой тут срач будет... и CL тема и image\file prjt тема и утверждение невоспроизводимости. Ох беда...

А по делу. А по делу всё от задач выбирать нужно выбирать.
С CL знаком когдашним 3хдевным знакомством, но понимаю, что сейчас для одной моей высоконагруженной приблуды, было бы идеальным иметь image путь. Но оной (CL) не знаю, и страшновато лепить что-то на быстром обучении.

Ой тут срач будет...

Да всё тут уныло как-то.

для одной моей высоконагруженной приблуды

Это смотря что за приблуда. А то может CL вообще не пойдет.

Ой тут срач будет...

Если не кормить ушлепка mastercoder1, то всё будет нормально.

Я не ушлепок, это ЛОР такой

Я не ушлепок

Ты ушлепок. Лживый.

Да иди ты

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

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

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

Я из-за SLIME дважды нерабочую версию gtk-cffi коммитил. Работаю, дописываю, компилю через C-c C-c и периодически asdf:load-system. В конце делаю asdf:load-system, запускаю все тесты: работает превосходно. Делаю коммит.

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

Приходится из-за этого периодически делать rm -rf ~/.cache/common-lisp && restart sbcl. Причём это «периодически» перед каждым коммитом.

Образ - это, ко всему прочему, ещё и вещь в себе. Смолтоковые образы (что GNU Smalltalk, что Pharo) содержат все загруженные пакеты в себе и (почти) полностью переносимы. Можно насохранять себе образов с уже загруженными веб-серверами, фреймворками и прочими батарейками, и потом *мгновенно* развертывать их на любом компьютере. В Pharo, ко всему прочему, можно сохранять образы непосредственно в процессе отладки, потом загружать их и продолжать отладку, скажем, через неделю, с того же места. В общем, сплошной профит.

https://github.com/fare/asdf3-2013

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

Ах, да. Поставить racket и выполнить make html.

когда образ foobar (fucked up beyond all repair) оказался

Во-первых, FUBAR; во-вторых, что, просто fucked up образ - это приемлемо?

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

Сборка проекта - это приведение объектного кода в соответствие с исходным. Если Lisp-проект большой, этот процесс тоже займет кучу времени.

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

Не понял. Есть образ, который меняется через defun/defmacro/defpackage. Есть файлы, в которых исходники. Общепринятый вариант гарантированно ломает синхронизацию после первого же C-c C-c на изменённом defmacro. Или даже на функции, если она использвается в макросе.

Кстати, http://www.informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/ibcl/ лучше тем, что если образ внезапно работает, то можно сохранить этот образ в текстовые файлы. Но печаль в том, что комментарии тогда можно писать _только_ в докстрингах.

Спустя некоторое время обновляю sbcl.

Разве sbcl не требует при любом обновлении убивать все fasl'ы?

Ситуация с «работает у меня в образе, не работает у других» схожа с системами контроля сорцов с двухфазной схемой коммита (commit в локальную копию, push в центральную). Ничего, живут же люди.

Подписываюсь на тред. Тоже интересно.

Во-первых, FUBAR;

FUBAR - ругательство, неприемлемое в обществе. FOOBAR можно, хотя смысл понятен.

во-вторых, что, просто fucked up образ - это приемлемо?

Ну если вовремя понял, что накосячил, и есть возможность косяк исправить, то часто проще исправить, чем перезапускаться.

Сборка проекта - это приведение объектного кода в соответствие с исходным. Если Lisp-проект большой, этот процесс тоже займет кучу времени.

Конечно. Но в случае с лиспом я могу прицепиться к процессу на удалённой машине, посмотреть проблему и даже исправить её на лету, а в случае с Ъ-энтерпрайз софтом, написанном на сишечке/крестах, такое не пройдёт.

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

По-моему, это всё равно, что брать на себя функции make. Можно, но не масштабируется.

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

Машинный код поправить нельзя, это да. Данные - по крайней мере теоретически можно.

https://github.com/fare/asdf3-2013

Много букв

Большое спасибо. Хоть кто-то собрал все «предрассудки и суеверия» в единый талмуд. Если читать с браузера, то лучше сразу отсюда: https://github.com/fare/asdf3-2013/blob/master/live-programming.scrbl

Разве sbcl не требует при любом обновлении убивать все fasl'ы?

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

Я, честно говоря, image based подход не пробовал, но не прочь бы разобраться.

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

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

К тому же можно делать несколько циклов добавил_фичу-вычислил-написал_тест-проверил с использованием репла, а потом проверку с чистым образом.

В общем, послушаем экспертов.

FUBAR - ругательство, неприемлемое в обществе.

Да ладно! Так говорят суровые американские военные. Ты же сам из Америки, не? Вот отлови сурового военного и послушай

По-моему, это всё равно, что брать на себя функции make. Можно, но не масштабируется.

Ты не понял, процесс сборки тут не при чём.

Машинный код поправить нельзя, это да. Данные - по крайней мере теоретически можно.

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

и (почти) полностью переносимы

В смысле с версии на версию, с оси на ось? Ну повезло, если так

Лучше собрать html и читать его. Из дебиана получалось, гентушный racket неосиливает. :/

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

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

недавно в ракетовской рассылке проскакивало:

http://comments.gmane.org/gmane.comp.lang.racket.devel/8519

У тебя странный какой-то sbcl У меня пишет, скомпилировано для версии такой-то, найдена такая-то. Может это настроить можно, хз.

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

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

• High-level
• Persistence
• Dynamicity
• Homoiconicity
• Transparence

и «мёртвые» с характеристиками

• Dualism
• Static
• Impermanence
• Low-level

.

Так вот, интересно, куда отнести Scheme? Разработка через образ там в общем случае не принята. В том же Racket есть инкрементальная make-like компиляция (поэтому день ждать пока всё перекомпилируется не надо), но REPL при компиляции перезапускается.

Ты не понял, процесс сборки тут не при чём.

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

В смысле с версии на версию, с оси на ось?

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

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

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

Вообще, проблемы, приписываемые всяким лиспам посторонним людям, существуют, но они в реальной жизни несущественны. Есть более серьёзные проблемы, про которые посторонние не знают, но крови у лисперов пьют куда больше невинностей типа передачи в функции объектов неправильного типа и разработки в REPL. Например, я натурально пару месяцев бился с каким-то неведомым багом в лиспворксе, из-за которого самодельная ОО-система (не моя) ложила всю лисповую систему на линуксе по ассерту или сегфолтила. Продукт был прибит к лиспворксу и линуксу. И хотя использовались только штатные лиспворксовские интерфейсы для метаобъектного протокола, такой use case из-за дикой сложности реализации MOP у разработчиков, видать, не всплывал. В итоге, от самодельной ОО-системы отказались, к большому огорчению её автора.

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

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

...по сравнению с чем-то гораздо худшим %)

типа передачи в функции объектов неправильного типа

Да это и в других «динамических говноязычках» (ц) возможно.

разработки в REPL

А что не так с разработкой в REPL? А то я по одной ссылке выудил замечательную фразу: «I think that *most* of Mikel's long post was about the advantages of having a live REPL, which IMO is much more useful than images».

...по сравнению с чем-то гораздо худшим %)

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

Да это и в других «динамических говноязычках» (ц) возможно.

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

А что не так с разработкой в REPL? А то я по одной ссылке выудил замечательную фразу: «I think that *most* of Mikel's long post was about the advantages of having a live REPL, which IMO is much more useful than images».

Я про REPL в случае image-based разработки. Да, косяки с наличием функциональности в образе и несохранённом емаксовом буфере при коммитах случались. Но это тоже несущественно, т.к. при каждом коммите rpm'ка собиралась, и через пару-тройку минут мыло с отчётом о поломке приходило. И регрессионное тестирование было, отличная штука.

Ломался в 98% случаев код на VHDL и сишечке, хотя никакой сверхсложной логики в них не было.

Это хорошо, что эти ваши реализации такие портабельные, чем sbcl не может похвастаться. Поэтому clisp - мой выбор, етить :) Не, там где нужна скорость, не обойтись без sbcl. Но clisp зато можно поставить куда хочешь

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

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

Вот как решают такие проблемы, интересно?

Это хорошо, что эти ваши реализации такие портабельные, чем sbcl не может похвастаться. Поэтому clisp - мой выбор, етить :) Не, там где нужна скорость, не обойтись без sbcl. Но clisp зато можно поставить куда хочешь

Максимальная скорость почти никогда не нужна. Лиспворкс тоже не самый быстрый код генерирует, но нам скорости хватало даже на Атоме. Стомегабитная сеть для связи с железом работала достаточно медленно, чтобы тормозов самого лиспворкса не видеть. Что там говорить про CLI, в котором юзер работал...

Я не про отлов бага, а про само обнаружение, если чё

Вот как решают такие проблемы, интересно?

bisect'ом. Начинают останавливать программу в разных точках и смотреть, где данные сломались.

Ну а у clisp скорость как у питона наверно, что не совсем хорошо. Что за софт опять же запускать.

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

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

Да, не, ясно что bisect'ом. Мне интересна проблема верификации софта для таких рассчетов, во как. Можно ли доказать, что она работает, не ставя дорогостоящего эксперимента ИРЛ.

Если чё, я тут полный нуб, спросил для интересу

А до этого у тебя был опыт с лиспом, VHDL'ем? Интересует, может ли простой сантехник дядя Вася управиться за 2 недели, обладая знанием сабжа, но небольшим опытом

А до этого у тебя был опыт с лиспом, VHDL'ем? Интересует, может ли простой сантехник дядя Вася управиться за 2 недели, обладая знанием сабжа, но небольшим опытом

Даже знания лиспа не было, пару поделочных биндингов до этого написал. И про финансовую галиматью вообще ничего не знал, первый вопрос был: «Что такое инструмент?».