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

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

Красивая графика — в смысле крутой графический движок с реалистичными эффектами?

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

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

С>Красивая графика — в смысле крутой графический движок с реалистичными эффектами?

Да, но не только. Если художники плохие, то они и крутой движок не спасет. Но это, конечно, не имеет отношения к 3d-акселераторам.

Bulat,

BZ>это просто мой спсооб написания ООП-стайл прорграм
BZ>a$.b = b a

Оператор "euro" из Understanding monads

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

Да, согласен, обычно так и происходит.

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

Смотрю, спасибо.

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

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

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

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

Обосновывать это можно до бесконечности. Для этого как минимум должны быть взаимосогласованные определения. Их не было и не будет. Всех нас всегда будет что то не устраивать. Здесь нечего ответить, поскольку поставьте вопрос на абстракцию выше и вы поймете почему все от всего зависит и выиграть во всем абсолютно не возможно. Каждый выбирает обязательные критерии сам. Главное чтобы выбор был. Вы еще помните концепцию начала и в чем конечный вывод должен состоять?

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

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

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

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

A>>

Sinclair notes:

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

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

А может тогда уж не будем путать ОБЪЕКТИВНЫХ и СУБЪЕКТИВНЫХ характеристик.
Количественные характеристики компактности и количества проверок, как оценочные характеристики, приведите пожалуйста.

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

Отвечу на базе вашей же цитаты:

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

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

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

E>Да, но не только. Если художники плохие, то они и крутой движок не спасет. Но это, конечно, не имеет отношения к 3d-акселераторам.

Я бы даже сказал, что хорошие художники важнее крутого движка. Тот же движок Doom3 намного круче Source, но Half-Life2 намного красивее Doom3 и Quake4. Или вот ты приводил Call Of Duty как пример — это же движок Quake3.

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

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

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

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

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

Вот теперь продолжайте количественно оценивать читабельность и надежность, иначе сравнивать нечем.

Я и Мы недостаточные характеристики определения.

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

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

E>> Я что-то писал про процессы или потоки?
S>Ты — нет. Ты писал про виртуальные машины. Вот, к примеру, каждая Java VM выполняется в отдельном процессе.
Под виртуальными машинами я подразумевал нечто, выполняющее байт-код, получившийся в результате компиляции скрипта.
У нас, например, они вообще все в одном потомке работают, просто опрашиваются по очереди все время.

E>>Зачем что-то колбасить? Вот LUA, вот python. Для того, чтобы делать что-то новое, нужно, чтобы это новое было чем-то лучше, чем готовое и многократно использованное и оттестированное старое. Чем вот эти псевдоязыки были бы лучше?
S>Ну, чисто теоретически, они бы еще сильнее контролировали дизайнера. Я, честно говоря, ни LUA ни Python не знаю, поэтому точно сказать ничего не могу. Но я 100% уверен, что дизайнеры не рождаются со знаниями ни того, ни другого. 100% известных мне дизайнеров делятся на тех, кто вообще ни на чем программировать не умеют, и тех, кто немножечко-немножечко знает JavaScript и PHP.
S>Я не знаю, почему вы выбрали Lua/Python для своих скриптов. Наверное, из них легче управлять игровыми объектами, чем из С++, и они дают меньше возможностей сделать какую-нибудь катастрофическую ошибку вроде прохода по памяти, использования удаленного объекта или неудаления использованного.
Не совсем так. На мой взгляд, скриптовые языки не предназначены для создания больших сложных систем. Гейм-дизайнеры пишут небольшие скрипты, которые состоят из несложной логики и вызовов API, который предоставляет им движок. Если скрипты стали получаться большие и сложные, значит пора звать программиста, который включит эту сложную логику в игру и создаст для скриптописателей новый интерфейс.
Поэтому требования к скриптовому языку несколько другие: простота, читаемость и желательно какая-нибудь интерактивность, чтобы написанный скрипт можно был тут же и запустить.
В таких условиях написание скриптов на "взрослых" языках вроде C# или джавы или C++ выглядит как стрельба из пушки по воробьям.

