Подкиньте дельную книженцию про ООП на русском

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

Не совсем по ООП но мне понравилась.

Тыц

то увидели знакомое слово, и возбудились на него.

Давай попорядку. Приведённая в СИКП реализация объектов (soft objects) обладет основым качеством ООП - ad-hoc polymorphism. Типизация - утиная, говорить о наследовании интерфейсов не приходится, наследование реализации - через аггрегирование. Вызов унаследованных методов - целиком на совести программиста. Инкапсуляция наличествует, пока сам её на нарушишь. Или же вы предпочитаете ограничивать ООП тем вариантом, который основан на классах?

>В ООП-фанатизме ничего плохого, как в lisp-фанатизме, фп-фанатизме и т.п. Через ООП можно решить большее количество задач.

Есть. Фанат, охваченный внушённым энтузиазмом, перестает трезво воспринимать сигналы реальности. Отсюда большинство срачей. Когда за большим количеством понимают что-то в духе 99.9%.

Про распределенные вычисления - так тогда давай лучше Fortran. C++ для математики не лучший язык все же, да и не его сильнейшая сторона мат.пременение. Большинство языков программирования позволяют проводить распределенные вычисления, и что? Аргумент С++-фапера, который дальше С++ не ушел.

Большинство языков ещё и являются тьюринг-полными, и что? Медаль на шею, паровоз навстречу.

Хочешь поговорить про фанатизм — посмотри сперва в зеркало и сними сутану. Своей репликой про 99,9% ты себя позиционировал именно как фанатика. Я сам уже высказывался в том духе, что хую вертел привязку к любому языку. Я могу писать (и призываю остальных) и на том, что подходит в данном случае. Хоть на форте-лиспе, хоть на плюсах, даже на фортране. Который, кстати, тихонько подыхает, по объективным причинам. То, для чего он давно использовался, сейчас и удобнее, и мощнее решать на C++ (и решают, естественно), так что ниша сжимается. Для распределённых вычислений в сложном контексте фортран уже малопригоден ввиду негибкости, и тянут его только из-за старого-старого кода, настолько ужасного, что его боятся трогать. С++ же вполне пригоден для задач вроде распределённых вычислений и управления, при грамотном применении.

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

Если ты где-то видел только работу C++-пионеров, это ни о чём в принципе не говорит, пионеров хватает везде. Но виноват в проблемах, конечно же, С++. Сами выбрали, но язык виноват. Что я могу сказать про твою задачу, не видя её? Ничего. Может, там ява была нужна с самого начала, почём мне знать? Зато про другие проекты я могу сказать, что никакая java, никакой erlang туда не лезет, и их нужно-таки писать на чём-то, что позволяет решить возникающие проблемы. Уж конечно не на C(неуправляемый copy-paste код будет).

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

>Приведи мне нормальный аналог связки C++/Qt4 для безпроблемного кроссплатформенного программирования.

C++/ACE, C++/Boost. GUI на фиг не сдался на плюсах писать, ненужное (как правило) напряжение сил. Скриптовый язык (руби/питон) в руки и выбирай — qt, wxWidgets, Fltk, gtk, etc. Бывает гибче и надёжнее всякие гуи даже не смешивать с основной логикой в одном процессе. Можно хоть десяток разных морд наплодить, на разных тулкитах.

Вообще для малопроблемного кроссплатформенного программирования — java, кроме шуток. А для использования C++ нужны и веские причины, и железная дисциплина в команде. Но причины, и команды такие действительно существуют, как бы это местным пламенным пионерам не было тошно признавать, эта ниша пока никуда не денется. C++ — для тех, кто проблем не боится и может мыслить без отрыва от реальности. Но ты должен знать альтернативы, чтобы было, из чего выбирать.

Ты, вася, баран совсем, чтоли, в SICP объектов не увидеть?
Там во второй главе все на тайптегах и CLOS-подобных обобщенных функциях делается. А в третьей так вообще классическое ООП, только без наследования.

Ого, давно туто таких долблюбителей плюсов не вылазило.

> По настоящему хорошие инструменты чаще всего малопопулярны ввиду своей сложности.

Какая замечательная мантра! Классическая, я бы сказал.

