5-й номер журнала «Практика функционального программирования»

> вот давай расскажи на примерах, где это hotpatching реально полезно

 — это могло бы быть реальной киллерфичей лиспа

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

Где-то в середине своей карьеры C++-разработчика я мог подолгу писать код, без компиляции, но чем дальше, тем чаще начинал компилировать и запускать, проверяя что получается, но при этом много времени терялось на то, что бы скомпилировать, запустить, активировать проблемный код. В итоге, эта наметившаяся тенденция в моём способе разработки нашла идеальное воплощение в CL+SLIME, ибо исчезли все непрофильные расходы времени: я мгновенно компилируют отдельный фрагмент кода и тут же запускаю проблемый код (а не всё приложение) в REPL, а в случае проблем тут же получаю необходимую информацию от отладчика.

> это я и спрашивал - зачем новые функции/методы обязательно подключать в рантайме?

hotpatching нужен __ТОЛЬКО__ для латания дырок

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

> и только в не-продакшн системе под отладчиком.

Хм, а почему нет? Для веб-приложений это обычно вполне терпимо, ибо если запрос не отрабатывает, то отладчик ничего плохого уже не сделает, а на другие части системы никак не повлияет (в CL). Я сделал специально для Hunchentoot патч, который при активном отладочном режиме лимитирует колличество запросов, которые могу одновременно отлаживаться. Бывает так, что на машине разработчика всё нормально, а на боевом сервере - проблемы. Можно спокойно, не опасаясь каких-либо плохих последствий подключиться к сбоящему серверу и выяснить причины проблемы, и возможно даже сразу исправить.

> Это позволяет изменять программу кусочек за кусочком и тут же проверять изменение поведения в REPL.

я уже говорил - тот же VC умеет делать также

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

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

я уже писал, что есть. И называется он distel

> я уже писал, что есть. И называется он distel

Ну как бы вызывает некоторые сомнения, что бы он может тягаться со SLIME ;)

> я уже говорил - тот же VC умеет делать также

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

> Бывает так, что на машине разработчика всё нормально, а на боевом сервере - проблемы.

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

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

> хотел горячий лайт фича инжекшен

не распарсил

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

может ты еще хотел и кнопку «сделать все за2.718бись» ?

> бывает, и я не против подцепиться отладчиком к боевому серверу,

но против hotpatching-а в этом случае...

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

> может ты еще хотел и кнопку «сделать все за2.718бись» ?
чего аргументы опять кончились ?) по аннотациям завтра поясню ...

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

ты опять бездоказательно пересказываешь то, что говорил не раз; я же просил (и прошу) привести конкретные примеры, ориентируясь, например, на список в http://www.linux.org.ru/jump-message.jsp?msgid=4911022&cid=4922352 и возразить (с конкретными примерам) по тем пунктам, где я сказал «ужас» или «не надо»

> могу ли я написать на ECL модуль и _прозрачно_ (без FFI) использовать его в SBCL?

могу ли я написать на CPython модуль и _прозрачно_ (без FFI) использовать его в Jython?

> чего аргументы опять кончились ?

у тебя они пока что даже и не начались; конкретно отвечать на твои понтовые неясные намеки, которые даже не распарсить, я не собираюсь

по аннотациям завтра поясню ...

ждем-с; можно даже и послезавтра; но если это способ слива — в следующий раз я тебе об этом напомню.

в файле evaluation'а написано: «виснет и жрет память при наличии точек с одинаковыми координатами»