мировать не умеют, и тех, кто немножечко-немножечко знает JavaScript и PHP.
S>>Я не знаю, почему вы выбрали Lua/Python для своих скриптов. Наверное, из них легче управлять игровыми объектами, чем из С++, и они дают меньше возможностей сделать какую-нибудь катастрофическую ошибку вроде прохода по памяти, использования удаленного объекта или неудаления использованного.
E>Не совсем так. На мой взгляд, скриптовые языки не предназначены для создания больших сложных систем. Гейм-дизайнеры пишут небольшие скрипты, которые состоят из несложной логики и вызовов API, который предоставляет им движок. Если скрипты стали получаться большие и сложные, значит пора звать программиста, который включит эту сложную логику в игру и создаст для скриптописателей новый интерфейс.
E>Поэтому требования к скриптовому языку несколько другие: простота, читаемость и желательно какая-нибудь интерактивность, чтобы написанный скрипт можно был тут же и запустить.
E>В таких условиях написание скриптов на "взрослых" языках вроде C# или джавы или C++ выглядит как стрельба из пушки по воробьям.

собственно, всё то же, что и принаписании скриптов в ОС. почему для этого используют bash, awk, perl, а не C#? вопрос риторический

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

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

DC>>Влад кто из производителей движков/ОС/драйверов переходит на Немерле/ОКамл/...
VD>Самые умные.
А можно поименно?

VD>>>Второе покоеление уже писалось с использованием скриптов и С++.
DC>>Использование скриптов ИМХО еще позже появилось.
VD>Погляди Анрэл 1.
Quake 1 — QuakeC — компилируемый язык с VM.

DC>> Где 3Д библиотеки для Немерле/ОКамл/... которые удовлетворяют разработчиков движков?
VD>Они прекрасно исползуют имеющиеся бибилотеки. Для Немерле будет радным XNA, от МС
Ой только не надо про %НЮ. Потому как кроме как нецензурно о этой поделке отозваться не могу... Шшупали...

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

VD>>>Данные похожие на данные из приводимой мной презентации, но они мало что говорят об оправданности такого решения.
VD>>>Из той же презентации видно, что на всю симуляцию игры уходит около 10% процессорного времени:
E>><таблицу поскипал>

Ok, я наконец ее посмотрел. Любопытно, спасибо.

Из забавного:

Solved problems:
Random memory overwrites
Memory leaks
Solveable:
Accessing arrays out-of-bounds
Dereferencing null pointers
Integer overflow
Accessing uninitialized variables
50% of the bugs in Unreal can be traced to these problems!

Даже не знаю, что сказать. У нас эта цифра составит, наверное, процентов 10. Т.е. за весь проект мы не видели ни одного проезда по памяти. Утечки в начале были, но после того, как всем программистам объяснили, что такое смартпоинтер, об утечках тоже забыли и не вспоминают уже года два. Массивы мы не практически используем, пользуемся контейнерами STL, с ними вылезти за границы сложнее. Обращению к нулевому указателю проявляют себя немедленно и тут же исправляются. Integer overflow не видал. Неинициализированные переменные — это да, проблема.

У нас главная проблема — это макароны и все, что с ними связано. Неправильная декомпозиция или ее отсутствие. Решения типа "сейчас пускай заработает, а потом я сделаю правильно" (а потом он уволился). Куски кода, к которые последовательно приложило лапу 2-3-4 человека, и никто уже не помнит, что он там и зачем делал.

Но это так, к слову.
Я в целом поддерживаю автора: неплохо бы получить новый, эффективный язык, лишенный недостатков того, что мы иcпользуем сейчас!
Правда, главный аргумент тут — это грядущая всеобщая многопроцессорность/многоядерность. До тех пор, пока можно работать в одном-друх потоках без ущерба для производительности, С++ в принципе подходит. Да, у него много недостатков, всяких раздражающих фич и пережитков прошлого, но работать можно.

