Re[46]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 20:59
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>Тем более пока C#2 нет, а переносимые варианты появятся еще позже.


Папа! Как же так? ... есть, а слова нету? (с)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[52]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 21:02
Оценка:
Здравствуйте, FR, Вы писали:

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


Видимо есть разные люди и разные методы программирования. Я вот очень часто пользуюсь помощью компилятора. Серьезный рефакторинг или написание большого логически завершенного кода очень часто заканчивается устранением ошибок найденных компилятором, а потом и ошибок логических (в С++ еще и ошибок втогого порядка).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 21:13
Оценка: 1 (1) +1
Здравствуйте, eao197, Вы писали:

E>Жаль, что гуру, говоря о достоинствах .NET-а, часто отмахиваются от наличия других платформ


Да никто не отмахивается. Но плевать многим на то что они и их заказчики не используют. Вот например, тем кто пишет игрушки для PS2 плевать не только на дотнет, но и на DX и другие технологии МС и даже Юникс если их нет на PS2.

Потом тут все говорят о чем-то иделаном. Так что почему бы не помечтать о расселении хорошего повсюду? Ну, почему бы не подрихтовать Шара или не сделать более гибкий язык для дотнета? Или почему бы не помечтать о том, что дотнет появится везде и будет предоставлять везде свои огромные библиотеки?

E>Лично мне очень жаль, что Microsoft не занимается сама портированием .NET и C# хотя бы на Unix-ы (типа Linux-а и BSD). Моно и ДотГНУ -- это хорошо, то далеко не Microsoft.


Они сделали порт CLR. Они даже помогают Моновцам и т.п. Но было бы глупо коммерческой конторе живущей с прибылей от продажи коммерческой ОС развивать конкурирующие продукты даже если они бесплатные.

E>Кстати да, очень часто в скриптовых программках натыкаешься на такой hard-coding. Это не значит, что на Python-е (Ruby) нельзя писать без hard-coding-а (равно как на C++, Java и C# легко писать с hard-coding-ом). Но часто именно на такой код нарываешься.


Проблема Питона и других "скриптовых" языков в том, что у ни зачастую нет разницы между строковым литералом и идентификатором программы. Ведь убидиться в корректности можно или с помощью банального тестирования, или с помощью утилит прикладного анализа. А этим подходам плевать на то с чем они работают. Статическая типизация тем и хороша, что она дает механизмы и правила контроля. Все остальное — рефакторин, IDE, рефлекшон и т.п. — это уже следствие наличия метаинформации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[50]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 21:19
Оценка:
Здравствуйте, eao197, Вы писали:

E> — то, что VladD2 и теперь уже WolfHound прибегают к аргументу, что линукс их не интересует


О. Опять я крайний.

Да, это так. Не то чтобы не интересуют. Новости я почитаю с интересом. В форуме с интересом тоже послушаю. Даже иногда подумаю о том, чтобы поставить в ВМВаре Линукс и поглядеть до чего дошел прогресс. Но я так же реально понимаю, что никакого интереса у меня к Линуксу нет. Все что мне от него может понадобиться я обычно получаю используя ЦИГВИН. Да и он мне требуется только ради спортивного интереса. Ну, нет для меня разницы между VC и GCC.

При этом против Линукса я ничего не имею. Даже рад за то что он есть. Все же от отсуствия конкурениции проигрывает в первую очередь потребитель. А я как раз потребитель.

В общем, пусть рассцветают все цветы. Но мне хватит и тех, что растут у меня на грядке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[51]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 21:26
Оценка: :)
Здравствуйте, GlebZ, Вы писали:

GZ>А я бы сказал что наоборот хорошо. Чем меньше Microsoft будет вмешиваться в сам Net, тем лучше.


+1

GZ>PS: вот если бы они коды JIT открыли, вот тогда Net компиляторы в натив начали бы плодится как грибы.


Дык Ротор содержит исходники JIT-а. Они конечно урезаны по сравнению с тем, что есть в коммерческом варианте дотнета, но все же... Есть не мало альтернативных джитов для Ротора. К тому же сейчас в недрах МС зреет проект phoenix который, прада, не открыает исходники джита, но предоставляет открытую архитектуру позволяющую расширять оптимизатор кода и джит кому угодно. Сам джит ничего не стоит без оптимизации кода. А этот проект превращает процесс озадния таких оптимизаций в научный и стало быть открытый. Думаю году к 2010 мы увидим небывалый расцвет этой отрасли.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[50]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 21:31
Оценка:
Здравствуйте, FR, Вы писали:

