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

>в С++ это задается просто:

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

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

вот и скажи наконец (на 18 странице), что не так с лиспом? а то весь тред слышны только одни визги с++ников и сочувствующих от лютого батхёрта.

> это не решение исходной задачи

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

вот и скажи наконец (на 18 странице), что не так с лиспом?

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

а то весь тред слышны только одни визги с++ников и сочувствующих от лютого батхёрта.

весь тред слышны оскорбления от лисперов, остальные ведут себя спокойно

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

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

С++ тоже имеет высокий уровень вхождения

и кучу недостатков по сравнению с другими современными яп. вот и рецепт фэйла.

я сам постоянно это пишу

то есть c++ - это только легаси? зачем же о нем тогда говорить в контексте лиспа и прочих передовых технологий?

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

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

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

Скажите спасибо луговскому и его «пропаганде».

> то есть c++ - это только легаси? зачем же о нем тогда говорить в контексте лиспа и прочих передовых технологий?

а сколько тебе лет? :)

>весь тред слышны оскорбления

где?

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

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

и кучу недостатков по сравнению с другими современными яп. вот и рецепт фэйла.

если лисп вдруг исчезнет - никто и не заметит, в отличие от «фэйла» в виде С/С++ :)

то есть c++ - это только легаси? зачем же о нем тогда говорить в контексте лиспа и прочих передовых технологий?

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

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

:-D

> где?

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

>а сколько тебе лет

отличный образец: переход на личности во втором посте - но фанбои ведь это только у лиспа.

> отличный образец: переход на личности во втором посте - но фанбои ведь это только у лиспа.

да :) Мне нравится лисп, но то, что ты тут говоришь - по большей части глупости.

>по большей части глупости.

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

>если лисп вдруг исчезнет - никто и не заметит, в отличие от «фэйла» в виде С/С++ :)

характеристика жавы и плюсов как катастрофы индустрии имеет поддержку известных людей.

достойных аналогов С/С++ пока не видно

C - другой язык.

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

от большего аппетита.

> характеристика жавы и плюсов как катастрофы индустрии имеет поддержку известных людей.

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”)

(с)

C - другой язык.

спасибо К.О. :) но вот только то, что ты привел в качестве аргумента против С++( сегфолты и утечки памяти ) - родом как раз из С, и С++ в этом плане даже лучше С - так как в нем есть контейнеры, «умные» указатели и пр.

>обозвать оппонентов ограниченными - это не оскорбление

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

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

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

есть требования индустрии к заменяемости и понижению рисков

индустрия выбирает Java

>так как в нем есть контейнеры, «умные» указатели и пр.

только от них быстро испаряется вся скорость С. и остаются недостатки.

horrors like GNU emacs

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

>С - инструмент для ограниченных

зачем переводить стрелки на C? Так понимаю, что решения задачи на C++ не будет?

> только от них быстро испаряется вся скорость С

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

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

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

> зачем переводить стрелки на C?

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

Так понимаю, что решения задачи на C++ не будет?

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

>ты создаешь новый топик в Developer

зачем? у меня и так всё нормально с самооценкой.

> зачем?

чтоб ты наконец понял, что ЯП создали, чтоб решать задачи, а не наоборот

у меня и так всё нормально с самооценкой.

рад за тебя

> opponent::mWin[ «cat» ][ «mouse» ] = true;

вообще интересно, есть ли что-то в CLOS, что не достичь такого рода подходом (вместо true может стоять анонимная функция)

> вообще интересно, есть ли что-то в CLOS, что не достичь такого рода подходом (вместо true может стоять анонимная функция)

Про ограничение такой модели писалось еще в SICP. Кроме того CLOS - это не только мультиметоды, это еще defclass и method-combination, как минимум.

> вообще интересно, есть ли что-то в CLOS, что не достичь такого рода подходом (вместо true может стоять анонимная функция)

Просто представь, как ты будешь управляться с наследованием и n-ым количеством функций.

