Страуструп про ЛИСП

> КАКОЙ ДЕБИЛ ПРИУЧИЛ ДРУГИХ ДЕБИЛОВ ПИСАТЬ «ЛИСП» ИМЕННО КАПСЛОКОМ И НИКАК ИНАЧЕ? ВОТ КАКОЙ? Я НЕ ВРУБАЮСЬ.

А какие проблемы? Ну подумаешь, архаическое написание. Многим привычно по старой литературе.

Раньше и ФОРТРАН, и ПЛ/1 писали так.

КАКИЕ ПРОБЛЕМЫ? НИКАКИХ ПРОБЛЕМ. СТАРАЯ ЛИТЕРАТУРА ОК.

PYTHON rules them all!

> PYTHON rules them all!

Python is not an acronym, unlike LISP.

Это не акроним, это имя собственное.

И самый killer-аргумент: стоило подумать, что такой сложный язык будут использовать исключительно как «улучшенный» С? Стоило. Потому что так его использовали чуть ли не до конца 90-х.

На мой взгляд, это, в основном, и обусловило популярность C++.

LISP is not an acronym too. It's stupid abbreviation only.

Python is not an acronym, unlike LISP.

Значит это какой-то свой бородатый LISP (который для AI и вообще один, ага). Теперь пишут Lisp, и при переводи это будет «лисп» (семейство), «в лиспах» (в языках семейства) - http://www.urbandictionary.com/define.php?term=lisp, http://en.wikipedia.org/wiki/Lisp_%28programming_language%29.

А ещё раньше в сорсах в upcase писали - сейчас, вроде, перестали.

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

Можно было хоть чуток подумать насчет того, что классы должны быть объектами (первого класса)? Можно. В качестве примера был Smalltalk.

Smalltalk не разу не был примером. Взяв его понимание «классов как объектов 1-го класса», мы сразу похерим возможность что-то сказать про классы во время компиляции.

А впрочем расскажи, какие операции над классами тебе нужны.

> По-настоящему абстрактные типы, ну это конечно не Страуструпа дело, класс-как-модуль — наше всиёё.

опять же раскрой тему

Я открою вам секрет. Раньше в C вместо { и } писали \( и \) потому, что не на всех машинах были фигурные скобки. Лисп еще старее - тогда не на всех машинах были строчные буквы, поэтому программы «фолдятся» в upcase для совместимости - традиции, понимаешь.

>Это невнятное хныкание.

Гы-гы-гы-гы. Допустим можно сравнить MFC и InterViews. Или привести пример Qt, разработчики которого засунули шаблоны С++ глубоко-глубоко из-за феерической «совместимости».

Даже совместимость на уровне «стандартных» библиотек оставляет желать.

почему использование в роли «улучшенного Си» - это плохо.

а) по закону подлости из обеих подходов берется только плохое б) в неиспользуемых фичах наступает разброд и шатание с точки зрения реализации ==> несовместимость.

что всё это сделает рантайм-сосуществование с Си затруднительным

Во-во.

Потому что у него перед глазами был пример Си

Потому что он стучался головой в столб. //fixed

> Потому что он стучался головой в столб.

Хм, а какой полезный язык создал ты? Или вообще, что полезного сделал?

>Взяв его понимание «классов как объектов 1-го класса»

А зачем брать *его* понимание? Да эту проблему даже в ObjectiveC решили, не говоря уж про JVM и MSIL.

>> По-настоящему абстрактные типы, ну это конечно не Страуструпа дело, класс-как-модуль — наше всиёё.

опять же раскрой тему

Букв много писать придется. Иногда, все что нам требуется от класса — это тип, но в нагрузку нам достается еще и интерфейс. Как результат, в интерфейсе приходится перечислять все доступные виды операций, и в обязательном порядке их реализовывать в конкретных классах, даже если они и не заинтересованы в этом. Поэтому, появляется множество оберток разной степени абстрактности. Как выход, можно использовать идиому Strategy, либо через микс-ины, либо через генерики и «сливать» несколько абстрактных классов в один. Но тогда, тогда интерфейс будет размазан по этим классам.

Абстрактные типы предоставляют некий баланс между контролем над интерфейсом и расширяемостью.

>Один лишь clos чего стоит, а это линеаризация иерархии нследования, mixin, etc.

А ты Одерского почитай ;)

Ну и зачем тогда была КАПСЛОКОВАЯ ДРАМА??

> почему использование в роли «улучшенного Си» - это плохо?

Потому, что в таком случае надо брать pure C, и не вы*бываться. А то, блин, массивы ручками делают, ручками, вместо того, чтоб заглянуть в справочник, и взять std::vector<ч0_то_там>. Даже те возможности, которые предоставляют плюсы, старательно не используются — и как это назвать?

> LISP is not an acronym too. It's stupid abbreviation only.

It is an acronym... «Lots of Incredibly Stupid Parentheses».

>> почему использование в роли «улучшенного Си» - это плохо?

Потому, что в таком случае надо брать pure C, и не вы*бываться.

У тебя дислексия.

А то, блин, массивы ручками делают, ручками, вместо того, чтоб заглянуть в справочник, и взять std::vector<ч0_то_там>. Даже те возможности, которые предоставляют плюсы, старательно не используются — и как это назвать?

Тяжелая дислексия.

> У тебя дислексия

Обоснуй.

> А то, блин, массивы ручками делают, ручками, вместо того, чтоб

заглянуть в справочник, и взять std::vector<ч0_то_там>. Даже те

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

используются — и как это назвать?