FR>PyChecker пишет: D:\temp\_tst\p1\tst1.py:4: No global (x) found


Вот, вот. За наличие "global x" и надо отрывать руки создателям языка.

Как показывает практика оные встречются не так редко. Особенно в неумелых руках. А простота Питона и Руби приводят к тому, что как раз в неумелые руки они попадают в первую очередь. А эти руки и про PyChecker ничего обычно не знают.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 21:38
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Можно услышать о применении майнстримового C#2?


Можно. Слушай.

ЗЫ

Если тему скажешь, то можно и пояснить. А так тут об этом уже сто раз говорено.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 21:39
Оценка:
Здравствуйте, _doctor, Вы писали:

_>Вот в VB, скажем, строку с числом сложить не проблема, "компилятор" даже не пискнет


Зависит от Option Strict
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[42]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 21:41
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>Я библиотеку .NET2 еще не изучал. Времени нет.

S>я тоже.

А зря. Ни то написали бы все в одну-две строки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[65]: Python vs C#
От: L.C.R. Россия lj://_lcr_
Дата: 19.05.05 21:52
Оценка: 1 (1)
VladD2,

VD>Спокойно.

Влад, я спокоен как твой розовый слон!

VD> [высказывание X]

Для меня ява — рабочий инструмент. Не больше, не меньше. Его (инструмент) я уже юзаю довольно давно, и я вижу что он вполне пауэрфул и вместе с тем далёк от совершенства. Однако так хочется хотя бы прикоснуться к этому самому совершенству, особенно когда я сталкиваюсь с чем-то подобным:


Возможно этот рисунок покажется не в тему, но на самом деле я хочу выразить этим одну мысль: нотация решает. В данном случае с помощью простой нотации описана достаточно сложная абстракция. В существующей нотации мэйнстримовых ЯП я вынужден "переводить тысячи тонн словесной руды ради единого слова" (с) Маяковский. Потому и меня, и _Вовина, и возможно ещё кого-то тянет на что-то совсем эдакое .

VD>В общем, .

Конечно,
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[51]: Создание игр на managed-языках
От: IT Россия linq2db.com
Дата: 20.05.05 03:34
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>ВМВаре


Блин.... ну это я с трудом перевёл в конце концов

VD>ЦИГВИН


А это что такое?

Влад, если у тебя нет латиницы на компе, то давай мы для тебя нарисуем переводчик из кирилицы в латиницу
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[43]: Python vs C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.05.05 03:39
Оценка: :))) :)
Здравствуйте, VladD2, Вы писали:
VD>А зря. Ни то написали бы все в одну-две строки.
Как? Вообще всё?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[42]: Python vs C#
От: FR  
Дата: 20.05.05 04:36
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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


VD>Не особо то. Но можно и проще:

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


VD>Не так же нужно забывать, что это проще читается и намного быстрее пишется.


Угу только это не полная программа, надо еще кучу не нужной обвязки

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


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


Дело в не готовых решениях а в том что на питоне легко и просто писать.

VD>Ну, и про скорость забывать не стоит. Этот пример вырожденный и скорость в нем не важна, но в реальности скорость все же важана. А без вэлью-типов и достаточно информации о типах скорости дотичь не удастся. Если дотнетный код хоать как-то сореврунется с С++-ным, то у Питона (даже при использовании разных ускорителей вроде преджитов) тут явная труба.


Для скорости у меня плюсы есть

VD>>>Кстати, если говорить о Питоне, то стоит глянуть на Boo. Это типизированный клон Питона для дотнета. Единственная проблема — это то что в нем так же не требуется декларировать перемнные. Бесит страшно.


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


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

VD>Мне кажется за этим будущее. Вкупе с компонентнотстью, джит- и инстол-тайм-компиляцией и другими решениями это может дать то самое более оптимальное решение которое было бы и простым в написании, и строгим, и порождало бы быстрый код.

видно будет.

FR>>так я просил чтобы что-то реальное привели, но не дождался.



VD>А что тебе пойдет? Вот у меня почти доделанные:

VD>* R# — парсер, метапреобразователь и генератор кода написанный на C#.
VD>* Rsdn.Editor — редактор кода вроде Синтилы написанный на C#.
VD>* RSDN@Home — опять же написанный на C#.

вообще-то имелись в виду небольшие задачки для измерения пипи

