[C++?] Серьезный вопрос.

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

Хо-хо. На себя посмотри для начала. Быдлизм так и прет изо всех щелей. Пришел тут "всезнающий функциональщик", который хаскеля и окамля даже на уровне хеллоуворлда не знает, быдлокодит где-то на C++ за еду, но знает все обо всем и считает свои бредовые высказывания истиной в последней инстанции.

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

>На Аде вагон софта в DARPA пишут.

А какие приложения, удовлетворяющие потребности конечного простого пользователя ПК, написаны на Ада? Кстати, а этот "вагон софта" не legacy случайно?

>Для Лиспа существует несколько коммерческих компиляторов (+ сред).

И что с того? Почему-то я не видел ни одного полезного приложения на Lisp.

>Мне вас, копошащихся в говне, даже жалко. Жизнь мимо проходит, прямо-таки.

Мне кажется, у тебя искаженное понимание картины мира :)

>Отлично подмечено: мы чрезвычайно умные.

Боязнь трудностей, которыми по словам плюсофобов изобилует C++, у нас уже как-то коррелирует с высоким интеллектом?

>> Что уж тогда говорить о POSIX или BSD Sockets.

> Ага, а ещё файлы, семафоры и процессы -- легаси.

Мне понятнее, когда термином legacy называется код, который достался в мое распоряжение. Например, написали 10 лет назад программулину, которую теперь мне приходится сопровождать -- вот это легаси. А COM, POSIX, Sockets, files, pipes -- это все не мое, это все действующие интерфейсы действующих систем. Для разработчиков ОС это, может быть, и легаси. А для меня, как для программиста, который все это использует в своем новом коде -- нифига не легаси.

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

> Также если человек, который с тобой общается на "вы" испытывает сильное желание назвать тебя долб*ом, это о чем-то да говорит.

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

> А какие приложения, удовлетворяющие потребности конечного простого пользователя ПК, написаны на Ада?

У конечного пользователя слишком мелкий интерес к вычислительной технике, чтобы для него хоть какая-нибудь интеллектуальная разработка велась. Какая-нибудь гламурная графическая оболочка, пара плейеров, браузер, офисный пакет (который он на 1% использует), игрушки. Всё.

> Кстати, а этот "вагон софта" не legacy случайно?

Что значит "легаси"? Армия - это не тусовка пидоров, там вооружение по 30 лет на службе стоит. "Сегодня Томагавки в моде, завтра - нет" - такого не бывает.

> И что с того? Почему-то я не видел ни одного полезного приложения на Lisp.

Опять "я", эгоцентризм зашкаливает? Я уже понял, что гламурный КДЕ и модные игрушки для тебя потолок, можешь не повторять.

> Мне кажется, у тебя искаженное понимание картины мира :)

Чем Уже у человека кругозор, тем искажённее он понимает мир. Лисп с Хаскеллями, знаючи, можно по уши в чан с говном окунуть, проблем хватает. Но для этого нужно детально владеть предметом, чего у вас не наблюдается. Поэтому сопли со слюнями по монитору размазываете только.

> Боязнь трудностей, которыми по словам плюсофобов изобилует C++, у нас уже как-то коррелирует с высоким интеллектом?

У тебя есть хоть какой-нибудь продолжительный опыт знакомства с чем нибудь, уровнем выше C++? Нет? О чём ты тогда споришь, если предметом спора не владеешь?

> У тебя есть хоть какой-нибудь продолжительный опыт знакомства с чем нибудь, уровнем выше C++? Нет? О чём ты тогда споришь, если предметом спора не владеешь?

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

Т.е., с предметной областью не знакомы, но обвинять C++программистов во всех смертных грехах горазды.

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

Absurd, если ты не заметил, не просто хает косяки в дизайне крестов, но указывает ещё и на то, как оно лучше сделано в других языках/технологиях.

> Т.е., с предметной областью не знакомы, но обвинять C++программистов во всех смертных грехах горазды.

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

> (*) Есть статья Мейерса с подробными выкладками и примерами.

Ссылка или название есть?

> Absurd, если ты не заметил, не просто хает косяки в дизайне крестов, но указывает ещё и на то, как оно лучше сделано в других языках/технологиях.

Я заметил, что он хает косяки на основании своего плохого опыта. Если бы он в C++ делал все нормально (а не так, как он показал пример с RAII), то он бы видел в C++ совсем другие проблемы.

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

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

