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

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

FR>>Где это код проще, я что-то пропустил?

VD>А ты отвернись на 20 секунд, повернись обратно и погляди беспристрастным взглядом. Тогда возможно поймешь, что использование 2 функций намного менее понятно чем два оператора.

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

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

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

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

FR>>Вообще разговор здесь начинался в контексте скриптов для игр,


VD>Что же ты все время об этом забываешь? Вот все пиняешь про разбор текстов и т.п...

Потому что уровень сложности близкий.

FR>> которые по сути как и утилитки небольшие программки,

VD>Прикить на какие высоты могли бы выйти игры если бы вместо мелких утилиток были бы производительные и сложные подпрограммы?

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

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

VD>Извини но опять пустые слова. Никаого серьезного приемущества в простоте синтаксиса нет. Это выдумки. Единственный факт который можно поставить в укор дотнету, это то что модули можно выгружать только целым доменом. Жаль, что для игр это не является проблемой, так как скрипты там распространяются на уровень при перезагрузке которых нет никаких проблем перезагрузить домен. Все остальное домыслы.

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

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

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

FR>> А студии и решарперы мало что дают для программ и модулей максимум в 1000 строк длиной.

VD>Во оно каа? А у меня все программы состоят из мелких классов лежащих в отдельных файлах. И почему-то при этом студия и решарпер дают удивительное ускорение. Не подскажешь в чем проблема?

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

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

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

FR>>Вряд ли проще, чем скормить SWIG'у заголовок и после этого забыть про проблему так как все делается автоматом.

VD>То есть ты считашь, что писать код на С++ проще чем на Питне? И что подключать код с помощью каких-то утилит проще чем писать его на одном языке? И что при написании костылей на С++ не нужно придерживаться жестких паттернов, и что их нарушение не выльется в AV в последствии?

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

VD>Если, да, то хочу признаться — ты крут!

угу

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

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

VD>Понятно. Так что ты там померить хотел?

Так меряем потихоньку, да и вообще длина относительна, не инвариант


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

VD>Тебе уже 100 раз повторили:
VD>1. Значитально более выская производительность.

Много задач где это неважно(не на первом месте).

VD>2. Отсуствие необходимости применения более низкоуровневых языков.

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

VD>3. Отличный отладчик.

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

VD>4. Отличные средства рефакторинга.

не нужно.

VD>5. Отличная IDE.

питоных иде тоже хватает.

VD>Ничего опровергающего это ты сказать так и не смог. А вот все твои аргументы — это чистой воды заявления. Ничем при этом не обоснованные.

FR>>Дело не в этом. Я смотрел примеры, слишком много закорючек, напоминает перл и форт

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

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

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

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

FR>>Угу, в упор не видишь что программировать (особенно начинающим) на шарпе все таки сложнее.

VD>Ага. В упор! Тяжело увидить того чего нет. А что до начинающих, ты вроде говорил о серьезном ПО (об играх). Их пишут не начанающие. Так что тут это вообще не причем.

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

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

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

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

VD>Осталось доказать свои утверждения...

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

FR>>Практика (широкое использование языков типа питона, перла и т. п. для обработки текстов) показывает что скорость вполне приемлемая.

VD>Ну, для чего-то неприменно. Вот только зачем себя загонять в рамки без необходимости?

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

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


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

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

FR,

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

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

Эти префиксы обязательны?

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

VD>>Тю... Чуть-чуть? А где же "гораздо короче" и "радикально чернее?" .
FR>ну до коммунизма пока далеко
Во-во...

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

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

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


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

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

Зря. После начала программирования на Ruby на них так же мало обращаешь внимания, как на структурирование программы пробелами в Python.

Здравствуйте, L.C.R., Вы писали:

LCR>FR,

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

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

LCR>Эти префиксы обязательны?

Да. И, имхо, это хорошо.

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

S>Здравствуйте, FR, Вы писали:
FR>>Вообще мне наплевать на чем написана библиотека.
S>Это неверный подход. Потому как он оставляет прикладника человеком второго сорта. Пользоваться готовым ты можешь, а воспроизвести — нет. Та же ситуация была в VB: разработчик был втиснут в жесткие рамки существующих активыксов, по большей части коммерческих. Состряпать свой — это пересесть на С++, язык, требующий совершенно другого уровня владения предметом. Простейшие в VB вещи превращаются в чудовищные конструкции на С++.

Со всем этим я согласен при условии что на VB сидит и работает разаработчик — программист. Если же скрипт должен писать(или править) специалист не программист (это и есть ситуация для компьютерных игр) то наоборот лучше все максимально ограничить и упростить.

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

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

E>Зря. После начала программирования на Ruby на них так же мало обращаешь внимания, как на структурирование программы пробелами в Python.

Если бы мне первым попался на глаза Ruby а не Python, я сейчас возможно также думал бы
Вообще есть и более страшные вещи, например Icon

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

FR>Если бы мне первым попался на глаза Ruby а не Python, я сейчас возможно также думал бы
FR>Вообще есть и более страшные вещи, например Icon
А че Icon? Очень даже ничего.

