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

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

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

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

FR>Может не стоит так сильно обобщать?
FR>Мне уже кажется что каждый из нас разговаривает сам с собой Я тебе про одну ситуацию, ты мне про совершенно другую.

Ключевое слово Синклера:

Ограничения еще никогда никому ничего не упрощали. Упрощение — это предоставление максимума функциональности в готовом к употреблению виде.

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

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

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

FR>Да надо было сразу делать как Гаптерон предлагал но лень.
FR>Вообще тут доказательством является само существование скриптовых языков, если бы все было для статики так радужно как ты думаешь их просто не было бы.

Класное доказательство. Эдак все что хочишь можно доказать. Вот дотнет с явой тоже существуют и даже широко используются.

FR>А писать все на C# это не загонять себя в рамки?

Нет. Да и у дотнета Шарп не единственный выбор.

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

VD>А какой смысл запускать Лисп-машину, над Ява-машиной?

Не запускать, а компилировать LISP->байт-код JVM. Исключительно ради макросов и описанной в статье процедуры разработки DSL-я.

VD>Дык я говорю о сложности. Там и Паскаля то нет. А Дельфи какой-нить на порядок сложенее. Мета-программирование это здорово. Но чертовски сложно.

Да? Ладно, я постараюсь разузнать у автора, сколько у него заняло/займет разработка подобного DSL (ну пусть это будет паскаль, зачем нам Delphi? ). И, кстати, идея состоит не в том, чтобы написать мега-комбайн, а в том чтобы разработать маленький и скромный DSL под каждую задачу. Надо GUI описывать — пишем один DSL, надо тексты определенным образом обрабатывать — другой, клеточные автоматы — третий, бизнес-правила — четвертый, и.т.д. Это все, разумеется, делается при условии, что конечная задача достаточно объемна, а не три формочки нарисовать.

Причем приведенный в пример псевдо-Паскаль компилируется в LISP, а соответственно имеет всю скорость LISP-а. Это ни в коем случае не интепретация.

VD>Дык есть же EBNF в котором все намного понятнее и проще. А время... есть ведь еще время на поддержку и развитие. Оно обычно дороже.

Я не пойму каким ты образом EBNF выполнять собрался. То что там приведено — вполне самостоятельный язык. Ты можешь написать на нем что-нибудь, обрамить макросом pasqualish (ну и заэскейпить еще надо) и получишь программу. Обрамление делается автоматически. Получаем что можно писать на этом языке совершенно не вдаваясь в скобочки LISP-а с одной стороны, и имея желаемый DSL — с другой.

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

VD>Лисп.

Дык речь не про LISP шла, а про некое средство разработки DSL, обладающее определенными качествами.

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

WF>И, кстати, идея состоит не в том, чтобы написать мега-комбайн, а в том чтобы разработать маленький и скромный DSL под каждую задачу. Надо GUI описывать — пишем один DSL, надо тексты определенным образом обрабатывать — другой, клеточные автоматы — третий, бизнес-правила — четвертый, и.т.д. Это все, разумеется, делается при условии, что конечная задача достаточно объемна, а не три формочки нарисовать.

Расскажу ка я одну историю из личного опыта. Было это где то в середине 90-х. Для одной задачки понадобился весьма специфичный набор отчетов. Встроенный тогда в Дельфи QuickReport и его сторонние аналоги приводил к очень большому объему работ. Поэтому было принято решение написать свой специализированный репортер. В качестве средства описания отчета был придуман простенький язычок, на первых порах чисто декларативный, навроде файла команд графопостроителя. Модного слова DSL тогда еще не было, но по сути это он и был. Так вот — репортер был сделан и продан заказчику в первой версии программной системы. Заказчик от возможности править отчеты руками в текстовом редакторе просто паром в потолок писал. А вот дальше все стало несколько печальнее. Началось все относительно безобидно — понадобилась условная генерация. Ну что ж, поскольку язык был декларативным условия были прикручены навроде того как это сделано в XSLT. Выглядело ужасно, но, поскольку требовалось очень редко, прокатило. Дальше хуже — наворотов требовалось все больше и больше. Самое страшное — все в итоге прекрасно понимали что изобретаем велосипед, но продолжали жрать кактус, поскольку на каждом этапе модификация требовалась небольшая и вроде как проще было ее внести, нежели переписывать весь репортер.
Закончилась же эта печальная история очень просто — поскольку язык был немного похож на паскаль, то написали просто препроцессор, который подгонял наш DSL к виду, компилируемому dcc32.exe. Причем этот самый DSL по сути просто в паскаль и выродился, а сложный препроцессор понадобился исключительно ради того чтобы не переделывать уже готовые отчеты.

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

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

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