Вы никогда не задумывались о том, ЧТО формирует картину популярности и распространенности языков? Вот так вот миллионы быдланов выстроились колонной, и пошли изучать C++ и Жаву. Коллективное бессознательное, ага.

Распространенность языков диктуется востребованностью в промышленном программировании, и только ей. А промышленность, как я уже неоднократно замечал, - сложный саморегулирующийся макроорганизм. И выбор его обусловлен следующими требованиями: скорость разработки, качество продукта, преемственность, управляемость и еще куча всего. И способность/неспособность быдла освоить конкретный инструмент - в этот список не входит.

Именно поэтому популярность языка и его сложность/простота - вещи ортогональные. Но, разумеется, проще свалить непопулярность на «95% населения», чем признать технические изъяны языка, иногда фатальные.

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

А вот и еще один замечательный миф: «Лисп - простой язык».

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

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

> ad-hoc polymorphism

Типизация - утиная

говорить о наследовании интерфейсов не приходится

наследование реализации - через аггрегирование

целиком на совести программиста

Инкапсуляция наличествует, пока...

Простите, но такое «ООП» можно натянуть хоть на Фортран.

>Ого, давно туто таких долблюбителей плюсов не вылазило.

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

P.S. По-вашему, популярные языки популярны в силу своей простоты. Вы вообще открывали когда-нибудь стандарты Java, C++? Если вы осмеливаетесь утверждать, что эти языки просты (особенно С++), то у меня для вас плохие новости.

>распределённые вычисления

Fortran+MPI :)

>Если вы осмеливаетесь утверждать, что эти языки просты (особенно С++), то у меня для вас плохие новости.

это не простота, а низкий порог вхождения

>Fortran+MPI :)

Не фонтан. Ручная работа с сообщениями, инкапсулированная работа с сетью, далеко не лучшее решение. Ну для плоского маленького кластера — может быть.

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

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

...и, кстати, более перспективной в этой области лично мне кажется Fortress, а не X10, Chapel etc. Правда, непонятно, что будет с этим языком в свете истории с Sun'ом и Oracle'ом. Хорошо хоть они открыли бложек, в который иногда блогает сам Guy Steele, Jr.

Простите, но такое «ООП» можно натянуть хоть на Фортран.

Ну тогда Python - тоже не ОО язык, его отличия - только по части наследования реализации. Что касается инкапсуляции - в каком языке её нельзя нарушить?

Раздвоение личности?

> Там во второй главе все на тайптегах и CLOS-подобных обобщенных функциях делается.

То, что в SICP рассматриваются методы, при помощи которых в CL было нагромождено подобие ООП - не приближает SICP к самому ООП ни на шаг. Точно так же можно было бы заявлять, что книжка по Фортрану насквозь кишит ООП, потому что в Фортране-90 есть функции и указатели, а в С++ ООП сделано через vtables, ага.

А в третьей так вообще классическое ООП, только без наследования.

«А в третьей так вообще построили классический автомобиль, только без рулевого механизма», ага.

Ты, вася, баран совсем

В который раз поаплодируем типичному представителю Лисп-сообщества за его предельную деликатность, интеллигентность и воспитанность :)

в CL было нагромождено подобие ООП

Только это «подобие ООП» более общее и функциональное, чем «классическое ООП».

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

80% выпускников технологических вузов америки считают их сложными, как и 99,9% быдла, которая не способна пойти дальше С++. сам же осилил и лисп(схему) и форт.

Есть. Фанат, охваченный внушённым энтузиазмом, перестает трезво воспринимать сигналы реальности.

Почему-то такие чаще всего пишут на java, python, c++

Большинство языков ещё и являются тьюринг-полными, и что? Медаль на шею, паровоз навстречу.

Вот именно, и что? Это был твой аргумент про Цэ++

Хочешь поговорить про фанатизм — посмотри сперва в зеркало и сними сутану. Своей репликой про 99,9% ты себя позиционировал именно как фанатика.

Не отрицаю. Считаю ООП-подход наиболее гибким

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

Обынчно пишут на том, на чем требуется заакзчику (которому частно не пофиг по массе объективных причин)

Который, кстати, тихонько подыхает, по объективным причинам.