E>>Если я правильно понимаю, поскипанная мной таблица — нечто вроде данных профайлинга, на что ушло больше процессорного времени?
VD>Нет совесм, это оценки авторов Анрыла. Там не только процессороное время.
E>>Если интересно, могу привести _наши_ данные, полученные от профайлера.
VD>Конечно интересно.

Тут есть затруднение. Дело в том, что профайлер выводит статистику по функциям. Game simulation и numeric computation там довольно сильно перемешаны. Я прямо сейчас не смогу ручкми все это посчитать, нету времени. Возможно, позже.

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

VD>Хохма заключается в том, что величина эта переменная и обычно она не превышает статистической пограшности. Алгоритмические просчеты или просто выбор не оптимальных путей дает куда больший проигрышь. Единственное что действительно приносится в жертву — это расходуемая память. GC показывает хорошую скорость только если занимает память с запасом. Плюс есть собсвтенные накладные расходы. Так что получается, что расход памяти у дотнета на уровне скриптовых языков.

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

E>>Предлагаю говорить все же более конкретно. Скажем, 10% для нас — это уже критично. У нас пока некоторые уровни на средних машинах на слайд-шоу похожи

VD>Дык. Тут уже язык мало что може сделать. Тут нужна или акселерация, или изменение алгоритмов. А на них нужно время. А оно уходит на больрбу с С++. Идея ясна?

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

VD>>Дык. Тут уже язык мало что може сделать. Тут нужна или акселерация, или изменение алгоритмов. А на них нужно время. А оно уходит на больрбу с С++. Идея ясна?

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

... сколько на борьбу с его сторонниками

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

E>Утечки в начале были, но после того, как всем программистам объяснили, что такое смартпоинтер, об утечках тоже забыли и не вспоминают уже года два.

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

Где логика я вас спрашиваю?

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

IT>Где логика я вас спрашиваю?

"вот из-за того, что вы говорите не то, что думаете, и думаете не то, что думаете — мы здесь и наблюдаем весь это горький катаклизм"

BZ>>представьте себе ассемблер с ООП расширениями, шаблонами, клозурами, монадами, примитивами синхронизации и т.д. смешно? было бы смешно, если б не было близко к правде. С появился как язык системного программирования, высокоуровневый ассемблер, и именно благодаря своей эффективности, близости к железу он завоевал симпатии в мире ранних мини-компьютеров и персоналок, с их скромными ресурсами

A>Теперь не применительно только к этой фразе а вывод в общем. Каждый инструмент создается as main concept для определенных задач. Кто то ниже говорил "разделять сервер и морду". Я совершенно с этим согласен и как видишь даже в бессмысленный спор не вступаю. Вопрос лишь в том кто будет морду реализовать.
A>Я прекрасно представляю ассемблер с шаблонами и примитивами синхронизации, но и вы представте C# в виде монстра, который решает не только задачи прикладного програмирования, а еще и будет перекручен конструкциями с определенными unmanaged оговорками для свободного манипулирования ресурсами под уровень ядра, либо все таки МС придется извратится чтобы все возможные варианты изобразить MSIL компилером. Все равно это будут не логичные для его контекста описания. Вообщем заметьте Г. получается как с одной, так и с другой стороны. Не нужно все это.
A>Пускай C++ занимается задачами в своем стиле и не нужно ему всего что касается managed расширений. Человек, который не хочет следить за ресурсами сам, либо не умеет оперировать типами, пускай не лезет в ++ (это не характеризует недостатки языка). При правильном архитектурном подходе, я поверь мне уже практически избавился от страшных снов связанных с этим, абсолютно. Каждый инструмент требует определенных навыков, опыта и мозгов. Кесарю, кесарево. Железная истина. Для прикладников языки другие.

