Здравствуйте, Андрей Хропов, Вы писали:

АХ>Наоборот, это сейчас самая горячая тема. Чисто в графике уже практически достигли фотореализма, дальше только трассировка лучей.

Ладно тебе. Там еще копать и копать до фотореалистичности. Рендеринг времен Парка юрского периода и то круче был.

Здравствуйте, eao197, Вы писали:

E>А призываю к тому, чтобы в C++ камнями перестали кидаться от нечего делать.

Если внимательно приглядеться, то можно понять, что от нечего делать камнями никто не кидается. Сторонники C++ заявляют что-то вроде: "Я C++ уже n лет использую, он зарекомендовал себя как хороший инструмент для решения задач и я его буду продолжать юзать". Люди отвечают: "Несомненно, C++ — не идеальный язык (как и любой ЯП). Так что наверняка сейчас уже появились ЯП мощнее C++, лучше подходящие для многих задач. Если же таких языков по-твоему не появилось, так почему же ты мучаешься с граблями C++? Если ты вынужден писать на C++, тогда не говори, что он лучий. Если у тебя есть выбор (но ты не видишь достойного преемника C++) то ты можешь поспособствовать тому, чтобы он появился". Последнее предложение — не обобщение. Но и эту идею можно заментить в той или иной форме, почитав сообщения.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, eao197, Вы писали:

VD>http://www.findarticles.com/p/articles/mi_m0NEW/is_1992_Dec_16/ai_13090337
VD>

New For PC: Symantec's Zortech 3.1 Compilers For OS/2, DOS 12/16/92 CUPERTINO, CALIFORNIA, U.S.A., 1992 DEC 16 (NB)

Конец 92-го, не удивительно, что в это время версии 3.1 у нас в Гомеле еще не было.
Выходит, я пробовал предыдущую версию.

Здравствуйте, VladD2, Вы писали:

VD>Так к системным задачам традиционно относят компиляторы, но любой кто более менее знает Лисп, Хаскель, ОКамл... Немерле в конце концом понимает, что писать компиляторы на С++ весьма не разумное решение.

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

E>>Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.

VD>Забыл добавить "... на С++". Иначе это не так верно. Замечательный пример обратного я скачал буквально недвано. BitTorrent. Программа написана на Питоне и офигительно качает себе в бэкграуде тонны файлов. Ну, да, жрет она 40 метров на моей машине. Ну, и фиг с ними! За-то она не вылетает, не глючит, проста и удобна в использовании, ставится в одно касание.

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

VD>Как не странно дрова и сетевые протоколы в Сингулярити написаны на C# и не уступают в эффктивности Линуксу с Виндовс.

Где не уступают? Где есть хотя бы одна промышленно используемая система на Сингулярити, работающая в режиме 24x7?

E>>Вообще-то на моей памяти максимальные оценки здесь получали как раз внезапно появляющиеся адепты функционального программирования, которые начинали рассказывать разные необычные для mainstream-программистов вещи.

VD>Ну, ты то к ним не относишся и в топе форума.

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

Здравствуйте, konsoletyper, Вы писали:

E>>А призываю к тому, чтобы в C++ камнями перестали кидаться от нечего делать.

K>Если внимательно приглядеться, то можно понять, что от нечего делать камнями никто не кидается.

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

K>Сторонники C++ заявляют что-то вроде: "Я C++ уже n лет использую, он зарекомендовал себя как хороший инструмент для решения задач и я его буду продолжать юзать". Люди отвечают: "Несомненно, C++ — не идеальный язык (как и любой ЯП). Так что наверняка сейчас уже появились ЯП мощнее C++, лучше подходящие для многих задач. Если же таких языков по-твоему не появилось, так почему же ты мучаешься с граблями C++?

А если не мучаешься и никогда не мучался?
Я могу, в принципе, поверить, что кто-то ужасно страдает от программирования на C++. Но вот не мой это случай

K>Если у тебя есть выбор (но ты не видишь достойного преемника C++) то ты можешь поспособствовать тому, чтобы он появился".

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

K>Если кто-то и кидается камнями в C++ от нечего делать (я, например ), то это случается весьма редко. Чаще люди проводят обычную конструктивную критику чьего-то порой нездорового консерватизма.

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

Здравствуйте, VladD2, Вы писали:

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

VD>Блин, GUI то с каких пор является коньком С++? На нем GUI всегда было гемороем если не вспоминать C++Builder.