Разница в том, что программа на С с синтаксисом Python — это не Python (который «тормоз каких поискать» ;). А вариант на Lisp'е — на Lisp'е полностью и, кстати, без никакой черной магии: вполне себе обычный Lisp-код (я думаю, Вы согласитесь, как человек с Lisp'ом знакомый). Черная магия — это если бы там было какое-то задействование особенностей реализаций, модификация байт-кода, FFI какой-то навороченный и т.п. Т.е. эту штуку волне можно на ABCL запустить, а вот на Jython не получится.

Т.е. Cython как хороший инструмент (С с питонячим синтаксисом) — это да, буду иметь в виду.

PS. А, кстати, по LOC то где-то наравне (что-то 800-900 получается в Вашем варианте).

>> могу ли я написать на ECL модуль и _прозрачно_ (без FFI) использовать его в SBCL?

могу ли я написать на CPython модуль и _прозрачно_ (без FFI) использовать его в Jython?

Нет. Но я и не приводил Jython как аналог Cython.

> Мне? Обычно никак (хотя немного раздражает, когда в девелоперский лист Python или D приходит такой и начинает объяснять, что всё не нужно, кроме лиспа). Такие фанбои мешают самому CL.

дык, истину говорят же. правда глаза колет?

пиcтон~--- говноязык, взлетевший благодаря бейсик-майндед-программерс.

Д~--- та еще какашка, недалеко отлетевшая от цепепе.

> В очень ограниченном виде

я вообще не понимаю зачем поддерживать изменение всего - чтоб мешать объекты, инициализированные старым кодом, с новыми?

С++ в принципе не может тягаться с Common Lisp по мощности средств интерактивной разработки,

язык и реализация разные вещи, интерпретаторы для С++ есть, но не пользуются спросом

> Нет. Но я и не приводил Jython как аналог Cython.

какой-то другой язык заначит? жистон?

> здорово, ну выгружу я плагин bgp и после этого сетка оператора частично ляжет ...

не выгружайте его - очевидно же

> Разница в том, что программа на С с синтаксисом Python — это не Python (который «тормоз каких поискать» ;). А вариант на Lisp'е — на Lisp'е полностью и, кстати, без никакой черной магии: вполне себе обычный Lisp-код (я думаю, Вы согласитесь, как человек с Lisp'ом знакомый). Черная магия — это если бы там было какое-то задействование особенностей реализаций, модификация байт-кода, FFI какой-то навороченный и т.п. Т.е. эту штуку волне можно на ABCL запустить, а вот на Jython не получится.

всё правильно говоришь, да - там белая магия :)

Т.е. Cython как хороший инструмент (С с питонячим синтаксисом) — это да, буду иметь в виду.

PS. А, кстати, по LOC то где-то наравне (что-то 800-900 получается в Вашем варианте).

ну да, если выкинуть грид оптимизацию и пользовать expat, то код раза в два сократился бы, ну и скорость упала бы в 2 раза где-то

> Отсюда вывод: объективного взгляда на синтаксис не бывает, есть только субъективный. И он нам говорит, что синтаксис си — говно.

Це~--- это хороший портабельный ассемблер. и он нужен. остальное правда.

> в файле evaluation'а написано: «виснет и жрет память при наличии точек с одинаковыми координатами»

кста, очень похоже на баг в Cython! я расковыряю этот вопрос на части, попозже..

> язык и реализация разные вещи, интерпретаторы для С++ есть, но не пользуются спросом

это не совсем точное возражение (хотя над интерпретаторами для С++ подумать надо)

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

это по-твоему было бы полезно?

> вот я бы не отказался от hotpatching-а с возможностью добавить несколько дополнительных аргументов

для какого рода программ?

это по-твоему было бы полезно?

если лично мое мнение - нет, как по мне такие изменения должны приходить с новой версией ПО

Ты просто не можешь или не хочешь понять. Впрочем, изволь: количество людей, которые считают синтаксис Лиспа говном, гораздо больше, чем тех, которые считают говном синтаксис Си или Питона.

Количество людей, считающих книжки Шварцшильда унылым говном, тоже много. О чём это говорит? Неужели о том, что Шварцшильд действительно ненужные книжки писал? Нет. Говорит только о том, что большинство (миллион мух) под книжкой считает популярные среди этого большинства высеры Донцовой или Коэльо. А фундаментальный труд по астрофизике - это для большинства и не книжка вовсе.

>> Нет. Но я и не приводил Jython как аналог Cython.

какой-то другой язык заначит?

Тоже нет. У тебя с чтением проблемы? Я сказал, что Cython используется для ускорения Python-кода; мне в ответ сказали про ECL. Причем тут ECL - я так и не понял.

> и возразить (с конкретными примерам) по тем пунктам,

где я сказал «ужас» или «не надо»

Хм. Мне казалось, что я уже пояснил. Ну да ладно:

Ну ты же не можешь изменить тип возвращаемого значения?

Или типы агрументов?

ужас какой; если это хочется, значит посыпется много где

Что это не нужно в C++ - согласен, но в CL то типы вообще не указываются, типа динамическая типизация.

нафиг, можно создать субкласс, а менять — вряд ли надо

В CL можно изменить определение класса и внесённые изменения отразятся и на уже существующих объектах, что совершенно не реально в случае с C++.

А изменить определение шаблона и потом перекомпилировать

зависящие от него функции?

на лету? нафиг.

В CL это обычная режим: изменил макрос, а потом перекомпилировал зависящий от него код. В С++ подобное вряд ли возможно, ибо очень большая вероятность сразу нарваться на «Segmentation fault».

ужас какой; если это хочется, значит посыпется много где

Вот, это самое интересное. Внесение серьзёных изменений в дизайн при программирование на C++ требует серьёзных раздумий и надо менять сразу много что, ибо компилятор будет стараться требовать согласования объявлений. Компилятор будет указывать на не согласованные участки кода, даже если они сейчас не очень интересны. Т.е. я хочу, например, проверить какую-то идею, мне надо изменить кое-что и запустить проблемный код, при этом, другой код может стать некорректным, но меня это не интересует - им я займусь позже, а сейчас я просто ставлю эксперимент. Т.е. программирую на CL и имею возможность осмысленно нарушать корретность всей программы, что бы добиться нужного эффекта в проблемном коде. Это позволяет заметно ускорить процесс разработки, ибо мне не приходиться уговаривать компилятор таки скомпилировать данный код.

И ещё раз: это всё имеет значение ни сколько во время выполнения, сколько во время разработки.

> Количество людей, считающих книжки Шварцшильда унылым говном, тоже много.

Эти люди - астрофизики? %)

