Сложный язык для сложных срограмм. - Философия программирования

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

VD>>С++ компактнее С только при условии, что на С код пишется в объектно-ориентированном стиле. ООП позволяет решать более сложные задачи за счет ОО-декомпозиции. Но кода получается обычно даже больше.
S>Нет. Шаблонные функции тоже рулят, т.к. позволяют не писать отдельные версии на каждый тип.

Рулят, рулят. Только моих слов это не изменяет. ООП для очень многих задач является оверкилом.

S>Кстати, K&R C, руливший во времена С++, все еще не позволял указывать типы аргументов в объявлениях функции и требовал объявлять все переменные только в начале.

Это не так. В времена С++ уже был ANSI C. Плюс K&R исходно позволял объявлять параметры по месту. Просто он же позволял и выносить их. Лично я K&R уже не застал. Хотя программирую на С с 93-его.

S> Насколько я помню, возврат структур также был запрещен (могу ошибаться). Ссылок в С тоже не было.

Ссылки — это сахар. Указатели решают все проблемы кроме проблемы кривых указателей.

Вот только ты ушел от емы слишком даеко.

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

Нет, получится, так как это как раз уже С++-ный код написанный в ограничениях С будет С-шным. А реализовав ту же задачу в "традициях" С++ мы получим оверкил.

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

S> Более того, структурно-процедурная программа на С++ будет скорее всего компактнее, чем на С, благодаря всяким простым штукам навроде наследования структур, которого не было в С.

Ну, вот практика показывает, что — нет. На С тоже можно писать довольно компактно. И так как людям эмуляция ООП стоит дорого, то они сто раз думают какие паттерны применить (для С++, что ООП, что ФП, все паттерны). А на С++ сразу лепят классы. Так ведь учили.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>По моему опыту, сложность AI ограничивается вовсе не производительностью процессора. У нас AI не тормозит. Что угодно тормозит, рендер, анимация, та же физика, а вот AI нет.
E>IMHO проблема тут не в производтельности, а в сложности реализации сложных моделей поведения, а также, в некторых случаях, в целесообразности этого.

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

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

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

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

В общем, хочется ума. Хочется чтобы бот радомом выбирал только одну из хороших стратегий, и хочется чтобы стратегии у него были.

И тут без паттерн матчинга или даже без логики предикатов никак не обойтись.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Может я необычен, но я с большим удовольствие прошел Постал 2 где графика была так себе, и мне было довольно скучно идти в Думе 3 и даже в Прэее (на последних уровнях). В ХавЛайфе 2 меня тоже задалбовали месильные части где надо было отстреливаться и выполнять тупые квесты, а радовали разные приколы с гравипушкой и красивые физические эффекты.

Я конечно только "за" хорошую графику, но без хорошей физики, хорошей режисуры, и хорошиго сюжета ничего не выйдет.

Кстати, все миденные мной игры с точки зрения погуружения и сюжета мне все же не понравились. Хочу побыть первым терминатором или охранником из "Зеленой мили", так чтобы жить в сюжете, а не наблюдать как программист и дизайнер уровня направляет меня к следющей двери.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>Поэтому требования к скриптовому языку несколько другие: простота, читаемость и желательно какая-нибудь интерактивность, чтобы написанный скрипт можно был тут же и запустить.
E>В таких условиях написание скриптов на "взрослых" языках вроде C# или джавы или C++ выглядит как стрельба из пушки по воробьям.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