VD>Сдается мне что дешевле обучить человека как следует программировать чем пытаться закрыть его ламерство. Все равно пишется код. Если уж создается среда для дизайнера, то там вообще не должно быть кода. Код должен писаться программистами и использоваться дизайнерами как компонент (черный ящик со свойствами).

Дизайнер не программист, он профессионал в своей области. Код который пишется очень специфичен, и черных ящиков там хватает. Среду для дизайнера без кода почти нереально сделать, этот редактор может получится сложнее чем вся остальная игра, кроме того задавать логику визуально не проще чем на скрипте(я видел несколько "конструкторов" игр, освоить их не проще чем скрипт а возможности гораздо уже).

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

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

FR>>Может не стоит так сильно обобщать?
FR>>Мне уже кажется что каждый из нас разговаривает сам с собой Я тебе про одну ситуацию, ты мне про совершенно другую.

VD>Ключевое слово Синклера:
VD>

Ограничения еще никогда никому ничего не упрощали. Упрощение — это предоставление максимума функциональности в готовом к употреблению виде.

VD>Для игр и дизайнеров это можно расшифровать так... Вообще не нужно чтобы дизайнер лазил в исходники (какими бы простыми они не были). Он должен иметь дело с высокоуровневыми сущьностями. Такими сущьностями на мой взгляд должны являться компоненты и разные файлы настройки. Для эффективности по ним даже можно генерировать код. Это не важно. Главное, что пользователь (которым является дизайнер в данном случае) будет всегда взаимодействовать с высокоровневым интерфейсом.

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

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

расшифруй что ты тут понимаешь под словом компонент, а то слишком напоминает волшебную палочку

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

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

FR>>Слушай я уже запутался, приведи эти куски кода.

VD>

VD>

VD>import sys, itertools
VD>print sum(itertools.imap(int, open("in.txt")))
VD>

VD>

VD>foreach (string value in File.ReadAllLines(@"C:\data.txt"))
VD>  sum += int.Parse(elem);
VD>

Ну просто код на питоне в функциональном стиле, и вроде тоже прост для понимания. А так тоже самое, вернее даже проще:

for line in open("in.txt"):
    sum += int(line)

FR>>Только когда ты говоришь что на Шарпе не надо думать например о выделении памяти это хорошо, а когда я про тоже самое(смысл "не надо думать" в автоматизации процесса и упрощении написания) это уже плохо? Читабельность мало зависит от того нужно ли явно и типизированно объявлять переменные в языке.

VD>Дык не думать потому-что что-то заменяется атоматикой и не думать вообще — это две большие разницы. Не находишь?

В данном случае аналогично заменяется автоматикой.

FR>>>>Вообще разговор здесь начинался в контексте скриптов для игр,
VD>>>Что же ты все время об этом забываешь? Вот все пиняешь про разбор текстов и т.п...
FR>>Потому что уровень сложности близкий.

VD>Уровень сложности определяется сложность и комплексностью задачи (конкретной). Тут же идет речь о разной специфике прикладных областей.

Спицифика разная уровень сложности близкий.

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

VD>Скрипты вообще не нужны для конфигурации. Ее нужно делать декларативно. Скрипты нружны для внесения разнообразия и записи некоторой прикладной логики. И чем больше возможностей при этом будет тем серьезнее получится продукт.

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

FR>>Для игр это является проблемой, особенно для отладки, вернее даже настройки (у игр есть дополнительный к обычным приложениям этап разработки, я называю его настройкой, этот этап часто занимает не меньше времени чем кодирование и заключается в настройке параметров так чтобы получилась игра с хорошим гамеплеем а не вьювер красивых картинок, на этом этапе очень полезно быстро выгрузить и снова загрузить какой то отдельный модуль не перегружая не только игру, но и даже уровень, это сильно ускоряет работу)