Да неужели! Т.е. масса библиотек кануло в лету, а чисто академические языки стали устаревать? В своей нише фортран держит позиции. Если конкретно ты на нем не пишешь - не значит, что он стал неиспольуемым.

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

Что может быть уже математических расчетов?

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

Неасилил чтение кода фортрана? Тянут его потому, что он заточен под свою нишу. А С++ не трогают из-за отвратного, падающего и непригодного нового кода.

С++ же вполне пригоден для задач вроде распределённых вычислений и управления, при грамотном применении.

А почему бы тебе для этого не использовать в конце концов тот же Clean? Ну или на худой конец Erlang? По моему они более пригодны. Почему ты их не применяешь? Твоей логике противоречит.

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

А пока надо писать на малопригодном для программирования С++?

Если ты где-то видел только работу C++-пионеров, это ни о чём в принципе не говорит, пионеров хватает везде.

Люди, работающие более 20 лет над управляемыми скважинами - явно не пионеры)

Но виноват в проблемах, конечно же, С++. Сами выбрали, но язык виноват. Что я могу сказать про твою задачу, не видя её? Ничего.

Проблема в Страуструпе, который изуродовал Си и сделал Си для быдлокодеров.

Может, там ява была нужна с самого начала, почём мне знать? Зато про другие проекты я могу сказать, что никакая java, никакой erlang туда не лезет, и их нужно-таки писать на чём-то, что позволяет решить возникающие проблемы. Уж конечно не на C(неуправляемый copy-paste код будет).

В нефтянке? На яве? Да вы батенька ананист. Еще бы дрова на яве предложили писать. А про Си - явно на нем мало работал. Видимо в твоем представлении это почти что asm в котором даже тех де функций нет.

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

Для тебя тоже. Выше по тексту обосрал фортран. Сначала сам пгерестань так делить языки. Если бы не делил: 1) не обосрал бы фортран; 2) не восхалял бы С++ (у которого вагон и маленькая тележка проблем в реализации); 3) перестал бы доказывать фанатизм других людей, если сам при этом фанатик С++

Именно поэтому популярность языка и его сложность/простота - вещи ортогональные. Но, разумеется, проще свалить непопулярность на «95% населения», чем признать технические изъяны языка, иногда фатальные.

Для справки - американцы используют ФЯ для отсева студентов. Статья «Опасность обучения Java»

А вот и еще один замечательный миф: «Лисп - простой язык».

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

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

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

>Обынчно пишут на том, на чем требуется заакзчику (которому частно не пофиг по массе объективных причин)
Т.е. ты реально считаешь что заказчик вот приходит и говорит «хочу ERP на плюсах!» или там «хочу map-reduce фреймворк на эрланге!» да ты ебанись. где эта страна эльфов? я тебя обрадую, заказчику в 99% случаев абсолютно похую на чём будет работать система, лишь бы реализовала требуемый функционал. так было, есть и будет. А уж почему новые проекты пишутся на С++, так это наверное потому что вокруг поголовно блять все дебилы, один Meerkat умный, дайте ему gvim и gforth, пусть ебёцца.

>>почему до сих пор никто не порекомендовал топикстартеру SICP?

Между прочим, там объясняется как ооп устроено изнутри, чего я не припомню ни в одной книжке с цветастой надписью «ООП» на обложке.

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

По настоящему хорошие инструменты чаще всего малопопулярны ввиду своей сложности.

Какая замечательная мантра! Классическая, я бы сказал.

Поддерживаю, это типичное самоубеждение для фанатов. При этом им как правило этих аргументов для самоубеждения не хватает и они начинают бегать по ЛОРам в поисках пациентов со схожими диагнозами.

Про распределенные вычисления - так тогда давай лучше Fortran...

Бугага, ты сам то много нараспараллеливал на фортране?

Большинство языков программирования позволяют проводить распределенные вычисления, и что?

И то, что C/C++ позволяют делать это легко и быстро.

В своей нише фортран держит позиции. Если конкретно ты на нем не пишешь - не значит, что он стал неиспольуемым.

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

Люди, работающие более 20 лет над управляемыми скважинами - явно не пионеры)

Если они все 20 лет распараллеливали чей-то креатив на фортране - ничего удивительного, пионеры чистой воды.