Здравствуйте, FR, Вы писали:
FR>Со всем этим я согласен при условии что на VB сидит и работает разаработчик — программист. Если же скрипт должен писать(или править) специалист не программист (это и есть ситуация для компьютерных игр) то наоборот лучше все максимально ограничить и упростить.
Ограничения еще никогда никому ничего не упрощали. Упрощение — это предоставление максимума функциональности в готовом к употреблению виде. Попробую подлиннее:
У нас есть задача А и задача Б.
Задача А встречается в природе в 100 раз чаще, чем задача Б.
Подход номер 1 состоит в том, что наша среда предлагает решение задачи A в одну строку (один клик мышкой — по вкусу).
Решение задачи Б при этом занимает 1500 строк, пишется на другом языке с другими правилами, при этом в большинстве случаев ошибка в любой из этих 1500 строк состоит во внезапной смерти приложения с невнятным сообщением об ошибкe "Что-то сломалось". Фактически, потенциальный барьер настолько высок, что его можно считать бесконечным. Ни один разработчик не станет тратить 800 часов личного времени на освоение параллельной технологии только ради того, чтобы выделить цветом одну строку в гриде.

Подход номер 2 состоит в том, что наша среда предлагает решение задачи A в одну строку (один клик мышкой — по вкусу). Решение задачи Б потребует, конечно, освоения несколько более глубокого пласта знаний, но его можно сделать на том же языке, уложившись в 150 строк. При этом значительным подспорьем являются исходники (все на том же языке!) для решения задачи А. Поскольку задача Б является всего лишь более экзотической версией задачи А, которая не укладывается в заранее предусмотренные рамки.

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

S>Здравствуйте, FR, Вы писали:
FR>>Со всем этим я согласен при условии что на VB сидит и работает разаработчик — программист. Если же скрипт должен писать(или править) специалист не программист (это и есть ситуация для компьютерных игр) то наоборот лучше все максимально ограничить и упростить.
S>Ограничения еще никогда никому ничего не упрощали. Упрощение — это предоставление максимума функциональности в готовом к употреблению виде. Попробую подлиннее:

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

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

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

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

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

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

Ну замени "существование" на "широкое использование".

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

VD>Да, да. В следующем году будет 50 лет как...

Чего 50 лет? Я имел ввиду некую среду для разработки DSL. Пишешь DSL, а в качестве бонуса получаешь отладчик, подсветку и рефакторинг — и все малой кровью. Например, написал я DSL — язык описания клеточных автоматов (Cellang). Хочу отладчик и подсветку. Подсветку еще довольно просто сделать, а вот с отладчиком уже сложнее.

Ну и в таком духе.

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

VD>Думаю, что не бесполезное, а слишком сложное. Лисп хорош только в качестве флэймвовых примеров. А на практике, что то народ к нему не часто прибегает.

Есть немного. Для меня основная проблема в отсутствии нормальных реализаций Scheme на вершине JVM, из-за ограничений оной.

VD>Может тут надо быть ясновидцем? Я как-то Паскаля там не налюлаю.

Ну что я могу сказать, читай внимательнее. 5 страница, слева снизу. Это результат. Остальное — вспомогательный код, реализация DSL. Он остается за кулисами.

VD>Да и Паскаль — это детство. Хотелось бы поглядеть во что выльется парсер C# или хотя бя Дельфи. Ну, и сравнить это дело с краматикой в EBNF-формате.

Что-то кажется мне, что ты сравниваешь теплое с мягким. В статье просто приведена реализания некоторого языка, похожего на Паскаль.

VD>Почему-то мне кажется, что это буде многократно сложее и не понятнее чем EBNF.

Для меня код выглядит write-only, однако я полагаю, что причина в моем малом опыте реализации парсеров и компиляторов (ну и названия переменных мне там не нравятся . Можно просто спросить автора, сколько у него заняло реализация этого чуда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VD>>Если, да, то хочу признаться — ты крут!

FR>угу



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

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

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

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

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

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

VD>>4. Отличные средства рефакторинга.
FR>не нужно.

Агащасблин.

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

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

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

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

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

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

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

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

VD>>Да, да. В следующем году будет 50 лет как...

WF>Чего 50 лет?

Лисп.

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

WF>Есть немного. Для меня основная проблема в отсутствии нормальных реализаций Scheme на вершине JVM, из-за ограничений оной.

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

VD>>Может тут надо быть ясновидцем? Я как-то Паскаля там не налюлаю.

WF>Ну что я могу сказать, читай внимательнее. 5 страница, слева снизу. Это результат. Остальное — вспомогательный код, реализация DSL. Он остается за кулисами.

Больно результат на паскаль не похож.

WF>Что-то кажется мне, что ты сравниваешь теплое с мягким. В статье просто приведена реализания некоторого языка, похожего на Паскаль.

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

VD>>Почему-то мне кажется, что это буде многократно сложее и не понятнее чем EBNF.

WF>Для меня код выглядит write-only, однако я полагаю, что причина в моем малом опыте реализации парсеров и компиляторов (ну и названия переменных мне там не нравятся . Можно просто спросить автора, сколько у него заняло реализация этого чуда.

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