VD>Не у меня еще куча софта в том числе несколько интерактивных 3D-игр полностью написанных на C#.


интересно, где ни будь можно взглянуть на это?

VD>Хотелось бы увидить хотя бы что-то похожее написанное на Питоне или Руби.


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

VD>ЗЫ


VD>Чтобы было яснее моя позиция... Мне нравятся многие вещи в Питоне и Руби. Это действительно удачные языки. Но их заточенность на интерпретацию, наплевательское отношение к статической типизации и вольное отношение к безопастности программирования (например, то же наплевательское отношение при декларации переменных) делают их для меня эти языки не более чем интересными. В общем, забавная игрушка у которой можно поучиться некотороым удачным решениям.


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

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


Мне Руби не нравится тем что на нем легко писать write only код, на питоне это сложнее.
Re[44]: Python vs C#
От: FR  
Дата: 20.05.05 04:36
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Как показала моя практика как раз задачи копирования и обработки файлов лучше решать опять жен на полноценных языках программирования. Да пока тебе нужно скопировать несколько файлов, то командная строка проста и достаточна. Но как только нужно прибавить мало мальски сложную логику, то она пасует по полной программе. У полноценного ЯП и возможности по формулированию логики по больше, и возможности по отладке куда шире.


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

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


При обработке текстов скорость питона часто близка к сишной (программа же 90% времени сидит в строковых библиотеках).
Re[45]: Python vs C#
От: FR  
Дата: 20.05.05 04:37
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


VD>В дотнете упаковано не меньше. Вернее точно больше.


Вот в яве говорят еще больше

FR>>Про затраты как раз и идет разговор, что на питоне писать проще.


VD>Очень убедительно.


Примерно так же убидительно ты говоришь о Шарпе

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


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


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

VD>Например, средства парсинга командной строки в дотнете и Шарпе явно не фантан. Однако народ разработал очень приятную библиотечку с которой парсинг командной строки становится декларативным процессом. Например, вот декларация параметров командой строки для одной из наших утилит:


VD>
VD>class Arguments
VD>{    
VD>    [Argument(
VD>            ArgumentType.AtMostOnce, 
VD>            HelpText="Enable archiver. Only for -type:diff",
VD>            DefaultValue = false)
VD>    ]
VD>    public bool Zip = false;

VD>    [Argument(
VD>            ArgumentType.Required,
VD>            HelpText="Work type.")
VD>    ]
VD>    public WorkType Type = WorkType.Diff;

VD>    [DefaultArgument(
VD>            ArgumentType.MultipleUnique, 
VD>            HelpText="Input files to count.")
VD>    ]
VD>    public string[] Files = null;

VD>    public bool ParseArgumentsWithUsage(string[] args)
VD>    {
VD>        return Parser.ParseArgumentsWithUsage(args, this);
VD>    }
VD>}
VD>


VD>А вот использование:

VD>
VD>arguments = new Arguments();
VD>if (arguments.ParseArgumentsWithUsage(args))
VD>    Work();
VD>...

VD>private void Work()
VD>{
VD>    switch (arguments.Type)
VD>    {
VD>        case WorkType.Diff:
VD>        {
VD>            Diff.DiffFiles(arguments.Files[0], arguments.Files[1],
VD>                arguments.Files[2], arguments.Zip, this);
VD>            break;
VD>        }
VD>        case WorkType.Patch:
VD>        {
VD>            Patch.Do(arguments.Files[0], arguments.Files[1],
VD>                arguments.Files[2]);
VD>            break;
VD>        }
VD>    }
VD>}
VD>


VD>То есть все описание аргументов польностью декларативно.


Извини конечно, но берем питон подключаем стандартный модуль OptionParser и:
from optparse import OptionParser

parser = OptionParser()
parser.add_option("-f", "--file", dest="filename",
                  help="write report to FILE", metavar="FILE")
parser.add_option("-q", "--quiet",
                  action="store_false", dest="verbose", default=True,
                  help="don't print status messages to stdout")

(options, args) = parser.parse_args()



Да на С++ тоже есть готовое решение boost::program_options
Re[47]: Python vs C#
От: FR  
Дата: 20.05.05 04:37
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


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


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


Простые задачи быстрее и проще решать на удобных языках. К тому же задачи делятся не только на простые и сложные есть и средние которые с успехом решаются тем же питоном.При обработке текстов и питон и перл показывают неплохую скорость.
Ты думаешь бизон нельзя подключить к питону? К тому же для питона кроме него есть еще несколько парсеров.
Re[51]: Создание игр на managed-языках
От: FR  
Дата: 20.05.05 04:59
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>PyChecker пишет: D:\temp\_tst\p1\tst1.py:4: No global (x) found