А почему бы тебе для этого не использовать в конце концов тот же Clean? Ну или на худой конец Erlang? По моему они более пригодны. Почему ты их не применяешь?

Ну приведи мне пример библиотеки для Erlang скажем для решения системы диффуров с матрицей 1000*1000.

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

Люди, работающие более 20 лет над управляемыми скважинами - явно не пионеры)

Выслуга лет невежеству не помеха. Не аргумент вообще.

Проблема в Страуструпе, который изуродовал Си и сделал Си для быдлокодеров.

Проблема, как всегда, в людях. В том числе вроде тебя, кому обязательно нужны волшебные правильные инструменты, чистые и непорочные как слеза младенца. Инструменты для Профессионалов. Если ты не понимаешь, что есть задачи, которые на си вместо высокоуровневого языка будут решать только маньяки (ибо время реализации и усилия на поддержку и развитие взлетают до небес), с тобой не о чем разговаривать. BTW, си и называют переносимым ассемблером за его примитивность.

Неасилил чтение кода фортрана? Тянут его потому, что он заточен под свою нишу. А С++ не трогают из-за отвратного, падающего и непригодного нового кода.

Нет, болезный, в том-то и беда, что осилил. Я видел собственными глазами подобную ситуацию как раз с фортраном: код, который править нельзя (кое-как работает и слава богу). Это конечно человеческий фактор, много лет назад писали на фортране очень грязно, да и сейчас тоже не рай. Это камень не в сам фортран, а в те реалии, в которых он развивался и из-за которых он ещё пыхтит. Повторяю: объективно кроме уже написанного кода и небольшой когорты любителей других бонусов от этого языка нет. Тот же самый код можно гибче, более управляемо имплементировать на C++, что и происходит постепенно. Более того, на C++ можно успешно писать много чего ещё, кроме числодробилок. А раз у языка нет особых бонусов, то в конкуррентной борьбе число новых проектов на нём будет стремиться к нулю, постепенно они исчезнут вовсе, эту тенденцию можно наблюдать, если вылезти из раковины. Например вот так примерно дела обстоят сейчас: http://langpop.com

Более чем красноречивые графики. Будет мало — гугл в помощь. Ну? Что такого-то? Много лет прошло, кое-чему научились, фортран своё пожил, пора на покой, чего упираться-то? Я тебя обрадую: и C++ не вечен, и ява, и остальные. Это эволюция.

Что может быть уже математических расчетов?

Пустое множество.

В нефтянке? На яве? Да вы батенька ананист.

Феерично мыслишь, товарищ грамотей. Что есть пресловутая «нефтянка» в твоём понимании — сигналка на контроле какой-нибудь трубы, рабочее место оператора, инфраструктура для управления всей системой? Могут java и в космос запустить, были бы условия. Там, кстати, надёжность кода очень ценится, повыше, чем производительность. А в чём непреодолимая проблема, расскажешь?

А почему бы тебе для этого не использовать в конце концов тот же Clean? Ну или на худой конец Erlang? По моему они более пригодны. Почему ты их не применяешь? Твоей логике противоречит.

Это по-твоему, эльф лесной. А я реалист. Если мне от этих инструментов в данном проекте вместо помощи головная боль, я ими пользоваться не буду. Будет помощь — буду пользоваться. Проекты развиваются и существуют не в вакууме, сколько раз тебе нужно сказать, чтобы дошло?

Для тебя тоже. Выше по тексту обосрал фортран. Сначала сам пгерестань так делить языки. Если бы не делил: 1) не обосрал бы фортран; 2) не восхалял бы С++ (у которого вагон и маленькая тележка проблем в реализации); 3) перестал бы доказывать фанатизм других людей, если сам при этом фанатик С++

Восхвалял? Я? А кто выше писал про дисциплину в команде? Где я сказал, что с языком не будет проблем? Это реальная жизнь. Фортран я не «обсирал», а поставил на то место, которое он занимает: выходящий из употребления язык. Ты же не стал опровергать аргумент на счёт гибкости? Ну правильно. Это же правда. А означает это правда, что языку конец, чуть выше я ткнул в детали, почему это так. Если это в твоём понимании «обсирал», могу развести руками. Это называется «правда глаза колет».

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

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

Недоумок, для C++ просто нет такого места, где он был бы нужен.