что C# с unmanaged code, что C++ с его managed расширениями типа smart pointers — это фактичсеки два разных языка за цену одного

можно считать, что я пошёл ещё дальше и весь прикладной код пишу на хаскеле, а низкоуровневый — на C++ и не требую ни от того, ни от другого языка неестественных для него трюков. что касается арзитектурного подхода, то я тоже когда-то отладивал C с помощью printf'ов. можно чему угодно обезьяну научить но всё же лучше потратить силы на то, чтобы научиться писать более сложные программы с современными языками, нежели учиться делать несложные вещи, которые становятся сложными из-за устаревшего инструментария


BZ>>в 80-х ...

A>Хватит о них. Мне 33 и я помню о них прекрасно. По моему до сих пор в обсуждении остались только люди, которые хоть как то ориентируются во всем этом флейме, не воспримите за оскорбление.

вы в 80-е программировали? да ещё и отслеживали все события в мире компилтяоров?? я-то просто недавно надыбал dr dobbs за эти годы и с удовольствием отследил борьбу и языков, и компиляторов. кол-во компиляторов C, паскаля и модулы было тогда практически одинаковым — 5 модул, шутк 6-7 Си. ну и ещё интерсено вспомнить, что С++ пошёл только потому, что разработчики были уверены, что на нём можно будет писать программы не медленней, чем на C


BZ>>однако когда речь доходит ло прикладного программирования и эффективность оказывается не главным, тут С++ напоминает Винни-Пуха, который прикидывался тучкой в языке нет GC и type-safe generic references, синхронизации, клозур и т.п. ну и фиг с ним! мы всё это сэмулируем! в результате чего есть язык С++, содержащий массу конструкций, которые прикладному программисту просто не следует использовать, и многочисленные бибилиотеки, которые худо-бедно эмулируют возможности, напрямую встроенные в другие, более современные языки

A>Вот и пускай будут они туда встроены. !!!! О БОЖЕ, мы наконец приходим к тому, к чему с самого начала стремились.
A>1. Я счастлив, что простому прикладнику наконец сделали инструменты, которые позволяют меньше думать и больше работать, но это отнюдь не означает что С++ плох. Ему просто все эти расширения не нужны.
A>2. Если человек владеет С++ — это должно четко обозначать что он в состоянии за время не меньшее, чем прикладник с помощью своего инструмента, может эмулировать все те вещи о которых мы говорим.
A>Для меня это кристальная истина. Все остальные лишь используют язык, в каких то узких целях, который им возможно и не нужен.

давайте это по-другому выразим. спец C++ , по-вашему — это человек, который в несколько раз дольше учился, в несколько раз больше работает, и в конечном счёте получает ровно то же, что и спец в более современно языке? "товарищ сержант, ну можно я веником подмету?"

знаете, что меня к хаскелу привело? я вроде тоже неплохой спец по C++ был, мой арзиватор arjz широко известен в узких кругах. и прикинув, на что больше всего времени тратится при разработке архиватора, я решил, что с (тогдашним) С++ мне не по пути. нужны гибкие структуры данных с мощными возможностями по их обработке, нужны клозуры, весьма желателен gc. C++ — по своей сути просто препроцессор, генерящий чисто императивный код, какая-нибудь фиговина типа map+sort без промежуточных переменных уже способна повергнуть его в ступор.

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

затем на руби, в нём замечательная объектная модель, клозуры, но язык всё же динамический со всеми вытьекающими отсюда ненадёжностью, медленностью и т.д.

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

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

-- |this function finds last space in String within 80-char boundary
len_f = last . filter (<80) . findIndices (==' ')

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

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


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

это вы про машину Тьюринга?


A>То что язык развивается в сторону метапрограммирования на базе шаблонов — это совершенно логичесное и естественное развитие языка данного уровня.

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