> Про ограничение такой модели писалось еще в SICP

цитату хотелось бы

> Просто представь, как ты будешь управляться с наследованием и n-ым количеством функций.

количество моих функций — нисколько не проблема

можно спокойно повторить все нужные CLOS-овские функции с человеческим синтаксисом f(x,y,z,t), тем более, что навскидку они кажутся очень простыми, типа dispatch_table[arg_type(f)]=f;

в то же время в ООП имеются правила, за соблюдением которых следит компилятор, и вот их реализовать в лиспе уже будет не просто

Ты уже приводил это высказывание Линуса ранее. Можно добавить еще одно, более знаменитое, о твоем горячо любимом Ц++ ;)

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said «to piss you off», but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using the «nice» library features of the language like STL and Boost and other total and utter crap, that may «help» you program, but causes:

- infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)

- inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app. ...etc...

и он во многом прав :) правда я уверен, что он не смог бы ответить по существу, что же в STL нестабильно и не портабельно - но он тоже человек и имеет право потроллить; и да, то что многие считают своим долгом, только начав программировать на С++, сразу заюзать буст и наплодить говно-кода на шаблонах - это плохо, я за здравый минимализм( и приводил уже примеры таких библиотек на С++, которые действительно хорошо сделаны )

> можно спокойно повторить все нужные CLOS-овские функции с человеческим синтаксисом f(x,y,z,t), тем более, что навскидку они кажутся очень простыми, типа dispatch_table[arg_type(f)]=f;

Это, если забыть про наследование.

в то же время в ООП имеются правила, за соблюдением которых следит компилятор, и вот их реализовать в лиспе уже будет не просто

Поподробее тут, пожалуйста.

Эх, «слова за слово, лиспом по столу» (с) Степень эмоционального неадеквата с всех сторон уже давно вышла за какие-либо пределы. Сравнивать С++ и Common Lisp не привязываясь к какой-либо задаче просто бессмысленно. Помимо прочего, все «суперфичи» CL имеют свою цену, и частично платить её надо даже если реально их не использовать, что прямо противоречит концепции C++. С++ даёт прямой контроль за уровнем производительности путем возможности выбора подходящих языковых средств. Это просто разные языки с вообще-то разной областью применений. Проблема лишь в том, что в своё время C++ использовали даже там, где его достоинства особенно и не нужны, а недостатки очевидны. Но это не проблема С++, а просто один из периодов в истории индустрии. В конце концов, лидер индустрии (Google, как и ряд других) активно используют C++ и не слушает аналитиков с ЛОР :)

подписываюсь под каждым словом :)

новый вброс

Эх, «слова за слово, лиспом по столу» (с) Степень эмоционального неадеквата с всех сторон уже давно вышла за какие-либо пределы.

как сам рубится так нормально, как другие так неадекватЪ ?)

Сравнивать С++ и Common Lisp не привязываясь к какой-либо задаче просто бессмысленно.

a кто тут говорил что абстарктные классы в С++ костыли ?)

Помимо прочего, все «суперфичи» CL имеют свою цену, и частично платить её надо даже если реально их не использовать

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

что прямо противоречит концепции C++. С++ даёт прямой контроль за уровнем производительности путем возможности выбора подходящих языковых средств.

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

Это просто разные языки с вообще-то разной областью применений.

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

Проблема лишь в том, что в своё время C++ использовали даже там, где его достоинства особенно и не нужны, а недостатки очевидны. Но это не проблема С++, а просто один из периодов в истории индустрии. В конце концов, лидер индустрии (Google, как и ряд других) активно используют C++ и не слушает аналитиков с ЛОР :)

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

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

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

> как сам рубится так нормально, как другие так неадекватЪ ?)

Я и про себя тоже, естественно.

значительная часть суперфичь бесплатна - следствие хороших идей

в основе языка,

Я уже давно в сказки не верю.

a кто тут говорил что абстарктные классы в С++ костыли ?)

