Здравствуйте, Шахтер, Вы писали:
VD>>Не допускаешь, что то что ты считаешь нормальным в сравнении с другим языком может оказаться ужасно сложно и медленно?
Ш>Нет, я допускаю, что ты пытаешься подменить предмет обсуждения.
Ухот от ответа можно расцнить как "да, допускаю"?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Переносимость на уровне исходников, это и есть основной приоритет комитета.
К сожалению они добились полностью протевоположенного результата.
DC>Влад в чем заключается мой самообман? В том, что ОС и Драйверы на управляемых языках экспериментальные? Или в том что на данный момент подавляющее большинство ОС и драйверов написано на С++ и/или С?
Самообман то что все перечисленное тобой удобнее писать на С++. Порой вынуждены писать на С/С++ — да. Но никак не удобнее. А вынуждеды по банальной причине — сама ОС написана на С и все интерфейсы у нее тоже в С-формате. Вот и получается, что иногда тебе "удобнее" писать на С++ только лишь потому, что иначе ты не можешь. Хотя на саомо деле можешь, но многие даже в свою голову это уложить не могут.
DC>Т.е С++ говно полюбому? Да Влад это как мантра.
С++ марально устарел еще 5, а то и больше лет назад. Это здравый логический вывод. На мантру скорее похоже бездумное повторение слов роде твоих.
DC>А если компания его использует уже 10-15 лет? Зачем при налаженном процессе переходить куда-то?
Затем, что конкуретны не стоят на месте. И то что сходило с рук 10 лет может не сойти сегодни и завтра.
Первые 3D-игры были написаны на С без скриптов и разных вольностей. В них и 3D-то как такового не было. Второе покоеление уже писалось с использованием скриптов и С++. Следующие должны писаться уже без С++, да и без скриптов. Технологии резко двинулись вперед и мы имеем все что имели и в скриптах, и в С++ (причем без их проблем) в одном флаконе.
DC>Нет, просто на С++ тонны кода,
Серьезно? Ой не верится, что весь этот код будет использоватья в новых проектах. К тому же технологии на сегодня позволяют полжить код в библиотеки и использовать их в другом окружении.
DC> возможности его не сильно хуже существующих управляемых языков.
Вот это уже загиб еще тот. Они не то что бы хуже. По сравнению с лучшеми представителями они катастрофически хуже.
Собственно повторять не охота. Скачай все же презентацию. Погляди ее. С чем ты там собственно не согласен?
DC> Понимаешь чтобы вытеснить С++ нужно предложить что-то намного лучшее. Для Java и .Net снижают стоимость разработки, и порог вхождения низкий, специалистов проще найти. Но только для некоторых областей!!! Где собственно С++ наиболее плох для применения.
Уверяю тебя просто эти области еще не расскачались. Плюс не только Java и .Net существуют в мире. Есть ОКамл, например. Там где Java и .Net могут оказаться не применимы он может дать очень неплохой эффект. У него только одна схожая с С++ проблема — он не поддерживает компонентности. Но он имет существенные приемущества перед С++, так как он типобезопасный, управляет памятью автоматичкски и значительно более выразительный (обладает более мощьными конструкциями).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Да хотя бы то, что возможностей у языка не меньше, а библиотек просто море + это проверенный инструмент.
Оба пункта откровенная лож. Особенно по возможности. Ведь мы не сравниваем возможности с точки зрения машины Тьюринга? Ведь с этой точки зрения все языки (от VB, до ассемблера) равны. А вот проблем у С++ хватает. И варазительность у него явно отстает.
DC>А теперь все таки ответьте на мой вопрос. Что кардинально изменит Немерле или ОКамл. Не просто уменьшат многословность, а именно дадут?
Просто позволят решать более сложные задачи, или решать те же задачи меньшими силами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>А кроме уменьшения многословности ничего дать-то и нельзя. См. Тезис Чёрча. Впрочем, с учетом константности плотности ошибок ничего, кроме краткости, и не требуется.
Кстати, число ошибок не пропорционально объмему кода. Язык очень сильно влияет на их количество. С++ как будто специально спроектирован так, чтобы программист мог допускать трудноуловимые ошибки. ОКамл же и Немерле (за последний зуб даю) проектировались так, чтобы программист совершал как можно меньше ошибок. Так что одинаковый объем код написанный хорошими программистами на Немерле и на С++ не только будут различаться по объему реализованных возможностей (или их сложности), но и будут содержать разное количество ошибок. Что само по себе очень приятно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Все бежим изучать J?
J дает не ту краткость. Это уже краткость в ущерб выразительности. Такая краткость называется сжатием. Это все равно как обсуждать краткость сжатой zip-ом сттатьи. Ну, и что, что она в 10 раз меньше? Прочесть же ее невозможно!
Нам нужна краткость поднимающая выразительность, а не сокращение количества строк/символов любой ценой.
Краткость должна достигаться использованием более мощьных констуркций вроде пасттерн-матчинга и интуитивно понятными умолчаниями. А в J краткость достигается шифроподобными символами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dr.Chaos, Вы писали:
DC>Влад, я мощьности на свой комп ставлю не для микрософта и ее ОС, а для того чтоб прикладное ПО там быстрее бегало.
Ясно. Каждому свое. Я же использую более быстрое железо и более новую ОС чтобы повысить комфорт своей работы, улучшить свое настроение и получить больше фукнциональности. Вот скажем, меня устраивает функционал моего сотового (и темболее домашнего) телефона, и я даже не думаю о том, чтобы купить новый телефон, чтобы на нем что-то там быстрее работало.
DC>[оффтопик] DC>Меня если честно удручает такое положение, я всерьез задумался над переходом на KUbuntu. Я понимаю что мне дал XP — большую стабильность, у меня он стоит уже 4 года, при этом синих экранов вообще не вспомню, подвисаний не больше 3-5 в год, учитывая то, что ставил я много всяких программ. Что мне даст виста? 3D интерфейс который мне не нужен? Какие принципиальные удобства я получу? Исправление собственных багов ценой моих денег и ресурсов моего компа? DC>[/оффтопик]
Ты? Видимо некаких. Я же их уже получил. Незнаю насколько Виста стоит своих денег, но ОС получилась очень удобной. Это первая версия Эксплорера (не IE, а простого) которой я могу пользоваться не протирая монитор от слюней.
Кстати, а зачем ты используешь ХРюшу? Ведь до этого была В2к. Тоже вполне себе ничего ОС. А до этого была просто NT. И она была очень ничего... по тем временам.
DC>. А по сложности задачи? Движок в том или ином виде содержит в себе рендерер. Он правда заточен на другое.
Больше такую глупость никому не говори. Начиная с третьего Квэйка игры рендереры уже практически не содержат. Рендеринг переместился в видеокарту. Причем игры последнего поколения нагружают видиокарту значительно сильнее чем ЦП. По оценкам упоминавшейся тут презентахи соотношение вычислительных затрат таково:
Именно по этому в играх могут использоваться скрипты и именно по этому глупо включать рендереры в состав игр. Хотя несомненно, что рендерер может предоставить куда более высокое качество картинки. Вот только современные процессор еще не достаточно мощьны, чтобы обеспечить приемлемую скорость. И язык или платформа тут ничего не определяют.
DC>Сколько в комитете людей от компаний занимающих производством движков?
Довольно много. Там, кстатити, и МС представлен. Только толку — 0. И стандарта тоже нет. Его уже года 4 отодвигают, и отодвигают. Уже не толко Java с C# появилась, но и следующее поколение проклевывается.
DC>Ты сказал, что стандарт ничего не изменит. Т.е. этот стандарт бред, несуразица
Я сказал, что с точки зрения этой презентации (а стло быть всей разработки игр класса Анрыла) новый стандарт практически ничего не даст. Причем то что помогло бы разработчиком игр было бы одновременно полезным и для большинства других пользователей языка. Но это не путь С++, по всей видимости.
DC>Достаточно хорош — это означает, что любую задачу можно решить используя высокоуровневые конструкции и современные приемы проектирования, при этом добиться максимальной эффективности.
Любую задачу потенциально можно решить на ассемблере или скажем на С. Но это:
1. Не разумно в большинстве случаев.
2. Требует больеш ресурсов и усилий чем может реально быть в распоряжении компании.
DC>Здорово . Только вот переход будет долгим не столько из-за дальновидности или еще чего-то, новый инструмент должен себя зарекомендовать, мало того чтобы вытеснить, он должен дать что-то что кардинально улучшит процесс разработки.
Ага. Но тут есть одна радостная вещь. Те кто окажется прозорливее и свалят вовремя получат ощутимое конкурентное приемущество.
DC>Возможно, время покажет.
Несомненно. Вот только время такая штука... мы оцениваем его только тогда когда оно уже проходит. И обычно если не предпринимать определенных усилий, время конечно все рашает само, но мы оказывамся уже не удел.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Сегодняшнее железо бывает разным, и скажем, на ноутбук, где проблема времени жизни от аккумулятора является одной из важнейших не имеет смысла ставит операционную систему которая будет впустую потреблять много энергии.
Эта мысль замечательна сама по себе, но к сожалению не имеет отношения к реальности. Так как каждая новая ОС как минимум не хуже ведет себя в этом отношении чем предыдущая. Та же Виста позвояет временно отключать Аэро и переходить в весьма экономный режим.
VD>> И это правильно, так как если у меня в машине 3D-акселератор с поддержкой DX 9.0, двух-ядерный процессор и 1-2 гига памяти, то глупо не задействовать это богатство для улучшения комфорта и удобства.
АХ>Глупо не иметь возможности задействовать это богатство. Но так же бессмысленно требовать DX 9.0 видеокарту, двух-ядерный процессор и 1-2 гига памяти на офисном компе у секретарши на котором в основном читают почту и серфят Инет.
Дык никто и не требует. Альтернатив море. Секретарша может использовать ХРюшу, или выключить Аэро если ее машина не его не тянет.
Прогресс же не для секритарш на которых экономит начальство.
У меня самого две машины. Ноут и десктоп. Ноут по слабей, да и ОС на нем уже стоит. Менять я ее если и будут, то сильно позже. А десктоп вот новый. Со всем необходимым для Висты. Что же мне теперь ради солидарности с неграми использовать менее удобную ОС на которую нужно ставить кучу дров чтобы только она заработала на моем новом железе? Вовсе нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>А вот, ни в коем случае не в плане аргументации, просто как заметка. E>Ради интереса посмотрел объем исходиков в проекте, над которым сейчас работаю (3D-шутер для PC, находится на завершающей стадии разработки). E>Примерно 5 мегов исходников на C++, не считая сторонних библиотек, и 1 мег скриптов. E>Реальность, данная мне в ощущениях
Данные похожие на данные из приводимой мной презентации, но они мало что говорят об оправданности такого решения.
Из той же презентации видно, что на всю симуляцию игры уходит около 10% процессорного времени:
Из той же презентации ясно, что объе этого кода несколько больше чем объем вычислительного кода (который по всей видимости и принято считать кодом тех самых "движков"). Там указывалось, что объем вычислительного кода и объм кода симуляции написанный на С++ приблизительно одинаков 250 000 строк, но код симуляции к тому же еще содержит скрипты на языке похожем на Яву.
Учитывая, что, например, дотнет если и дает проигрыш в производительности, то он все равно измеряется в процентакх, и то, что процессорные затраты на него не велики, то не кажется ли тебе не разумным писать этот код на С++? Если вместо скрипа использовать безопасный, удобный, но быстрый язык — то вы могли бы значительно упростить себе работу при этом практически ничего не потеряв в производительности.
В итоге вы могли бы больше времени потратить на остальные части игры, или просто быстрее выпустить игру сделав ее при этом более надежной.
Так чем же тогда собственно определяется использование С++ хотя бы в области симуляции?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
J>>Я всего ее кода не видел, только маленький кусок, но что я увидел там: она была написала на С++, и более того, стратегии AI для игры за разные страны (там у разных стран разные строения, оружие, стоимость ресурсов и прочее, поэтому по-разному надо действовать) были тоже написаны на С++ и упрятаны в DLL-ки с названиями стран (т.е. если ты хотел играть против, скажем, Австрии, то просто подгружалась соответствующая DLL-ка и начинала против тебя играть). На моей тогдашней слабенькой машинке все летало.
E>Предполагаю, что такой подход использовали именно из-за того, что там такое огромное кол-во юнитов на поле одновременно. Возможно, скриптовый движок не потянул такое кол-во выполняемых одновременно скриптов. E>IMHO если юнитов поменьше (у нас, например, обычно не больше 20), то лучше все-таки писать скрипты. Тогда можно будет переложить работу с программистов на дизайнеров миссий, что во многих отношениях правильно.
Ребяты (с). Создать 64К простых юнитов не проблема. Представляй каждого из них простой структурой лежащей в массиве и нет проблем.
Скрипты этого скорее всего не позволят, но ведь кроме скриптов и С++ есть еще кое какие языки.
Мне вот интересно что даст скрипт по сравнению с тем же Немерле?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Дык и работает, только вот фортрановский модуль на AIX-е нигде кроме AIX-а работать не будет. Да и работать будет, потому что JNI на AIX-е реализуется через нативные AIX-овские коды. В таких условиях и к C++ модули C/Fortran спокойно линкуются.
Здравствуйте, Константин Л., Вы писали:
КЛ>хм...Ты business-analyst'ом работаешь? Если нет, то тогда лучше бы молчал.
А при чем здесь аналисты? Всё очень просто. Если так экономят на разработчиках сайта, который есть "лицо фирмы" — значит, на всё остальном экономят еще жестче.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А это один из критериев качества. Быстрее, меньше памяти требуется и т.д.
Качество — это когда программа делает свою работу правильно, не падает и не рушится. А скорость — это отдельный параметр, и к качеству никакого отношения не имеет.
Bulat,
BZ>преимущества Хаскела — очень строгая типизация, отлавливающая большинство ошибок с типами, и лёгкость конструирования алгоримтов из составных частей. я не представляю себе потребности игр,
Тим Свини в своей презентации утверждает, что очень хочется статического контроля выхода за пределы массивов, статического контроля за null-значениями, статического контроля за переполнением, хорошей поддержки concurrency, и подобные мелочей.
BZ>вот напоследок ещё один небольшой алгоритм. суть его в том, что есть а-ля RAR список номеров сбойных секторов в архиве и его надо разделить на две части — секторы, чей номер по модулю rec_sectors уникален (их можно восстановить), от тех, которые накладываются друг на друга:
Здравствуйте, dr.Chaos, Вы писали: DC>Ну уж нет, Си явно выражал концепцию структурного программирования, т.е. вводил новые абстракции что ли.
С действительно компактнее ассемблера, чем и рулит. С++ компактнее С. Новые абстракции не нужны сами по себе — они оправданы только тем, что сокращают запись. Тензорное исчисление само по себе ничего нового не дает по сравнению с обычной алгеброй. Просто более компактная запись длинных уравнений.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали: VD>Кстати, число ошибок не пропорционально объмему кода. Язык очень сильно влияет на их количество. С++ как будто специально спроектирован так, чтобы программист мог допускать трудноуловимые ошибки.
В некоторой степени согласен. Но в первую очередь ошибки С++ лежат там же, где и многословность. Например, встроенные указатели максимально компактны при определении, а любые мимикрирующие под них обертки — длиннее. Поэтому всегда есть искушение обойтись char* вместо std::string, и нарваться там ровно на все грабли с выходом за границы и несвоевременным уничтожением. VD>ОКамл же и Немерле (за последний зуб даю) проектировались так, чтобы программист совершал как можно меньше ошибок. Так что одинаковый объем код написанный хорошими программистами на Немерле и на С++ не только будут различаться по объему реализованных возможностей (или их сложности), но и будут содержать разное количество ошибок. Что само по себе очень приятно.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.