VD>А кто тебе сказал о медленной выгрузке? На этом этапе вообще не обязательно что-либо выгружать. Дотнет без проблем переваривает наличие в одном процессе сотен версий одной и той же сборки. Так что не никаких проблем подгружать измененные версии. А в игре они будут грузиться один раз. Плата за это объем оперативки у разработчика. Что не проблема. К тому же тут и про оперативку то речи не идет. Тут виртуальная память требуется. Неиспользуемая версия сборки просто высвоповывается на диск и все.

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

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

VD>>>А вот то, что у "скриптов" производительность в 10 раз ниже — это серьезный недостаток. Не находишь?

FR>>Нет если использовать их правильно.

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

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

VD>Ай не верится. Это как же они не связаны? Все созаются ради одной цели. Испоьзуются одинаково. К меня в большой программе тоже не все классы пересекаются напрямую. Дык и у тебя будет код склеивающий все это. Просто код будет С-шный.

Наоборот как раз питон и склеивает сишные компоненты. Уровень связности скриптов на порядок ниже чем классов в приложении.

VD>>>А сколько таких "скримтов" в большой игре? 100? 1000? И как они влюяют друг на друга? Неужели кому-то станет хуже если их можно будет отлаживать человеческими средствами?

FR>>У питона вполне нормальные средства отладки.

VD>Можно о них по подробнее?

Так я уже вроде давал ссылки, отладчиков на уровне VC6 полно например Pythonwin, отладчик из SPE или BoaConstructor. Кромет того есть VisualPython плугин к VS.NET.

FR>>Есть много ситуаций когда разделить код на две части и писать их на разных языках лучше чем на одном, пример те же скрипты для игр.

VD>О! Заявлениями мы тут уже сыты. Попробуй обосновать это утверждение. Я лично никак не могу понять как писать на двух средствах у одного из которых нехватает производительности кода, а у другого произоводительности программиста и надежности может быть лучше чем на одном у которого нет ни тех, ни тех проблем.

На этих средствах пишут обычно разные люди.


FR>> Жестких паттернов подерживатся не нужно, я к примеру без проблем подключил свой спрайтовый движок(когда я его писал про питон ничего ни знал) к питону, практически ничего в нем не переделывая.

VD>А как же на счет управления памятью? Тут или паттерны, или описание всего и вся.

Во первых SWIG умеет обертывать C++ классы так чтобы нормально управлять их временем жизни, во вторых движок был основан на com подобных интерфейсах с подсчетом ссылок и состыковать его с питоном оказалось несложно.

VD>>>1. Значитально более выская производительность.
FR>>Много задач где это неважно(не на первом месте).

VD>Ага. Задачи так и называются — маловажными.

кому как.

VD>>>2. Отсуствие необходимости применения более низкоуровневых языков.
FR>>Так сейчас в играх(если думаешь о портировании) без C++ никуда.

VD>Ну, это пожалуй аргумент. Вот только тогда что говорить о каких-то там приемуществах?

не понял.

VD>>>3. Отличный отладчик.
FR>>У питона много хороших отладчиков, есть даже специализированные для игр.

VD>Можно хотя бы скриншот?

http://sourceforge.net/projects/hapdebugger/


VD>>>5. Отличная IDE.
FR>>питоных иде тоже хватает.

VD>Сравним со студией + решарпер?

Угу VisualPython

VD>>>Ну, давай эти свои примеры сюда. Посмотрим вместе. Боюсь, это опять голословные утверждения. Все что я видел на Руби было очень даже элегантно.

FR>>Угу я сплю и мечтаю начать холивар Python vs Ruby

VD>А, чё? Нелья же только Шарп пиарить. А холивар лучший пиар.

Так не интересно, они слишком близки.

FR>>И вообще не хочу нарушать здешние правила когда холивар должен быть обязательно таким(NET vs <...>)

VD>Дык ты же эти правила и создашь. Кстати, не так давно все холивары были С++ вс. что-то там. Но видимо что-то меняется в этом мире.

Это только на RSDN меняется

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

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


