LINUX.ORG.RU
Ответ на: комментарий от MaZy

> приведи пример, когда оправданно?

Один характерный и распространённый пример, когда оправданы C++: высокопроизводительные графические приложения — движки игр и сред 3d-проектирования. Нужна производительность уровня Си с одной стороны, с другой же стороны игра - это не ядро, которое 20 лет в разработке, нужно за 2 года склепать, кое-как отладить, выпустить и забыть. C++ имеет смысл при такой постановке вопроса.

geekless ★★
()
Ответ на: комментарий от MaZy

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

babusha
()
Ответ на: комментарий от MaZy

Не могу: мне С во все поля хватает.

А вообще, подозреваю, что в случае реальной необходимости ООП и наследований классов...

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от MaZy

> С и С++ сильно отличаются? это же родственники, не?

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

Если все-таки решишь изучать C++, обязательно изучи этот сайт http://yosefk.com/c++fqa/ и подумай над своим выбором ещё раз.

nozh
()
Ответ на: комментарий от Eddy_Em

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

Добавлю, что в случае реальной необходимости, ООП и наследование как в C++ можно сделать в C на структурах и указателях на функцию.

nozh
()
Ответ на: комментарий от nozh

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

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

> Но я примера придумать не могу.

Быдлокодинг игровых движков. И то не всяких, впрочем. Я, на самом деле, других примеров тоже сходу найти не могу. Во всех случая получается что: либо экстремальная производительность не критична (или проблемные места можно вынести в отдельный модуль на Си), либо высокоуровневость некритична, либо наоборот средств Си++ недостаточно для обеспечения нужной степени высокоуровневости.

geekless ★★
()
Ответ на: комментарий от MaZy

Госспади, и как меня в этот топик занесло-то???

приведи пример, когда оправданно?

Не так и редко оно оправдано. Дело даже не в поддержке ООП, она, как уже сказали, и в С организуется, если надо. А всякие километровые иерархии и множественные наследования - это имхо зло, в коде потом хрен разберешься.

Плюсы позволяют гораздо меньше думать о всякой рутине типо освобождения ресурсов в случае ошибки (RAII, smart pointers). И это очень сильно сокращает спектр ошибок, которых можно наделать. И код более емким становится, больше смысла, меньше вознию. Ну и благодаря шаблонам там куда более богатые возможности в компайл тайме. Чего стоят хотя бы Boost.MSM, Boost.Spirit. А если уж про C++0x (грядущий стандарт) говорить...

Если конкретных целей стать программистом нету - поддерживаю совет изучить Scheme по SICP. Хотя, может оказаться не самым простым чтивом.

ratatosk
()
Ответ на: комментарий от Eddy_Em

> либо создавать в ней объект - родительскую структуру

Чуть больше букв писать придётся, да.

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

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

nozh
()
Ответ на: комментарий от nozh

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

Смысл множественного наследования я себе вообще слабо представляю за исключиением каких-нибудь утилитарных классов типа ref_counted, noncopiable. А вот RTTI, exceptions и шаблоны ограничивают пожалуй только в embedded. Без этого всего C++ будет просто кастрированным унылым говном.

ratatosk
()
Ответ на: комментарий от Gorthauer

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

«Некоторый скилл» заключается в следующем:

Язык заставляет программиста изучить систему метапрограммирования через шаблоны, паттерны, различные механизмы и принципы декомпозиции программы, управления памятью и работы с указателями (глубокое копирование, смарт указатели, интерфейсные указатели, 100500 реализаций коллекций и итераторов, грани, фабрики, объекты классов, выделение памяти из пула, множественная передача, ручной подсчёт ссылок, автоматический подсчет ссылок... блджад! кажется, я могу перечислять названия этих магических заклинаний бесконечно!), освоить парочку запутанных библиотек шаблонов, научиться читать и понимать 10-строчные сообщения об ошибках, состоящие из <<<<>>>>, реализовать в процессе всего этого несколько матерых велосипедов, чтобы понять изученное, и... И ничего не даёт взамен.

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

geekless ★★
()
Ответ на: комментарий от geekless

и... И ничего не даёт взамен.

Тред потихоньку зарастает жиром.

