BZ>>когда ресурсы критичны, определённо ничего лучше С++ не сделаешь. но — может проблема была именно в некомпетентности тех программистов?
E>Программисты те, которые есть. Очень даже не плохие. И времени на решение задач, как всегда не много. Поэтому было сделано так, как было, в отведенное время уложились, результат получили. Теперь с ростом объемов результат E>оказывается неудовлетворительным.
я только в том смысле, что может, эта задача не так уж критична по времени/памяти, и при прямых руках её и на более высокоуровневом языке можно сделать, уложившись в требования. и при этом сэкономить время
E>Что до Erlang-а, то мы запустили свои решения в работу уже N лет назад, а про Erlang я услышал в первый раз здесь M лет назад,
так звучит лучше
E>Такое невежество может и не делает мне чести, однако это реальность. И существующие C++ продукты гораздо дешевле сейчас сопровождать и развивать, чем переписывать на чем-то другом.
E>Вообще же это уже начинается оффтопик. Любую задачу можно успешно решать разными инструментами. Важно, чтобы руки были правильные и инструмент хорошо в руку ложился. Не знаю как где, но в наших условиях человека гораздо проще научить программировать на C++ в стиле C with classes, чем на Erlang или Haskell. Это тоже, к сожалению (или к счастью) реальность, с которой приходится считаться.
более того — для Хаскела до сих пор нет ни одной книги типа "Haskell in real world", а некоторые элементарнейшие библиотеки типа сериализации мне пришлось писать самому. т.е. практика такова, что в этот вагон не стоит спешить. кстати, вышеупомянутая позиция с эрлангом — вообще, первая FP позиция, которую я увидел в нашей стране
года 4 назад я тусовался в ruby тусовке, которая находилась в таком же состоянии и мечтала о killer app. недавно я увидел, что в одессе ищут человека на ruby rails т.е. у них такой killer app всё же появился, и одно время, я слышал, большую часть сообщений в ruby-talk занимало именно обсуждение rails ну то есть потом для него создали отдельную эху
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А самолет, который я описал, движется ? Да. Летает со скоростью 100 км/час. И даже, может, и не падает. Жрет горючее как 100 Боингов, но летает
PD>Ну и счастливого полета на этом качественном самолете. В соседнюю деревню, За рогами и копытами.
Если до соседней деревни 15 километров, то скорости в 100км/ч за глаза хватит. Если горючего так же в избытке — то такой самолет можно применять, зачем что-то другое искать? Оно же ведь наверняка еще и больше денег стоить будет, за эффективность-то?
Здравствуйте, eao197, Вы писали:
E>Сколько сарказма
Это правда жизни.
E>Тема, я думаю исчерпана.
Для меня тема C++ исчерпана давно. Если бы некоторые индивидуумы всерьёз не считали бы C++ "сложным языком для сложных программ" и не пудрили периодически здесь мозги другим, то я бы о нём уже давно забыл.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Имхо, в этом и есть главная причина недопонимания собеседников. Почему-то считают, что в исходной фразе под 'absolutely complex problems' подразумевают абсолютно любые сложные задачи. Если же, к примеру, ограничить контекст сложными задачами в области системного программирования, тогда ситуация станет более реальной.
Тогда слова не будут восприниматься откровенным бредом и надменной наглостью, но спорности они все равно не потеряют.
Так к системным задачам традиционно относят компиляторы, но любой кто более менее знает Лисп, Хаскель, ОКамл... Немерле в конце концом понимает, что писать компиляторы на С++ весьма не разумное решение.
Что касается задач вроде дравйверов. Конечно! Конечно если сама ОС написана на С и у нее C API, драйверы работают в нулевом кольце защиты... то и думать нечего о написании драйверов на чем-то более продвинутом. Но ведь и ОС может быть другой! Блин, когда ОС вроде Сингулярити будет доступна смернным?!
E>Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.
Забыл добавить "... на С++". Иначе это не так верно. Замечательный пример обратного я скачал буквально недвано. BitTorrent. Программа написана на Питоне и офигительно качает себе в бэкграуде тонны файлов. Ну, да, жрет она 40 метров на моей машине. Ну, и фиг с ними! За-то она не вылетает, не глючит, проста и удобна в использовании, ставится в одно касание.
И это на тормозном Питоне! А что если взять языки которые от С++ по скорости кода мало чем отличаются? Мы только выиграем в качестве.
E>Или, скажем, приложение, которое разбирает и перемаршрутизирует трафик с сотнями/тысячами пакетов по каждому соединению. И соединений по несколько десятков. И временами интересные эффекты на уровне сетевого стека начинают происходить (к примеру, соединение умирает, а через select это не видно, как будто сокет жив и здоров). И опять, из простой по логике задача превращается в сложную по исполнению из-за своих условий.
Как не странно дрова и сетевые протоколы в Сингулярити написаны на C# и не уступают в эффктивности Линуксу с Виндовс. Хотя надо признать, что задача битодробления действительно хорошо подходя для С++ и единственной его проблемой тут будет его небезопасность.
E>Так что есть еще место для объектно-ориентированного почти ассемблера с шаблонами и исключениями (но без замыканий, монад, примитивов синхронизации и прочего).
Не так. С граблями, UB, скудными библоитеками, и без... далее по тексту.
E>Вообще-то на моей памяти максимальные оценки здесь получали как раз внезапно появляющиеся адепты функционального программирования, которые начинали рассказывать разные необычные для mainstream-программистов вещи.
Ну, ты то к ним не относишся и в топе форума.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Речь идет именно о морде. E>Существующая морда написана в лоб и слишком прожорлива. Сейчас приходится многое переделывать, чтобы удовлетворить поставленным условиям.
Блин, GUI то с каких пор является коньком С++? На нем GUI всегда было гемороем если не вспоминать C++Builder.
Я тебе на C# напишу такое ГУИ в десятки раз быстрее, проще и надежнее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Хм, т.е. все улучшения которые дают Немерл и Окамл это уменьшение многословности? Мда уж что-то тогда индустрия на месте топчется получается, только шаги красивше и меньше выходят.
Это ЗНАЧИТЕЛЬНОЕ увеличение уровня языка, при спопоставимой с С++ производительностью.
Давай простой эксперемент проведем.
К сожалени, человек практически не может оценить более мощьный язык. Об этом замечательно в свое время сказал Пол Грэхем
Вот попробуй сравнить классический ОО-код (на C#, правда, но на C++ он меньше не стал бы) на ООЯ с кодом на Немреле написанном в фукнциональном стиле: Re[9]: Принцип подстановки Барбары Лисков
Можно попробовать сравнить и на простых примерах. Покажи, например, как ты на С++ решил бы задачу преобразования массива целых (скажем std::vector<int>) в строку где каждое значение разделено запятой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, dr.Chaos, Вы писали:
DC>>>Переносимость на уровне исходников, это и есть основной приоритет комитета.
VD>>К сожалению они добились полностью протевоположенного результата. DC>Какого? Переносимости на уровне исходников нет? .
Ага. Странно что ты считашь себя С++-программистом и не знал этого. Полной переносимости нет, так как компиляторы не реализуют стандарт, и так как стандарт изобилует кучей мест где возможно UB. Про то что такое UB объяснять надо?
DC> Ты открыл мне глаза. Только как я компилюсь каждый деть с одним кодом под Win/AIX, может я что-то неправильно делаю??
Ты используешь не весь С++, а его упрощенный сабсэт который переносим для выбранных тобой компиляторов. Причем ты находишь этот сабсэт по интуции тупо компилируя и тестирую код на обоих платформах. Так же ты избегаешь использования чужих библиотек, так как не хочешь разбираться в том, что они используют из "запрешенного С++".
DC>Влад удобнее хотя бы потому, как это проверенный временем инструмент. Те что по-новее пока в стадии, если не разработки, то активного тестирования — не дальше.
С тоже был проверен временем, а С++ молод и недоработан. Но почему-то ты на С сейчас не пишешь ведь.
VD>>С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод. DC>В чем его моральная старость?
Во многом. Главный список фич:
1. Наличие моря UB.
2. Отсуствие автоматического управления памятью.
3. Не типобезопастность.
4. Наличие моря граблей в добавок к гланым гряблям из п. 3.
5. Плохая выразительность определяемая отсуствием в языке (вделенно так как библиотечная реализация перечисляемых фич сильно ущербна) удобных конструкций вроде функциональных объектов, интерфейсов (или классов типов Хаскеля если угодно), замыканий, модульности, метааднных, компонентности, сопоставления с образцом, полноценной системы метапрограммирования.
DC>Каких именно слов? То, что это достаточно хороший инструме
Например, вот этих:
Кто кроме С++ дает такие возможности с обобщенным программированием при строгой типизации? Java, .Net?
Чем тебе дженерики дотнета не обобщенное программирование при строгой типизации? И знаком ли ты с обобщенным программированием в Хаскеле и ОКамле, например?
DC>Влад кто из производителей движков/ОС/драйверов переходит на Немерле/ОКамл/...
Самые умные.
VD>>Второе покоеление уже писалось с использованием скриптов и С++. DC>Использование скриптов ИМХО еще позже появилось.
Погляди Анрэл 1.
VD>>Следующие должны писаться уже без С++, да и без скриптов. Технологии резко двинулись вперед и мы имеем все что имели и в скриптах, и в С++ (причем без их проблем) в одном флаконе.
DC>Кому должны и где имеем?
По логике должны. Но логика не всегда работает в человеческом мире.
DC> Где 3Д библиотеки для Немерле/ОКамл/... которые удовлетворяют разработчиков движков?
Они прекрасно исползуют имеющиеся бибилотеки. Для Немерле будет радным XNA, от МС и DirectX (хотя с выходом XNA смысла в последнем мало), для ОКамла лучше одойдет OpenGL, так как он довольно кросплатформынй. В прочем и для Немерла можно OpenGL исползовать. Инетроп у него отличный. Любые С-шные библотеки в виде dll/so он глотает без проблем.
DC>Какие поименно? — причем в разрезе применения для ОС/драйверов/графических движков.
Выразительность, типобезопасность, безграбельность, проверяемость (контрль времени компиляции за инвариантами и т.п.), ктаткость. В общем, почитай о том же Немерле или Скале хотя бы. А лучше попробуй. Уверяю тебя, что как только втянешся мнение твое резко начнет меняться. Я вообще-то тоже старый С++-ник. Просто меня перевербовали. Сначала через компонентные технологии, а потом и по астальным каналам.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Каких возможностей не хватает в С++ : сопоставления с образцом? — В движках всегда switch'a хватало;
Про блаба я уже давал ссылку?
DC> Замыканий? — да могу я их сделать функторами; как собственно и ФВП ; да это не будет так красиво, и кратко как в ОКамле или Немерле.
Это будет настолько не красиво, что ты быстро бросишь это дело и вернешся к циклам и т.п. Да и читать это бует не очень приятно. Без сахара вроде лямбд и частичного применения ФВП мало что дают. Хотя бесспорно их можно и в С++ использовать. Но не красиво это получается.
DC>Только объясни мне где в алгоритмах в движке их применять. Я, если честно, не вижу сильного выигрыша от их применения.
Я не знаком с твоей спецификой, но уверяю тебя, что в любом коде будет выигрышь.
VD>>Просто позволят решать более сложные задачи, или решать те же задачи меньшими силами.
DC>Вот блин опять абстракция, я про движок графический спрашиваю. То что в физическом движке ФП будет возможно лучше использовать, я соглашусь, но ты мне объясни где я выиграю в 3D движке???
Ладно. Уломал речистый. Дам тебе один убийственный аргумент — макросы. Они тебе позволят сделать движок в разы проще и максимально эффективно. Более мощьного средства для создания системных средств еще не придумано. А макросы того же Немерла — это одна из лучих реализаций оных среди существющих. Соперчинчать реально могут только макросы Лиспа, но Лисп динамически типизирован, весма своеобразен и слишком сложен для восприятия (скрипты им вряд ли заменишь). А уж метапрограммирование на шаблонах С++ вообще пролетает по всем статьям.
ЗЫ
Эти слова не значат, что кроме макросов ничего нет. Просто приемущество макросов тебе будет проще понять. А там если заинтересушся, то все пойдет смо собой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Читай выделенное.для рендеринга просто используется как ты правильно заметил дополнительный специализированный процессор.
Ага. И, заметь, все вычисления он производит самостоятельно. Тебе только надо ему данные (в виде текстур, полигонов и шейдеров) скормить. А это отнюдь не самые бльшие процессоные ресурсы требует.
Такие языки как C# или Nemerle с такой задачей справятся великолпно. Да что там они. Вот погляди: http://www.haskell.org/haskellwiki/Frag
это Ку3 написанный на Хаскеле! А Хаскель — это очень медленно.
DC>MC там представлен я не сомневаюсь, только MC не производитель движков.
Да? А кто по твоему MS Flight Simulator делает?
А Эдж Оф Эмпаир под чьим крылом? К тому же они делают главную штуковину DirectX, XNA и драверы для видео. Так что они точно знают что нужно разработчикам игр.
VD>>Я сказал, что с точки зрения этой презентации (а стло быть всей разработки игр класса Анрыла) новый стандарт практически ничего не даст. Причем то что помогло бы разработчиком игр было бы одновременно полезным и для большинства других пользователей языка. Но это не путь С++, по всей видимости.
DC>Оооо. Сколько оговорок появилось для простой фразы — Ничего не изменит.
Какие оговорки?
VD>>Любую задачу потенциально можно решить на ассемблере или скажем на С. Но это: VD>>1. Не разумно в большинстве случаев. VD>>2. Требует больеш ресурсов и усилий чем может реально быть в распоряжении компании.
DC>С и Асм не предоставляют столько высокоуровневых абстракций для проектирования. Мало того на С++ действительно неразумно решать многие задачи, т.к. появились специализированные инструменты.
Все тоже самое справидливо по отношению скажем С++ vs. Немерле. Написать то можно все, но абстракций удобных меньше. Тало быть писать сложнее. А это приводит к тому, что при некотором уровне сложности задачи перестают решаться в разумные сроки и за разумные деньги.
DC>Я и не сомневаюсь, только до этого, как ты сам оценил 5-10 лет.
Через 10 будет поздно. Все уже будут там.
DC>С++-шники не у дел не останутся . Они просто перейдут в другие области.
С-шники и даже Кобольники тоже так говорили. И некоторые до сих пор работают на своих любимых языках.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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) -- Hoping to increase the popularity of its Zortech C-plus-plus compiler, Symantec has introduced two new versions for the DOS and OS/2 platforms.
The new versions, Zortech C-plus-plus version 3.1 for DOS and Windows 3.1 and Zortech C-plus-plus version 3.1 for OS/2 2.0, are fully compliant with AT&T CFRONT C-plus-plus version 3.0 and ANSI C and, according to the company, offer full 32-bit and advanced numerics support.
The company says that AT&T compliance is important to programmers because it gives support for pre-compiled headers and templates, thereby saving compilation time and increasing code reusability. Zortech C-plus-plus 3.1 conforms to the IEEE-754 floating point standards and the NCEG 91-015 draft for numerical extensions.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Тема, я думаю исчерпана.
Ой, очень давно. И вообще я уже несколько часов читаю и с ужасом жду когда вы начнете обсуждать очередность выхода компиляторов С от МС, а потом Фортрана от IBM и понимаю, что спать мне оставалось каких-то два часа... (с)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
C>>Некоторые товарищи до сих пор preprocessor-based компиляторы поставляют.
IT>
А что смешного то? Прикинь С++ переносим только с бутылкой водки и какой-то матерью, а С переносим замечательно. Но мы такие вот умные и написали все на С++. Что делать если надо это дело по шустрому портировать на 20 платформ? И тут мы находим препроцессор в С... быстренько делаем код совместимым с ним и тупо компилируем исходники на все нужных платформах.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>я тоже могу привести свой код, но смысл? я специально привёл маленькие примеры, которые позволяют увидеть экспрессивную мощь ФП. для любой обработки данных (с которой я встречался) ф.п. упрощает дело. и чем сложнее алгоритмы, тем больше ты выигрываешь. НО — это работает медленней, чем императивнй код
Последнее заблуждение. Или не всегда правда. Если испльзовать Хаскель, то конечно. Если пытаться реализовать все функционально (даже, скажем быструю сортировку), то тоже конечно. Но если использовать язык который позволяет писать и функционально и объектоно-ориентировано, и еще макросами побаловаться, то все уже совсем выглядит по другому. Можно добиваться скорости С++ или даже больше (за счет более сложных алгоритмов) и при этом иметь краткий и выразительный код.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, dr.Chaos, Вы писали: DC>>Ну уж нет, Си явно выражал концепцию структурного программирования, т.е. вводил новые абстракции что ли. S>С++ компактнее С. Новые абстракции не нужны сами по себе — они оправданы только тем, что сокращают запись.
С++ компактнее С только при условии, что на С код пишется в объектно-ориентированном стиле. ООП позволяет решать более сложные задачи за счет ОО-декомпозиции. Но кода получается обычно даже больше.
Но на С можно писать и в фукнциональном стиле, и в простом структрном, процедурном. При этом иногда даже получается более краткий и понятный код.
Вот такие парадоксы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Простота == лаконичности.
Это не верно. Отличные примеры демонструющие ошибочность такой логики это:
* J.
* Регулярные выражения.
Они локаничны, но совершенно не понятны.
Правильно будет утверждать, что простота == выразительная лаконичность.
То есть когда мы можем выразить мысль более кратко, но при этом не теряя в понятности.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>В предыдущем посте я имел в виду сложность модели. А в начальном именно упрощение синтаксиса. Т.е. Понятия ООП позволили представлять более сложные модели. Немерле и ОКамл, по вашим, утверждениям служат только для уменьшения многословности, что я воспринял, как простое упрощения синтаксиса (не хочу употреблять "синтаксический сахар", а то еще один флейм поднимут ). Я прошу дать именно те абстракции которых нет в С++, но есть в Немерле/ОКамл, которые позволят мне понизить сложность при создании алгоритмов для 3Д движка.
Дык модели они тоже более кратко описывают. И более того, они позволяют эти модели так же кракто оанализировать! И тут С++ сливает по полной. Впрочем как любой чистый ООЯ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>Между тем, есть отличные игры, которые без нее неплохо обходятся. Посмотрите, например, на Call of Duty.
Дык посмотри дуум 1-2 или вообще Вульфа2Д. Они прекрасно обходились без 3Д-акселерации (да и без 2Д тоже).
Хреновый аргумент? Вот твой такой же.
Да, сегодняшние игры обходятся, но они примитивны. Вних мало объектов, мало динамики, мало взаимодействий. Будущие игры возможно позолят иметь 64К юнитов, но уже не таких примитивных тупых точке как в Казаках, а таких как боты в Ку3. Но при этом ЦП (и не один!) должен будет целиком заняться логикой их поведения используя для этого мощьные средства вроде сопоставления с образцом или локики предикатов. Вот тогда перекладывание всей физики на плечи специализированной железки будет оправдано и даст хороший эффект.
Только проблема в том, что тут нужны стандарты и интеграция. Такие ускорители лучше всего встраивать в графические платы. Все равно игровая машина без серьезного видо-адаптера немыслема.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
и длинные руки 
Если нам не помогут, то мы тоже никого не пощадим.
.