E>>Видимо, FR имел ввиду префиксы, которые Ruby использует для обозначения глобальных переменных, атрибутов объектов и атрибутов классов:

FR>Угу я как их увидел, так и испугался

Как я уже говорил, напрасно пугался. Вот мне вчера потребовалось сделать пару скриптиков для обработки log-файлов. Сначала мне потребовалось определить, сколько операций выполнялось в минуту (т.е., нужно было взять все timestamp-ы из лога и просуммировать количество сообщений, попадающих в одну минуту). Вот с помощью такой простой штуки (читается стандартный ввод, каждое сообщение лога в отдельной строке, результат на стандартный вывод):

times = Hash.new
times.default = 0

while line = gets
    m = /timestamp\s\"(\d{4}\.\d{2}\.\d{2}\s\d{2}:\d{2}):\d{2}\"/.match( line )
    times[ m[ 1 ] ] = times[ m[ 1 ] ] + 1
end

times.keys.sort.each do |key| print "#{key},#{times[ key ]}\n" end

Затем потребовалось сделать тоже самое, но не по минутам, а по четвертям часа (хотя признаю, делалось это наспех, можно было чего-нить покрасивши сделать):

times = Hash.new
times.default = 0

current_time = nil

while line = gets
    m = /timestamp\s\"(\d{4})\.(\d{2})\.(\d{2})\s(\d{2}):(\d{2}):\d{2}\"/.match( line )
    t = Time.local( m[1].to_i, m[2].to_i, m[3].to_i, m[4].to_i, m[5].to_i)
    if current_time 
        if (t - current_time) < 15 * 60
            t = current_time
        end
    end

    if t != current_time
        t = Time.local( t.year, t.mon, t.mday, t.hour, (t.min / 15) * 15, 0 )
        current_time = t
    end

    times[ t ] = times[ t ] + 1
end

times.keys.sort.each do |key| print "#{key.strftime("%H:%M:%S")},#{times[ key ]}\n" end

Лично я, будучи приверженцом статически типизированного C++, не испытал здесь проблем ни с отсутствием типов для переменных m и t, ни с чем-либо еще.

PS

Сейчас проверил, оказывается фрагмент:

if current_time 
    if (t - current_time) < 15 * 60
        t = current_time
    end
end

можно было переписать как:

t = current_time if (t - current_time) < 15 * 60 if current_time

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


FR>>Угу я как их увидел, так и испугался

E>Как я уже говорил, напрасно пугался. Вот мне вчера потребовалось сделать пару скриптиков для обработки log-файлов. Сначала мне потребовалось определить, сколько операций выполнялось в минуту (т.е., нужно было взять все timestamp-ы из лога и просуммировать количество сообщений, попадающих в одну минуту). Вот с помощью такой простой штуки (читается стандартный ввод, каждое сообщение лога в отдельной строке, результат на стандартный вывод):

Я не совсем понял тут используются регулярные выражения? Если нет, то не зря я пугался

E>Лично я, будучи приверженцом статически типизированного C++, не испытал здесь проблем ни с отсутствием типов для переменных m и t, ни с чем-либо еще.

Так у меня тоже когда пишу на питоне с этим проблем нет, они только у Влада появляются

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

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


FR>>>Угу я как их увидел, так и испугался

E>>Как я уже говорил, напрасно пугался. Вот мне вчера потребовалось сделать пару скриптиков для обработки log-файлов. Сначала мне потребовалось определить, сколько операций выполнялось в минуту (т.е., нужно было взять все timestamp-ы из лога и просуммировать количество сообщений, попадающих в одну минуту). Вот с помощью такой простой штуки (читается стандартный ввод, каждое сообщение лога в отдельной строке, результат на стандартный вывод):

FR>Я не совсем понял тут используются регулярные выражения? Если нет, то не зря я пугался

Именно они и используются. Если же regex записать в POSIX-нотации, то еще страшнее будет :

m = /timestamp[[:space:]]\"([[:digit:]]{4})\.([[:digit:]]{2})\.([[:digit:]]{2})[[:space:]]([[:digit:]]{2}):([[:digit:]]{2}):[[:digit:]]{2}\"/.match( line )