(миллион мух)

Простите, это вы астрофизиков мухами назвали? :D

> Тоже нет. У тебя с чтением проблемы? Я сказал, что Cython используется для ускорения Python-кода; мне в ответ сказали про ECL. Причем тут ECL - я так и не понял.

ECL тут конечно не к месту приплели

> Я сказал, что Cython используется для ускорения Python-кода;

мне в ответ сказали про ECL. Причем тут ECL - я так и не понял.

В общем, это какое-то недоразумение, ибо использовать ECL для ускорения lisp-кода просто не получится. Ведущие реализации компилируют lisp-код сразу в машинный и это даёт лучшие результаты, чем компилировать через промежуточный С-код. И ЕСL, не являетcя аналогом Cypthon, ибо ЕСL это реализация Common Lisp, а Cypthon не является реализаций Python. Ну и для Common Lisp аналог Cypthon просто не нужен.

> Ну и для Common Lisp аналог Cypthon просто не нужен.

+100

> И ещё раз: это всё имеет значение ни сколько во время выполнения, сколько во время разработки.

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

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

кстати я верно понимаю, что писать тесты лисперы не любят? для С++ обычная практика написать интерфейс, написать тесты - а потом реализовать это все, получив реализацию задуманного, а не подогнав задуманное под написанный код

Эти люди - астрофизики? %)

Программисты, не понимающие лиспа - программисты? %)

>> Я сказал, что Cython используется для ускорения Python-кода; мне в ответ сказали про ECL. Причем тут ECL - я так и не понял.

ECL тут конечно не к месту приплели

О чем и речь. А если кто-то хочет сказать, что для SBCL инструмент вроде Cython и не нужен, подумайте - разве не пригодилось бы вам средство по-быстрому переписать кусок программы на Си (как раз это и есть Cython)?

> в том то и дело что не очевидно что нужный hook был задуман заранее и вообще не придется менять живые структуры

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

Что-то из тегов erlang, haskell, lisp тут только лисп обсуждают. Отсюда как-то напрашивается вывод о том, что всё же среди выше упомянутых языков с поддержкой фп, лисп сильно выделяется своими преимуществами.

> Программисты, не понимающие лиспа - программисты? %)

Тебе трудно будет принять этот ответ, но да - они программисты :) Да и кто сказал, что все, кому не нравится синтаксис Лиспа, не поняли его? ;)

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

Это ты так думаешь.

> кстати я верно понимаю, что писать тесты лисперы не любят?

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

для С++ обычная практика написать интерфейс, написать тесты -

а потом реализовать это все

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

> Что-то из тегов erlang, haskell, lisp тут только лисп обсуждают.

Обсуждение нового выпуска журнала закончилось на 4-й странице. После этого начался веселый тролльфест :)

> во время разработки я предпочту взять в руки лист бумаги и карандаш, чем писать код построчно и сразу проверять

ну тут, листом бумаги будет РЕПЛ, карандашом - руки, вводящие секспы.

в чем разница?

> Программисты, не понимающие лиспа - программисты? %)

вот вам цитата Линуса:

«I'm distrustful of projects that do not have well-defined goals, and well-defined interfaces. They tend to bloat and do “everything” over time. This is what gives us horrors like GNU emacs and Mach: they don't try to do one thing well, they try to do _everything_ based on some loose principle (“LISP is good” or “microkernels make sense” or “GGI should do graphics”)»

Тебе трудно будет принять этот ответ, но да - они программисты :) Да и кто сказал, что все, кому не нравится синтаксис Лиспа, не поняли его? ;)

Я вообще-то критиковал аргументацию про «количество людей». БОльшинство людей на планете - суть биологический шлак, только зря потребляющий ресурсы. Единственный от них прок - вероятность появления гения, который из этого шлака вырвется и сделает что-нибудь полезное.

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

> О чем и речь. А если кто-то хочет сказать, что для SBCL инструмент вроде Cython и не нужен, подумайте - разве не пригодилось бы вам средство по-быстрому переписать кусок программы на Си (как раз это и есть Cython)?

здесь эта сущность просто не нужна, как уже сказали.

> ибо бесконечные компиляции занимают всё время.

среднее время билда после мелких изменений меньше 2 сек - специально только что проверил