Представьте себе такую ситуацию. Есть десктоп на котором стоит система с гномом или КДЕ или чем-то ещё, неважно. И абсолютно весь софт, кроме ядра, написан питоне/руби/лиспе. Все демоны, системные библиотеки, рабочий стол, офис, IDE, разный вспомогательный софт. Представили? А теперь подумайте как это все будет адово тормозить, жрать память в неимоверных количествах на пустом месте. Все эти ваши питоны могут нормально работать лишь потому, что большая часть остального софта написана на C/C++.

Эх... Времена изменились. Раньше термин «высокий уровень» по отношению к языку подразумевал наличие слоя абстракции над системой команд процессора. Языком высокого уровня вполне можно было назвать Си или Паскаль. Теперь «высокий уровень» подразумевает высокий уровень потребления машинных ресурсов.

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

> Представьте себе такую ситуацию. Есть десктоп на котором стоит система с гномом или КДЕ или чем-то ещё, неважно. И абсолютно весь софт, кроме ядра, написан питоне/руби/лиспе.

Тред потихоньку зарастает жиром.


Всего два абзаца переставил, и даже развернутый ответ писать не надо.

geekless ★★
()
Ответ на: комментарий от geekless

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

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

anonymous
()
Ответ на: комментарий от anonymous

> результат жрет память и тормозит в 10-100 раз больше чем аналог на крестах?

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

geekless ★★
()
Ответ на: комментарий от geekless

> Тяжко там вам приходится в параллельной реальности.

Добро пожаловать, на планету Земля, брат по разуму! Да, у нас тут, в XXI веке дела обстоят именно так.

Первый контакт, блджад...

anonymous
()
Ответ на: комментарий от pathfinder

> И абсолютно весь софт, кроме ядра, написан питоне/руби/лиспе.

лиспе

Кстати, кто юзал EQL? Как оно?

anonymous
()
Ответ на: комментарий от pathfinder

Еще один непониматель того, что:

1) имеет значение не абсолютная скорость выполнения алгоритма, а скорость работы программы относительно налагающихся на неё требований производительности;
2) совершенно ничто не мешает писать критичные участки на Си — как отдельные процессы, так и модули, вызываемые из другого языка, и результат получается ничуть не хуже, и удосбтво разработки ничуть не страдает;
3) требования программы к ресурсам вообще в общем случае никак не коррелируют с используемым языком, а коррелируют с алгоритмами, применёнными в. А уж тормозящих на пустом месте быдлокодов на плюсах написано столько, что все лиспы, питоноруби и тикли вместе обзавидуются такому «эффективному» расходованию вычислительных мощностей.

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

geekless ★★
()
Ответ на: комментарий от ratatosk

> Смысл множественного наследования я себе вообще слабо представляю за исключиением каких-нибудь утилитарных классов типа ref_counted, noncopiable. А вот RTTI, exceptions и шаблоны ограничивают пожалуй только в embedded.

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

Проблема с exception handling в том, что exception-safe код довольно сложно писать, и очень просто допустить в нем ошибку, приводящую к утечке памяти или другого ресурса. Намного проще не использовать исключения вообще.

Шаблоны хорошая штука, но то, как они используются в stdlib и boost - это жуть. Медленно компилируется и на какую-нибудь простенькую ошибку (например вместо == написал =) компилятор выдает несколько страниц текста, в котором даже намёка нет на истинную причину ошибки.

Вобщем эти фичи унылое говно.

Без этого всего C++ будет просто кастрированным унылым говном.

Следовательно C++ - унылое говно само по себе.

nozh
()
Ответ на: комментарий от ratatosk

> Плюсы позволяют гораздо меньше думать о всякой рутине типо освобождения ресурсов в случае ошибки (RAII, smart pointers). И это очень сильно сокращает спектр ошибок, которых можно наделать. И код более емким становится, больше смысла, меньше вознию. Ну и благодаря шаблонам там куда более богатые возможности в компайл тайме. Чего стоят хотя бы Boost.MSM, Boost.Spirit. А если уж про C++0x (грядущий стандарт) говорить...

YOU* are full of bullshit. (c) Linus Torvalds

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.

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.

anonymous
()
Ответ на: комментарий от ratatosk