E>>Лично я, будучи приверженцом статически типизированного C++, не испытал здесь проблем ни с отсутствием типов для переменных m и t, ни с чем-либо еще.

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

E>Именно они и используются. Если же regex записать в POSIX-нотации, то еще страшнее будет :
E>

E>m = /timestamp[[:space:]]\"([[:digit:]]{4})\.([[:digit:]]{2})\.([[:digit:]]{2})[[:space:]]([[:digit:]]{2}):([[:digit:]]{2}):[[:digit:]]{2}\"/.match( line )
E>

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

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

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

E>>Именно они и используются. Если же regex записать в POSIX-нотации, то еще страшнее будет :
E>>

E>>m = /timestamp[[:space:]]\"([[:digit:]]{4})\.([[:digit:]]{2})\.([[:digit:]]{2})[[:space:]]([[:digit:]]{2}):([[:digit:]]{2}):[[:digit:]]{2}\"/.match( line )
E>>

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

Строка вида {timestamp "YYYY.MM.DD hh:mm:ss" }
Весь файл состоит из таких строк. Пустых строк нет.

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


E>Строка вида {timestamp "YYYY.MM.DD hh:mm:ss" }
E>Весь файл состоит из таких строк. Пустых строк нет.

Если корректность строк формату не нужно проверять то так:

import re
times = {}

for line in open("kykukk_in.txt"):
    m = re.split(r'[.": ]', line)
    if not times.has_key(m[-3]): times[m[-3]] = 0
    times[m[-3]] =  int(times[m[-3]]) + 1
    
print times

Да еще как сортируется вывод я не понял, поэтому просто вывел.

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

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


E>>Строка вида {timestamp "YYYY.MM.DD hh:mm:ss" }
E>>Весь файл состоит из таких строк. Пустых строк нет.

FR>Если корректность строк формату не нужно проверять то так:
FR>

FR>import re
FR>times = {}

FR>for line in open("kykukk_in.txt"):
FR>    m = re.split(r'[.": ]', line)
FR>    if not times.has_key(m[-3]): times[m[-3]] = 0
FR>    times[m[-3]] =  int(times[m[-3]]) + 1
    
FR>print times
FR>

FR>Да еще как сортируется вывод я не понял, поэтому просто вывел.

Почти тоже самое. Только нужно, чтобы вывод был отсортированный.

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

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

FR>>Вообще тут доказательством является само существование скриптовых языков, если бы все было для статики так радужно как ты думаешь их просто не было бы.
WH>Brainfuck это очень крутой язык для разработки, а его связка с мегаязыком Whitespace дает просто невероятные возможности.
WH>Доказательством этого является то что эти языки вобще существуют.

Вообще-то, это ты начал приводить "популярность" в качестве доказательства "крутизны" языка. "Cуществование" — аргумент совершенно такого же порядка, но здесь автор очевидено имел в виду тот факт, что на скриптовых языках все-таки пишут, и пишут много. А вообще — не надоело еще третью фундаментальную проблему IT решать?

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

VD>>

VD>>foreach (string value in File.ReadAllLines(@"C:\data.txt"))
VD>>  sum += int.Parse(elem);
VD>>

FR>Ну просто код на питоне в функциональном стиле,

Вот только зачем не ясно.

FR>и вроде тоже прост для понимания.

Куда сложнее чем банальный форич.

FR> А так тоже самое, вернее даже проще:
FR>

FR>for line in open("in.txt"):
FR>    sum += int(line)
FR>

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

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

Взять даже этот простой пример. Из Шарповскоко примера я получаю всю информацию о процессе.

Код:

foreach (string value in File.ReadAllLines(@"C:\data.txt"))
  sum += int.Parse(elem);

однозначно читается как "для каждой текстовой строки из файла "C:\data.txt" произвести преобразование к целому числу и сумировать полученные результаты". При этом разочтений минимум. А в Питоне я весь в услоностях:

for line in open("in.txt"):
    sum += int(line)

Что возвращает функция open? Текстовый файл на чтение? Или бинарный на запись? И ведь до того как это место будет исполнено я так и не узнаю правильно ли я интерпретирую ее суть.
А что делает "sum += int(line)"? Текстовую конкатинацию так как sum — это строка, или все же сумирование? И если сумирование, то целочисленное или все же с плавающей точкой? И вообще формат файла допускает плавающую точку?

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