BZ>>вот поэтому вы и need a complex language — чтобы созранить совместимость с кодом 30-летней давности, сгенерить как можно более эффективную программу, а затем попытаться как-то сэмулировать современные языки.

A>Что вы так пристали к этой совместимости. Она остается до сих пор только потому, что нет смысла язык наворачивать не свойственными ему вещами изначально.
A>Если для вас совместимость главный критерий, то для меня абсолютно. Я уже ранее говорил, что в определеной степени владения языком нет проблем в эмуляции того о чем мы говорим. Просто кто то — это сделает быстрее, а кто то не сделает вообще и то что язык требует более высокого уровня skills — это не недостаток его, а лишь характеристика.

совместимость с BCPL — это ограничитель развития самого C++. ну ни к чему в один язык тащить все aborb? которые когда-либо были изобретены. а когда тащат и начинают всё вместек совмещать, "эмулировать" — тогда и выходит коктейль из switch'a с лямбдой


BZ>>я тут выше приводил пару примеров кода в хаскел, напиши их аналоги в С++ и сравни сам. если вместо изучения всех этих legacy features и методов эмуляции modern features изучать напрямую современный язык, то ты здорово сэконишь во времени изучения и затем во времени написания/отладки кода.

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

ну с таким подходом мы вообще должны сами проектировать кмпьютер для решения каждой новой задачи — гибче некуда. ИНДУСТРИЯ программирования развивается в сторону того, чтобы выделить паттерны, обобщить их и внести в методолгию/язык/whatever. это повышает призводительность труда, а производительность труда, по Марксу — это мерило степени развития общества помню, как мне один амер в 90-х говорил "не занимайся ассемблерной оптимизацией, брось бяку!", а я ему не верил сейчас я вам говорю то же самое, сыны мои

РАЗВИТИЕ ПРОГРАММИСТА ОПРЕДЕЛЯЕТСЯ УРОВНЕМ ЗНАНИЯ СОВРЕМЕННЫХ ТЕХНОЛОГИЙ, А НЕ СПОСОБНОСТЬЮ СЭМУЛИРОВАТЬ ИХ ЧЕРЕЗ СТАРЫЕ. по очень простой причине — деньги. быстрее делаешь программу — длиннее деньги. а для интереса я и сам с удовольствием C++ со всеми его наворотами прочту (но зазубривать не стану, и не просите )


BZ>>именно об этом я и говрю — что в С++ thread-safe программирование требует специального изучения и в job offers, например, указывается как отдельное требование чтобы понять, насколько это смешно, представьте себе скажем требование "умение вызывать функции рекурсивно". это тоже может специальным умением в языке типа Фортрана, где это не поддерживалось

A>Сравнивать "рекурсивный вызов" и "thread-safe" — это все равно что в правах на вождение автомобиля указывать уровень владения самокатом. Давайте не опускаться до такого уровня. Человек ничего не знающий о потоках и разделяемых ресурсах и в C# репу перегреет такими понятиями как ThreadMutex и т.д.

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

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

-- Thread, который в цикле читает команды из потока и исполняет их
graphThread c = do cmd <- getChan c
                   cmd
                   graphThread c

-- Создаёт graphThread и посылает ему команды на исполнение
main = do с <- newChan
          forkOS $ graphThread c
          putChan c (print "Hi")
          tid <- forkOS $ putChan c (print "Hi from other thread")
          putChan c (print "Bye")
          waitThread tid

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


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

у меня было аналогично. когда я решил присобачить к своему арзиватору read-ahead, опережающее чтение файлов в отдельном от упаковки треде, я потратил неделю. на то, чтобы во всём этом разобраться, и чтобы осознать, КАК это просто будет сделать. у меня просто мозги этого не совпринимали, как и ваши наверно сейчас разобравшись, я сделал за день, там строк 40 кода всего понадобилось. а вот ни в одлном из других арзиваторов этого до сих пор нет. почему? наверно, потому, что они все на C++ написаны

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


