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

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

Может его ещё в жопу поцеловать? У меня своё мнение есть, не менее ценное.

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

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

>> разве не пригодилось бы вам средство по-быстрому переписать кусок программы на Си (как раз это и есть Cython)?

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

То есть переписывать критические куски на Си лисперам не приходится никогда-никогда?

> всё правильно говоришь, да - там белая магия :) при определенной сноровке белая магия неотличима от инжиниринга ;)

А если серьезно, я написал редакции предложить всем призерам описать кратко о том, как они решали задачи — это был бы действительно интересный итог для конкурса (а не для флейма :) Не знаю, конечно, будет ли одобрено. Классная, кстати, сопроводительная записка к твоему решению. Еще б снабдить несколькими код-снипетами, и был бы отличный раздел в такую статью. И в итоге Практика функционального программирования постепенно бы сконверджилась в Практику провинутого, что ли, программирования. Не сошелся то свет клином на одной функциональной парадигме — у всех есть свои хорошие стороны...

Кстати, забыл подписаться. Эти 3 сообщения от меня. --vseloved (Всеволод Дёмкин)

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

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

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

ok, напоминаю про prolog встроенный в scala

ps
не все в Московском часовом поясе живут

> Может его ещё в жопу поцеловать?

эти лисперы такие затейники

У меня своё мнение есть

у всех есть

не менее ценное

его мнение влияет на что-то, твое - нет

> Я вообще-то критиковал аргументацию про «количество людей». БОльшинство людей на планете - суть биологический шлак

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

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

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

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

а я?

его мнение влияет на что-то, твое - нет

Тебе так кажется. Opensource тем и прекрасен, что в твоём проекте твоё мнение - самое главное ;)

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

> а если поменять шаблон?

а вот этим отличается хорошее проектирование от «интерактивного программирования», т.к. надо понимать что пишешь не абы как, а так чтоб потом ничего не ломать ни людям, ни себе

> а я?

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

> Opensource тем и прекрасен, что в твоём проекте твоё мнение - самое главное ;)

у тебя есть Opensource-проект? покажешь?

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

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

> То есть переписывать критические куски на Си лисперам не приходится никогда-никогда?

если сильно прижмет, а в чем проблема? изменил Ц-либу, пересобрал, перегрузил в РЕПЛ. поехали дальше.

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

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

для небоевых программ программ под отладчиком и даже (ересь!) возможно для боевых

упрощенный пример: допустим, у нас есть функция

char* parse_up_to(char* what, char* upto)

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

тут очевидно просится флажок добавить:

char* parse_up_to(char* what, char* upto, bool eat=false)

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

> но отрицать полную никчёмность его идей и технологий - ну смешно же.

эта пять

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

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

> для небоевых программ программ под отладчиком

VC такое умеет

> а вот этим отличается хорошее проектирование от «интерактивного программирования», т.к. надо понимать что пишешь не абы как, а так чтоб потом ничего не ломать ни людям, ни себе

вот прям так, на листе, дизайнится идеальная программа? Потом без ошибок имплементится на цепепе?

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

*так* сразу и надо было писать; над этим можно подумать — идея непривычная

> обойти защиту и в голову старой функции вставить jmp

для добавления новых фич такое точно не надо

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

+1, и думаю здесь достаточно часто лист бумаги и карандаш победят по скорости лисп, а не только «статический» с++

> вот прям так, на листе, дизайнится идеальная программа?

нет конечно, идеальных программ не бывает, но бывают хорошие и плохие

Потом без ошибок имплементится на цепепе?

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

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

+1, и думаю здесь достаточно часто лист бумаги и карандаш победят по скорости лисп, а не только «статический» с++

Достаточно всего лишь несколько раз сделать неправильную модель, реализовать её на 80% и понять, что модель была говном ;) Потом то самое чутьё приходит, которое опытного граблехода от молодняка отличает.

> для добавления новых фич такое точно не надо такое надо если hook не предусмотрен и собрали не vs2010, только остается еще помолится что функция не заинлайнилась еще где нибудь :)

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