FR>>>Только когда ты говоришь что на Шарпе не надо думать например о выделении памяти это хорошо, а когда я про тоже самое(смысл "не надо думать" в автоматизации процесса и упрощении написания) это уже плохо? Читабельность мало зависит от того нужно ли явно и типизированно объявлять переменные в языке.

VD>>Дык не думать потому-что что-то заменяется атоматикой и не думать вообще — это две большие разницы. Не находишь?

FR>В данном случае аналогично заменяется автоматикой.

Нет батенька. Аналогии тут нет и в помине. Ты ставишь знак равенства между халтурностью кодирования и отсуствием кодирования в виду наличия автоматики. Я же не говорю, что дотнет имеет приемущество над Питоном потому что в нем есть ЖЦ? Я понимаю, что у питона есть своя автоматика на этот счет.

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

VD>>Уровень сложности определяется сложность и комплексностью задачи (конкретной). Тут же идет речь о разной специфике прикладных областей.

FR>Спицифика разная уровень сложности близкий.

Я выделил ключевые слова.

FR>Декларативность это хорошо, но с ее помощью тяжело задавать логику, при загрузке это может потребоватся.

Логику при загрузке? Запросто. Будет только проще. Скрипты нужны там где есть динамика. А если ее нет, то некий декларативный ДСЛ будет лучшим выбором. Как компромис можно сделать ДСЛ с возможностью подключения скриптов.

Инициализация же это вообще довольно статическая задача. Кстати, хорошим примером такой задачи является Авалон. В примерах к Авалону есть не мало проектов которые сделаны декларативно (на XAML-е) и императивно (на Шарпе или Васике). Декларативные версии примеров обычно намного короче и понятнее чем императивные версии.

VD>>А кто тебе сказал о медленной выгрузке? На этом этапе вообще не обязательно что-либо выгружать. Дотнет без проблем переваривает наличие в одном процессе сотен версий одной и той же сборки. Так что не никаких проблем подгружать измененные версии. А в игре они будут грузиться один раз. Плата за это объем оперативки у разработчика. Что не проблема. К тому же тут и про оперативку то речи не идет. Тут виртуальная память требуется. Неиспользуемая версия сборки просто высвоповывается на диск и все.

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

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

Код изменения данных будет полностью аналогичным.

FR>Наоборот как раз питон и склеивает сишные компоненты. Уровень связности скриптов на порядок ниже чем классов в приложении.

Ты явно не понимашь принципов компонентного ПО. Уровень связанности в компонентных приложениях будет таким каким ты его определишь в проекте.

FR>Так я уже вроде давал ссылки,

Я видимо не заметил.

FR>отладчиков на уровне VC6

То есть уровня семилетней давности? Ну, хотя бы на это глянуть. Хотя конечно отладчик из VC6 и рядом ле стоял с отладчиком из VS2005.

FR>полно например Pythonwin, отладчик из SPE или BoaConstructor. Кромет того есть VisualPython плугин к VS.NET.

Дал бы сслочки...

FR>>>Есть много ситуаций когда разделить код на две части и писать их на разных языках лучше чем на одном, пример те же скрипты для игр.

VD>>О! Заявлениями мы тут уже сыты. Попробуй обосновать это утверждение. Я лично никак не могу понять как писать на двух средствах у одного из которых нехватает производительности кода, а у другого произоводительности программиста и надежности может быть лучше чем на одном у которого нет ни тех, ни тех проблем.

FR>На этих средствах пишут обычно разные люди.

А какая разница? Производительность обоих будет выше если они будут работать в единой среде. Даже если производительность будет выше только у тех кто раньше писал на С++, то в сумме она уже повысится.

FR>Во первых SWIG умеет обертывать C++ классы так чтобы нормально управлять их временем жизни,

Я очень много возился с компонентным ПО и как никто другой знаю, что обернуть можно толко что что придерживается единых паттеров. Или прийдется воротить кучу метаинфомации и ее интерпритации. Так что не нужно мне рассказвать сказки. Бесплатный сыр бывает только в мышеловке.