Согласен, что был неправ используя слово «костыли». Скажем так, при подходе CLOS абстрактные классы не нужны.

С++ язык относительно низкого уровня с кучей полу

высокоуровневых надстроек, со всеми вытекающими последствиями

Не знаю, что из этого вытекает и как мерить уровень. С++ даёт работать как на очень высоком уровне, так и на очень низком, выбор за разработчиком. А последствия вытекают из того, что это всегда был язык компромиссный, в котором практическая потребность и понимание реальной ситуации ставились выше идеальных конструкций. Соответственно, с одной стороны это делает его относительно легкой мишенью для нападок с самых разных сторон, а с другой обеспечило очень широкое распространение.

например не массово тиражируемые гуи фронтенды

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

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

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

что реально никогда DROP не делали ?)

> какое это имеет отношение к вопросу ?

действительно - к чему это вы SQL приплели?

что реально никогда DROP не делали ?)

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

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

в правиле пять классов и несколько синтетических сущностей к какому классу привязать ?
сложные правила в стиле пролога это то что не ложится в ООП удобно и аннотации не спасают

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

archimag - няшка, всё уладил хорошо

> Я уже давно в сказки не верю.

defmacro и MOP например в рунтайме ничего не стоят

Не знаю, что из этого вытекает и как мерить уровень.

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

Нет, это слишком нечётко заданная область

путь будет только гуй для корп. баз. данных например

> действительно - к чему это вы SQL приплели?
т.е. аналог вида ALTER CLASS ... ADD FIELD вам не нужен ?

> т.е. аналог вида ALTER CLASS ... ADD FIELD вам не нужен ?

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

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

> разве я этого где то утверждал ?

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

и я таки жду ответа на свой вопрос

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

> Это, если забыть про наследование.

а с наследованием нужно пробежаться по dispatch_table от самого специфичного класса до первого найденного предка — ах как сложно!

в то же время в ООП имеются правила, за соблюдением которых следит компилятор, и вот их реализовать в лиспе уже будет не просто

Поподробее тут, пожалуйста.

public private protected на доступ к членам и методам

public private protected как виды наследования

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

> в правиле пять классов и несколько синтетических сущностей к какому классу привязать ?

к специально для них созданному

сложные правила в стиле пролога это то что не ложится в ООП удобно и аннотации не спасают

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

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

> defmacro и MOP например в рунтайме ничего не стоят

defmacro, очевидно (как и шаблоны в C++) раздувают размер машинного кода.

А как так может быть, что бы MOP ничего не стоил? Как же он тогда работает? Ему никакая инфраструктура во время выполнения не нужна?

путь будет только гуй для корп. баз. данных например

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

> defmacro, очевидно (как и шаблоны в C++) раздувают размер машинного кода.

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

А как так может быть, что бы MOP ничего не стоил? Как же он тогда работает? Ему никакая инфраструктура во время выполнения не нужна?

еще раз, никаких доп. расходов по производительности и размеру объектов в рунтайме нет, MOP использует уже существующую инфраструктуру

Дельфи же :)

:) интересный ответ на boolean вопрос - могут ли С++ и CL применятся в этой нише ...

Какая технология лучше подходит?

ну хорошо, по твоей же логике если корпоративый web то php (ну или java/net для мажористых контор) ? - в филиалах же в глубинке интернет каналы тонкие и дорогие - нужно ставить локальные сервера и поддерживать - а трезвыми только php-ников найти можно, а если таких филиалов еще нет то они могут появится.

Дак чтож ты сам на CL корпоративый web делаеш ?)

> MOP использует уже существующую инфраструктуру

Какую это существующую? Конечно, она существует, раз MOP есть. Что бы MOP был возможен нужна инфраструктура, которая сама по себе и не нужна.

по твоей же логике если корпоративый web то php

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

Дак чтож ты сам на CL корпоративый web делаеш ?)

Ну, я подумал и выбрал технологию.