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

> Кстати, а что мешает эксперементировать в haskell?

Никогда не доводилось слышать, что REPL является сильной стороной haskell. Скажем, кое-какой REPL есть в том же Python и Ruby, но это так, с REPL с CL не сравнить. REPL это же не просто командная строка, если говорить в контексте SLIME то целый комплекс средств максимально упрощающих интерактивную разработку. При чем, эти средства во многом так эффективны и удобны потому, что спецификация Common Lisp была написана с прицелом на подобные инструменты (точнее, скорее на основе опыта их использования).

ну претензия была к тому что система типов мешает эксперементировать, то что у лиспа класный repl мы уже поняли

Вот это срачЪ, ахренеть

www_linux_org_ru

Потом, далеко не каждый C++-разработчик понимает частичную специализацию

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

Спасибо, смеялся до слез :)

Да и вообще весь тред доставляет. Торт!

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

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

т.е. зачем сложно описывать
несложные вещи?

Фишка не в том, что имел ввиду автор, а в том, как это преподнесено. Красиво, тролльно, задорно и весело. А сама мысль-то дурацкая, бесспорно.

продолжим бурление

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

в данном случае имея make-instances-obsolete мне даже думать об этом не надо

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

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

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

a зачем сравнивать ? в cl доступно все это + make-instances-obsolete, только последние прямой путь, а остальное костыли в данном контексте, ты же не будеш софтину редизайнить на «все в sql» только чтоб hot upgrade эмулировать

> в данном случае имея make-instances-obsolete мне даже думать об этом не надо

это совсем разные задачи, а make-instances-obsolete как раз не решение первой, а хак, не дающий ее решить

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

выразить то может и выразиш, но как обычно через костыли

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

короче переложи красиво «типа пролог» на аннотации :)

> это совсем разные задачи, а make-instances-obsolete как раз не решение первой, а хак, не дающий ее решить

в этой ветке общая «теория» программирования удивительно легко подстраивается под ограничения любимых инструментов комментаторов :)

хак у вас будет когда через reinterpret_cast будите private ссылки менять на немного подросшаю новую версию вашего «реструктуризированного» объекта

>«типа пролог» на аннотации :)

Получив полу- или не- разрешимую задачу? Нафиг-нафиг.

> в этой ветке общая «теория» программирования удивительно легко подстраивается под ограничения любимых инструментов комментаторов :)

а отсутствие чего-либо в лиспе так же удивительно оказывается костылем или ненужным :)

хак у вас будет когда через reinterpret_cast будите private ссылки менять на немного подросшаю новую версию вашего «реструктуризированного» объекта

никогда так не делал и не буду делать

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

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

никогда так не делал и не буду делать

а есть другой не «теоретический» путь ?

> например ?, может в этом месте просто в лиспе другой подход и он не чем хуже, а может и даже лучше, только совсем непривычный

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

а есть другой не «теоретический» путь ?

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

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

ща фокус покажу

есть - не быть индусом на подработках

да быть индусом очень плохо

а когда есть свой долгосрочный проект - такие хаки даже в теории не рассматриваются

а ALTER TABLE ... ADD COLUMN - тоже нельзя ? и чем оно принципиально отличается от ре-defclass/make-instances-obsolete

> а ALTER TABLE ... ADD COLUMN - тоже нельзя ? и чем оно принципиально отличается от ре-defclass/make-instances-obsolete

1. это данные так или иначе
2. почему вы выбрали ADD, а не DROP? ;)

интерфейсы/фабрики, разделение кода на приватный и публичный

ну про defgeneric/defmethod уже говорили, фабрики - это вообще недостаток

фокус, вот другие абстракции - типа лингвистические:

(fighters (stone scissors paper))

(fight-rules
  ((stone scissors :-> stone)
   (scissors paper :-> scissors)
   (paper stone :-> paper)))

(fight '(stone stone paper))

я специально опустил реализации, в качестве реализации может быть backend: defmethod (реализация всего несколько строк), sql или еще что-нибудь

интерфейсом является синтаксис

в решении на с++ куда больше борьбы с с++ чем с задачей, на а про выразительность и лаконичность лучше вообще помолчим :)

> 1. это данные так или иначе
ну прямо как объекты

2. почему вы выбрали ADD, а не DROP? ;)

ADD позитивней, но можно и DROP

> фокус, вот другие абстракции - типа лингвистические

обычная перегрузка операторов на С++ дает тоже самое

в решении на с++ куда больше борьбы с с++ чем с задачей

давайте задачу - сравним

на а про выразительность и лаконичность лучше вообще помолчим :)

согласен - ничего более ничитабельного чем «оптимизированный» код на лиспе нет :)

> ну прямо как объекты

ну тогда вы в курсе про то, что в СУБД есть такое же разделение данных на «приватные», «публичные», «константные» и пр. - будете доказывать, что это не надо?

ADD позитивней, но можно и DROP

клиент по другую сторону «провода» очень обрадуется :)

> клиент по другую сторону «провода» очень обрадуется

хотя это не самое веселое, веселее будет, если поменять тип поля например

обычная перегрузка операторов на С++ дает тоже самое

сделай что-то типа такого:

(defclass opponent () ())