BZ>я лично предпочитаю писать скрипты на ruby. для сравнения пробовал haskell — некоторые вещи в нём проще (ну я тут уже приводил три примера

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

А зачем интерпретирвемый?

ЗЫ

У ОКамла проблемы с черезмерной строгостью и статиченостью. Компонентность он поддерживает хуже чем С++.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

E>Даже не знаю, что сказать. У нас эта цифра составит, наверное, процентов 10.

Извини, но мой опыт не позволяет мне с тобой согласиться. Да и доверия этому товарищу все же больше. Как ни как в Анрыл я играл чуть ли не 10 лет назад.

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

Значит вы его просто пока не сдали.

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

Вот она ключевая фраза — "уже года два"! То есть вы убили время еще тогда, и теперь еще 2 (!) года возитесь с проектом! А могли бы ВООБЩЕ не возиться с этими проблемами!

E> Массивы мы не практически используем, пользуемся контейнерами STL, с ними вылезти за границы сложнее.

Сложнее не значит невозможно. Подставь end от нетого итератора и вуаля... Ты вот меня уверяешь, что проблем у вас нет, а меж тем ошибся в предложении выше без проблем "Массивы мы не практически используем" по-русски значит, "используем не практически", а не то что ты хотел сказать "не неиспользуем на практике". Вот такие же ошибки у вас сплош и рядом в С++. Понятное дело, что вы их исправляете, но на это уходит много времени. И самое обидное, что какие-то из них все равно остаются в программе.

E> Обращению к нулевому указателю проявляют себя немедленно и тут же исправляются. Integer overflow не видал. Неинициализированные переменные — это да, проблема.

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

E>У нас главная проблема — это макароны и все, что с ними связано.

А ты представь себе на минуточку, что автор презентации организовал работу так, что код у них стал хорошим. Вот он и высказывает свои мысли о том как еще улучшить процесс разработки.

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

Это тяжело объяснить, но поверь, все перечисленное тобой умножается на проблемы языка. Вот вы и получаете 2 года разработки после того как какзалось бы всем все объяснили.

К тому же ты вдумайся в свои слова "объяснили всем что надо". Это значит, что вы ограничили язык до некого сабсета. Причем контролирвать это будут люди. Ты конечно потом сможешь позлорадствовать, что мол эти козлы наколбаслии, да я бы такоего никогда не допуситл... но время уйдет. По этому все что может контролировать машина должна контролировать машина. А твоя задача сфомрмировать процесс производства ПО так чтобы этот контроль был. Сюда входит выбор инструмента, и выработка тех.процессов.

E>Но это так, к слову.
E>Я в целом поддерживаю автора: неплохо бы получить новый, эффективный язык, лишенный недостатков того, что мы иcпользуем сейчас!

Дык, мы как раз о том и говори, что такие языки уже появились.
Не все конечно идеатльно, но с С++ точно не сравнить. Вот BulatZiganshin хвалит Хаскель. Правда у Хаскеля много своих проблем. И об этом как раз и говорит автор презентации. Но вот Немерле очень близок к этому идиалу. К тому же его можно подстрагивать под задачу.

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

Многопроцессорность — это одно из изменнеий в мире. Но не единственное. Другими являются появление огромных объеемов памяти, крутых акселераторов, и конечно же, новых мощьных языков программирования и библиотек/RAD-средств.

С++ используется исключительно потому что это прокатанный путь.

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

ОК, если будет время попробуй.

E>То, что ест много памяти, плохо

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

На XBox используется более экономный GC. Незнаю как он в плане производительности, но в 512 метров вроде игры влазят.

К тому же 512 это сегодня. Игра которую начнут делать сегодня будет готова через год-два, а там глядишь и гиг будет стандартом.

К тому же имея более мощьный язык ты можешь уделить больше времени оптпимизациям. Да и делать их автоматизировано.

E>Идею, которые ты двигаешь в массы, я понял уже давно

Но, как видно из начала сообщения время уходит не столько на борьбу с С++, сколько на борьбу с ошибками проектирования и организации разработки.

Дык если есть более мощьный язык, то все становится проще. Нужно меньше программистов, проектирование становится ближе к коду. Объем исходников становится меньше. В итоге и бороться нужно с меньшим объемом проблем. Скажем, если на разработку игры на С++ нужно 10 программистов, то на Немерле возможно будет остаточно 4-ых. Это обязательно повысит эффктиность. К тому же проще делить код на крутой системынй и прикладной. Крутые программисты могут писать макросы и фрэймворки, а по слабее собирать из них готоые решения оторые в виду своей простоты будут иметь меньше ошибок и быстрее реализовываться.

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

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

DC>Ммм. Возможно, мне трудно оценить их мощь.

У меня даже нет сомнений. Если конечно ты не лисп-хакер с десятилетним стажем.

DC>Но с алгоритмами они врядли способны что-то сделать, разве что упростят построение модели.

Они позволяют сделать возможным мечты.

Ты можешь относительно просто превраить интерпретакцию в компиляцию. Макарнонный код в краткий DSL. Сгенерировать код так как тебе надо, а не так как выходит.

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

Это вопрос мировозрения. Сейчас я уже так не считаю. Но макросы — это секретное оружие которое лисперы скрывали за грудой скобок много лет. И если бы не они, то небыло бы самого Немерле. Он в основном обязан себе и своим макросам. В нем даже большинство конструкций воде if/else или for реализованы макросами.

В общем, мое мнение, что и без мкросов С++ ему может составить конкуренцию только в простых задачах битовыжимания (что элементарно выносится в библиотеки). А с макросами он вообще недосягаем. Ведь это возможность заточить язык под свои задачи. Причем сделать это очевидным и доступным окружающим образом.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>Сильное определение. Уверенность в себе — это конечно похвально. Но я бы как минимум заменил артикль это на возможно.

Это понятно. Ты ведь не видел того как может выглядеть метапрограммирование будь оно органично встроено в язык. Потому и сомневашся. А вот IT видел. Как сейчас помню восторженный его восклик в аске — "Оифигеть! Я добавил поле типа Location и забыл сделать его изменяемым, но компилятор мне сказал об этом! И это делает простой макрос!". Так что вы в разных условиях. Он видел и то, и то, а ты только шаблоны С++.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

ОК, поясни что за концепция языка (гы-гы, тем кто использовал этот язык 10 лет к ряду), что не позволяет просто определить атрибуты? Может их просто нет в этом языке, а средства эмуляции настолько убоги, что не позволяют это сделать качественно? Я ошибаюсь? А тогда в чем же дело?

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

В С# нет встроенного метапрограммирования. По этому и обсуждать не чего. А вот в Nemerle есть. И метапрограммирование на С++ на его фоне выглядит полнейшим извращением и убожеством.

Звучит громко? Но это правда. И чтобы ее осознать надо просто прочесть пару статей про макросы Немерле.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Прблема в том, что у С++ очень куцие концепции. И рассматривая в них казалось бы простые и логичные решения оправдываются весьма уродливые решения.

A> Понятие "снег" не является generic. Ни один язык не вместит всех понятий на уровне встроенных типов.

Это не так. В хорошем языке на котором можно описывать лызные гонки, например, есть понятие "снег". И без него дейсвтительно глупо говорить о лыжных гонках. Представь всебе:

Бегун на плоских палках привязанных к ногам вырывается вперед...

Ужас, правда? Так вот хороший язык позволяет добавлять в него новые понятия. Применительно к ЯП такими возможностями являются библиотеки фукнций и классов, а так же метапрограммирование. То что можно добавить библиотекой (при приемлемо качестве) нет смысла реализовывать метапрограммой, но далеко не все можно сделать библиотекой. Вот тут и помогает матапрограммирование. Но оказываетс, что один язык предоставляет удобные и мощьные концеции для расширения себя любимого, в адругой один хитрый патцан научился использовать побочные эффекты от рекурсивного определения шаблонов, чтобы сэмулировать примитивнеший фукнциональный язык с убогим синтаксисом и плохой связью с компилятором. В итоге на одном языке можно творить чудеса, а на другом путем неимоверных по своему садизму изнасилований мозга получать примитивнийшие решения и радоваться этому как младенец.

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

Скорее с неимоверной убогостью. Но ты не поймешь этого пока будешь знать один С++, так как тут работает парадок Блаба.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

BZ>я тут привёл 3 примера кода, написанного на хаскел (http://rsdn.ru/Forum/?mid=2337746&flat=0), и так и не дождался чтобы хоть кто-нибудь написал для сравнения их аналоги на своём языке

Приколист ты. Тут 90% Хаскеля вообще не знает. Еще 9% знает его в рамках прочтения введения. И еще 0.9% чуть глубже. А оставшиеся 0.1% или не заметила твое сообщение, или им просто влом этим заниматься. Тут пенисометрии был вагон и малая тележка. Поищи сам.

Скажу от себя, что почти любой язык с приличной поддержкой ФЯ и опциональной линивостью полвзоялет описать такие примеры не хуже. Поиск символа вообще смешон. В C#, например, это будет выглядить как str.Substring(80).LastIndexOf(' '), не говоря уже о ФЯ.

Так что проблемы тут бубут только у С++, так как на нем все надо воспринимать в его же концепциях (с).

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

Здорово. Жаль только что 7zip уже есть и он всех устраивает. А многих устраивает просто zip.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Извини, ты смарт-поинтерами пользуешся?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>В C#, например, это будет выглядить как str.Substring(80).LastIndexOf(' '), не говоря уже о ФЯ.

VD>Так что проблемы тут бубут только у С++, так как на нем все надо воспринимать в его же концепциях (с).

Да уж... Rocket science... То, что ты изобразил на C#, на C++ выглядит, мягко говоря, не сложнее: str.rfind(' ', 80)

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

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

S>>Вот это утверждение хотелось бы как-то обосновать. Кто гибче — С или С++? А ведь С++ лаконичнее!
A>Обосновывать это можно до бесконечности. Для этого как минимум должны быть взаимосогласованные определения. Их не было и не будет. Всех нас всегда будет что то не устраивать. Здесь нечего ответить, поскольку поставьте вопрос на абстракцию выше и вы поймете почему все от всего зависит и выиграть во всем абсолютно не возможно. Каждый выбирает обязательные критерии сам. Главное чтобы выбор был. Вы еще помните концепцию начала и в чем конечный вывод должен состоять?
Перечитал три раза, ничего не понял. Попробуй сосредоточиться и ответить на два вопроса: какой из языков гибче — С или С++? Какой из языков лаконичнее?

A>Некоторые вещи могут иметь конечно эквивалентный результат с совершенно различной архитектурой. Ну давайте уж порассуждаем о первостепенных происхождения. Я смотрю мы потихоньку сходим от осязаемого определения к блестанию умом на базе количества и гибкости оперируемых понятий.
Ну так не сходите. Поясняю: все эти "условно-одинаковые" подходы одинаковы только математически, при пренебрежении стоимостью разработки. На практике выигрывает та техника, которая позволяет сделать разработку дешевле. В основном за счет сокращения объема кода (в лексемах, естественно, а не в байтах) и автоматизации QA.
Нельзя отвлекаться от цели при анализе языков программирования. Все эти class, private, protected, namespace — они не сами по себе. Они только для того, чтобы сделать разработку дешевле.

A>>>

Sinclair notes:

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

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

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

obj->class->method(obj, 1);
obj->method(1);

? Или непонятно, вызов какой из функций будет лучше проверен компилятором:

add(a, b)
{
  int a;
    int b;
    return a+b;
}

или

int add(a, b) { return a + b; }

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

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

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

A>Запросто. Помимо человеко-лет есть набор составляющих уравнения, которые позволяют откатить человеки годы до вменяемой составляющей с учетом определенного уровня владения.
А можно то же самое по-русски? Ниче ведь не понятно: что такое "откатить"? Эаплатить откат? И что такое "вменяемая составляющая"? А что значит "учет определенного уровня владения"? Это что-то из бухгалтерии?

1.2.0 alpha rev. 655

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

E>Идею, которые ты двигаешь в массы, я понял уже давно

Но, как видно из начала сообщения время уходит не столько на борьбу с С++, сколько на борьбу с ошибками проектирования и организации разработки.

Угу хорошая идея начать коммерческую разработку на языке который все еще в бете (а судя по тому что недавно творилось в "Декларативном программировании" и как не смеялись некторые товарищи над багзилой другого языка в весьма глубокой).

Притом каких-то больших преимуществ в скорости разработки по сравнению с C++ + хороший скрипт (питон, луа) вы не получите.

Если рассматривать ситуацию Немерле vs (С++ + python) для тех же игр (правда я сейчас пишу только маленькие игры, но в больших тоже немного участвовал), то у Немерле по моему такие недостатки.

1) Язык не зарелизиен, до промышленного уровня ему как минимум еще несколько лет.
2) Язык (именно язык) вполне хорош для написания внутренностей ядра и тому подобного в игре, но написанное на на нем проигрывает C++ (притом сильно если будет использоватся mono) в производительности и расходе памяти. Для многих жадных по памяти и процессору алгоритмов проигрыш может быть фатальным.
3) Как язык для скриптов и вообще дизайнеров немерле слишком сложен, придется писать DSL, зная бардак с проектированием в игровых проектах 100% вы будете не один раз его переписывать, в общем лишняя работа обеспечена.
4) DSL будет на макросах, и так как скорее всего часто будет менятся и поэтому точно не будет предкомпилированным, и учитывая что в игру могут грузится много сотен скриптов получите хороший тормоз при перекомпиляции и загрузке этого счастья (что то порядка минут вместо секунд для скрипта).
5) Для С/C++ для разработки игр море как готовых библиотек так и просто всякого рода примеров обучалок и тому подобного. Конечно некторые из них можно скомпилировать и вызывать через интероп, но многие нет, так как цена вызова может быть дороговатой. Так что добавится работа по переписыванию с С++.
6) Платформа ограничена Windows и Xbox360. Есть mono для других платформ, но его производительности наверняка не хватит.

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