VD>Вот, вот. За наличие "global x" и надо отрывать руки создателям языка.


PyChecker выдает такие сообщения когда обнаруживает попытку использования неинициализированной переменной, так что global здесь просто означает что ничего похоже на x он не нашел.
Re[47]: Создание игр на managed-языках
От: Borisman2 Киргизия  
Дата: 20.05.05 05:24
Оценка: 1 (1) +1 -1
Здравствуйте, Козьма Прутков, Вы писали:

КП>Трурль wrote:

>> Здравствуйте, WolfHound, Вы писали:
>> Поставим вопрс по-другому. Стоит ли связываться с C#, если есть питон?
КП> стоит ли шить сапоги если мы уже умеем плести лапти?
КП>Питон безусловно хорошая вещь (это я по дискуссии сужу), но для своих
КП>целей. И как лапти хороши сегодня для сувенира иностранцу, так сапоги
КП>для того, чтобы использовать их в качестве обуви. В лаптях конечно тоже
КП>можно ходить (ну ходили же наши предки), но не далеко.
Вы когда-нибудь ходили в лаптях, для того чтобы утверждать что в них недалеко уйдешь?
КП>Да, конечно, прикольно не иметь статической типизации, все мочить в коде
КП>и т.д. Но это вряд ли сильно положительно скажется на простоте поддержки
КП>разрабатываемой системы, ее расширяемости, простоте отладки и т.д.
Может сказаться как отрицательно, так и положительно. Статическая типизация vs. динамическая типизация — топик далеко не так ясный, как Вы стараетесь его представить. Особенно в области скриптов для компьютерных игр, где традиционно используются такие языки как Lua
КП>Юнит-тесты это хорошо, но строгая типизация — куда более строгий
КП>инструмент.
Это Вас кто-то обманул. Те тесты, которые Вы делаете сам, компилятор НИКОГДА не сумеет провести автоматически.
КП>И вряд ли отсутствие типизации ускорит разработку, учитывая
КП>что юнит-тестов надо написать куда больше, плюс отлаживаться придется
КП>дольше.
Насчет юнит тестов тоже не вполне ясно. Время, потраченное на борьбу с типами можно с пользой потратить на написание тестов. Насчет отладки — это я не понял. Почему дольше ?
КП>Благо дизайн приложений уже довольно развит,
Это кто сказал ? Это Ваше личное мнение ?
КП>что дает
КП>дополнительный аргумент в пользу наличия типизации. Такие штуки,
КП>наверное, хороши для написания пакета утилит для администрирования и
КП>т.п. для собственного пользования. Но писать промышленную систему,
КП>которая будет здорово развиваться, я бы на них не стал.
Питон заводами управляет. Производством. Поинтересуйтесь.
КП>Что касается библиотеки, то да, .NET предлагает менее развитую в
КП>рассмотренных отношениях библиотеку. Но он ориентирован на разработку
КП>корпоративных приложений, автоматизации бизнеса, а не утилит и игр. Если
КП>есть специфическая потребность — ее надо осмыслить и один раз написать
КП>нужную библиотеку.
КП>Итого, всему свое место в жизни
Кстати, одним из главных преимуществ Питона я считаю встроенный тип данных — "словарь" (mapping, hashtable, как Вам больше нравится). Это не пустяк, это ОЧЕНЬ и ОЧЕНЬ серьезное преимущество.
Re[47]: Создание игр на managed-языках
От: Трурль  
Дата: 20.05.05 06:41
Оценка: 13 (2) +3 :))) :))
Здравствуйте, Козьма Прутков, Вы писали:

КП>И как лапти хороши сегодня для сувенира иностранцу, так сапоги

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

Сапоги хороши для хождения строем. А если надо быстро бежать, то даже лапти получше будут.
Re[52]: Создание игр на managed-языках
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.05.05 06:59
Оценка: +1
Здравствуйте, IT, Вы писали:

VD>>ВМВаре


IT>Блин.... ну это я с трудом перевёл в конце концов


А чего тут переводить? VMWare и есть.

VD>>ЦИГВИН


IT>А это что такое?


cygwin
... << RSDN@Home 1.1.4 beta 7 rev. 456>>
AVK Blog
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.