Не так и редко оно оправдано. Дело даже не в поддержке ООП, она, как уже сказали, и в С организуется, если надо. А всякие километровые иерархии и множественные наследования - это имхо зло, в коде потом хрен разберешься.

Лиспы позволяют гораздо меньше думать о всякой рутине типо освобождения ресурсов в случае ошибки (GC). И это очень сильно сокращает спектр ошибок, которых можно наделать. И код более емким становится, больше смысла, меньше вознию. Ну и благодаря defmacro там куда более богатые возможности в компайл тайме. Чего стоят хотя бы loop, iter. А если уж про haskell (грядущий мейнстрим) говорить...

P.S. не мог не исправить.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

Так и запишем: ниасилил.

defmacro ... Чего стоят хотя бы loop, iter.


Так и запишем: для реализации самых примитивных конструкций нужны костыли (макро). Жабщики и плюсовики смотрят на тебя, как на говно.

haskell (грядущий мейнстрим)


Юноша бледный со взором горящим. Тут вон ещё один такой же считает, что будущее — за кодогенерацией на CL. Что же вы не можете с соседями по секте договориться? Почему вы противоречите друг другу?

anonymous
()
Ответ на: комментарий от anonymous

>> loop, iter.

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


Жабщики и плюсовики не имеют конструкций, сопоставимых по мощности и удобности с iter. Так что не надо про примитивные конструкции, iter совсем не примитивный.

Что же вы не можете с соседями по секте договориться?


Во-первых, сект нет, угу. Во-вторых, лисперы и хаскелисты самые ярые друг друга ненавистники ) Ибо языки диаметрально разные.

archimag ★★★
()
Ответ на: комментарий от anonymous

Почему вы противоречите друг другу?

Потому, что сколько лисперов, столько и взглядов на лисп. Один лиспер пишет ООП код как на жабе, только перимущества CLOS и сигнального протокола использует во все поля. Другой заморачивается с хитрооптимальной многоуровневой кодогенерацией, а третий может лепить чистые ФВП и писать программу на свёртках и отображениях.

Всё это лисп, но программы выйдут существенно разные. Ибо язык сей вельми могуч и развит. В отличии от других ЯП, кои примитивны и все фичи в них гвоздями прибиты. Вот и выходят их пользователи узколобыми фанатиками.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

> Ибо язык сей вельми могуч и развит.

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

Kuka ★★
()
Ответ на: комментарий от Kuka

Лисп опоздал к раздаче программерского пирога. Если бы SBCL в его нынешнем состоянии перенести на 20 лет назад (половина (программ (писалась (бы (на (круглых (скобках))))))). Однако в момент формирования индустрии лисп был тормозным академическим проектом для искусственного интеллекта и в таком качестве не был готов для промышленного использования. Сейчас готов, но поезд уже ушёл.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

академическим проектом для искусственного интеллекта и в таком

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



Это не совсем так. CL никогда не был академическим языком. Его использовали американские военные и в NASA для реально больших систем. А это очень серьёзные конторы с большим количеством программистов. Однако...

Первое: отдача от CL не соответствовала тому колличеству бабла, которое в него вкладывали.

Второе: CL просто не работал на x86 и да, не мог поучаствовать в разделе пирога. Собственно, в этом плане его судьба схожа с участью Unix. Но юникс был спасён одним талантливым скандинавским студентом, а в мире CL такого не оказалось.

Третье: в то время просто ещё не было успешного опыта использования динамических языков для разработки промышленных проектов, что приводило к значительным проблемам интеграции.

archimag ★★★
()
Ответ на: комментарий от archimag

CL никогда не был академическим языком.

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

ugoday ★★★★★
()
Ответ на: комментарий от archimag

> юникс был спасён одним талантливым скандинавским студентом

4.2

Юникс был спасен группой людей во главе с талантливым американским программистом.

LamerOk ★★★★★
()
Ответ на: комментарий от ugoday

>Согласен. «академический» не совсем верное слово, т.к. он был создан для прикладного программирования.

Над этим думаю ТС должен сам позаботиться в первую очередь, при всем уважении, не вижу lisp в роли языка для системного программирования.

bukinist
()
Ответ на: комментарий от bukinist

