Здравствуйте, Alexmoon, Вы писали:
A>Здравствуйте, BulatZiganshin, Вы писали:
A>Раз уж остановился здесь, то отвечу на этот пост. Прошу не воспринимать как личный выпад.
тут проблема скорее в противоположном — чтоб мои слова не воспринимались слишком близко к сердцу
A>С чего все началось: A>
A>We need relatively complex language to deal with absolutely complex problems.
A>Это фразой сказано абсолютно все и ничего более. Эволюция только потому и появилась в нашем лексиконе, потому абсолютное совершенство недостижимо в принципе, не говоря уже об этапе рождения. Все что приходит после — лишь наследие того, что появился какой то глобальный набор задач, который требует уточнения используемых инструментов и их постепенного развития.
представьте себе ассемблер с ООП расширениями, шаблонами, клозурами, монадами, примитивами синхронизации и т.д. смешно? было бы смешно, если б не было близко к правде. С появился как язык системного программирования, высокоуровневый ассемблер, и именно благодаря своей эффективности, близости к железу он завоевал симпатии в мире ранних мини-компьютеров и персоналок, с их скромными ресурсами
в 80-х было три конкурирующих языка процедурного программирования — С, паскаль, модула-2. для прикладного программирования наилучшим, имхо, была модула. в области ООП были представлены Эйфель, С++ и Objective C. Objective C предлагал компонентное программирвоание (кто-то здесь ругался на то, что его не "догадались" сделать в С++), Eiffel на мой взгляд — это вообще референсный компилируемый ООП язык
выиграли соревнование парочка С/С++. почему? имхо потому, что во-первых они обеспечивали обратную совместимость (в отличие от идеальной на мой взгляд пары Модула/Эйфель), во-вторых народ тогда ещё беспокоился об эффективности и ObjC с его всегда динамическим связыванием выглядел подозрительно
последние 15 лет С++ развивается только в направлении усиления шаблонов (можете поправить меня — тут я не гуру), т.е. всё той же идеи наиболее высокоуровневой записи высокоэффективного кода. ну и учитывая прогресс в области оптимизации, сейчас С++ является наиболее высокоуровнеым способом написать код, который будет не медленней ассемблерного. и это здорово
однако когда речь доходит ло прикладного программирования и эффективность оказывается не главным, тут С++ напоминает Винни-Пуха, который прикидывался тучкой в языке нет GC и type-safe generic references, синхронизации, клозур и т.п. ну и фиг с ним! мы всё это сэмулируем! в результате чего есть язык С++, содержащий массу конструкций, которые прикладному программисту просто не следует использовать, и многочисленные бибилиотеки, которые худо-бедно эмулируют возможности, напрямую встроенные в другие, более современные языки
вот поэтому вы и need a complex language — чтобы созранить совместимость с кодом 30-летней давности, сгенерить как можно более эффективную программу, а затем попытаться как-то сэмулировать современные языки. что из этого получается, можно охарактеризовать далогом из моей переписки:
— пробовал я эти lazy evaluation да higher-order funcs. фигня, код даже для простых вещей получается сложным и неудобочитаемым
— а какой язык ты пробовал?
— какой язык? они же в boost есть!
я тут выше приводил пару примеров кода в хаскел, напиши их аналоги в С++ и сравни сам. если вместо изучения всех этих legacy features и методов эмуляции modern features изучать напрямую современный язык, то ты здорово сэконишь во времени изучения и затем во времени написания/отладки кода. но понятное дело, что если ты уже 15 лет живёшь с С++ и занешь его до тонкостей, то возможность другого человека лёгким движением руки достичь аналогичной квалификации кажется тебе чем-то неправильным и поневоле начинаешь искать контраругменты. я лично всегда интересовался ЯП и знаю их до чёрта, поэтому меня углубление в детали в С++ давно перестало интересовать, ещё со второй версии языка с её немерянными правилами относительно множ наследования
A>
BZ>>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет.
A>А я когда пишу с применением не удовлетворяющего вас языка, то при условии правильного архитектурного рещения, у меня проблем в многопоточной среде не возникает вообще. Если ты владеешь инструментом и знаешь платформо-зависимую реализацию используемого, то язык тебе не помощник. От всех неурядиц в жизни даже мама не спасет. Что значит словосочетание километры геморроя придется искать в словаре. Мне конструкций и объектов синхронизации хватает для решения любых вопросов. Конечно язык позволяет достичь и non thread-safe реализаций, но это не значит, что меня обязывают делать именно так или язык ущербен.
именно об этом я и говрю — что в С++ thread-safe программирование требует специального изучения и в job offers, например, указывается как отдельное требование чтобы понять, насколько это смешно, представьте себе скажем требование "умение вызывать функции рекурсивно". это тоже может специальным умением в языке типа Фортрана, где это не поддерживалось
т.е. опять речь о complex language, порождённом тем, что современные концепции программирования в нём — нечто дополнительно прикрученное сбоку с теми самыми километрами художеств
ps: кстати, насчёт +500 — мне счас пришло в голову, что принятая на этом форуме система оценки поощряет конформизм, в частности поощряет сторонников mainstream языков программирования
Здравствуйте, BulatZiganshin, Вы писали:
BZ>однако когда речь доходит ло прикладного программирования и эффективность оказывается не главным, тут С++ напоминает Винни-Пуха, который прикидывался тучкой в языке нет GC и type-safe generic references, синхронизации, клозур и т.п. ну и фиг с ним! мы всё это сэмулируем! в результате чего есть язык С++, содержащий массу конструкций, которые прикладному программисту просто не следует использовать, и многочисленные бибилиотеки, которые худо-бедно эмулируют возможности, напрямую встроенные в другие, более современные языки
BZ>вот поэтому вы и need a complex language — чтобы созранить совместимость с кодом 30-летней давности, сгенерить как можно более эффективную программу, а затем попытаться как-то сэмулировать современные языки. что из этого получается, можно охарактеризовать далогом из моей переписки:
Имхо, в этом и есть главная причина недопонимания собеседников. Почему-то считают, что в исходной фразе под 'absolutely complex problems' подразумевают абсолютно любые сложные задачи. Если же, к примеру, ограничить контекст сложными задачами в области системного программирования, тогда ситуация станет более реальной.
Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.
Или, скажем, приложение, которое разбирает и перемаршрутизирует трафик с сотнями/тысячами пакетов по каждому соединению. И соединений по несколько десятков. И временами интересные эффекты на уровне сетевого стека начинают происходить (к примеру, соединение умирает, а через select это не видно, как будто сокет жив и здоров). И опять, из простой по логике задача превращается в сложную по исполнению из-за своих условий.
Так что есть еще место для объектно-ориентированного почти ассемблера с шаблонами и исключениями (но без замыканий, монад, примитивов синхронизации и прочего).
По поводу применимости C++ в прикладных областях и по поводу прикручивания в C++ lazy evaluation и high order funcs я с вами согласен.
PS.
BZ>ps: кстати, насчёт +500 — мне счас пришло в голову, что принятая на этом форуме система оценки поощряет конформизм, в частности поощряет сторонников mainstream языков программирования
Вообще-то на моей памяти максимальные оценки здесь получали как раз внезапно появляющиеся адепты функционального программирования, которые начинали рассказывать разные необычные для mainstream-программистов вещи.
PPS.
Eiffel действительно замечательный язык. Но, имхо, загубил его маркетинг.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.
по-моему, здесь неправильная постановка эту вот хрень надо определённо разделить на сервер и морду
E>Или, скажем, приложение, которое разбирает и перемаршрутизирует трафик с сотнями/тысячами пакетов по каждому соединению. И соединений по несколько десятков. И временами интересные эффекты на уровне сетевого стека начинают происходить (к примеру, соединение умирает, а через select это не видно, как будто сокет жив и здоров). И опять, из простой по логике задача превращается в сложную по исполнению из-за своих условий.
очень хорошо решается на эрланг. здесь даже job offer есть с такой примерно фразой — "покажем, что не только Ericson умеет надёжэные распределённые системы на эрланге писать!" кстати, может и предыдущая задача к нему подходит? по крайней мере, правила обработки приятней писать на эрданге, нежели изобретать свой язык
BZ>>ps: кстати, насчёт +500 — мне счас пришло в голову, что принятая на этом форуме система оценки поощряет конформизм, в частности поощряет сторонников mainstream языков программирования
E>Вообще-то на моей памяти максимальные оценки здесь получали как раз внезапно появляющиеся адепты функционального программирования, которые начинали рассказывать разные необычные для mainstream-программистов вещи.
меня определённо ждёт успех!
E>Eiffel действительно замечательный язык. Но, имхо, загубил его маркетинг.
а имхо дело было именно в том, что он не предлагал постепенной миграции, как C++. C и C++ в конце 80-х как бы взаимно усиливали позиции друг друга. первый был популярен потому, что с него легко можно было перейти на ООП язык (а ООП было coined уже тогда, хотя приличных компиляторов ещё не было), а С++ — потому, что на него легко было переходить с С
Здравствуйте, BulatZiganshin, Вы писали:
E>>Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.
BZ>по-моему, здесь неправильная постановка эту вот хрень надо определённо разделить на сервер и морду
Речь идет именно о морде.
Существующая морда написана в лоб и слишком прожорлива. Сейчас приходится многое переделывать, чтобы удовлетворить поставленным условиям.
E>>Или, скажем, приложение, которое разбирает и перемаршрутизирует трафик с сотнями/тысячами пакетов по каждому соединению. И соединений по несколько десятков. И временами интересные эффекты на уровне сетевого стека начинают происходить (к примеру, соединение умирает, а через select это не видно, как будто сокет жив и здоров). И опять, из простой по логике задача превращается в сложную по исполнению из-за своих условий.
BZ>очень хорошо решается на эрланг. здесь даже job offer есть с такой примерно фразой — "покажем, что не только Ericson умеет надёжэные распределённые системы на эрланге писать!" кстати, может и предыдущая задача к нему подходит? по крайней мере, правила обработки приятней писать на эрданге, нежели изобретать свой язык
Сильно сомневаюсь в производительности erlang-овского решения. В задаче нужно не только разбирать и перемаршрутизировать, но и некоторую обработку делать. В довольно ограниченных, опять же, ресурсах.
E>>Вообще-то на моей памяти максимальные оценки здесь получали как раз внезапно появляющиеся адепты функционального программирования, которые начинали рассказывать разные необычные для mainstream-программистов вещи.
BZ>меня определённо ждёт успех!
Желаю удачи!
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
май 90 — tc++ 1.0 (кстати, одновременно с drdos 5.0 и win 3.0)
три месяца спустя — 1.01
февраль 91 — bc++ 2.0 с поддержкой программирования под винды (просто sdk туда включили). кстати, полная исталляция — 17 мег, что на 40-никах тогдагних времён смотрелось sexy
ноябрь 91 — tc++/dos 3.0 и tc++/win 3.0. каждый содержал среду и библиотеки только для одной платформы
июнь 92 — bc++ 3.1 (среда и библиотеки для обоих платформ плюс dpmi-16)
как вилите, настоящая чехарда. они позиционировали BC как платформу для профессионалов, с большей ценой, поэтому tc и bc продавались параллельно, но новые версии выпускались не синхронно
tc101 и bc31 у меня есть. в последнем точно есть темплейты. НО — в ходе развития C++ темплейты непрервыно разивались, так что неудивительно, что в 4.0 они стали более продвинутыми и т.д.
Здравствуйте, dr.Chaos, Вы писали:
BZ>>преимущества Хаскела — очень строгая типизация, отлавливающая большинство ошибок с типами, и лёгкость конструирования алгоримтов из составных частей. я не представляю себе потребности игр, но вот к примеру печать простых чисел:
DC>Жаль у меня нет куска кода для оптимизации сцены при преобразовании во внутренний формат движка . Могли бы провести эксперимент .
я тоже могу привести свой код, но смысл? я специально привёл маленькие примеры, которые позволяют увидеть экспрессивную мощь ФП. для любой обработки данных (с которой я встречался) ф.п. упрощает дело. и чем сложнее алгоритмы, тем больше ты выигрываешь. НО — это работает медленней, чем императивнй код
BZ>>я к примеру пишу многопоточную программу, проблем с синхронизацией практически не возникает, а если и возникают — достаточно добавить операцию withLocking при создании переменной и withLock при её использовании. а почему так просто? потому, что язык функциональный, изменяемых данных (а тем более разделяемых при этом между разными нитями) раз-два и обчёлся. в C++ же вокруг этой проблемы три километра геморроя, вплоть до написания thread-safe конструкторов копирования отсюда и результат — я думаю о реализации логики задачи, вы — боретесь с трудностями и при этом продолжаете верить, что после C++ ничего лучше уже не будет
E>Я постоянно пишу многопоточные программы на C++ и проблем с синхронизаций практически не возникает. Потому что специально заточенным для этого инструментом пользуюсь. Так что функциональность или императивность языка здесь дело далеко не принципиальное.
разница в том, что ты поьзуешься специальным инструментом, который потребовал специального изучения, а я первые 8 месяцев вообще ничего не делал. оно просто работало ввиду отсутствия расшаренных ресурсов. потом такой ресурс появился и я добавил к нему locking. it's all. поэтому я и утверждаю, что сложность С++ вызвана его попыткой быть одновременно и эффективным никзоурневым языком, и языком прикладного программирования и обилием legacy features, а не сложностью типичных решаемых задач
Здравствуйте, BulatZiganshin, Вы писали:
BZ>тут проблема скорее в противоположном — чтоб мои слова не воспринимались слишком близко к сердцу
Я как раз близко к сердцу и не воспринимал, но раз дискуссия продолжается теми аргументами, которые есть, значит кто то все таки это воспринимает именно так
BZ>представьте себе ассемблер с ООП расширениями, шаблонами, клозурами, монадами, примитивами синхронизации и т.д. смешно? было бы смешно, если б не было близко к правде. С появился как язык системного программирования, высокоуровневый ассемблер, и именно благодаря своей эффективности, близости к железу он завоевал симпатии в мире ранних мини-компьютеров и персоналок, с их скромными ресурсами
Теперь не применительно только к этой фразе а вывод в общем. Каждый инструмент создается as main concept для определенных задач. Кто то ниже говорил "разделять сервер и морду". Я совершенно с этим согласен и как видишь даже в бессмысленный спор не вступаю. Вопрос лишь в том кто будет морду реализовать.
Я прекрасно представляю ассемблер с шаблонами и примитивами синхронизации, но и вы представте C# в виде монстра, который решает не только задачи прикладного програмирования, а еще и будет перекручен конструкциями с определенными unmanaged оговорками для свободного манипулирования ресурсами под уровень ядра, либо все таки МС придется извратится чтобы все возможные варианты изобразить MSIL компилером. Все равно это будут не логичные для его контекста описания. Вообщем заметьте Г. получается как с одной, так и с другой стороны. Не нужно все это.
Пускай C++ занимается задачами в своем стиле и не нужно ему всего что касается managed расширений. Человек, который не хочет следить за ресурсами сам, либо не умеет оперировать типами, пускай не лезет в ++ (это не характеризует недостатки языка). При правильном архитектурном подходе, я поверь мне уже практически избавился от страшных снов связанных с этим, абсолютно. Каждый инструмент требует определенных навыков, опыта и мозгов. Кесарю, кесарево. Железная истина. Для прикладников языки другие.
BZ>в 80-х ...
Хватит о них. Мне 33 и я помню о них прекрасно. По моему до сих пор в обсуждении остались только люди, которые хоть как то ориентируются во всем этом флейме, не воспримите за оскорбление.
BZ>последние 15 лет С++ развивается только в направлении усиления шаблонов.
За исключением доработки в сторону узких мест — ты совершенно прав. Метапрограммирование — это следующий шаг развития.
BZ>однако когда речь доходит ло прикладного программирования и эффективность оказывается не главным, тут С++ напоминает Винни-Пуха, который прикидывался тучкой в языке нет GC и type-safe generic references, синхронизации, клозур и т.п. ну и фиг с ним! мы всё это сэмулируем! в результате чего есть язык С++, содержащий массу конструкций, которые прикладному программисту просто не следует использовать, и многочисленные бибилиотеки, которые худо-бедно эмулируют возможности, напрямую встроенные в другие, более современные языки
Вот и пускай будут они туда встроены. !!!! О БОЖЕ, мы наконец приходим к тому, к чему с самого начала стремились.
1. Я счастлив, что простому прикладнику наконец сделали инструменты, которые позволяют меньше думать и больше работать, но это отнюдь не означает что С++ плох. Ему просто все эти расширения не нужны.
2. Если человек владеет С++ — это должно четко обозначать что он в состоянии за время не меньшее, чем прикладник с помощью своего инструмента, может эмулировать все те вещи о которых мы говорим.
Для меня это кристальная истина. Все остальные лишь используют язык, в каких то узких целях, который им возможно и не нужен.
В языке достаточно минимально необходимых примитивов для эмуляции чего угодно. Все что нельзя сделать, неправильно концептуально спроектировано
То что язык развивается в сторону метапрограммирования на базе шаблонов — это совершенно логичесное и естественное развитие языка данного уровня.
BZ>вот поэтому вы и need a complex language — чтобы созранить совместимость с кодом 30-летней давности, сгенерить как можно более эффективную программу, а затем попытаться как-то сэмулировать современные языки.
Что вы так пристали к этой совместимости. Она остается до сих пор только потому, что нет смысла язык наворачивать не свойственными ему вещами изначально.
Если для вас совместимость главный критерий, то для меня абсолютно. Я уже ранее говорил, что в определеной степени владения языком нет проблем в эмуляции того о чем мы говорим. Просто кто то — это сделает быстрее, а кто то не сделает вообще и то что язык требует более высокого уровня skills — это не недостаток его, а лишь характеристика.
BZ>я тут выше приводил пару примеров кода в хаскел, напиши их аналоги в С++ и сравни сам. если вместо изучения всех этих legacy features и методов эмуляции modern features изучать напрямую современный язык, то ты здорово сэконишь во времени изучения и затем во времени написания/отладки кода.
может ведь и не хватить мозгов ее отладить даже в такой среде. все относительно.
на времени обучения сильно сэкономишь, но сильно проиграешь в развитии и гибкости.
BZ>именно об этом я и говрю — что в С++ thread-safe программирование требует специального изучения и в job offers, например, указывается как отдельное требование чтобы понять, насколько это смешно, представьте себе скажем требование "умение вызывать функции рекурсивно". это тоже может специальным умением в языке типа Фортрана, где это не поддерживалось
Сравнивать "рекурсивный вызов" и "thread-safe" — это все равно что в правах на вождение автомобиля указывать уровень владения самокатом. Давайте не опускаться до такого уровня. Человек ничего не знающий о потоках и разделяемых ресурсах и в C# репу перегреет такими понятиями как ThreadMutex и т.д.
BZ>т.е. опять речь о complex language, порождённом тем, что современные концепции программирования в нём — нечто дополнительно прикрученное сбоку с теми самыми километрами художеств
Где явное определение того, что так называемый complex language охватывает весь спектр современных концепций и что есть весь спектр современных концепций?
Я надеюсь понятно без лишних объяснений почему вам не удастся быть объекивных в этой части вопроса.
Здравствуйте, eugene0, Вы писали:
E>Зачем что-то колбасить? Вот LUA, вот python. Для того, чтобы делать что-то новое, нужно, чтобы это новое было чем-то лучше, чем готовое и многократно использованное и оттестированное старое. Чем вот эти псевдоязыки были бы лучше?
А всем ли хорош Python. Если дизайнер совершит ошибку (переменную одного типа присвоит переменной другого типа), то эта ошибка выявится только после прогона сценки по всевозможным сценариям, причём, возможно, ошибка выявляется в уж очень редких случаях. Вот в Nemerle нет такого фатального преимущества, потому он лучше.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну а Боинг, Локхид и Туполев продолжают своими делами заниматься — изготовляют качественные самолеты. И с некоторым удивлением смотрят на это авиамоделирование
Профессиональные лучники, годами оттачивавшие мастерство и способные эффективно поражать цели на расстоянии в 200 метров, тоже долго с умилинем поматривали на крестьян с пороховыми пукалками, которые могли стрелять на 50 метров, имели малую убойную силу и долгое-долгое время перезарядки. Но зато не требовали обучения.
Однако лучники — они ведь настоящие мастера, им всегда рады в любой армии мира
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, BulatZiganshin, Вы писали:
E>>>Вот к примеру, требуется GUI программка для on-line мониторинга сотни-полутора параметров с дальнейшим привязыванием к этому мониторингу трендов, звуковой сигнализации и пр. И чтобы для каждого параметра можно было задавать свои правила обработки. И чтобы работая в фоне отжирала не более 10%-15% процентов процессорного времени. И памяти не больше десятка-другого мегабайт. Бах -- и задача из простой превращается в сложную.
BZ>>по-моему, здесь неправильная постановка эту вот хрень надо определённо разделить на сервер и морду
E>Речь идет именно о морде. E>Существующая морда написана в лоб и слишком прожорлива. Сейчас приходится многое переделывать, чтобы удовлетворить поставленным условиям.
когда ресурсы критичны, определённо ничего лучше С++ не сделаешь. но — может проблема была именно в некомпетентности тех программистов? у меня в программе есть вещи, которые работают быстрее, чем у конкурентов на С++. и не потому, что я волшебник, а потому, что они используют более простые алгоритмы. более высокий уровень языка даёт возможность больше времени потратить на алгоритмическую оптимизацию. и делать это, заметим, интереснее, чем писать низкоуровневый код
у них скорость сервера получилась сравнимой с апачем, правда имхо за счёт того, что они использовали light-weight threads, а апач тогда — нет
E>>>Или, скажем, приложение, которое разбирает и перемаршрутизирует трафик с сотнями/тысячами пакетов по каждому соединению. И соединений по несколько десятков. И временами интересные эффекты на уровне сетевого стека начинают происходить (к примеру, соединение умирает, а через select это не видно, как будто сокет жив и здоров). И опять, из простой по логике задача превращается в сложную по исполнению из-за своих условий.
BZ>>очень хорошо решается на эрланг. здесь даже job offer есть с такой примерно фразой — "покажем, что не только Ericson умеет надёжэные распределённые системы на эрланге писать!" кстати, может и предыдущая задача к нему подходит? по крайней мере, правила обработки приятней писать на эрданге, нежели изобретать свой язык
E>Сильно сомневаюсь в производительности erlang-овского решения. В задаче нужно не только разбирать и перемаршрутизировать, но и некоторую обработку делать. В довольно ограниченных, опять же, ресурсах.
а вы в курсе, что эрланг был создан Эриксоном как раз для программирования своих АТСок? в том числе и очень больших. он компилируется, хотя как динамический язык он конечно не может быть столь быстрым, как С++ и даже наверно Ява. с другой стороны, обработку можно делать вызовами сишных функций — каждому своё, как было написано на входе в какой-то концлагерь
вот мой собственный пример. я пишу архиватор. там проихводительность критична так же, как скажем и в играх: 10% — это уже заметная разница. НО — свою программу я чётко разделил на две части: библиотеки сжатия и всё остальное. библиотеки написаны на С++ и по большой части не мной. мне же остаётся только дирижирование всем этим оркестром. так что я не теряю ни в скорости, ни в удобстве программирования. память была проблемой, но сейчас по памяти я даже обхожу некоторых конкурентов. почему? потому, что они хранят в памяти имена файлов целиком (это основные затраты памяти), а я — отдельно имя каталога (оно одно на 10-15 файлов) и отдельно имя внутри каталога. и сливаю их только при использовании. можно такое сделать в C++ (на котором написаны другие арзиваторы) с GC? можно, но сделано только в одном
Здравствуйте, eugene0, Вы писали:
E>Создать столько юнитов, конечно, не проблема. Но представь себе, что каждый из этих юнитов есть интерпретатор или виртуальная машинка, выполняющая скрипт и все это одновременно.
А это и не нужно. Ни один С++ не позволит наделить тысячи объектов сложной логикой. Если их много, то они по пределению будут тупы.
Вспомни монстров дума и ботов Q3.
E>В играх скрипт по сравнению с С++ и другими языками дает обычно два приемущества: E>1) в скриптах как правило не пишется архитектурно сложного кода, поэтому их пишут не программисты, а дизайнеры миссий/уровней/карт, которые в силу специфики своей работы скриптовыми языками владеют, а С++ и Немерле — нет.
И все же, чем же Немерле тут будет отличаться от скрипта? Разве что тем, что кроме примитивного кода, он все же позволит писать и довольно сложный. Ну, так это приемущество.
E>2) когда логика поведения юнитов написана на скриптах, дизайнер может менять ее без перекомпиляции кода. На самом деле ему вообще не нужны исходники игры, хватит исполняемых файлов.
Устроить незаметную для глаза компиляцию скрипта во время его записи нет проблем. И менять его тоже будет просто.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>Зачем что-то колбасить? Вот LUA, вот python. Для того, чтобы делать что-то новое, нужно, чтобы это новое было чем-то лучше, чем готовое и многократно использованное и оттестированное старое. Чем вот эти псевдоязыки были бы лучше?
Дык, на вопрос "зачем" как раз ответ ясен. Ты получаешь мощь выше чем в Питоне со скоростью сравнимой с С++.
E>Дизайнер может действовать так: он строит сцену из готовых объектов, настрайвает их свойства, пишет скрипты. Это обычно происходит в режиме "на паузе". После этого он сохраняет сцену, запускает ее и смотрит, что получилось. Обычно, сначала что-нибудь идет не так, как хотелось. Тогда дизайнер перегружает сцену, подправляет ее немного (передвигает неправильно стоящий объект, правит скрипт и т.д.), сохраняет, смотрит, что получилось. И т.д. и т.п.
Сам игрался с редакторами к размы играм, например, к ФарКраю, и представлю это.
E>При этом никаких длительных перерывов в его работе нет, из редактора он не выходит. Если бы вместо скриптов была захардкоденная логика, ему пришлось бы выходить, править, перекомпилировать как минимум тот модуль, который он поправил.
Дык о том и речь. Только сегодня вместо скриптов можно использоать более мощьные языки. Причем, что забано само ядро игры можно писать на них же и тлько откровенно тонкие части оптииизировать на низкоуровенвых языках.
E>Вот о чем я пытался сказать выше. Насколько мне известо, разработка уровней организована таким образом не только у нас.
Естественно. Вопрос тольк в том, зачем там скрипты и С++. Первое порождает медленный результат и чревато багами отлавиливаемыми только в рантайме, а второе очень медленно в разработке и чревато трудно уловимыми багами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugene0, Вы писали:
E>Здравствуйте, VladD2, Вы писали:
VD>>Данные похожие на данные из приводимой мной презентации, но они мало что говорят об оправданности такого решения. VD>>Из той же презентации видно, что на всю симуляцию игры уходит около 10% процессорного времени: E><таблицу поскипал>
E>Я пропустил место, где приводилась презентация.
Нет совесм, это оценки авторов Анрыла. Там не только процессороное время.
E>Если интересно, могу привести _наши_ данные, полученные от профайлера.
Конечно интересно.
E>Конечно же, я с удовольствием писал бы на удобном и безопасном языке. Вопрос только в том, сколько все же составляют те самые проценты, на которые он медленнее неудобного и опасного, но более быстрого языка.
Хохма заключается в том, что величина эта переменная и обычно она не превышает статистической пограшности. Алгоритмические просчеты или просто выбор не оптимальных путей дает куда больший проигрышь. Единственное что действительно приносится в жертву — это расходуемая память. GC показывает хорошую скорость только если занимает память с запасом. Плюс есть собсвтенные накладные расходы. Так что получается, что расход памяти у дотнета на уровне скриптовых языков.
E>Предлагаю говорить все же более конкретно. Скажем, 10% для нас — это уже критично. У нас пока некоторые уровни на средних машинах на слайд-шоу похожи
Дык. Тут уже язык мало что може сделать. Тут нужна или акселерация, или изменение алгоритмов. А на них нужно время. А оно уходит на больрбу с С++. Идея ясна?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>когда ресурсы критичны, определённо ничего лучше С++ не сделаешь. но — может проблема была именно в некомпетентности тех программистов?
Программисты те, которые есть. Очень даже не плохие. И времени на решение задач, как всегда не много. Поэтому было сделано так, как было, в отведенное время уложились, результат получили. Теперь с ростом объемов результат
оказывается неудовлетворительным.
Что до Erlang-а, то мы запустили свои решения в работу уже N лет назад, а про Erlang я услышал в первый раз здесь года два тому. Такое невежество может и не делает мне чести, однако это реальность. И существующие C++ продукты гораздо дешевле сейчас сопровождать и развивать, чем переписывать на чем-то другом.
Вообще же это уже начинается оффтопик. Любую задачу можно успешно решать разными инструментами. Важно, чтобы руки были правильные и инструмент хорошо в руку ложился. Не знаю как где, но в наших условиях человека гораздо проще научить программировать на C++ в стиле C with classes, чем на Erlang или Haskell. Это тоже, к сожалению (или к счастью) реальность, с которой приходится считаться.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Alexmoon, Вы писали:
A>Я прекрасно представляю ассемблер с шаблонами и примитивами синхронизации, но и вы представте C# в виде монстра, который решает не только задачи прикладного програмирования, а еще и будет перекручен конструкциями с определенными unmanaged оговорками для свободного манипулирования ресурсами под уровень ядра,
Думаю, что для уровня ядра в качестве переносимого высокоуровнего ассемблера лучше подойдёт C, а не C++.
BZ>>последние 15 лет С++ развивается только в направлении усиления шаблонов.
A>За исключением доработки в сторону узких мест — ты совершенно прав. Метапрограммирование — это следующий шаг развития.
С одной оговоркой. Метопрограммирование на шаблонах — это тупиковая ветвь развития человечества.
A>В языке достаточно минимально необходимых примитивов для эмуляции чего угодно. Все что нельзя сделать, неправильно концептуально спроектировано
Мне очень нравится декларативная составляющая современных языков. Не мог бы ты сэмулировать на C++ атрибуты?
A>То что язык развивается в сторону метапрограммирования на базе шаблонов — это совершенно логичесное и естественное развитие языка данного уровня.
Ничего логичного и естетсвенного. Метапрограммирование на шаблонах — это высокоинтеллектуальное извращение. А извращение не может быть естественным. Даже высокоинтеллектуальное.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
E>>Речь идет именно о морде. E>>Существующая морда написана в лоб и слишком прожорлива.
IT>Т.е. прожорливые морды можно писать и на плюсах?
Я когда-нибудь утверждал обратное?
Тем более, что на плюсах получилась прожорливая, но работающая. А на Java была бы и прожорливая и тормознутая.
А на C# была бы только под Windows.
В общем, есть из чего выбрать.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
. Могли бы провести эксперимент 
Если нам не помогут, то мы тоже никого не пощадим.