Если ты видел только MFC, ATL и C++Builder, то это не значит, что GUI всегда было геморроем.

VD>Я тебе на C# напишу такое ГУИ в десятки раз быстрее, проще и надежнее.

Во-первых, сложность не в GUI.
Во-вторых, написанный тобой GUI я имел возможность наблюдать, пользуясь некоторое время назад Янусов. В сад такое быстрое, простое и надежное GUI на C#.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Alexmoon, Вы писали:

IT>Думаю, что для уровня ядра в качестве переносимого высокоуровнего ассемблера лучше подойдёт C, а не C++.

Как вы любите цеплятся за определения. Ответьте себе сами. C# еще менее подходит для этого.

IT>С одной оговоркой. Метопрограммирование на шаблонах — это тупиковая ветвь развития человечества.

Сильное определение. Уверенность в себе — это конечно похвально. Но я бы как минимум заменил артикль это на возможно.
Дальнейший спор не имеет смысла, поскольку он не этого уровня обсуждения. Скажу единственное. Все нужно рассматривать в концепциях языка. И на столь громкий выпад, отвечу. Нет. Объяснения не имеют смысла, поскольку это будет обречено на двести постов флейма. Все и так уже описано не раз. Достаточно для себя сделать вывод

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

IT>Мне очень нравится декларативная составляющая современных языков. Не мог бы ты сэмулировать на C++ атрибуты?

Мог бы и это не сверхестественное умение. Просто в концепциях языка с точки зрения логики сие выглядело бы совершенно по другому, но если кому так не нравится, или кто то боится ошибится при реализации, тогда смотри выше мое предыдущее сообщение. Два раза одно и то же я не повторяю. Мы не дети. Давайте без нравится, а то я напишу что мне нравится Jennifer Lopes.

IT>Ничего логичного и естетсвенного. Метапрограммирование на шаблонах — это высокоинтеллектуальное извращение. А извращение не может быть естественным. Даже высокоинтеллектуальное.
Ничего общего с тем что вы определили не имеет. То что в вашем понимании извращение, может таковым совершенно не являтся, но в концепциях С# конечно такой гибкости нет, поэтому можно и таким аттрибутом по умолчанию наградить. Давайте озаглавливать контексты "Я так думаю", и наче обсуждение обречено.

Здравствуйте, IT, Вы писали:

IT>Для меня тема C++ исчерпана давно. Если бы некоторые индивидуумы всерьёз не считали бы C++ "сложным языком для сложных программ" и не пудрили периодически здесь мозги другим, то я бы о нём уже давно забыл.

Я в любом случае приношу свои извинения, раз человека так допекло. Но попрошу. Давайте остановимся на фразе:

Бывает. Видимо я (мы) слишком чувствительны и восприимчивы к тому, что на нас как на пользователей так долго и так нагло кладёт комитет. У нас со временем это стало обоюдным. Ну а вас это не волнует совершенно. Понимаю.

Вы не являетесь четким определением параметров страшного сна. Забыли и слава богу, для нас. Те индивидуумы, которыми вы соблаговолили назвать и меня до сих пор чудесно справляются с поставленными задачами и с не меньшей эффективностью нежели вы господин. Я уже сам нервничать начинаю от столь громких заявлений. Все за прохрадительными напитками То что проектирование на ++ требует большего skills — это не значит что это извращение по сравнению с #. Я уже говорил. Каждому свое. Нет не решаемых архитектурных проблем ни с применением ни одного ни другого. То что вы считаете "так нагло кладет комитет" может быть лишь просто суровой действительностью и если бы он нагло клал, то вы бы и в сторону шаблонов развития никогда бы не увидели.

А теперь дружно порвали рубахи и обменялись аплодисментами

Здравствуйте, VladD2, Вы писали:

VD>Они локаничны, но совершенно не понятны.
Лаконичность нужно мерить не в символах, а в синтаксических элементах. Иначе мы получим рассуждения С.Г. о "синтаксическом оверхеде", а замена всех имен переменных на одно-двух-символьные сочетания должна будет существенно упрощать программу.

поэтому, например, в эмуляция ООП в C менее понятна, чем настоящее ООП в С++:

obj->method(obj, param1) 
obj->method(param1);

в первом случае второе упоминание obj — лишнее.

Простые замыкания в Linq понятнее, чем в C# 1.0:

private static bool SelectRichEmployee(Employee e)
{
  return e.Salary > 1000;
}

{
  collection.Select(new PredicateDelegate(SelectRichEmployee)); //1.0
    collection.Select(SelectRichEmployee); // 2.0
    collection.Select(delegate(Employee e) { return e.Salary > 1000; }); // Advanced 2.0
    collection.Select(Employee e => e.Salary > 1000); // 3.0
}

Здравствуйте, VladD2, Вы писали:

VD>С++ компактнее С только при условии, что на С код пишется в объектно-ориентированном стиле. ООП позволяет решать более сложные задачи за счет ОО-декомпозиции. Но кода получается обычно даже больше.
Нет. Шаблонные функции тоже рулят, т.к. позволяют не писать отдельные версии на каждый тип. Кстати, K&R C, руливший во времена С++, все еще не позволял указывать типы аргументов в объявлениях функции и требовал объявлять все переменные только в начале. Насколько я помню, возврат структур также был запрещен (могу ошибаться). Ссылок в С тоже не было.

VD>Но на С можно писать и в фукнциональном стиле, и в простом структрном, процедурном. При этом иногда даже получается более краткий и понятный код.
Короче, чем на С++ уже не получится, т.к. такая программа автоматически будет и С++ программой. Более того, структурно-процедурная программа на С++ будет скорее всего компактнее, чем на С, благодаря всяким простым штукам навроде наследования структур, которого не было в С.

Здравствуйте, Alexmoon, Вы писали:
A>Дальнейший спор не имеет смысла, поскольку он не этого уровня обсуждения. Скажу единственное. Все нужно рассматривать в концепциях языка.
Вот как раз не надо рассматривать ничего в концепциях языка. Потому как бессмысленно пытаться рассматривать "лыжи" на языке, где нет понятия "снег".
A>Мог бы и это не сверхестественное умение. Просто в концепциях языка с точки зрения логики сие выглядело бы совершенно по другому, но если кому так не нравится, или кто то боится ошибится при реализации, тогда смотри выше мое предыдущее сообщение.
Дело не в Дженнифер Лопес, а в совершенно объективных и измеримых характеристиках. Почему-то когда сравнивается эмуляция ООП на С с его реализацией в С++, ты с готовностью признаешь, что С++ — far superior, т.к. в нем не нужно вручную заполнять VMT, что снижает шанс сделать дурацкую ошибку и сокращает код. Зато эмуляция атрибутов кошмарными конструкциями — это вполне нормально, потому как "в концепциях языка с точки зрения логики это то же самое".

Здравствуйте, VladD2, Вы писали:

DC>> Замыканий? — да могу я их сделать функторами; как собственно и ФВП ; да это не будет так красиво, и кратко как в ОКамле или Немерле.

VD>Это будет настолько не красиво, что ты быстро бросишь это дело и вернешся к циклам и т.п. Да и читать это бует не очень приятно. Без сахара вроде лямбд и частичного применения ФВП мало что дают. Хотя бесспорно их можно и в С++ использовать. Но не красиво это получается.

Там где это будет эффективней я могу и потерпеть синтаксический оверхэд.

DC>>Только объясни мне где в алгоритмах в движке их применять. Я, если честно, не вижу сильного выигрыша от их применения.

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

Вот только в чем? В красоте или в эффективности выполнения? BulatZiganshin утверждает что на хаскеле будет медленнее, хотя и более кратко и красиво.

VD>>>Просто позволят решать более сложные задачи, или решать те же задачи меньшими силами.

DC>>Вот блин опять абстракция, я про движок графический спрашиваю. То что в физическом движке ФП будет возможно лучше использовать, я соглашусь, но ты мне объясни где я выиграю в 3D движке???

VD>Ладно. Уломал речистый. Дам тебе один убийственный аргумент — макросы. Они тебе позволят сделать движок в разы проще и максимально эффективно. Более мощьного средства для создания системных средств еще не придумано. А макросы того же Немерла — это одна из лучих реализаций оных среди существющих. Соперчинчать реально могут только макросы Лиспа, но Лисп динамически типизирован, весма своеобразен и слишком сложен для восприятия (скрипты им вряд ли заменишь). А уж метапрограммирование на шаблонах С++ вообще пролетает по всем статьям.

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

VD>ЗЫ

