LINUX.ORG.RU

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

 , ,


2

13

archimag сказал, что image-based разработка — для него основное достоинство Common Lisp. В варианте SLIME. То есть не формируем в конце исходники из образа, а меняем исходники и на каждом шагу чуть-чуть меняем образ.

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

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

С другой стороны, предполагаю, blub-парадокс. Поэтому хочу узнать, что же особенно хорошего в image-based разработке с точки зрения тех, кто считает image-based лучше чем file-based.

★★★★★

Последнее исправление: monk (всего исправлений: 3)

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

dave ★★★★★
()

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

dave ★★★★★
()

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

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

mastercoder1
()

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

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

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

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

mastercoder1
()

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

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

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

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

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

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

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

mastercoder1
()

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

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

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

Фактически, перекомпилировать/перезапускать всё нужно, когда образ 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. Причём это «периодически» перед каждым коммитом.

monk ★★★★★
() автор топика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mv ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Много букв

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Dualism
  • Static
  • Impermanence
  • Low-level

.

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

monk ★★★★★
() автор топика
Последнее исправление: monk (всего исправлений: 1)
Ответ на: комментарий от mv

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

разработки в 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».

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

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

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

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

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

А что не так с разработкой в 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 и сишечке, хотя никакой сверхсложной логики в них не было.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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