> при всем уважении, не вижу lisp в роли языка для

системного программирования.


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

Хотя некоторые пытались (или даже пытаются до сих пор) использовать его и для этого тоже, например: http://common-lisp.net/project/movitz/movitz.html

archimag ★★★
()
Ответ на: комментарий от archimag

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

интересно - чем американские военные отличаются от ссср-овских ;-)

bukinist
()
Ответ на: комментарий от bukinist

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

интересно - чем американские военные отличаются от ссср-овских ;-)

Кстати сссровские военные в это времф писали в машкодах и не парились.)))

anonymous
()
Ответ на: комментарий от anonymous

Сссровские военные не заказывали языков программирования.

LamerOk ★★★★★
()
Ответ на: комментарий от anonymous

> Кстати сссровские военные в это времф писали в машкодах и не парились.)))

В Совиет Раша машкоды писали на сссровских военных и не парились.

// обвиос фикс

anonymous
()
Ответ на: комментарий от geekless

Толстота то. Это паттерны у нас стали языкозависимыми.

Gorthauer ★★★★★
()
Ответ на: комментарий от MaZy

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

Reset ★★★★★
()
Ответ на: комментарий от archimag

Деструкторов в Си действительно нет, поэтому надо очень много заниматься микроменеджментом. А аналоги контейнеров stl в виде tree.h/queue.h это ужаснах.

Reset ★★★★★
()
Ответ на: комментарий от archimag

> как будто для С уже нет готовых реализаций этих «велосипедов».

Для Си нет _общепринятых_ реализаций велосипедов.

LamerOk ★★★★★
()
Ответ на: комментарий от Reset

> Деструкторов в Си действительно нет, поэтому надо очень

много заниматься микроменеджментом.


Зависит от ситуации, возьмите для примера те же пулы ресурсов в Apache - никаких проблем с управлением ресурсами.

archimag ★★★
()
Ответ на: комментарий от Eddy_Em

А вообще, подозреваю, что в случае реальной необходимости ООП и наследований классов...

Да дело даже не в ООП. ООП с наследованием и на Си делается. Все дело в том, что в Си надо очень много заниматься посторонними вещами, никак не связанными с задачей. При этом довольно часто такой код оказывается медленнее аналога на Си++.

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

Reset ★★★★★
()
Ответ на: комментарий от archimag

Я не знаю что такое пул ресурсов апача. Но если там есть что-то типа resource_acquire/resource_release то это уже микроменеджемент.

Reset ★★★★★
()
Ответ на: комментарий от Reset

> Я не знаю что такое пул ресурсов апача.

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

archimag ★★★
()
Ответ на: комментарий от archimag

Да, вариант, сам такой механизм реализовывал несколько раз, но он не всегда подходит.

Reset ★★★★★
()
Ответ на: комментарий от archimag

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

backbone ★★★★★
()
Ответ на: комментарий от ugoday

На ФВП и вообще в функциональном стиле в generic-лиспе писать - себе дороже. Поскольку tail call optimization гвоздями не прибита, половина приемов не работает. Scheme в этом плане куда правильней.

А что там хорошего в CLOS ?

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

Гейшлюхой.

К.О.

LamerOk ★★★★★
()
Ответ на: комментарий от anonymous

> На ФВП и вообще в функциональном стиле в generic-лиспе писать

- себе дороже.


Правильно, умные люди уже давно сделали выбор в пользу других парадигм.

А что там хорошего в CLOS ?


Мощнейшая из известных система ООП.

archimag ★★★
()
Ответ на: комментарий от archimag

>Мощнейшая из известных система ООП. Мощнейшая из систем ДЛЯ ООП в эрланге.

умные люди уже давно сделали выбор в пользу других парадигм.

В лиспе-то? Да, там кроме как на макрах ничего сделать нельзя. Какое счастье, что лиспом мир не ограничивается.

anonymous
()
Ответ на: комментарий от anonymous

> Мощнейшая из систем ДЛЯ ООП в эрланге.

Там есть мультиметоды? Или аналог MOP?

В лиспе-то? Да, там кроме как на макрах ничего сделать нельзя


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

archimag ★★★
()
Ответ на: комментарий от archimag