и чем же это отличается от разработки на CL?

> Потом то самое чутьё приходит, которое опытного граблехода от молодняка отличает.

как раз молодняк и не «страдает» проектированием, а пишет все сходу

>> То есть переписывать критические куски на Си лисперам не приходится никогда-никогда?

если сильно прижмет, а в чем проблема? изменил Ц-либу, пересобрал

Я сказал «переписывать». Это значит, с Лиспа на Си. Про «изменил Ц-либу» речи не было.

> надо если hook не предусмотрен

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

> и чем же это отличается от разработки на CL?

давайте ссылку на код - чтоб было видно, что на CL так и пишут

> Это значит, с Лиспа на Си.

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

>> Это значит, с Лиспа на Си.

зачем?

То есть нет. Ну, круто, чо.

у нас уже есть оптимизирующие компиляторы.

У Си есть компиляторы покруче, а всё равно иногда делают ассемблерные вставки.

> у нас уже есть оптимизирующие компиляторы.

но вы их не покажете? тот же sbcl сливает gcc по полной:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=gcc&lang2=...

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

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

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

вспомним например nginx, который умеет рестарт что-то вроде «все процессы со старой версией бинарника по завершнии работы умирают, запускаются только процессы с новой версией бинарника»

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

его можно было бы сравнить с make-instances-obsolete, и это было бы интересно

ok, напоминаю про prolog встроенный в scala

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

(но не ответил, кстати, корвину насчет «ооп-формы»)

ps не все в Московском часовом поясе живут

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

> VC такое умеет

ссылку кинь

> в том то и дело что в лиспе в этом месте сбоку и прямо почти не отличаются и без костылей

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

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

по-моему стандартнейший юз-кейс для ООП

> давайте ссылку на код - чтоб было видно, что на CL так и пишут

да любая мало-мальски серьезная библиотека на CL. например bordeaux-threads: http://www.cliki.net/Bordeaux-Threads

там есть и интерфейс, представляющий експортированные символы пакета bordeaux-threads, куча реализаций CL, которые этот интерфейс реализуют:

src/
bordeaux-threads.lisp
condition-variables.lisp
default-implementations.lisp
impl-abcl.lisp
impl-allegro.lisp
impl-clisp.lisp
impl-clozure.lisp
impl-cmucl.lisp
impl-corman.lisp
impl-ecl.lisp
impl-lispworks-condition-variables.lisp
impl-lispworks.lisp
impl-mcl.lisp
impl-sbcl.lisp
impl-scl.lisp
pkgdcl.lisp
unsupported.lisp

+ тесты:

test/
bordeaux-threads-test.lisp

что не так?

> ссылку кинь

http://msdn.microsoft.com/en-us/library/0dbey757%28v=VS.80%29.aspx

тут описано как раз что нельзя

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

AFAIK, в Clozure CL можно писать на встроенном ассемблере.

Вообще в CL компилятор встроен в рантайм. Там же есть low-level доступ к его кишкам. Можно его расширять в том же рантайме.

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

таки да, и даже более того: совсем не просто найти юзкейсы, где современные языки (+обвязка) сливают лиспу

> тот же sbcl сливает gcc по полной

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

Ну точно фанатик. Да и вообще журнал 'практика фп', а обсуждают какой-то цлисп.

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

очень даже близко.

т.е. сливает

а все потому, что не хватает абстракций, которые в с++ имеются

вот love5an пытался портировать мой код, измеряющий скорость эксепшенов, в лисп, и попал на 2-4 кратное отставание из-за того, что часть битов в инт-е отдается под тип, и это ему побороть не удалось

> Да и вообще журнал 'практика фп', а обсуждают какой-то цлисп.

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

> БОльшинство людей на планете - суть биологический шлак, только зря потребляющий ресурсы.

Они не шлак — они планктон, с которого кормятся программисты. Кому бы мы писали гуйню и более сложные вещи без них?

> куча реализаций CL

это п%ц :) ну и я имел ввиду реализацию не под каждый отдельный «лисп» - это таки не так связано с проектированием, как с жеванием кактуса :)