BZ>>т.е. опять речь о complex language, порождённом тем, что современные концепции программирования в нём — нечто дополнительно прикрученное сбоку с теми самыми километрами художеств

A>Где явное определение того, что так называемый complex language охватывает весь спектр современных концепций и что есть весь спектр современных концепций?
A>Я надеюсь понятно без лишних объяснений почему вам не удастся быть объекивных в этой части вопроса.

а мне кажется — можно multi-threading, GC, лямбды и прочие вещи, которые в других языках есть изначально, и умение пользоваться эмуляцией которых в C++ рассматривается как необходимое условие для устройства на работу

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

<...поскипано...>

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

<...поскипано...>

BZ>а теперь посмотрите как записывается многопоточная программа на хаскеле:

BZ>

BZ>-- Thread, который в цикле читает команды из потока и исполняет их
BZ>graphThread c = do cmd <- getChan c
BZ>                   cmd
BZ>                   graphThread c

BZ>-- Создаёт graphThread и посылает ему команды на исполнение
BZ>main = do с <- newChan
BZ>          forkOS $ graphThread c
BZ>          putChan c (print "Hi")
BZ>          tid <- forkOS $ putChan c (print "Hi from other thread")
BZ>          putChan c (print "Bye")
BZ>          waitThread tid
BZ>

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

<...поскипано...>

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

И так бывает, однако.

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

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

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

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

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

Из ГУИ януса я делал только дерево.

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

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

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

Не может быть?! Спасибо, ты мне открыл глаза. И какие же еще? Уж не СОбжектайзер ли?

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

Ясно, ясно. Все программы что ты не видел ничего не делают. Кто бы сомневался. Это же не СОбжектайзер. Он постоянно отслеживает десятки, а то и сотни параллельно ралботающих torrent и выводит информацию о них (ксолько чего от кого или кому скачалось и т.п.). Причем эти параллельные клиенты постоянно исчезают и появляются.

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

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

Нет необходимости в промышленных системах чтобы доказать что это так. Люди сделали тесты и представили их результаты людям. Оставь свою демагогию при себе. Это факт.

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

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

E>Из любого правила есть исключения.

Но это не ты.

E> Ты, кстати, не далеко от меня обосновался, так что ктобы жаловался

А я в функциональщики перевербовался.

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

DC>>>Влад кто из производителей движков/ОС/драйверов переходит на Немерле/ОКамл/...
VD>>Самые умные.
CC>А можно поименно?

Нельзя. Это коммерческая тайна.

VD>>>>Второе покоеление уже писалось с использованием скриптов и С++.
DC>>>Использование скриптов ИМХО еще позже появилось.
VD>>Погляди Анрэл 1.
CC>Quake 1 — QuakeC — компилируемый язык с VM.

Кармак все еще и на С пишет. Это не показаоель. Показатель скорее то, что он просрал очередной виток технологий ФарКику.

DC>>> Где 3Д библиотеки для Немерле/ОКамл/... которые удовлетворяют разработчиков движков?
VD>>Они прекрасно исползуют имеющиеся бибилотеки. Для Немерле будет радным XNA, от МС
CC>Ой только не надо про %НЮ. Потому как кроме как нецензурно о этой поделке отозваться не могу... Шшупали...

А кто ты такой чтобы твое мнение по этому поводу было интересно?

МС же компания которая привыкла доводить начинания до конца. Так что XNA будет стандартом хоть ты в штаны наложи, а DirectX и OpenGL сегодняшние стандарты которые уже давно можно прекрасно использовать из того же Немерла. Так что скипай, не скипай, а это факты.

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

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

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

А в твоих словах я вижу как раз бараваду. Да не простую браваду, а снобистскую браваду посредственностью.

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

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

VD>>Они локаничны, но совершенно не понятны.
S>Лаконичность нужно мерить не в символах, а в синтаксических элементах.

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

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

+1