FR> во вторых движок был основан на com подобных интерфейсах с подсчетом ссылок и состыковать его с питоном оказалось несложно.

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

VD>>Ну, это пожалуй аргумент. Вот только тогда что говорить о каких-то там приемуществах?

FR>не понял.

Арумент то что если игра пишется с рассчетом на несколько платформ, то дотнет может не подойти просто потому что его нет на платформе. Только причем тут приемущества скритов? Ты же сравнивашь менеджед-приложения вообще и скрипты + С++ вообще. А выводы делашь на частных случаях. В общем, если брать конкретно PS2 и конкретно дотнет, то я согласен. Говорить о разработке игр при таких условиях смешно. Так что или не нужно приплетать аргумент с платформами, так как речь о стратегии и применимости в общем, или не нужно приплетать левые аргументы типа "скрпты проще", так как они тут уже и на фиг не упали.

VD>>>>3. Отличный отладчик.
FR>>>У питона много хороших отладчиков, есть даже специализированные для игр.

VD>>Можно хотя бы скриншот?

FR>http://sourceforge.net/projects/hapdebugger/

Как ты понимашь это чудо поставить не просто. Лучше просто скриншот с возможностями. У них странича в Интернете есть?

VD>>>>5. Отличная IDE.
FR>>>питоных иде тоже хватает.

VD>>Сравним со студией + решарпер?

FR>Угу VisualPython

Ой не верю что сравнимый.

FR>Это только на RSDN меняется

Отнюдь.

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

FR>Дизайнер не программист, он профессионал в своей области.

ОК...

FR> Код который пишется очень специфичен, и черных ящиков там хватает. Среду для дизайнера без кода почти нереально сделать,

Стоп. Или он не программист. Или ему на фиг не упала среда с кодом! Ты заранее создаешь протеворечивые услоия и пыташся еще на базе них сравнивать что-то с чем-то. У тебя постановка задачи ни к черту. Скрпты для не программиста — это уже неграмотное решение. Я еще согласшусь, что программист может быть прикладной и что ему нужен более заточенный под задачу язык, но он все таки или программист, или не программист.

FR> этот редактор может получится сложнее чем вся остальная игра, кроме того задавать логику визуально не проще чем на скрипте(я видел несколько "конструкторов" игр, освоить их не проще чем скрипт а возможности гораздо уже).

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

По сути игра это движок с рантайм-расширениями. А редактор — это вся игра плюс некий интерфейс позволяющий задать некие настройки, раставить нружные детали (персоонажи, ландшафт и т.п.).

"Скрипты" тут могут играть роль неких компонентов позволяющий расширять возможности игры не модифицируя движка. Заниматься этой задачей все равно должен программист. Только в отличии от системного программиста занимающегося вопросами отрисовки и т.п. этот программист должен заниматься вопросами разработки ИИ, управления объектами мира игры и т.п. В общем — это два программиста с разной специализаций. И это вовсе не обязательно тоже лицо что занимается разработкой внешнего вида уровня или моделей.

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

FR>Только файлов настройки не хватает, дизайнеру нужна возможность задавать и менять логику, скрипт тут самый лучший выход.

Логика логике рознь.

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

Если речь идет о настройках параметров, то тут тоже не должно быть скриптов. Параметры должны быть у объектов и компонетов. Их легко можно задавать с помощью редактора свойств (возможно спаренного с монтажной (временной) доской.

Скрипты же полезны исключительно когда речь идет о программировании. Да и скриптами подобный код быть не обязан. Это всго лишь попытка упростить написание прикладного кода. Так и надо называть такой код прикладным, а не скриптами. И тут, по мне так, тоже грамотно было бы не отдавать этот прикладной код на откуп дизигрерам, а оформлять его в виде компонетов. Тогда можно будет четко разграничить обязанности. Системщик пишет ядро которое может расширяться компонентами. Прикладник пишет прикладные компоненты. А дизайнер наполняет ядро прикладными компонентами и задает параметры этих компонентов. Вот это я называю грамотным решением. А дать дизайнеру скриптовый язык и заставить его учиться программированию — это халтура.

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

FR>расшифруй что ты тут понимаешь под словом компонент, а то слишком напоминает волшебную палочку

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

ЗЫ

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