Я работал в трёх компаниях, где использовали С++ и подобного его использования не видел. Все, естественно, использовали std::vector и т.п. Вы вообще откуда?

> Вы вообще откуда?

Ставрополь, Северный Кавказ. :-) В профиле-же есть, кажись.

Он имел в виду ущербные препроцессорные макросы в его плюсах, да )

> Ставрополь, Северный Кавказ. :-)

Хм, переезжайте хотя бы в Краснодар или Ростов, хоть на нормальный C++ посмотрите ;)

> переезжайте хотя бы в Краснодар или Ростов, хоть на нормальный C++ посмотрите

Может, и соберусь. А пока я сам пытаюсь этот нормальный C++ делать. Интернеты, опять же. :-)

>> У тебя дислексия

Обоснуй.

Люди хотят использовать «улучшенный Си», а ты говоришь, что надо использовать обычный. Речь идет о 90-х, а ты говоришь о std::vector. Всё это как бы намекает на то, что ты не понимаешь прочитанного.

> Люди хотят использовать «улучшенный Си»

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

>> Люди хотят использовать «улучшенный Си»

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

Эээ... и что? Любой язык можно использовать бездумно.

Плюсы — это не «C с классами», а вообще очень другой язык.

Типичная точка зрения поколения Пеп^WБуста.

>Типичная точка зрения поколения

Т.е. все еще хуже? И совместимость с С была одним из факторов? И GoF были поколением песи, а Александреску — аццким сотоной?

Весь джанк-код типа MFC — норма? А малоизвестные разработки, описанные в GoF, так и остались уделом узкого круга избранных?

Пойду читать vObj Одерского. С горя.

> Весь джанк-код типа MFC — норма?

Джанк-код - это не норма // К.О.

Остальной поток сознания ниасилел.

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

Черт возьми!

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

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

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

Не делать класс, не разрешать, не определять. Зачем класс?

> А зачем брать *его* понимание? Да эту проблему даже в ObjectiveC решили, не говоря уж про JVM и MSIL.

ObjectiveC не катит, как и смоллтолк — слишком динамически типизированый

что решили в JVM и MSIL?

рефлексию сделали? ну это в плюсы можно и нужно добавить (и неясно, почему это в стандарт не внесли — есть же gcc-xml например) — но это явно не classes as first-class citizens

а вот можно ли на основе JVM и MSIL сделать нормальное множественное наследование ( то есть как раз операцию над двумя классами: C = inherit_from<A,B> ) так, чтобы вызов нестатического метода класса С

1. проверялся компилятором

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

> Не делать класс, не разрешать, не определять. Зачем класс?

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

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

Выкинь С++ и не ешь больше те грибы.

> Буста

Чего это ты на boost взъелся? Вполне себе работающая, и неплохо работающая библиотека.

>Черт возьми!

Не передергивай. Про NotImplementedException слышал?

И че ты предлагаешь?

Предлагаю выносить некоторые операции на уровень типа, а не интерфейса.

>а вот можно ли на основе JVM и MSIL сделать нормальное множественное наследование

В какой-то мере в Scala. Миксины на, правда только из trait'ов, там обычное дело. Но, ясен пень, происходит линеаризация иерархии наследования.

> Чего это ты на boost взъелся?

Я на него не взъедался. Просто новое поколение кодеров, выросшее на STL и Boost, уже достало посторять, как попугаи: «Си++ и Си - это два разных языка».

Вполне себе работающая, и неплохо работающая библиотека.

Она слишком сложна для тех возможностей, которые предоставляет.

> Не передергивай. Про NotImplementedException слышал?

А оно мне нужно?

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

Предлагаю выносить некоторые операции на уровень типа, а не интерфейса.

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

> В какой-то мере в Scala. Миксины на, правда только из trait'ов, там обычное дело. Но, ясен пень, происходит линеаризация иерархии наследования.

И у тебя, я так понимаю, есть хотя бы натянутый пример, где скаловские трейты не подходят, или твой подход «выносить некоторые операции на уровень типа, а не интерфейса» более элегантен?

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

Самое интересное, что и в скале эта проблема решена: можно в одном object'е (который по сути дела является модулем) объявить тип через type. Но как я понял в таком случае тип не будет абстрактным, т.е. мы можем делать предположения о структуре типа в других модулях.

Кстати, интересная бумажка насчет композиции и миксинов:

http://infoscience.epfl.ch/record/150347/files/gpce63-rompf.pdf

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

Конвейерному производству это расскажи.

> новое поколение кодеров, выросшее на STL и Boost, уже достало посторять, как попугаи: «Си++ и Си - это два разных языка»

Ну и чем же они одинаковы, кроме части синтаксиса и нескольких языковых конструкций? В общем случае, исключая пару-тройку HelloWorld-ов, плюсовую программу C-шный конпелятор не прожуёт. Это называется «одинаковые языки», да?

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

Нужно ещё добавить что плюснутый конпелятор не прожуёт код на си в некоторых случаях.

А что ты называешь «нестатического метода ... диспетчеризовался компилятором»? Т.е., если я опять не путаю терминологию++, статический метод проверяется во время компиляции по определению, а нестатический это динамический? Тогда он диспетчиризируется в рантайме, тоже по определению. То о чём ты говоришь, если забыть о терминологии плюсов, это что-то вроде вывода типов - чтобы было понятно при type-checking что тут будет именно объет класса C и можно специфицировать, во время компиляции, именно его метод. Но тогда не понятно зачем в языках с системой типов классы аля С++.

Уж кому а трупу страуса лучше помолчать про недостатки %-)