> CL был бы одним из самых мощных языков даже если бы там вообще не было макросов.

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

Donnie_Darko
()
Ответ на: комментарий от Donnie_Darko

Да не, это правда. Ничего мощнее нетипизированного лямбда-исчисления ещё не придумали. Хотя вот об удобстве там говорить не приходится.

anonymous
()
Ответ на: комментарий от archimag

>Там есть мультиметоды? Или аналог MOP?

Что характерно, это НЕ ооп. ООП - это объекты + сообщения. И мультиметодов как раз в хорошем коде быть не должно, если это не продиктовано соображениями производительности.

anonymous
()
Ответ на: комментарий от Donnie_Darko

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

Я не люблю думать, я большое полагаюсь на опыт.

archimag ★★★
()
Ответ на: комментарий от anonymous

> Что характерно, это НЕ ооп.

Да что вы такое говорите?

И мультиметодов как раз в хорошем коде быть не должно, если это

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



Не распарсил. Можно подробней в этом месте?

archimag ★★★
()
Ответ на: комментарий от archimag

>> Что характерно, это НЕ ооп.

Да что вы такое говорите?

А вы не знали? Методы, наследование, виртуальные методы - это детали реализации, делающие чистый ОО - подход б.-м. пригодным для среднестатистического идиота, который не может провести корректную декомпозицию. Конечно, со временем костыли превратились в суть метода (тм) и даже появились такие мутанты как мультиметоды. Которые делают правильную декомпозицию невозможной, ага.

Впрочем, пионеры (тм), пишущие на лиспах, которые суть набор костылей над мощной, но негуманоидной и кастрированной абстракцией, это могут и не понять, да.

Не распарсил. Можно подробней в этом месте?

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

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

anonymous
()
Ответ на: комментарий от archimag

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

Т.е. Лавсан ничего, кроме как на фап-фап на MOP да венду не способен, теперь вот второй лиспер недоделанный вылез. Ох, лолушки.

anonymous
()
Ответ на: комментарий от archimag

> Да вы же просто бредите.

++

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

что за абстракция такая?

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

нет же

Которые делают правильную декомпозицию невозможной, ага.

которые позволяют обойтись без костылей а ля шаблон проектирования Visitor

korvin_ ★★★★★
()
Ответ на: комментарий от anonymous

> осилить простейших, я подчеркиваю, простейших утверждений? Как это впечатляет.

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

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

>что за абстракция такая?

http://en.wikipedia.org/wiki/Lambda_calculus

нет же

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

которые позволяют обойтись без костылей а ля шаблон проектирования Visitor

Какой, к хренам собачьим, visitor? Нужно реагировать на некоторые сообщения извне - так реагируй. Проблем-то. Нужен реестр подписантов? Сделай да вынеси в библиотеку. Опять же, проблем-то.

anonymous
()
Ответ на: комментарий от korvin_

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

anonymous
()
Ответ на: комментарий от anonymous

> http://en.wikipedia.org/wiki/Lambda_calculus

Вы Common Lisp давно видели? а Scheme?

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

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

Какой, к хренам собачьим, visitor?

http://en.wikipedia.org/wiki/Visitor_pattern

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

т.е. доказать свои высказывания Вы не можете?

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

>Вы Common Lisp давно видели? а Scheme? CL - месяц назад, схему - недели две. И в гробу их видал, честно говоря. Но то, что их модель - изуродованная лямбда с энергичной редукцией - осознал. В отличии от. Если вы этого не знаете - почитайте классику. Что-то вроде 'Abstract machines - lambda calculus perspective'

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

Дерево выбора менее развесистое. Хотя да, конечно.

anonymous
()
Ответ на: комментарий от anonymous

> Но то, что их модель - изуродованная лямбда с энергичной редукцией - осознал. В отличии от.

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

anonymous
()
Ответ на: комментарий от anonymous

> Если вы этого не знаете - почитайте классику. Что-то вроде 'Abstract machines - lambda calculus perspective'

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

korvin_ ★★★★★
()
Ответ на: комментарий от korvin_

А я читал. Ну, на схему читал, на CL просматривал. до места 'не прибита гвоздями TCO', после чего он мне стал неинтересен, как поделие пионеров.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.