VD>Эти слова не значат, что кроме макросов ничего нет. Просто приемущество макросов тебе будет проще понять. А там если заинтересушся, то все пойдет смо собой.

Насколько я понимаю эти макросы и есть основной конек Немерле.

Здравствуйте, konsoletyper, Вы писали:

K>Здравствуйте, eao197, Вы писали:

E>>А призываю к тому, чтобы в C++ камнями перестали кидаться от нечего делать.

K>Если внимательно приглядеться, то можно понять, что от нечего делать камнями никто не кидается. Сторонники C++ заявляют что-то вроде: "Я C++ уже n лет использую, он зарекомендовал себя как хороший инструмент для решения задач и я его буду продолжать юзать". Люди отвечают: "Несомненно, C++ — не идеальный язык (как и любой ЯП). Так что наверняка сейчас уже появились ЯП мощнее C++, лучше подходящие для многих задач. Если же таких языков по-твоему не появилось, так
почему же ты мучаешься с граблями C++? Если ты вынужден писать на C++, тогда не говори, что он лучий.

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

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

А что ты считаешь достойным приемником? В каком смысле достойным?

K>Если кто-то и кидается камнями в C++ от нечего делать (я, например ), то это случается весьма редко. Чаще люди проводят обычную конструктивную критику чьего-то порой нездорового консерватизма.

А в чем наш консерватизм? У нас есть любимый инструмент, зачем этот инструмент поносить? Мало того если ты им не пользуешься? Мы вроде не поносили С#, Немерле и сотоварищей? Смысл ругать отвертку за то что она такая? Просто с распространенностью и универсальностью С++ пока еще никто не сравнялся. О причинах можно много говорить, но факт остается фактом.

Здравствуйте, Sinclair, Вы писали:

S>Вот как раз не надо рассматривать ничего в концепциях языка. Потому как бессмысленно пытаться рассматривать "лыжи" на языке, где нет понятия "снег".

Все нужно рассматривать в концепции языка. Понятие "снег" не является generic. Ни один язык не вместит всех понятий на уровне встроенных типов. Для меня необходимым и достаточным является то, что с максимальной гибкостью я могу определить любое из высокоуровневых понятий набором базовых. То что понятие гибкость и локаничность взаимозависимы, ну так здесь никто и никогда не найдет золотой середины. Одни средства появляются не на смену другим а лишь в их дополнение. И то что используются до некоторых пор языки, которые кто то считает не уместными — это не их недостаток и лишь характеристика, что они все еще актуальны и нет до сих пор понятий, которые за конечное время и с доступным владением интрумента невозможно выразить. Нет ничего абсолютного, есть только достаточное. Поэтому каждому свое. Шарп создавали для прикладников с реализацией устоявшихся понятий, для увеличения скорости и простоты разработки и некоторой степенью защиты от кривых рук, ну и слава богу, и это не обозначает что все это нужно пихать в ++. Я уже сказал зачем. Он развивается в те стороны, которые для него актуальны и логичны. Сказанное касается и для всех остальных инструментов и языков и всего.

Для тех на кого клал комитет по их мнению, да простят меня за злословие, создают свой комитет по защите обманутых потребителей и т.д.

Прошу не отвечать на данное высказывание. Этот лишь аттрибут поддержки интереса к абстрактной сложности вопроса.


A>>Мог бы и это не сверхестественное умение. Просто в концепциях языка с точки зрения логики сие выглядело бы совершенно по другому, но если кому так не нравится, или кто то боится ошибится при реализации, тогда смотри выше мое предыдущее сообщение.
S>Дело не в Дженнифер Лопес, а в совершенно объективных и измеримых характеристиках. Почему-то когда сравнивается эмуляция ООП на С с его реализацией в С++, ты с готовностью признаешь, что С++ — far superior, т.к. в нем не нужно вручную заполнять VMT, что снижает шанс сделать дурацкую ошибку и сокращает код. Зато эмуляция атрибутов кошмарными конструкциями — это вполне нормально, потому как "в концепциях языка с точки зрения логики это то же самое".

Кошмарными для кого? !!!!!!!!!!!!!!!!!!!!!!!!!!! Ну читайте же вы между строк и то что инструмент обладает необходимым набором составляющих поезда — это абсолютно не обозначает что он должен включать и его определение и также не значит что его нужно складывать из понятия колбаса (что вы определяете как кошмар).

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

NO EMOTION ONLY MIND