E>>Поэтому требования к скриптовому языку несколько другие: простота, читаемость и желательно какая-нибудь интерактивность, чтобы написанный скрипт можно был тут же и запустить.
E>>В таких условиях написание скриптов на "взрослых" языках вроде C# или джавы или C++ выглядит как стрельба из пушки по воробьям.

VD>С++- конечно. А вот два других как раз более мем могут быть преспособлены для решения данной задачи. Ну, и конечно есть третий наличие которого делает бессысленым все три и скрипты в придачу.

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

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

сколько они тебе за это заплатили?

ps: спрашиваю не из любопытсва — может, я продешевил?

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

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

интересная мысль. что если ясность можно измерить кол-вом концепций, которые человек должен помнить одномоментно?

тогда получится, что функциональный подход выигрывает потому, что вместо нескольких переменных, описывающих обработку, можно ввести одну функцию, которая её осуществляет, к примеру вместо x*a+b ввести функцию f = (+b).(*a) и дальше думать только об "f x"

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

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

От:	VladD2	www.nemerle.org
Дата:	09.02.07 00:56
Оценка:

От:	VladD2	www.nemerle.org
Дата:	09.02.07 02:56
Оценка:

От:	VladD2	www.nemerle.org
Дата:	09.02.07 02:56
Оценка:

От:	VladD2	www.nemerle.org
Дата:	09.02.07 02:56
Оценка:

От:	VladD2	www.nemerle.org
Дата:	09.02.07 02:56
Оценка:

	От:	Павел Кузнецов
	Дата:	09.02.07 05:14
	Оценка:	1 (1) +6

От:	Sinclair	https://github.com/evilguest/
Дата:	09.02.07 05:53
Оценка:	+1