О, недоумки-овцеёбы подтянулись.

день торта в тематических разделах...

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

Ага, блин. Навешиватель ярлыков, не отличающий Лисп от Коммон Лиспа. Очаровательно.

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

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

Фортран действительно уже давно превратился в read-only язык. И используют его в основном только из Си и Си++.

Да, C++ «плох», но почему-то JVM именно на нем и написана. Это еще лишний раз доказывает — каждому языку своя ниша.

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

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

Теперь переходим к реальным сложностям лиспа. Послушаем человека, который в течение 9 лет программировал на лиспе:

Чем плох?
- Плохо устроена модульность
- класс не создаёт пространства имён, как в Java и C++.
- статической типизации по сути нет, из-за этого ООП несколько тормозит (хотя я думаю, всё ещё в разы быстрее того же питона)
- ООП плохо масштабируется, поскольку функции не принадлежат классам. В С++ можно иметь foo::add(один аргумент) и bar::add(два аргумента) а в лиспе сигнатура функции фиксирована и не зависит от типов.
- во многих конструкциях действительно есть лишние скобки
- компилятор редко показывает конкретную строчку с ошибкой
- вообще, со сборкой плоховато
- лисперы - в основном теоретики и редко доводят хорошие идеи до полного и полезного воплощения

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

Простые задачи писать не лиспе неудобно. Да, где-то можно с помощью DSL сделать из 10 строк 1000. Но DSL не покрывают всех случаев. В итоге, всё равно DSL будет генерить только треть кода, остальные две трети придётся писать вручную. Именно поэтому лисп - среды, которые я видел, настолько убоги - просто на лиспе неудобно программировать.

К сожалению, у тега url едет крыша, привожу ссылки как есть:
den73 переходит на Python (комментарий)
Создатель Python разочарован в Scala (комментарий)

Это что же, человек за 9 лет никак не избавится от «лютого когнитивного диссонанса»? Или, может, не все в порядке в консерватории, а?

> Плохо устроена модульность

как-то расплывчато.

класс не создаёт пространства имён, как в Java и C++.

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

ООП плохо масштабируется, поскольку функции не принадлежат классам. В С++ можно иметь foo::add(один аргумент) и bar::add(два аргумента) а в лиспе сигнатура функции фиксирована и не зависит от типов.

т.е. человек за 9 лет не узнал про MOP?

во многих конструкциях действительно есть лишние скобки

и про defmacro?

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

в Схеме чаще наоборот — показывает, а в CL да, согласен, скорее редкость.

вообще, со сборкой плоховато

опять пространная фраза и ни грамма конкретики

Только было хотел поинтересоваться, почему до сих пор никто не порекомендовал топикстартеру SICP?

Потому что там нет того ООП, которого нужно TC, К.О. :)

А ещё, вы сами рушите всю свою критику, называя «лиспом» очень специфичный его (семейства) диалект - Common Lisp.

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

Теперь переходим к реальным сложностям

Ну так а где нет реальных сложностей? Вы хотите доказать что «лисп» не серебряная пуля? Ну так это не надо доказывать - быть-то серебряной пулей, то за 50 лет уж как-нибудь выстрелило бы :)

во многих конструкциях действительно есть лишние скобки

Праздничный бред!1 Какой сегодня праздник?

Лиспер жалуется - скобок много :(

;)

Осень приближается. Шизофреники активизировались.

> Недоумок, для C++ просто нет такого места, где он был бы нужен.

+1, они прото не понимают этого. И фапают на С++. С++ культ страшнее лисперского - в нем ты тем кручем, чем меньше в программировании понимаешь и чем больше фапаешь на С++

>> +1, они прото не понимают этого. И фапают на С++. С++ культ страшнее лисперского - в нем ты тем кручем, чем меньше в программировании понимаешь и чем больше фапаешь на С++

О, типичная школота нарисовалась... Скоро первое сентября, училке хризантемы купил?

>> Ну так это не надо доказывать - быть-то серебряной пулей, то за 50 лет уж как-нибудь выстрелило бы :)

А кто тебе сказал, что лиспу, в его сегодняшнем виде, 50 лет? До принятия стандарта Лисп был сборищем из полутора десятков несовместимых диалектов с разными фичами и странностями, распространенными каждый в своем узком кругу приверженцев/разработчиков/экспериментаторов.