Это все было о девочках. А теперь конкретный вопрос, на который ни вы не я и никто не ответит.

Sinclair notes:

Дело не в Дженнифер Лопес, а в совершенно объективных и измеримых характеристиках.

Что есть ИЗМЕРИМЫЕ а тем более ОБЪЕКТИВНЫЕ характеристики?

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

Здравствуйте, VladD2, Вы писали:

E>>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.

VD>Дык посмотри дуум 1-2 или вообще Вульфа2Д. Они прекрасно обходились без 3Д-акселерации (да и без 2Д тоже).
VD>Хреновый аргумент? Вот твой такой же.

Этим играм сто лет в обед, а Call of Duty 2 вышел в прошлом году, когда производители уже успели вволю наиграться с физическими движками. Так что это твой аргумент так себе.
Давайте все-таки выясним, чем конкретно реалистичная физика может сделать интереснее игру.

VD>Да, сегодняшние игры обходятся, но они примитивны. Вних мало объектов, мало динамики, мало взаимодействий. Будущие игры возможно позолят иметь 64К юнитов, но уже не таких примитивных тупых точке как в Казаках, а таких как боты в Ку3. Но при этом ЦП (и не один!) должен будет целиком заняться логикой их поведения используя для этого мощьные средства вроде сопоставления с образцом или локики предикатов. Вот тогда перекладывание всей физики на плечи специализированной железки будет оправдано и даст хороший эффект.

По моему опыту, сложность AI ограничивается вовсе не производительностью процессора. У нас AI не тормозит. Что угодно тормозит, рендер, анимация, та же физика, а вот AI нет.
IMHO проблема тут не в производтельности, а в сложности реализации сложных моделей поведения, а также, в некторых случаях, в целесообразности этого.
Сложность AI не означает интересности игры. Во многих 3D-шутерах сложную логику поведения врагов просто никто не оценит. Q3 изначально был нацелен на multiplayer, боты там, по-моему, вообще больше для тестов и начальной тренировки новичков. Ну если ты все же играешь в Q3 один, какого усложненное поведение ты хотел бы у них увидеть?

Здравствуйте, Alexmoon, Вы писали:
A>Все нужно рассматривать в концепции языка. Понятие "снег" не является generic.
Кто это сказал? Снег, значит, есть, а понятия нету?

A>Ни один язык не вместит всех понятий на уровне встроенных типов.
Ну, если рассуждать обо всем с позиции типов — да. Но язык не обязан сводиться к типам. Да и само понятие "тип" сильно зависит от языка. В ассемблере, например, "тип" == количество байт, и указатель неотличим от инта.

A>Для меня необходимым и достаточным является то, что с максимальной гибкостью я могу определить любое из высокоуровневых понятий набором базовых.
Это иллюзия. Если тебя оставить наедине с по-настоящему базовыми понятиями, ты через полчаса запросишься обратно к маме. А ну-ка сконструируй мне хотя бы конвертер Koi-8->Win1251, пользуясь _исключительно_ нулем, инкрементом, и функцией выбора N-го аргумента!
Так что вопрос ровно в том, какие понятия считать базовыми. Вот С считает, что структур вполне достаточно для всех случаев жизни и можно вполне успешно определить "класс" как структуру, а объект — как другую структуру.

A>То что понятие гибкость и локаничность взаимозависимы, ну так здесь никто и никогда не найдет золотой середины.
Вот это утверждение хотелось бы как-то обосновать. Кто гибче — С или С++? А ведь С++ лаконичнее!

A>Одни средства появляются не на смену другим а лишь в их дополнение. И то что используются до некоторых пор языки, которые кто то считает не уместными — это не их недостаток и лишь характеристика, что они все еще актуальны и нет до сих пор понятий, которые за конечное время и с доступным владением интрумента невозможно выразить.
Ага. Это т.н. "классическая квантовая механика". Предполагает, что можно измерить любой параметр с любой точностью. К сожалению, на высокоэнергетических проектах проявляются релятивистские эффекты: нельзя измерить координату с бесконечной точностю, т.к. это потребует бесконечной неопределенности импульса. А она запрещена, p < mc.
Вот и в программировании так же: некоторые вещи в принципе невозможно реализовать на более простой технологии, т.к. человеко-годы стремятся к бесконечности. Возникает потребность в более производительных инструментах. Парадокс, знаете ли, ахилла и черепахи.