>Ссылка или название есть?

http://www.ddj.com/cpp/184401197

>Если бы он в C++ делал все нормально (а не так, как он показал пример с RAII), то он бы видел в C++ совсем другие проблемы.

Еще раз: Код который ты пишешь в данный момент времени должен по возможности зависеть от кода который стабилен в данный момент времени. RAII обертки в момент написания кода нестабильны, так как они пишутся параллельно. Могу повторить хоть десять раз.

> Еще раз: Код который ты пишешь в данный момент времени должен по возможности зависеть от кода который стабилен в данный момент времени. RAII обертки в момент написания кода нестабильны, так как они пишутся параллельно. Могу повторить хоть десять раз.

Фигня, повторенная десять раз, фигней быть не перестает. Это во-первых.

Во-вторых, твоя реализация как выглядела?

> void someFunction() { struct Guard { handle_t _h; Guard (h) :_h(h) {} ~Guard() { Release(_h); } } g(Acquire()); ... Пишем тут ... }

Почему нельзя было сделать хотя бы так:

void someFunction() { struct Guard { handle_t _h; Guard () :_h(Acquire()) {} ~Guard() { Release(_h); } } g; ... Пишем тут ... }

чтобы это действительно было RAII? Такой код гораздо проще преобразуется в повторно-используемый.

В-третьих, далее шли стенания:

> Есть еще конечно фанбойский вариант написать отдельную обертку в util/* и получить антипаттерн "Orphanage", поскольку их никто никогда не структурирует. А не структурируют, потому что программисты работают параллельно и необходимость синхронизироваться с коллегами и искать уже существующую обертку это досадная подножка сбивающая с ритма. По быстрому навалял - и в утиль/*. А потом на этапе интеграции мы получим обертки оберток, метаобертки, впердоливатели в метаобертки и прочую плюсовую благодать.

которые к C++ никакого отношения не имеют. Если разработчики не могут огранизовать свои исходники, то они не могут это делать вне зависимости от языка. Я видел Java проект, в котором в трех пакетов было три собственных реализации функции Sort. Поскольку никто из разработчиков не синхронизировался с коллегами.

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

void someFunction() { Guard<handle_t> guard( Aquire(), &Release ); ... Пишем тут ... }

В-пятых, если не нравится делать нормальные RAII обертки для внешнего не-C++ного API (а сделать это достаточно один раз нормально, например, как в Google сделали для PCRE), то можно воспользоваться SCOPE_EXIT из Boost-а.

>void someFunction() { struct Guard { handle_t _h; Guard () :_h(Acquire()) {} ~Guard() { Release(_h); } } g; ... Пишем тут ... }

>чтобы это действительно было RAII? Такой код гораздо проще преобразуется в повторно-используемый.

Повторно использовать тут нечего. Если в нескольких местах, то имеет смысл вынести это дело в анонимный неймспейс в начало .cxx файла. Но никогда - в публичный интерфейс чтобы мой собственный код не перестал работать от загадочных плюсофильских коммитов в util/*.

>void someFunction() { struct Guard { handle_t _h; Guard () :_h(Acquire()) {} ~Guard() { Release(_h); } } g; ... Пишем тут ... }

В чем цимес?

>Если разработчики не могут огранизовать свои исходники, то они не могут это делать вне зависимости от языка. Я видел Java проект, в котором в трех пакетов было три собственных реализации функции Sort. Поскольку никто из разработчиков не синхронизировался с коллегами.

Это неизбежно и, хоть и некрасиво, но тут каждый сам отвечает за свой код и, как следствие, кусков которые влияют на все и на которые нельзя дышать тут нет. BTW, а) обобщенный sort в жабовской стандартной либе есть б) В системе с gc заниматься перефасовкой из одной RAII-абстракции в другую не нужно.

>> >void someFunction() { struct Guard { handle_t _h; Guard () :_h(Acquire()) {} ~Guard() { Release(_h); } } g; ... Пишем тут ... }

> В чем цимес?

В этом случае действительно RAII -- ресурс захватывается как часть инициализации объекта Guard-а.

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

Когда каждый сам отвечает за свой код, то в результате проект нифига не работает, зато есть отмазки вида "к пугавицам претензии есть?" и "с моей стороны пули вылетают"

> BTW, а) обобщенный sort в жабовской стандартной либе есть

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

> б) В системе с gc заниматься перефасовкой из одной RAII-абстракции в другую не нужно.

На колу мочало... Если бы все было так просто, в .NET не добавили бы тот же самый RAII в виде IDisposable и using.

>>> >void someFunction() { struct Guard { handle_t _h; Guard () :_h(Acquire()) {} ~Guard() { Release(_h); } } g; ... Пишем тут ... }

>> В чем цимес?

>В этом случае действительно RAII -- ресурс захватывается как часть инициализации объекта Guard-а.

А я вот хочу проверить возвращаемое значение от Acquire без кидания экзепшена из конструктора, например.

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

>Когда каждый сам отвечает за свой код, то в результате проект нифига не работает, зато есть отмазки вида "к пугавицам претензии есть?" и "с моей стороны пули вылетают"

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

>Если бы все было так просто, в .NET не добавили бы тот же самый RAII в виде IDisposable и using.

Я что-то не понимаю почему все так носятся с этим IDisposable как с писаной торбой?

> А я вот хочу проверить возвращаемое значение от Acquire без кидания экзепшена из конструктора, например.

Можно проверять g._h после завершения конструктора.

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

> Я что-то не понимаю почему все так носятся с этим IDisposable как с писаной торбой?

AFAIK, наличие using-а в C# очень резко сокращает количество finally. Как следствие, упрощается контроль за ресурсами и уменьшается количество связанных с этим ошибок.

Боюсь соврать, но с using-ом была связана какая-то интересная штука с исключениями. Если есть несколько using-ов, и при раскручивании первого из них будет выброшенно исключение, то остальные using-и все равно отработают (т.е. будет вызван метод Dispose). Это убирает еще одну проблему Java, когда в finally вызывается метод, бросающий исключения. Впрочем, сам я на .NET не программировал, не буду утверждать, что так оно и есть, это информация из третьих рук.

Очень остроумно. То есть ты делаешь вывод о моем опыте на основании только упоминания одной программы. Недалекий вывод. Впрочем, ЛОР - это не то место, где нужно что-то доказывать.

>Какая-нибудь гламурная графическая оболочка, пара плейеров, браузер, офисный пакет (который он на 1% использует), игрушки. Всё.

То есть по-твоему, браузер, аудио и видеокодеки -- это элементарная фигня?

>Что значит "легаси"? Армия - это не тусовка пидоров, там вооружение по 30 лет на службе стоит.

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

>Опять "я", эгоцентризм зашкаливает? Я уже понял, что гламурный КДЕ и модные игрушки для тебя потолок, можешь не повторять.

Хорошо, какие ты видел полезные приложения на лиспе (а еще лучше -- какими пользовался). И только не надо заводить песню про emacs.

>Лисп с Хаскеллями, знаючи, можно по уши в чан с говном окунуть, проблем хватает.

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

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

Что ты понимаешь под "положительным опытом"? Писал ли я когда-то на чем-либо отличном от C или C++? В какой-то период моего нелегкого отрочества мне даже на пыхе приходилось писать за деньги, и ничего -- не умер. Щупал жабы/перлы, даже круглоскобочный Lisp пробовал. Ничего выдающегося не обнаружил.

>О чём ты тогда споришь, если предметом спора не владеешь?

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

> То есть по-твоему, браузер, аудио и видеокодеки -- это элементарная фигня?

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

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

> Хорошо, какие ты видел полезные приложения на лиспе (а еще лучше -- какими пользовался). И только не надо заводить песню про emacs.

Для емакса куча всего написано и продолжает активно появляться, см. emacswiki. Так что "только не надо заводить песню про емакс" смотрится также глупо, как и "только не надо заводить песню про программы, собирающиеся с помощью gcc".

> Что ты понимаешь под "положительным опытом"?

Я написал: "продолжительным".

> даже круглоскобочный Lisp пробовал. Ничего выдающегося не обнаружил.

Макросы, кондишены с рестартами, мощнейшая объектная система, программируемый ридер, доступный в рантайме интерпретатор/компилятор - всё мимо твоего внимания прошло? Или дальше пары страниц старой финской книжки никуда и не уходило?

>Закодировать готовый алгоритм много ума не надо

Даже числа Фибоначчи можно посчитать медленно и рекурсивно (без приложеия ума), а можно очень быстро в цикле. Кстати, отсутствие наличия адекватной реализации алгоритма долгое время препятствовало использованию Theora и до сих пор препятствует dirac'у.

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

Это и отличает местных быдлоскриптеров он небыдлоплюсокодеров.

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

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

>Я написал: "продолжительным".

Продолжительно я какое-то время писал за еду на похапе.

>Макросы

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

>кондишены с рестартами

Это такие аналоги исключений?

>мощнейшая объектная система

Все так говорят, но никто не может объяснить разницы.

>программируемый ридер

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

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

а) негативно влияют на размер результирующего бинарника; б) доступно даже в Javasript и в Java.

>Или дальше пары страниц старой финской книжки никуда и не уходило?

Уходило, потому и говорю, что не впечатлило.

> Изучение Окамла после крестов включает в себя знакомство с новыми абстракциями, что требует определённого напряжения мозга (качественно другого рода, чем поиск банальных утечек памяти), поэтому окамлщик имеет такое же право на социальный артефакт в виде повышенного ЧСВ.

Список абстракций окамла, отстутсвующих в плюсах, в студию.

Причем именно абстракций, а не "ой, вот тут в плюсах, для получения аналогичного результата, придется написать на 4 строки больше" (да, это конечно преимущество окамла, но как минимум не требует напряжения мозга, что касается ЧСВ, его пока оставим в стороне).

> рестартами

допустим, f вызывает g, которая может произвести рестарт, работающий в фрейме стека f

чем рестарт лучше передачи в g анонимной функции, определенной во фрейме стека f (что вполне реально в с++0х или boost::lamdba)?

>Список абстракций окамла, отстутсвующих в плюсах, в студию.

>Причем именно абстракций, а не "ой, вот тут в плюсах, для получения аналогичного результата, придется написать на 4 строки больше" (да, это конечно преимущество окамла, но как минимум не требует напряжения мозга, что касается ЧСВ, его пока оставим в стороне).

Те же лямбды. При чем не эмуляция. Лямбда должна нормально захватывать окружение и как абстракция не течь.

Сборщик мусора. То есть не само наличие gc, а возможность работать с объектами как с некими абстрактными сущностями (хм.. коряво выразился), а не кусками памяти.

> Те же лямбды. При чем не эмуляция. Лямбда должна нормально захватывать окружение

лямбда -- это частный случай обычной функция, разве что анонимная -- никакой новой абстракции тут нет

> и как абстракция не течь.

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

> Сборщик мусора. То есть не само наличие gc, а возможность работать с объектами как с некими абстрактными сущностями (хм.. коряво выразился), а не кусками памяти.

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

>если какая-то абстракция (та же boost::lambda) подтекает (да), то это значит, что у плюсисты при ее использовании больше напрягают мозг

Да. А с другой стороны это значит, что это абстракция вовсе не лямбды, а "квази-лямбды".

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

Смотри к чему я. Возьмем для примера матрицы. Так вот. Я хочу под матрицей понимать матрицы в полноценном математическом смысле. Вот это и будет настоящей абстракцией. Если мне надо освобождать память после использования матрицы, то это уже не те матрицы. Это похожая абстракция, которой можно заменить матрицу, но не в коем случае не матрица.

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

> Смотри к чему я. Возьмем для примера матрицы. Так вот. Я хочу под матрицей понимать матрицы в полноценном математическом смысле. Вот это и будет настоящей абстракцией. Если мне надо освобождать память после использования матрицы, то это уже не те матрицы. Это похожая абстракция, которой можно заменить матрицу, но не в коем случае не матрица.

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

> Уходило, потому и говорю, что не впечатлило.

Таки не уходило, твои ответы это подтверждают. Смысла дискутировать с человеком не в теме дальше не вижу.

> Список абстракций окамла, отстутсвующих в плюсах, в студию.

Тебе шашечки или ехать?

> чем рестарт лучше передачи в g анонимной функции, определенной во фрейме стека f (что вполне реально в с++0х или boost::lamdba)?

Так и дженерики легко руками при помощи boost::function делаются! Ваще кресты отличный выразительный язык, пиши, да пиши.

> пиши, да пиши.
Это да, замечательное средство для проматывания проектных денег и просиживания перед бустовскими выхлопами, пытаясь реимплементировать лисп^W^W сотворить на крестах что-то правильно работающее. ;)

> COM уже легаси решение? Бу-га-га. MS для него просто удобную нашлепку в виде .NET-а сделала. А сам он никуда не делся.

.NET - это удобная нашлёпка для COM? Бу-га-га. Про архитектуру .NET почитай что ли.

> > пиши, да пиши. > Это да, замечательное средство для проматывания проектных денег и просиживания перед бустовскими выхлопами, пытаясь реимплементировать лисп^W^W сотворить на крестах что-то правильно работающее. ;)

Простите мне мой французкий, но количество правильно работающего софта на C++ в разы больше, чем аналогичного на Lisp-е, OCaml-е, Erlang-е и Haskell-е вместе взятых.

Если еще и принять на веру утвердения mv о более высоком интеллектуальном уровне OCaml-овских программистов, то оказывается, что даже тупым разработчикам удается массово писать на C++ правильно работающий софт.

>игрушки.

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

> .NET - это удобная нашлёпка для COM

Может вы еще будете утверждать, что из С++ с COM работать проще, чем из .NET? В .NET работа с COM упрощена значительно, и именно это я называл "нашлепкой".

>> Я написал: "продолжительным".

> Продолжительно я какое-то время писал за еду на похапе.

Соболезную. Даже смеяться над этим неудобно. Но ты это к чему? Неужели ты решил, что mv под языком, уровнем выше C++, подразумевал похапе?

> Может вы еще будете утверждать, что из С++ с COM работать проще, чем из .NET? В .NET работа с COM упрощена значительно

да

> и именно это я называл "нашлепкой".

Ладно, я понял, читать не интересно, интересно спорить.

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

> Я наслышан об одном очень крупном корпоративном приложении, написанном на j2ee.

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

> > Может вы еще будете утверждать, что из С++ с COM работать проще, чем из .NET? В .NET работа с COM упрощена значительно

> да

"Да" относится к чему?

> COM вообще сбоку. .NET на нём не базируется, поэтому никак нашлёпкой являться не может. В .NET есть интерфейс взаимодействия с COM -- обычный интерфейс взаимодействия с legacy-технологией.

Еще раз для первобытных: я не утверждал, что .NET базируется на COM. Моя мысль такова: COM никуда не делся, даже при программировании на .NET разработчики вынуждены его использовать. Но в .NET работа с COM значительно удобнее, чем в C++ и это неспроста. Это одна из фишек .NET-а.

> Она уж никак не может являться примером хорошего современного высокоуровнего языка.

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

Адекватной современной замены для C++ сейчас нет - на этом я буду настаивать.

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

Йа, йа, натюрлих! Векторная и матричная алгебра, а также зачатки теории машин и механизмов, теормеха и сопромата - это пипец какой bleeding edge науки! Именно поэтому движок пишут целых два программиста, а остальная орава придумывает сценарий, пишет скрипты, строит модели и рисует текстуры.

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

> Простите мне мой французкий, но количество правильно работающего софта на C++ в разы больше, чем аналогичного на Lisp-е, OCaml-е, Erlang-е и Haskell-е вместе взятых.

Виндузятнический аргумент.

Нас просто пока ещё мало. :) Хаскелл только сейчас начал набирать популярность.

> Хаскелл только сейчас начал набирать популярность.

Да, на форумах его становиться все больше и больше.

> Да, на форумах его становиться все больше и больше.

Ну вот, скоро начнёт появляться софт :) Хотя, я думаю, что на Окамле больше писать будут, он не такой ультраортодоксальный для среднего программиста, как Хаскелль.

> "Да" относится к чему?

что "из С++ с COM работать проще, чем из .NET"

> Еще раз для первобытных: я не утверждал, что .NET базируется на COM. Моя мысль такова: COM никуда не делся, даже при программировании на .NET разработчики вынуждены его использовать.

Вот твои слова:

> MS для него просто удобную нашлепку в виде .NET-а сделала.

Тебе объяснить разницу между "являться" и "иметь"?

> > Да, на форумах его становиться все больше и больше.

> Ну вот, скоро начнёт появляться софт :)

Как это говорят: talks don't cook rice...

> Адекватной современной замены для C++ сейчас нет - на этом я буду настаивать.

Ну так вам говорят про Лисп, Хаскель и Окамл, а вы в ответ: жаба -- говно.

> > "Да" относится к чему?

> что "из С++ с COM работать проще, чем из .NET"

Да, это многое объясняет.

> Вот твои слова:

Я вам объясил вложенный в эти слова смысл.