(defgeneric fight (op1 op2))

(defmacro define-opponets (&rest names)
  `(values ,@(mapcar (lambda (x) `(defclass ,x (opponent) ())) names)))

(defmacro defbat (win los fstr)
  `(values 
    (defmethod fight ((op1 ,win) (op2 ,los))
      (format t ,fstr) ',win)
    (defmethod fight ((op1 ,los) (op2 ,win))
      (format t ,fstr) ',win)))

(defmacro define-battles (&rest spec)
  `(values ,@(mapcar (lambda (x) `(defbat ,@x)) 
                     (mapcar #'(lambda (lst)
                                 (destructuring-bind (&key win los mes) lst
                                   (list win los mes))) spec))))

(define-opponets cat dog mouse)

;; нормально
(define-battles (:win cat :los dog :mes "cat wins") (:win mouse :los dog :mes "mouse wins"))

;; ошибка типов при загрузке/компиляции
(define-battles (:win cat :los fish :mes "cat wins"))

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

>g++ --pedantic c тобой не согласен

это ведь должны были сделать C++0x, но ведь уже 2010 год, а о новых плюсах так ничего и не слышно. разве стандартизацию ещё не отменили за очевидной не надобностью? так что это не плюсы.

мы это уже обсуждали, нормальное и быстрое решение тут маппить идентификаторы/строки, как сделать на классах - я тоже писал

> это ведь должны были сделать C++0x

в каком месте?

но ведь уже 2010 год, а о новых плюсах так ничего и не слышно

что не мешает уже пользоваться ими в icc, VC2010, gcc

>как сделать на классах - я тоже писал

где код? В лиспе десяток строк, что сложно на С++ их переписать?

нормальное и быстрое решение тут маппить идентификаторы/строки

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

>что не мешает уже пользоваться ими в icc, VC2010, gcc

мешает пользоваться C++ исключительно здравый рассудок.

в каком месте?

левый оператор, может ещё и шаблоны - сильно не смотрел.

> ты же не будеш софтину редизайнить на «все в sql» только чтоб hot upgrade эмулировать

обычно это надо дизайнят СРАЗУ, т.к. тогда уже ясно, десктопный ли это шейпер для недопущения перерасхода GPRS трафика, либо решение уровня провайдера

но с другой стороны, что помешает редизайну, если уж так вышло?

> Хорошо что эйлер перевел все на человеческий язык

емнип лейбниц это алгоритмизировал, а не эйлер; да и сами по себе плюсовые шаблоны существенно проще матана

хотя современные обозначения действительно в основном от эйлера

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

я че-то не въехал, где это проверяется

где код? В лиспе десяток строк, что сложно на С++ их переписать?

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

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

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

struct opponent {
	opponent battle( opponent p ) 
		{ return mWin[ m_name ][ p.m_name ] ? this : p; }

	string m_name;
	static map<string,map<string,bool>> mWin;
};

это будет работать и с загрузкой из файла, и с декларативным описанием

левый оператор

какой?

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

в аннотации можно указать название класса, в котором реализована соответствующая логика (исполняемая в рантайме); а тебе подробнее надо написать, т.к. дефекты у аннотаций есть, и если ты найдешь неизвестные мне новые дефекты — это интересно

> короче переложи красиво «типа пролог» на аннотации :)

запость подробное описание своей задачи и вопрос «а можно ли это сделать через аннотации в яве» в девелопмент

>тут вообще иерархия классов не нужна

ты же даже задачу толком не понял. в классах весь смысл.

при этом городя тихий ужас

тихий ужас это плюсы - костыли вокруг структурного программирования на низкоуровневом C.

> ты же даже задачу толком не понял. в классах весь смысл.

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

> тихий ужас это плюсы - костыли вокруг структурного программирования на низкоуровневом C.

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

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

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

> в решении на с++ куда больше борьбы с с++ чем с задачей, на а про выразительность и лаконичность лучше вообще помолчим :)

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

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

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

ну я и говорю - лишь бы как в лиспе

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

ну ты вот даже понять не смог, не говоря уже о решении.

зато на плюсах люди делом занимаются

трахаются с утечками памяти и сегфолтами?

>ну я и говорю - лишь бы как в лиспе

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

ну ты вот даже понять не смог, не говоря уже о решении.

ололо :) есть задача - набор «животных» и набор результатов, в С++ это задается просто:

{ "cat" , { "mouse", true } }

или

opponent::mWin[ "cat" ][ "mouse" ] = true;

создать животное тоже просто - opponent( «cat» ), а лисперы начинают добавлять лишние сущности, неудивительно, что программы на лиспе и памяти едят больше и медленней

трахаются с утечками памяти и сегфолтами?

у лисперов тоже есть «сексуальная» жизнь :)

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

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

> вполне логичные требования к расширяемости.

наследование от opponent даст все что нужно

если ограниченные языки даже этого не умеют - значит они для ограниченных

узнаю лиспера :)

уже лет десять все твердят, что выбор плюсов в 90% случаев равен фэйлу.

я сам постоянно это пишу - т.к. С++ тоже имеет высокий уровень вхождения

> не обосновано критиковать всё что не плюсы - это у всех цецепешников так принято?

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