A>Нет ничего абсолютного, есть только достаточное. Поэтому каждому свое. Шарп создавали для прикладников с реализацией устоявшихся понятий, для увеличения скорости и простоты разработки и некоторой степенью защиты от кривых рук, ну и слава богу, и это не обозначает что все это нужно пихать в ++.
Никто и не предлагает всё это пихать в С++. Просто есть некоторые запросы, на которые С++ отказывается отвечать. Не надо копировать ответы из шарпа; можно было бы копировать и другие ответы. Увы.


A>

Sinclair notes:

A>Дело не в Дженнифер Лопес, а в совершенно объективных и измеримых характеристиках.

A>Что есть ИЗМЕРИМЫЕ а тем более ОБЪЕКТИВНЫЕ характеристики?
1. Компактность кода
2. Количество проверок, выполняемых компилятором
A>Продолжая сопоставлять и анализировать все вышесказанное, попытайтесь ответить так, чтобы не положить ни на единого хотя бы участника общения.
Запросто. См. выше.

S>>Вот как раз не надо рассматривать ничего в концепциях языка. Потому как бессмысленно пытаться рассматривать "лыжи" на языке, где нет понятия "снег".

A>Все нужно рассматривать в концепции языка.

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

A>Что есть ИЗМЕРИМЫЕ а тем более ОБЪЕКТИВНЫЕ характеристики?

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

все эти языки появляются для решения всё техз же извечных задач — уменьшения времени программирвования/отладки, увеличения читабельности и надёжности. в Хаскеле большинство ошибок обнаруживается компилятором. в С я периодически наталкиваюсь на нулевые укащатели, или на ручной (и потенциально ошибочный) кастинг указателей туда/сюда. в хаскеле я записываю алгоритм в одлну строчку, в Си — в десять, к тому же разбросанных по программе потому, что нет клозур для sort. я тут привёл 3 примера кода, написанного на хаскел (http://rsdn.ru/Forum/?mid=2337746&amp;flat=0

Автор: BulatZiganshin
Дата: 06.02.07

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

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

Здравствуйте, eugene0, Вы писали:

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

Геймплей некоторых игр основан именно на реалистичной физике. Например, автосимуляторы. Есть более редкие и своеобразные экземпляры, например GISH.
Если тебя интересует, чем реалистичная физика может сделать интереснее 3D-шутер, то в качестве игры, где это сделано, могу назвать Half-Life 2.

BZ>>преимущества Хаскела — очень строгая типизация, отлавливающая большинство ошибок с типами, и лёгкость конструирования алгоримтов из составных частей. я не представляю себе потребности игр,

LCR>Тим Свини в своей презентации утверждает, что очень хочется статического контроля выхода за пределы массивов, статического контроля за null-значениями, статического контроля за переполнением, хорошей поддержки concurrency, и подобные мелочей.

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

вот описание моей библиотеки — http://haskell.org/haskellwiki/Library/Streams . посмотри, какие типы в ней конструируются и это ведь норма для современного программирования, в C++ шаблонах получается не хужее. вопрос только в том, кто будет их выяснять — программист или компилятор

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

LCR>let (recoverable,bad) = bad_crcs .$ sort_and_groupOn (`mod` rec_sectors) 
LCR>                                 .$ partition (null.tail) 
LCR>                                 .$ mapFst concat .$ mapSnd concat
LCR>

LCR>Глупый вопрос: кто такой ".$"?

это просто мой спсооб написания ООП-стайл прорграм

a$.b = b a

Здравствуйте, Сергей, Вы писали:

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

С>Геймплей некоторых игр основан именно на реалистичной физике. Например, автосимуляторы. Есть более редкие и своеобразные экземпляры, например GISH.
С>Если тебя интересует, чем реалистичная физика может сделать интереснее 3D-шутер, то в качестве игры, где это сделано, могу назвать Half-Life 2.
Про HL2 согласен, он весьма завязан на свой физический движок. Местами даже кажется, что дизайнерам чуть ли не прямым текстом сказали: "Ребята! У нас лучшая в мире физика. Будет обидно этим не воспользоваться"

У меня такое ощущение, что я заигрался в адвоката дьявола. А я всего лишь хотел сказать, что физика — не так важна для игры, как, к примеру, красивая графика, и поэтому сравнивать ускоритель физики с 3D-акселератором неправильно. На самом деле я не против физики, нет.