Скажи спасибо, что эту кашу привели в порядок в 1994-году. Итого, лиспу 16 лет.

> Да, C++ «плох», но почему-то JVM именно на нем и написана. Это еще лишний раз доказывает — каждому языку своя ниша.

Что-то новое. Насколько знаю, JVM все же написана на Си. Или у кого-то есть другая информация?

сановская jvm.

Скажи спасибо, что эту кашу привели в порядок в 1994-году. Итого, лиспу 16 лет.

Да семейство это, семейство :) Называется «Лисп» (в древности писали ЛИСП). И ему 50 лет, да.

Common Lisp? Насколько я помню, первый вариант стандарта разрабатывался в 1987-1989, а в 1994 это уже ANSI-2. Т.е. CL за 20 уже. И чтобы не путать с Scheme (elisp, clojure, what ever) лучше говорить не «лисп» а CL.

> А вот и еще один замечательный миф: «Лисп - простой язык».

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

Префиксно-s-exp-овый синтасис заточена на рекурсивный обход кода. А reader macro добавляет всякие синтаксические плюшки. В остальном синтаксис не сильно выделяется из прочих регулярых.

К всему прочему CL позволяет делать индивидуальные read table для каждого пакета, что позволяет работать в пределах одного образа в одном пакете с кодом на питоне, в другом на js, а в третем поменять круглые скобки на фигурные. Это я все про нетривиальные вещи.

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

Опытный лиспер в отличае от вас знает, что в пакете :cl aka стандартная библиотека всего около 1000 экспортированых символов. А если считать точно, то в sbcl например 977 из которых 752 функции и спец. формы.

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

На С pe/elf пускалка и немножко рантайма (а может он и весь на жабе не помню точно). Компилятор и библиотки на самой жабе как ни странно.

>> К всему прочему CL позволяет делать индивидуальные read table для каждого пакета, что позволяет работать в пределах одного образа в одном пакете с кодом на питоне, в другом на js, а в третем поменять круглые скобки на фигурные. Это я все про нетривиальные вещи.

А грамматику языка кто будет реализовывать? Трудозатраты сравнимы с написанием парсера/лексера для питона на любом языке.

Да, где-то можно с помощью DSL сделать из 10 строк 1000. Но DSL не покрывают всех случаев.

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

> Что-то новое. Насколько знаю, JVM все же написана на Си. Или у кого-то есть другая информация?

Sun HotSpot JVM - на миксе из С++ и Си.
(С++ взялся из Animorphic Smalltalk VM, http://strongtalk.org/).
Компилятор и основные библиотеки (за исключением native) написаны на самой Java.

Сановская же Maxine написана уже на самой Java. (http://labs.oracle.com/projects/maxine/)
Айбиэмная JVM написана, кажется, на Смоллтолке (http://www.ibm.com/developerworks/java/jdk/linux/download.html).

>> К всему прочему CL позволяет делать индивидуальные read table для каждого пакета, что позволяет работать в пределах одного образа в одном пакете с кодом на питоне, в другом на js, а в третем поменять круглые скобки на фигурные. Это я все про нетривиальные вещи.

А грамматику языка кто будет реализовывать? Трудозатраты сравнимы с написанием парсера/лексера для питона на любом языке.

На самом деле поменьше потому что потоковый парсер в связке reader/read-table уже имеется.

Но вобще я говорил о том что синтаксис CL в связке с read-table штука относительная и изменяемая под нужды конкретной задачи. А возможности CL позволяют развести разработчиков по разным пакетам и не мешать друг другу. Что вобщем-то и ценно. Ну и относительно бесшовно интегрировать «нетривиальные вещи» в систему. И так бесшовно переключать синтаксис в REPL-е. Например в clsql c базой можно работать на лиспе а можно при желании одной командой переключится в режим чистого SQL иработать с базой напрямую. Не столь уж частая операция, но в нужный момент очень радует. Такими вот предусмотренными мелочами в дизайне CL и притягивает.

>Айбиэмная JVM написана, кажется, на Смоллтолке

Любопытно. А где можно про это прочитать? По линку просто загрузка.