Re[47]: Создание игр на managed-языках
От: Трурль  
Дата: 20.05.05 06:41
Оценка: 13 (2) +3 :))) :))
Здравствуйте, Козьма Прутков, Вы писали:

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

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

Сапоги хороши для хождения строем. А если надо быстро бежать, то даже лапти получше будут.
Re[50]: Python vs C#
От: FR  
Дата: 23.05.05 08:12
Оценка: 2 (2) +3 :)
Здравствуйте, WolfHound, Вы писали:

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


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

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

Ну замени "существование" на "широкое использование".
Re[49]: Создание игр на managed-языках
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 14.05.05 15:20
Оценка: :))) :)))
WH>нажимаю пару кнопок и получаю
WH>
WH>        private float Foo(int i, string s)
WH>        {
WH>            throw new NotImplementedException();
WH>        }
WH>

WH>красота

Столько сложностей и всё ради того, чтобы получить ошибку времени выполнения!
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[68]: Python vs C#
От: L.C.R. Россия lj://_lcr_
Дата: 17.05.05 16:55
Оценка: 10 (2) +3
Здравствуйте, WolfHound, Вы писали:

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


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

WH>По сравнению с силой гигабаксов микрософта и сана...
.
Видишь — ненулевая! Даже по сравнению.

Преувеличить могущество сана и мелкософта мы всегда успеем — всё равно с их гигабаксов нам перепадает совсем немножко. Поэтому не вижу смысла фанатеть за мэйнстрим вообще. Лучше найти себе что-нибудь красивое, и шлифовать своё мастерство одновременно получая и пользу, и удовольствие.

Зы: Я не про Brainfuck
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[64]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 17.05.05 13:30
Оценка: 4 (4) +1
Здравствуйте, L.C.R., Вы писали:

_>>Да все они давно обсуждены.

LCR>Дык я и хочу узнать, где они обсуждены... Искал-искал, ничего не нашёл. Про нуль только помню.

Неплохой подход к сравнению языков приведен у Пола Грэхэма. Там же утверждается неполноценность сравнения языков на основании порстого разложении по фичам (хотя это тоже важно). Тезис — сравнить между собой языки можно только после того, как плотно поработал с ними. Тогда становится очевидно, что язык Х дает больше возможностей, чем язык Y, как более "высокоуровневый". При этом, если на языке X человек не писал, объяснять ему логически, что Х "лучше" и выразительнее — бесполезно, так как фичи — это одно, а общая парадигма, идеология языка, не является простой суммой его фич, это нечто большее. Понять парадигму сложнее, фич для этого недостаточно. Мой пост Clean vs C++, проскакивавший недавно в юморе — сатира на эту тему.

vovin_ на rsdn является главным "адвокатом" языка Smalltalk. Он проделал огромную разъяснительную работу в форуме "философия", за что ему большое спасибо. Он убедил многих в мысли (а меня в ней укрепил), что Java при межязыковом сравнении проигрывает Smalltalk по всем пунктам.

Искать надо флеймы про Smalltalk — там он постоянно сравнивается с Java/C#.
Re[45]: Создание игр на managed-языках
От: Трурль  
Дата: 14.05.05 09:22
Оценка: 1 (1) +2 :))
Здравствуйте, WolfHound, Вы писали:

FR>>Возможностей питона для них тоже вполне хватает,

WH>Я с этим и не спорю вот только стоит ли связываться с питоном если есть C#2

Поставим вопрс по-другому. Стоит ли связываться с C#, если есть питон?
Re[43]: Создание игр на managed-языках
От: Gaperton http://gaperton.livejournal.com
Дата: 14.05.05 11:47
Оценка: 1 (1) +3 :)
Здравствуйте, WolfHound, Вы писали:

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


G>>Да правда чтоли? VB со своим IDispatch, JScript, PHP, Perl и ваш любимый C# c контейнерами Object-ов — типизированны по самое нехочу?

WH>С++, C#2...
Это у нас весь мэйнстрим?
FR>>А отсутствие типизпции может быть и преимуществом.
WH>Да правда чтоли? Интересно почему тогда весь мейнстрем типизированый по самое нехочу?
Плохонький аргумент, короче, с твоей стороны. Совсем никакой.
Re[60]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 16.05.05 07:55
Оценка: 1 (1) +3 :)
Cyberax wrote:

> _vovin wrote:

>
>
>>>G>Кстати, я работая на С++ прекрасно обхожусь без вашего ReSharpera.
>>
>>И неудержимой тяги писать его аналог не испытываю.
>>
>>>Я тоже не испытывал пока не попробовал. Вобщем ReSharper это наркотик
>>
>>такой.
>>ReSharper это полный аналог возможностей IDEA, или еще что-то уникальное?
>
>
> Почти полный, его пишут те же люди, что и IDEA. Хотя по сравнению с IDEA
> он часто глючит.
>

Тогда наркотики у каждого свои. Использую IDEA полтора года, но выкинул
бы ее вместе с Java при первом удобном случае. Никакие удобные рюшки не
помогают прикрыть убогость языка и, особенно, типичных решений на нем.
Posted via RSDN NNTP Server 1.9
Re[70]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 17.05.05 16:33
Оценка: 1 (1) +4
Здравствуйте, AndrewVK, Вы писали:

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


>>> Ты кажется не понял. Вот возьмем к примеру янус. Он довольно сильно популяризует платформу среди посетителей RSDN. А теперь задай себе вопрос — мог бы янус быть написанным на ST?


_>>Естественно мог бы. Хоть на брэйнфаке. Если ты действительно спрашиваешь

_>>о теоретической возможности.

AVK>Нет конечно. Речь исключительно о возможности практической.


Мог бы. Достаточно желания. Хотя на брейнфаке. Кстати, ничего личного, но мне лично Янус сильно не нравится. Могу по пунктам описать, почему. От платформы он может скорее оттолкнуть, ИМХО, и популяризовать ее не может — альтернативного оффлайнового клиента, т.е. выбора, просто нет, вот им и пользуются.

_>>Если же речь идет о вероятности этого

_>>события, то это совсем другой вопрос.
_>>Ну и я не вижу связи между ценой среды и янусом.

AVK>Связь очень простая — отсутствие бесплатных средств разработки это однозначно приговор.

Что вы зачастили — "приговор, приговор". Разве мы в суде?
Re[38]: Python vs C#
От: WolfHound  
Дата: 13.05.05 11:15
Оценка: 4 (2) :))
Здравствуйте, FR, Вы писали:

FR>По объему кода, вот простейшая программка считывает файл построчно и выводит его в другой файл отсортированным по строкам:

Функции readlines в библиотеке .НЕТ нет по этому мы ее напишем.
        static IEnumerable<string> Lines(Stream stream)
        {
            using (StreamReader reader = new StreamReader(stream))
                for (string line; (line = reader.ReadLine()) != null; )
                    yield return line;
        }

FR>arr = open("test.txt").readlines()
FR>arr.sort()
            List<string> lines;
            using (Stream file = File.OpenRead("text.txt"))
                lines = new List<string>(Lines(file));
            lines.Sort();

FR>out = open("out.txt", "w")
FR>for line in arr:
FR>    print >> out, line,
            using (TextWriter file = File.CreateText("out.txt"))
                foreach (string line in lines)
                    file.WriteLine(file);

Отсутствие типизации и необходимости объявлять переменные в питоне я считаю большим недостатком.

FR>Суммирование чисел из файла(в каждой строке файла одно число):

Опять библиотека...
Да будут операторы
        delegate T Operator<T>(T l, T r);
        interface IMathOperators<T>
        {
            Operator<T> Add { get; }
            Operator<T> Sub { get; }
            Operator<T> Mul { get; }
            Operator<T> Div { get; }
        }
        class MathOperatorsInt : IMathOperators<int>
        {
            public Operator<int> Add { get { return delegate(int l, int r) { return l + r; }; } }
            public Operator<int> Sub { get { return delegate(int l, int r) { return l - r; }; } }
            public Operator<int> Mul { get { return delegate(int l, int r) { return l * r; }; } }
            public Operator<int> Div { get { return delegate(int l, int r) { return l / r; }; } }
        }
        static Dictionary<Type, object> MathOperatorsMap = new Dictionary<Type, object>();
        static IMathOperators<T> MathOperators<T>()
        {
            return (IMathOperators<T>)MathOperatorsMap[typeof(T)];
        }
        static Program()
        {
            MathOperatorsMap.Add(typeof(int), new MathOperatorsInt());
        }

Теперь сделаем недостающие функции
        delegate T Parse<T>(string s);
        static IEnumerable<T> Map<T>(Stream stream)
        {
            Parse<T> parse = (Parse<T>)Delegate.CreateDelegate(typeof(Parse<T>),
                typeof(T), "Parse");
            foreach (string line in Lines(stream))
                yield return parse(line);
        }
        static T Sum<T>(IEnumerable<T> numbers)
        {
            Operator<T> add = MathOperators<T>().Add;
            T val = default(T);
            foreach (T number in numbers)
                val = add(val, number);
            return val;
        }

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

    using (Stream file = File.OpenRead("text.txt"))
        Console.WriteLine(Sum(Map<int>(file)));


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

Это тоже решается библиотекой.


А самое главное что все что ты привел очень синтетические задачи не имеющие с реальностью ничего общего.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: Создание игр на managed-языках
От: Козьма Прутков Россия  
Дата: 14.05.05 10:17
Оценка: 3 (1) +2 -1
Трурль wrote:
> Здравствуйте, WolfHound, Вы писали:
> Поставим вопрс по-другому. Стоит ли связываться с C#, если есть питон?
стоит ли шить сапоги если мы уже умеем плести лапти?
Питон безусловно хорошая вещь (это я по дискуссии сужу), но для своих
целей. И как лапти хороши сегодня для сувенира иностранцу, так сапоги
для того, чтобы использовать их в качестве обуви. В лаптях конечно тоже
можно ходить (ну ходили же наши предки), но не далеко.
Да, конечно, прикольно не иметь статической типизации, все мочить в коде
и т.д. Но это вряд ли сильно положительно скажется на простоте поддержки
разрабатываемой системы, ее расширяемости, простоте отладки и т.д.
Юнит-тесты это хорошо, но строгая типизация — куда более строгий
инструмент. И вряд ли отсутствие типизации ускорит разработку, учитывая
что юнит-тестов надо написать куда больше, плюс отлаживаться придется
дольше. Благо дизайн приложений уже довольно развит, что дает
дополнительный аргумент в пользу наличия типизации. Такие штуки,
наверное, хороши для написания пакета утилит для администрирования и
т.п. для собственного пользования. Но писать промышленную систему,
которая будет здорово развиваться, я бы на них не стал.
Что касается библиотеки, то да, .NET предлагает менее развитую в
рассмотренных отношениях библиотеку. Но он ориентирован на разработку
корпоративных приложений, автоматизации бизнеса, а не утилит и игр. Если
есть специфическая потребность — ее надо осмыслить и один раз написать
нужную библиотеку.
Итого, всему свое место в жизни
Posted via RSDN NNTP Server 2.0 beta
Да хранит вас господь в сухом прохладном месте...
Re[41]: Создание игр на managed-языках
От: FR  
Дата: 13.05.05 18:27
Оценка: 2 (2) +1 :)
Здравствуйте, WolfHound, Вы писали:

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


FR>>Код все равно больше по объему.

WH>И что с того если все это за меня автокомплит набил?

А читать потом этот код тоже автокомплит будет?

FR>>А отсутствие типизпции может быть и преимуществом.

WH>Да правда чтоли? Интересно почему тогда весь мейнстрем типизированый по самое нехочу?

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

FR>>В первом примере никаких библиотек не использовалось только встроенные возможности языка.

WH>Те в язык встроели работу с файлами?

Скорее с потоками, а файлы так на закуску.

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

WH>Зачем?
WH>Елси мне очень сильно приспичет пописать на функциональном языке то я возьму функциональный язык. Благо их на .НЕТ портировано до чертиков.

Угу чтобы пару строк кода написать будешь переключатся на другой язык.

FR>>В примере на питоне все решается без библиотек.

WH>Ну не встроели в C# вызов соответствующих функций фреймворка... беда то какая.

Так библиотеки еще и написать надо.

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

WH>Тема была про скрипты в играх. А для чего в играх используются скрипты? Правильно чтобы объекты в игре что-то делали.
WH>
WH>class World
WH>{
WH>    public IEnumerable<GameObject> GetObjects(Position pos, float range)
WH>    {
WH>        foreach (GameObject obj in objects)
WH>            if (obj.Pos.DistanceTo(pos) < range)
WH>                yield return obj;
WH>    }
WH>}
WH>class Bomb : GameObject
WH>{
WH>    public void Detonation()
WH>    {
WH>        foreach (GameObject obj in world.GetObjects(Pos, detonationRange))
WH>            obj.Damage(detonationDamage);
WH>    }
WH>}
WH>


Ну это же не компилируемый кусок, как я понял есть список игровых объектов надо пройтись по нему и взорвать те которые на нужном расстоянии от бомбы, так этот код слово в слово можно переписать на питоне (yeld там тоже есть). Ты лучше опиши задачу и дай реализацию на шарпе, а так не знай откуда вырваные куски не интересно.
Re[40]: Python vs C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.05.05 05:03
Оценка: :))) :)
Здравствуйте, FR, Вы писали:
FR>Не надо по деревьям лазить, достаточно брать любую небольшую утилитку активно работающую с текстовыми файлами, объем кода будет сильно меньше чем на плюсах или шарпе, близко к объему на перле, но в отличии от перла не write-only а вполне читабельный код.
Угу. А вот при рисовании линий на экране лого порвет этот ваш питон как тузик грелку.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[40]: Python vs C#
От: eugals Россия  
Дата: 14.05.05 06:09
Оценка: :))) :)
Здравствуйте, Трурль, Вы писали:

Т>Чисто для прикола:

Т>
Т>"out.txt" 0: t[<t: 0: "text.txt"]
Т>


bash$ sort text.txt > out.txt


... << RSDN@Home 1.1.4 beta 5 rev. 395>> {WinAmp: silent}
Re[46]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 00:46
Оценка: +1 -1 :))
Здравствуйте, Трурль, Вы писали:

Т>Поставим вопрс по-другому. Стоит ли связываться с C#, если есть питон?


Более чем. Но ты не поверишь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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[48]: Python vs C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.05.05 05:59
Оценка: 17 (1) +2
Здравствуйте, FR, Вы писали:
FR>Вообще мне наплевать на чем написана библиотека.
Это неверный подход. Потому как он оставляет прикладника человеком второго сорта. Пользоваться готовым ты можешь, а воспроизвести — нет. Та же ситуация была в VB: разработчик был втиснут в жесткие рамки существующих активыксов, по большей части коммерческих. Состряпать свой — это пересесть на С++, язык, требующий совершенно другого уровня владения предметом. Простейшие в VB вещи превращаются в чудовищные конструкции на С++.
Delphi с самого начала предложил использование единого языка для написания как приложений, так и библиотек. Это обеспечило наличие огромного количества бесплатных и почти бесплатных компонент.
Та же система прослеживается в .Net: ты не ограничен в выборе языка. Более того, особых неэффективностей нет ни в одном из них. Поэтому VB-шнику не потребуется осваивать шарп или еще что-то из-под палки. Все фичи FCL (кроме особо системных) он может воспроизвести самостоятельно, не слезая со своего языка. А задачи оптимизации сверх предлагаемой C#/VB встречаются редко, и в таких ситуациях, когда найм отдельного скилластого девелопера для переноса узких мест на unmanaged вполне оправдан.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[57]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.05.05 07:05
Оценка: 10 (3)
Здравствуйте, WFrag, Вы писали:

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


Расскажу ка я одну историю из личного опыта. Было это где то в середине 90-х. Для одной задачки понадобился весьма специфичный набор отчетов. Встроенный тогда в Дельфи QuickReport и его сторонние аналоги приводил к очень большому объему работ. Поэтому было принято решение написать свой специализированный репортер. В качестве средства описания отчета был придуман простенький язычок, на первых порах чисто декларативный, навроде файла команд графопостроителя. Модного слова DSL тогда еще не было, но по сути это он и был. Так вот — репортер был сделан и продан заказчику в первой версии программной системы. Заказчик от возможности править отчеты руками в текстовом редакторе просто паром в потолок писал. А вот дальше все стало несколько печальнее. Началось все относительно безобидно — понадобилась условная генерация. Ну что ж, поскольку язык был декларативным условия были прикручены навроде того как это сделано в XSLT. Выглядело ужасно, но, поскольку требовалось очень редко, прокатило. Дальше хуже — наворотов требовалось все больше и больше. Самое страшное — все в итоге прекрасно понимали что изобретаем велосипед, но продолжали жрать кактус, поскольку на каждом этапе модификация требовалась небольшая и вроде как проще было ее внести, нежели переписывать весь репортер.
Закончилась же эта печальная история очень просто — поскольку язык был немного похож на паскаль, то написали просто препроцессор, который подгонял наш DSL к виду, компилируемому dcc32.exe. Причем этот самый DSL по сути просто в паскаль и выродился, а сложный препроцессор понадобился исключительно ради того чтобы не переделывать уже готовые отчеты.
... << RSDN@Home 1.1.4 beta 7 rev. 458>>
AVK Blog
Re[49]: Создание игр на managed-языках
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.05.05 11:45
Оценка: 2 (2) +1
Здравствуйте, GlebZ, Вы писали:

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


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

GZ>Так я не понял, это хорошо или плохо?

Хорошо, что есть Моно и дотГНУ.
Плохо:
— то, что Microsoft официально не занимается портированием .NET и C# на другие платформы сама ;
— то, что VladD2 и теперь уже WolfHound прибегают к аргументу, что линукс их не интересует
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[43]: Создание игр на managed-языках
От: FR  
Дата: 14.05.05 08:21
Оценка: 1 (1) +1 -1
Здравствуйте, WolfHound, Вы писали:

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


FR>>А читать потом этот код тоже автокомплит будет?

WH>Учтитывая особенности человеческого чтения это не есть проблема.

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

WH>К томуже статически типизированые языки позволяют создавать утилиты для рефакторинга. Нука покажи мне аналог ReSharper'а для питона...


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

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

WH>Знаешь я лучше буду пользоваться шаблоными чем терпеть выходки питона. То он переменную сам объявит то...

Сам не объявит

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

WH>Вот еще ползоваться какимито левыми утилитами если можно взять нормальный язык.

Так ты же пользуешся левой утилитой ReSharper?
Раньше и для си был lint очень похож на PyCheker.

FR>>Скорее с потоками, а файлы так на закуску.

WH>А смысл?

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

FR>>Угу чтобы пару строк кода написать будешь переключатся на другой язык.

WH>Если мне понадобится что-то хитровывернутое то я какнибудь обойдусь.

понятно

FR>>Так библиотеки еще и написать надо.

WH>Не надо. Ибо толку от них всеравно не будет.

угу если чего нет в шарпе то это ниому не нужно

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

WH>Дело в том что все скрипты в играх будут выглядеть примерно так как я показал. Те возможностей C#2 для них выше крыши.

Я видел скрипты из реальных игр, и очень небольшая часть их выглядит также. Возможностей питона для них тоже вполне хватает, и как плюс они будут короче и понятней, осбенно настроечные скрипты с которыми работают дизайнеры, то есть те кто мало разбирается в кодировании.
Re[70]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 18.05.05 17:12
Оценка: 1 (1) +2
Здравствуйте, WolfHound, Вы писали:

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


LCR>>Видишь — ненулевая! Даже по сравнению.

WH>Дык Апач в отличии от смаллтолка бесплатный. По тому и держится.
WH>К томуже там написано Across All Domains те включая странички Васей Пупкиных с содержанием
WH>

WH>Линух 4ever!!! Мелкософт на свалку!!

WH>Причем эни это не сами придумали, а наслушались "кулхацкеров".
Напрасно преуменьшаешь долю Apach + Linux. Она выше даже за вычетом Васей Пупкиных. Можно у Gartner и IDC глянуть — просто так лень, но готов заключить пари — и я достану сведения.

LCR>>Поэтому не вижу смысла фанатеть за мэйнстрим вообще.

WH>А я не фанатею просто реально смотрю на вещи.
LCR>>Лучше найти себе что-нибудь красивое, и шлифовать своё мастерство одновременно получая и пользу, и удовольствие.
WH>Ты с этим предложением опоздал. Мне давно не интересно сидеть и что-то просто так шлифовать.
WH>А получать пользу со смаллталка не реально ибо он нафиг никому не нужен.
WH>Взять хотябы местного евангилистасмаллталка... на чем он пишет... правильно на жабе
Автор: _vovin
Дата: 16.05.05
.

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

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

КП>Трурль wrote:

>> Здравствуйте, WolfHound, Вы писали:
>> Поставим вопрс по-другому. Стоит ли связываться с C#, если есть питон?
КП> стоит ли шить сапоги если мы уже умеем плести лапти?
КП>Питон безусловно хорошая вещь (это я по дискуссии сужу), но для своих
КП>целей. И как лапти хороши сегодня для сувенира иностранцу, так сапоги
КП>для того, чтобы использовать их в качестве обуви. В лаптях конечно тоже
КП>можно ходить (ну ходили же наши предки), но не далеко.
Вы когда-нибудь ходили в лаптях, для того чтобы утверждать что в них недалеко уйдешь?
КП>Да, конечно, прикольно не иметь статической типизации, все мочить в коде
КП>и т.д. Но это вряд ли сильно положительно скажется на простоте поддержки
КП>разрабатываемой системы, ее расширяемости, простоте отладки и т.д.
Может сказаться как отрицательно, так и положительно. Статическая типизация vs. динамическая типизация — топик далеко не так ясный, как Вы стараетесь его представить. Особенно в области скриптов для компьютерных игр, где традиционно используются такие языки как Lua
КП>Юнит-тесты это хорошо, но строгая типизация — куда более строгий
КП>инструмент.
Это Вас кто-то обманул. Те тесты, которые Вы делаете сам, компилятор НИКОГДА не сумеет провести автоматически.
КП>И вряд ли отсутствие типизации ускорит разработку, учитывая
КП>что юнит-тестов надо написать куда больше, плюс отлаживаться придется
КП>дольше.
Насчет юнит тестов тоже не вполне ясно. Время, потраченное на борьбу с типами можно с пользой потратить на написание тестов. Насчет отладки — это я не понял. Почему дольше ?
КП>Благо дизайн приложений уже довольно развит,
Это кто сказал ? Это Ваше личное мнение ?
КП>что дает
КП>дополнительный аргумент в пользу наличия типизации. Такие штуки,
КП>наверное, хороши для написания пакета утилит для администрирования и
КП>т.п. для собственного пользования. Но писать промышленную систему,
КП>которая будет здорово развиваться, я бы на них не стал.
Питон заводами управляет. Производством. Поинтересуйтесь.
КП>Что касается библиотеки, то да, .NET предлагает менее развитую в
КП>рассмотренных отношениях библиотеку. Но он ориентирован на разработку
КП>корпоративных приложений, автоматизации бизнеса, а не утилит и игр. Если
КП>есть специфическая потребность — ее надо осмыслить и один раз написать
КП>нужную библиотеку.
КП>Итого, всему свое место в жизни
Кстати, одним из главных преимуществ Питона я считаю встроенный тип данных — "словарь" (mapping, hashtable, как Вам больше нравится). Это не пустяк, это ОЧЕНЬ и ОЧЕНЬ серьезное преимущество.
Re[42]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 14.05.05 12:31
Оценка: :)))
Здравствуйте, Трурль, Вы писали:

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


Т>>>Чисто для прикола:

Т>>>
Т>>>"out.txt" 0: t[<t: 0: "text.txt"]
Т>>>

FR>>Ruby?
Т>Не, не Ruby. Это — Gaperton знает что.

"А это вообще gaperton-знает-что". Дожили — ругательство новое появилось . Такой язык можно только перебором определить, понятное дело, подсовывая код разным компиляторам, по другому no way.

Кстати, gaperton еще знает С++
Автор: Gaperton
Дата: 04.05.05
, до кучи .
Re[54]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 14.05.05 14:28
Оценка: +1 :))
Здравствуйте, WolfHound, Вы писали:

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


WF>>Я думаю, потому что никому нафиг не надо C++. Изображать LISP-ом C++ синтаксис — совершенно бесполезное занятие.

WF>>Вот тебе Pascal вместо C++:
WF>>http://arxiv.org/abs/cs.PL/0409016
WH>А отладчик и автокомплит на этом DSL работать будут?
А ты пробовал когда-нибудь встроить в свою программу среду разработки от MS и сделать из этого DSL? Хотя бы специально для этого предназначенный Visual Basic for Applications? А ты попробуй. Тогда понятно станет, почему большинство производителей предпочитают так не делать, не покупаясь на замануху вроде отладчика и автокомплита. Все эти мульки в результате проще самому написать.

Кстати, предупреждая ответы в духе "а вот .NET" — проект Visual Studio for Applications.NET свернут осенью прошлого года. Нет никакого дотнета . А прежде чем предлагать с каждой копией продукта тащить полноценный VS.NET подумайте о том, как это будет лицензироваться и сколько будет стоить вашему клиенту.
Re[73]: Python vs C#
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 18.05.05 16:13
Оценка: :)))
S>>> Ребята хотять создать свой движек,
S>>> http://1l.w4b.ru/
ANS>>http://1l.w4b.ru/?news_detail=80
ANS>>Питон. Еслиб на C# писали, может у них что и получилось бы, а так труп, однозначно
S> Вот здесь позволю несогласится. Основная задача у них это использование текущих конфигураций, а там аля васик, питон походит, правда как
См.смайлик. Это я так Влада подманиваю
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[64]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 19:26
Оценка: +3
Здравствуйте, L.C.R., Вы писали:

_>>Да все они давно обсуждены.


LCR>Дык я и хочу узнать, где они обсуждены... Искал-искал, ничего не нашёл. Про нуль только помню.


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

IDEA — круть. Посление навороты вообще офигеть. РеШарпер тоже круть. В связке с C# 2.0 будет супер-пупер-мега-круть. В Смолтоке тоже много чего интересного есть. Как и в Питоне с Руби в прочем.

Но к сожалению аргументы здесь не в ходу. Никто не хчет признать, что у его любимой игрушки крутые только отдельные фичи и есть серьезнейшие проблемы. Есть такие проблемы и у дотнета с Явой. И по мне так они круты не отдельными мегафичами, а комулятивным эффектом. Но поять таки все это пустые слвоа, так как никто со своих позиций не сойдет. _vovin при каждом удобном случае будет рекламировать Смолток. Гапертно ФЯ. FR Питон. ПК С++. Кто-то Руби... Ну, и я пока что остановлюсь на Шарпе с донетом (ну, или на дотнете с Шарпом во главе и всем остальным в придачу). Ты же как я понял остановился на Яве.

В общем, .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[52]: Python vs C#
От: missile Россия  
Дата: 02.06.05 10:28
Оценка: +3
Здравствуйте, VladD2, Вы писали:

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


FR>>Угу студия и решарпер просто незаменимы при написании программ длиной в пару строк, дают гигантское ускорение, я думаю процентов 500 точно


VD>Я правильно понимаю, что более высокоуровневые языки с более лАкОничными конструкциями нужно исключительно для написания программ в пару строк?



VD>ЗЫ


VD>В общем, согласен. Признаю... для написания "Хэлоу, уорд" Питон является идЕальным средством.


Вопрос к VladD2: неграмотность в каждом сообщении -- это такой прикол или же действительное незнание грамматики?
P.S. Мы вот используем Python для создания небольших утилит по преобразованию, конвертации, интеграции модулей -- и ок. И с поддержкой легче, чем с ++, и по кол-ву кода -- куда как меньше.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
Re[51]: Python vs C#
От: WolfHound  
Дата: 23.05.05 06:41
Оценка: 18 (1) +1
Здравствуйте, FR, Вы писали:

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

FR>ну до коммунизма пока далеко
Во-во...

FR>Угу студия и решарпер просто незаменимы при написании программ длиной в пару строк, дают гигантское ускорение, я думаю процентов 500 точно

При написании программ на 10 метров кода примерно так и происходит. Тут уже важнее не пара рюшечек в библиотеке которые можно за 15 минут сотворить, а автокомплит, рефакторинг, навигация по коду...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[49]: Python vs C#
От: WolfHound  
Дата: 23.05.05 07:45
Оценка: 18 (1) :)
Здравствуйте, FR, Вы писали:

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

Brainfuck это очень крутой язык для разработки, а его связка с мегаязыком Whitespace дает просто невероятные возможности.
Доказательством этого является то что эти языки вобще существуют.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: Python vs C#
От: eugals Россия  
Дата: 13.05.05 12:23
Оценка: 6 (2)
Здравствуйте, FR, Вы писали:

FR>По объему кода, вот простейшая программка считывает файл построчно и выводит его в другой файл отсортированным по строкам:

FR>
FR>arr = open("test.txt").readlines()
FR>arr.sort()

FR>out = open("out.txt", "w")
FR>for line in arr:
FR>    print >> out, line,
FR>


А теперь то же самое с использованием возможностей питона 2.4:
file("out.txt", "w").writelines(sorted(file("test.txt")))
... << RSDN@Home 1.1.4 beta 5 rev. 395>> {WinAmp: Whitney Houston — I Wanna Dance With Somebody (Who Loves Me)}
Re[37]: Python vs C#
От: FR  
Дата: 13.05.05 09:35
Оценка: 3 (1) :)
Здравствуйте, WolfHound, Вы писали:

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


WH>>>А я вот не знаю просвети не разумного.

FR>>знаешь
WH>Нет. Не знаю.

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

WH>Примеры в студию. Только мериться будем с C#2

По объему кода, вот простейшая программка считывает файл построчно и выводит его в другой файл отсортированным по строкам:
arr = open("test.txt").readlines()
arr.sort()

out = open("out.txt", "w")
for line in arr:
    print >> out, line,


Суммирование чисел из файла(в каждой строке файла одно число):
import sys, itertools
print sum(itertools.imap(int, open("in.txt")))


Другой пример я уже приводил Владу, простейший калькулятор(он из темы где вы с Владом спорили и ты делал этот же калькулятор на плюсах ссылки к сожалению не помню)
# -*- coding: cp1251 -*-
import psyco, time

from math import sin
from math import cos

formula =r"-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234"

ParseCount = 1
CalcCount  = 10000

#компилируем
t1 = time.clock()
for i in xrange(ParseCount):
    f = eval(compile("lambda asd, qwe : " + formula, "<string>", "eval"))
    psyco.bind(f)
t2 = time.clock()
print "Парсинг %d проходов. Выполнено за %f сек." % (ParseCount, t2 - t1)

#используем
def run():
    t1 = time.clock()
    for i in xrange(1, CalcCount + 1):
        f(i, i)
    t2 = time.clock()
    print "Подсчет %d проходов. Выполнено за %f сек."  % (CalcCount, t2 - t1)

psyco.bind(run)

run()
run()

print "f(1, 1,) =", f(1, 1)
print "f(-1, 333) =", f(-1, 333)
Re[47]: Создание игр на managed-языках
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.05.05 11:20
Оценка: 1 (1) +1
Здравствуйте, WolfHound, Вы писали:

FR>>Тем более пока C#2 нет,

WH>Уже есть бета 2
FR>>а переносимые варианты появятся еще позже.
WH>Микрософт перенесет его везде где есть винда очень быстро. А всякие линухи лично меня не волнуют.

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

WH>Очень обманчивое "преймущество". Взять тотже "Vampire: The Masquerade Bloodlines" блин все руки надо пообравать этим горе программерам которые эти скрипты писали.

WH>Замет все задается строками и магическими числами. И так везде.
WH>
WH>def mercurioFight():
WH>    npc = Find("Mercurio")
WH>    pc = __main__.FindPlayer()
WH>    state = pc.GetQuestState("Astrolite")
WH>    if(state == 5):
WH>        npc.SetModel("models/character/npc/unique/Santa_Monica/Mercurio/Mercurio.mdl")
WH>        npc.SetDisposition("Neutral", 1)
WH>        teleporter = Find("healthy_mercurio_spot")
WH>        teleporter.Teleport()
WH>        script = Find("mercurio_turn_around")
WH>        script.StartSchedule()
WH>        trigger = Find("mercurio_angry_talk_trigger")
WH>        trigger.Enable()
WH>        journal = Find("mercurio_journal")
WH>        journal.ScriptUnhide()
WH>        sparklies = Find("journal_sparklies")
WH>        sparklies.ScriptUnhide()
WH>    if(__main__.IsDead("Mercurio")):
WH>        npc.Kill()
WH>

WH>Представляю сколько времени они это отлаживали... Ведь одна опечатка в одном строковом литерале и...

+1

Кстати да, очень часто в скриптовых программках натыкаешься на такой hard-coding. Это не значит, что на Python-е (Ruby) нельзя писать без hard-coding-а (равно как на C++, Java и C# легко писать с hard-coding-ом). Но часто именно на такой код нарываешься.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
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[40]: Python vs C#
От: Cyberax Марс  
Дата: 13.05.05 14:36
Оценка: +1 -1
FR wrote:

> AVK>А закрывать файлы кто будет?

> GC
> Вообще на питоне если на файл ссылок нет он сразу после использования
> закрывается.

Это если в Питоне используется подсчет ссылок вместо настоящего GC, что
далеко не всегда правда.

Вообще, за такой код (с утечками ресурсов) я бы отрывал головы...

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[41]: Создание игр на managed-языках
От: Gaperton http://gaperton.livejournal.com
Дата: 13.05.05 19:20
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

FR>>А отсутствие типизпции может быть и преимуществом.

WH>Да правда чтоли? Интересно почему тогда весь мейнстрем типизированый по самое нехочу?
Да правда чтоли? VB со своим IDispatch, JScript, PHP, Perl и ваш любимый C# c контейнерами Object-ов — типизированны по самое нехочу?
Re[39]: Python vs C#
От: FR  
Дата: 13.05.05 19:41
Оценка: -1 :)
Здравствуйте, Gaperton, Вы писали:

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


G>Не самый удачный пример. В шарпах нет лямбда-функций, встроенных списков и (соответственно) list comprehensions (for in, использующиеся для преобразований/формирований списков). Если ты построишь пример на этих свойствах языка, C# будет порван. Возьми какой-нибудь алгоритм, выполняющий преобразования деревьев. Не бинарных, а произвольных. Деревья моделируй списками списков. Используй for-in и лямбду (как параметр generic-функциям). Если текст выражения лямбды в питоне допускает ссылки на локальный контекст (я насчет этого не в курсе), будет еще лучше.


Не надо по деревьям лазить, достаточно брать любую небольшую утилитку активно работающую с текстовыми файлами, объем кода будет сильно меньше чем на плюсах или шарпе, близко к объему на перле, но в отличии от перла не write-only а вполне читабельный код.
Re[42]: Python vs C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.05.05 07:06
Оценка: +2
Здравствуйте, FR, Вы писали:
FR>from turtle import *
Боюсь, что как только заходит речь об import, то практически любой язык общего назначения будет выглядеть одинаково. Разница только в количестве и разнообразии доступных библиотек.
Мериться составом RTL в этом смысле не очень показательно. Показательно сравнивать затраты на подготовку этих библиотек; или сравнивать состав стандартной поставки с точки зрения некоторой группы задач. Ну, вот скажем, Cw на порядок лаконичнее C# при работе с XML и SQL. А вот задача копирования группы файлов элегантнее решается на языке командной строки DOS (не говоря уже о более продвинутых шеллах).
Кстати, раз уж речь зашла:
sort < out.txt > out2.txt

... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[42]: Создание игр на managed-языках
От: WolfHound  
Дата: 14.05.05 07:45
Оценка: -1 :)
Здравствуйте, FR, Вы писали:

FR>А читать потом этот код тоже автокомплит будет?

Учтитывая особенности человеческого чтения это не есть проблема.
К томуже статически типизированые языки позволяют создавать утилиты для рефакторинга. Нука покажи мне аналог ReSharper'а для питона...

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

Знаешь я лучше буду пользоваться шаблоными чем терпеть выходки питона. То он переменную сам объявит то...
FR>А для решения проблем с нетипизированностью есть специальные утилиты проверяющие корректность кода, например тот же PyChecker.
Вот еще ползоваться какимито левыми утилитами если можно взять нормальный язык.

FR>Скорее с потоками, а файлы так на закуску.

А смысл?

FR>Угу чтобы пару строк кода написать будешь переключатся на другой язык.

Если мне понадобится что-то хитровывернутое то я какнибудь обойдусь.

FR>Так библиотеки еще и написать надо.

Не надо. Ибо толку от них всеравно не будет.

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

Дело в том что все скрипты в играх будут выглядеть примерно так как я показал. Те возможностей C#2 для них выше крыши.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: Python vs C#
От: WFrag США  
Дата: 14.05.05 08:56
Оценка: +2
Здравствуйте, FR, Вы писали:

FR>Пока ты будешь писать свой пробельный язык я давно уже решу эту же задачу одной строкой кода в питоне. Разработку питон сильно ускоряет.


Да, зато DSL (Domain Specific Language) по времени выгоднее. Стоимость старта определенно выше, зато из-за того, что DSL лучше подходит под решение задачи (собственно, для этого он разрабатывается), стоимость разработки на DSL ниже.

Есть вообще мнение, что выгоднее вместо General Purpose Languages использовать DSL и развитие в ближайшем будущем должно идти в сторону удешевления создания DSL.
Re[41]: Python vs C#
От: Трурль  
Дата: 14.05.05 09:20
Оценка: :))
Здравствуйте, FR, Вы писали:

Т>>Чисто для прикола:

Т>>
Т>>"out.txt" 0: t[<t: 0: "text.txt"]
Т>>

FR>Ruby?
Не, не Ruby. Это — Gaperton знает что.
FR>По моему питон читабельней, хотя Ruby тоже не плох
Согласен и с тем, и с другим.
Re[43]: Python vs C#
От: WolfHound  
Дата: 14.05.05 10:08
Оценка: +2
Здравствуйте, eugals, Вы писали:

E>"перестановка, упорядочивающая файл"?

E>Что тут написано? Попробовал подсунуть этот текст Эрлангу и Хаскелю — они его не поняли. Какой ещё язык Гапертон знает? Clean что ли?
Я думаю К
Автор: Трурль
Дата: 19.04.05
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: Создание игр на managed-языках
От: Cyberax Марс  
Дата: 14.05.05 10:33
Оценка: +2
FR wrote:

> WH>На что спорим что я на питоне закриптую программу так что ты в ней

> озвереешь разбираться.
> Конечно напишешь Но суть в том что создатели java и C# выкинув
> процедурный стиль просто принуждают из простейших вещей делать криптокод.

Объясните, что вы понимаете под "процедурным стилем"? Код с глобальными
переменными и фукнциями?

> WH>Есть очень большая проблема: Отсутствие статической типизации.

> Чем ее отсутствие помешает преименовыванию методов и т. п.

Вот такой код:
class Test
    def test_method(self):
       ...
...
tst=some_external_function()
tst.test_method()

Предположим, что код класса "Test" и переменная tst расположены в разных
файлах в большом проекте из 5000 классов. Как нам теперь переименовать
метод test_method в new_test_method?

В языках со статической типизацией все просто — переименовываем метод и
компилируем программу, а потом по сообщениям об ошибках находим все
точки использования метода test_method. Или если язык достаточно просто
(типа Java или C#), то IDE может проанализировать код и заменить все без
перекомпиляции.

> WH>Что называется почувствойте разницу.

> и что?

А то, что с ReShaper'ом или IDEA "производительность" получается ничуть
не хуже, чем у питонистов.

> WH>Сомнительное преймущество.

> угу также как и шаблоны в плюсах

Темплейты в С++ — это огромное его преимущество, и ничуть не сомнительное.

> Может наоборот? Тем более пока C#2 нет, а переносимые варианты

> появятся еще позже.

Переносимый вариант (Mono) выйдет через пол-года.

> А связыватся стоит, так как портировать питон и настраивать под

> определенную задачу гораздо легче чем шарп, и памяти он кушает намного
> меньше.

Не факт.

> FR>>и как плюс они будут короче и понятней, осбенно настроечные

> скрипты с которыми работают дизайнеры, то есть те кто мало разбирается
> в кодировании.
> WH>Сильно сомневаюсь
> зря, только то, что питон подерживает процедурный стиль уже гигантское
> упрощение, код можно писать без всякой обвязки, и читатся он будет не
> сложнее чем ini файл.

Только если при этом он будет делать примерно то же, что и "hello world".

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[46]: Создание игр на managed-языках
От: WolfHound  
Дата: 14.05.05 11:05
Оценка: -2
Здравствуйте, FR, Вы писали:

FR>Конечно напишешь Но суть в том что создатели java и C# выкинув процедурный стиль просто принуждают из простейших вещей делать криптокод.

Может уже пора писать в объектно-ориентированом стиле?

FR>Чем ее отсутствие помешает преименовыванию методов и т. п.

Ну попробуй переименовать функцию some принимающею три параметра типов int, float, string сласса foo. Причем так чтобы ничего не поломалось ни при каких наворотах в коде.

WH>>ReSharper не проверяет код. Он помогает его набивать, модифицировать и осуществлять навигацию. Те это часть IDE, а не компилятора.

WH>>Что называется почувствойте разницу.
FR>и что?
А то что ReSharper не берет на себя функции компилятора по проверки программы на наличие ошибок.

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

Не знаю как там у тебя но у меня при малейшей нестыковки программа просо не компилируется. И не нужны мне никакие варнинги.

FR>Тем более пока C#2 нет,

Уже есть бета 2
FR>а переносимые варианты появятся еще позже.
Микрософт перенесет его везде где есть винда очень быстро. А всякие линухи лично меня не волнуют.
FR>А связыватся стоит, так как портировать питон
Ну для того чтобы портировать .НЕТ надо только прекомпилировать JIT и GC под конкретную платформу. А библиотеки те что чисто managed портируются автоматически.
FR>и настраивать под определенную задачу гораздо легче чем шарп,
Это чем же?
FR>и памяти он кушает намного меньше.
Ой да брось ты. .НЕТ жрет памяти сколько винде не жалко. Но как только винде понадобится память .НЕТ ее отдает еще до того как винда потянит свои ручки к свопу.

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

Ну в программе из 10 строк это можно заметить. А вот в программе на несколько мегабайт исходников ты это и под микроскопом не увидишь.
FR>код можно писать без всякой обвязки, и читатся он будет не сложнее чем ini файл.
Очень обманчивое "преймущество". Взять тотже "Vampire: The Masquerade Bloodlines" блин все руки надо пообравать этим горе программерам которые эти скрипты писали.
Замет все задается строками и магическими числами. И так везде.
def mercurioFight():
    npc = Find("Mercurio")
    pc = __main__.FindPlayer()
    state = pc.GetQuestState("Astrolite")
    if(state == 5):
        npc.SetModel("models/character/npc/unique/Santa_Monica/Mercurio/Mercurio.mdl")
        npc.SetDisposition("Neutral", 1)
        teleporter = Find("healthy_mercurio_spot")
        teleporter.Teleport()
        script = Find("mercurio_turn_around")
        script.StartSchedule()
        trigger = Find("mercurio_angry_talk_trigger")
        trigger.Enable()
        journal = Find("mercurio_journal")
        journal.ScriptUnhide()
        sparklies = Find("journal_sparklies")
        sparklies.ScriptUnhide()
    if(__main__.IsDead("Mercurio")):
        npc.Kill()

Представляю сколько времени они это отлаживали... Ведь одна опечатка в одном строковом литерале и...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[53]: Создание игр на managed-языках
От: genre Россия  
Дата: 16.05.05 16:45
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

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


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

S>Именно. В чем цель и состоит.
ага. зато потестить кусок функционала не получится.
уж лучше совместить warning и exception
... << RSDN@Home 1.1.4 beta 4 rev. 0>>
Re[70]: Python vs C#
От: L.C.R. Россия lj://_lcr_
Дата: 18.05.05 10:41
Оценка: +2
WolfHound,

LCR>>Видишь — ненулевая! Даже по сравнению.

WH>Дык Апач в отличии от смаллтолка бесплатный. По тому и держится.

Оу, кмон. Будет комьюнити, будет и бесплатные среды, и бесплатные продукты. А если комьюнити будет достаточно большим и бурно развивающимся, то эти продукты не будут уступать коммерческим ни в чём. И дальше оно покатится как снежный ком: появятся и рабочие места, и программисты и решения на этой базе и т.д. и т.п.

Всё что нужно смоллтоку — это сформировать комьюнити вокруг себя. А я так понимаю, оно уже есть, и вроде как растёт (хотя и медленно). Так что поживём — увидим.

LCR>>Лучше найти себе что-нибудь красивое, и шлифовать своё мастерство одновременно получая и пользу, и удовольствие.

WH>Ты с этим предложением опоздал. Мне давно не интересно сидеть и что-то просто так шлифовать.

Если ты перестал стремиться к красоте — ты пропал!
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[76]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.05.05 15:14
Оценка: +2
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Если программа не запускается под поддерживаемой(!) ОС, то фича это или баг — вопрос натурально философский. Как по мне, то в 21 веке прикладных программ не работающих из под простого пользователя быть уже не должно.


Расскажи это МС, которая сделала так, что СОМ сервер можно зарегистрировать только из под администратора.

AVK>>1) Добавить ключик, который блокирует регистрацию протокола. Но при смене версий придется этот ключик руками отключать и включать.

AVK>>2) Отказаться от поддержки протокола вне процесса януса.

ANS>На кой ляд он вообще нужен?


Некоторым удобно.

AVK>>3) Вынести регистрацию протокола в инсталлятор.


ANS>С этим то какие проблемы? Всё равно инсталятор есть.


Проблема ровно одна — при этом янус лишится одного очень вкусного свойства, а именно deploy by copy.
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[46]: Python vs C#
От: FR  
Дата: 23.05.05 06:17
Оценка: :))
Здравствуйте, 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 <...>)
Re[53]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.06.05 22:15
Оценка: -2
Здравствуйте, missile, Вы писали:

M>Вопрос к VladD2: неграмотность в каждом сообщении -- это такой прикол или же действительное незнание грамматики?


Кагда как. Но точно известно, что разговоры на эту тему приводят в баню. Пункт 5... знаете ли...

M>P.S. Мы вот используем Python для создания небольших утилит по преобразованию, конвертации, интеграции модулей -- и ок.


А мы для тех же целей испоьзуем C# и вроде тоже все ОК.

M> И с поддержкой легче, чем с ++, и по кол-ву кода -- куда как меньше.


Чем С++? Бесспорно! А вот по сравнению с Шарпом уже очень и очень спорно.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[52]: Python vs C#
От: WFrag США  
Дата: 14.05.05 13:39
Оценка: 18 (1)
Здравствуйте, Cyberax, Вы писали:

C>Мне С++ный, пожалуйста... А на практике — LISP получается


Я думаю, потому что никому нафиг не надо C++. Изображать LISP-ом C++ синтаксис — совершенно бесполезное занятие.

Вот тебе Pascal вместо C++:

http://arxiv.org/abs/cs.PL/0409016

И делается это проще, чем, например комбинация: XML->XML Parser->DOM Model->Lots of Java code->CGLIB->Java byte code для какого-нибудь DSL, например, для ORM mapping-а. А если отбросить парсер и оставить скобочный синтаксис — так и еще проще, не нужно XML в скобки превращать

Но речь не о LISP-е идет. Это один из возможных примеров.
... << RSDN@Home 1.1.4 beta 6a rev. 438>>
Re[52]: Python vs C#
От: FR  
Дата: 21.05.05 09:00
Оценка: 5 (1)
Здравствуйте, AndrewVK, Вы писали:


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


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

AVK>>>Это отступление от условий задачи. В условиях было сказано что в качестве аргументов передается имя файла, а не поток. Да ты сам написал что перевел почти дословно, и именно дословный перевод я и увидел.



AVK>Ну вот никакой экономии и нет. Те же яйца вид в профиль.


Угу тогда C++ тоже ни чем ни уступает шарпу:

string ReadCharBlock(int length, istream &fin)
{
vector<char> buf(length);
fin.read(&buf[0], length);
return string(buf.begin(), buf.end());
}

void FillFromHashToDisk(string file, map<string, string> &props)
{
 string currentKey = "";
 ifstream fin(file.c_str(), ios::binary);
 while(!fin.eof())
  {
  string tag; getline(fin, tag);
  if(tag == "END") return;
  vector<string> parts;
  if(split(parts, tag, is_space()).size() > 1)
    {  
    if(parts[0] == "K")
        currentKey = ReadCharBlock(lexical_cast<int>(parts[1]), fin);
    else if(parts[0] == "V")
        props[currentKey] = ReadCharBlock(lexical_cast<int>(parts[1]), fin);
    }    
  }
}
Re[69]: Python vs C#
От: WolfHound  
Дата: 18.05.05 08:51
Оценка: 4 (1)
Здравствуйте, L.C.R., Вы писали:

LCR>Видишь — ненулевая! Даже по сравнению.

Дык Апач в отличии от смаллтолка бесплатный. По тому и держится.
К томуже там написано Across All Domains те включая странички Васей Пупкиных с содержанием

Линух 4ever!!! Мелкософт на свалку!!

Причем эни это не сами придумали, а наслушались "кулхацкеров".

LCR>Поэтому не вижу смысла фанатеть за мэйнстрим вообще.

А я не фанатею просто реально смотрю на вещи.
LCR>Лучше найти себе что-нибудь красивое, и шлифовать своё мастерство одновременно получая и пользу, и удовольствие.
Ты с этим предложением опоздал. Мне давно не интересно сидеть и что-то просто так шлифовать.
А получать пользу со смаллталка не реально ибо он нафиг никому не нужен.
Взять хотябы местного евангилистасмаллталка... на чем он пишет... правильно на жабе
Автор: _vovin
Дата: 16.05.05
.
Если уж фанатик не может найти работу то как мне простому программеру найти работу на которой можно писать на смаллталке?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[46]: Python vs C#
От: FR  
Дата: 19.05.05 19:08
Оценка: 4 (1)
Здравствуйте, AndrewVK, Вы писали:


AVK>Вот рабочий алгоритм на первом шарпе:

AVK>
AVK>private void FillFromHashToDisk(string file, IDictionary props)
AVK>{
AVK>    string currentKey = "";
AVK>    using (StreamReader sr = new StreamReader(file))
AVK>        while (true)
AVK>        {
AVK>            string tag = sr.ReadLine();
AVK>            if (tag == "END")
AVK>                return;
AVK>            string[] parts = tag.Split(' ');
AVK>            if (parts[0] == "K")
AVK>                currentKey = ReadCharBlock(int.Parse(parts[1]), sr);
AVK>            else if (parts[0] == "V")
AVK>                props[currentKey] = ReadCharBlock(int.Parse(parts[1]), sr);
AVK>        }
AVK>}

AVK>private static string ReadCharBlock(int length, StreamReader sr)
AVK>{
AVK>    char[] buffer = new char[length];
AVK>    sr.Read(buffer, 0, length);
AVK>    return new string(buffer);
AVK>}
AVK>


Понятно меня просто смутило то что файл читается как бинарный без корректировки концов строк.А так оно почти дословно перепишется:
def FillFromHashToDisk(fin):
    props = {}
    key = ""
    while True:
        tag = fin.readline();
        if tag[:3] == "END": break
        parts = tag.split(' ')
        if parts[0] == "K":
            key = fin.read(int(parts[1]))
        elif parts[0] == "V":
            props[key] = fin.read(int(parts[1]))
    return props        
        
print FillFromHashToDisk(file("data.txt", "rb"))

Да и вообще и на C++ с бустом также почти дословно перейдет. Хотя на питоне все равно чуть короче
Re: Python vs C#
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.05.05 12:41
Оценка: 4 (1)
Появилось интервью с Guido van Rossum -- автором языка Python.

Мне в нем понравились две вещи (имхо, они в контексте обсуждавшихся в этой ветке проблем):

I currently work for Elemental Security -- a startup in California. We have created a large server/agent based security application that can monitor and manage the security configuration settings and network traffic of hosts on a large enterprise network. I've written a large part of the agent code in Python.


Это к тому, что Python (я думаю, как и Ruby, и Perl) вполне могут применяться для больших проектов. Нужно их только уметь готовить

We're currently designing a new compound statement that lets you code resource acquisition and release pairs (such as acquiring and releasing a lock, or opening and closing a file) in a way that guarantees the release always happens without having to write a try-finally statement. Look at the recent python-dev summaries (http://www.python.org/dev/summary/) to find out more


Это по поводу обсуждавшихся проблем про закрытие файлов и т.п. Видимо с этим в Python-е ситуация наладится.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[62]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 17.05.05 07:27
Оценка: 3 (1)
L.C.R. wrote:
> _vovin,
>
> _>Никакие удобные рюшки не помогают прикрыть убогость языка и, особенно, типичных решений на нем.
>
> (подбираю слова, как бы сформулировать вопрос)
> (смотрю в словарь что такое "убогий")
> (грустно)
> (наконец решаюсь задать вопрос)
>
> Хотя бы парочку примеров убогости и ещё парочку неудовлетворительных типичных решений.
>
> Кроме null.

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

Вот, недавно, записал пример наркотического сеанса (4.23МБ):
http://www.smalltalk.ru/downloads/DolphinBouncingBalls.zip
Posted via RSDN NNTP Server 1.9
Re[65]: Python vs C#
От: Cyberax Марс  
Дата: 27.05.05 14:15
Оценка: 2 (1)
EvilChild wrote:

> C>Нет, у нас код из-за COM не разрастается (используем Comet вместо ATL),

> C>да и организация интерфейсов в OLE достаточно разумная.
> Можешь поделиться впечатлениями об использовании Comet?
> С точки зрения дизайна он мне показался красивее ATL'я.

Работает нормально, никаких претензий. Единственное НО: его
кодогенератор лучше не использовать для неOLE-интерфейсов.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[67]: Python vs C#
От: Cyberax Марс  
Дата: 30.05.05 10:51
Оценка: 2 (1)
EvilChild wrote:

> C>Работает нормально, никаких претензий. Единственное НО: его

> C>кодогенератор лучше не использовать для неOLE-интерфейсов.
> Ты имеешь в виду его tlb2h?

Да.

> Он у меня споткнулся на объектной модели ворда, как вы такие вещи

> объезжаете?

Исключаем проблемные классы. Если эти классы нужны, то руками пишем
обертки по образу и подобию автосгенерированных. Кстати, объектная
модель из Outlook'а у меня вполне нормально импортировалась.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[45]: Python vs C#
От: FR  
Дата: 14.05.05 06:32
Оценка: 1 (1)
Здравствуйте, Cyberax, Вы писали:

C>FR wrote


>> Тут есть небольшой UB, так как документация не гарантирует такое

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

C>_Уже_ поменяли в Jython и IronPython (или как его там зовут). Когда

C>выйдет Parrot, то поменяют и в обычном Питоне.

Как я уже писал разработчики Jython лентяи уже с 2001 года не могут новую версию сделать. А IronPython еще глубокая альфа.
Re[47]: Python vs C#
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.05.05 08:17
Оценка: 1 (1)
Здравствуйте, WolfHound, Вы писали:

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


FR>>Я понимаю конечно что иногда очень сильно тянет кого нибудь поучить, сам

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

Имхо, зря тут на FR наехали по поводу кода
arr = open("test.txt").readlines()
arr.sort()

out = open("out.txt", "w")
for line in arr:
    print >> out, line,


Ведь насколько я понимаю, это полностью готовая программа на Python-е. Ее можно отдать Python-у и он ее выполнит. Т.е. это не выдранный откуда-то фрагмент, который нуждается в оборачивание в какой-нибудь import+class+main().

А для данного конкретного случая -- чтение одного файла, сортировка его содержимого и запись в другой файл -- это вполне корректное решение. Т.к. после завершения обработки этого скрипта Python корректно закроет все открытые файлы.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[63]: Python vs C#
От: Cyberax Марс  
Дата: 16.05.05 11:14
Оценка: 1 (1)
Gaperton wrote:

> C>А он мне не нужен, мне было нужно несколько инстансов VBA в одном

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

У этого MT VBA слишком большая куча глюков, чтобы его нормально
использовать.

> C>Теоретик.... OLE — это ведь не просто три буквы, это и определенная

> C>организация приложения, и КУЧА интерфейсов. Все это скрещивать с Явой —
> C>ну уж нет, лучше на старом добром С++.
> Да где уж нам до практиков.
> 1) COM для вас превратится в три не простых, а очень веселых буквы
> (разрастание кода вдвое), как только выльется в "определенную
> организацию приложения" на "старом добром с++".

Нет, у нас код из-за COM не разрастается (используем Comet вместо ATL),
да и организация интерфейсов в OLE достаточно разумная.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
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[35]: Python vs C#
От: FR  
Дата: 13.05.05 08:52
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

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


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

WH>Значит надо смотреть что они там делают.

FR>>так ты сам должен лучше меня знать

WH>А я вот не знаю просвети не разумного.

знаешь

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

WH>Это в каком это месте на питоне писать проще чем на C#? Просвети пожалуйста. И еще не забывай что для C# есть такие мегарулезы как ReSharper у меня по началу создавалось впечатление что эта штука мои мысли читает.

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

WH>А если Влад доведет до рабочего состояния R# то это вобще будет супер.
Re[40]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.05.05 12:34
Оценка: :)
Здравствуйте, FR, Вы писали:

FR>Вообще на питоне если на файл ссылок нет он сразу после использования закрывается.


Т.е. GC запускается на каждую строчку кода?
... << RSDN@Home 1.1.4 beta 7 rev. 453>>
AVK Blog
Re[43]: Python vs C#
От: eugals Россия  
Дата: 13.05.05 13:52
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

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


AVK>>>Т.е. GC запускается на каждую строчку кода?


E>>такого GC как в CLR — нет.

E>>Банальный счетчик ссылок.

AVK>Как в VB6?

Похоже, но не совсем. Отличия:
1. В VB6 есть разделение на value-типы и на объектные, а в питоне всё есть объект, соответственно и счетчик тоже висит на всём подряд.
2. Есть детектор циклов (запускается время от времени и убивает зависшие объекты).

Правда, этот детектор хорош только если вся программа написана на чистом питоне — безо всяких сиплюсплюсных библиотек
... << RSDN@Home 1.1.4 beta 5 rev. 395>> {WinAmp: Faith No More — We Care a Lot [Original Version]}
Re[41]: Python vs C#
От: Cyberax Марс  
Дата: 13.05.05 14:37
Оценка: +1
AndrewVK wrote:

> FR>Вообще на питоне если на файл ссылок нет он сразу после

> использования закрывается.
> Т.е. GC запускается на каждую строчку кода?

Просто считаются ссылки. Кольцевые структуры потом подбираются настоящим GC.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[38]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 13.05.05 16:07
Оценка: -1
Здравствуйте, FR, Вы писали:

Не самый удачный пример. В шарпах нет лямбда-функций, встроенных списков и (соответственно) list comprehensions (for in, использующиеся для преобразований/формирований списков). Если ты построишь пример на этих свойствах языка, C# будет порван. Возьми какой-нибудь алгоритм, выполняющий преобразования деревьев. Не бинарных, а произвольных. Деревья моделируй списками списков. Используй for-in и лямбду (как параметр generic-функциям). Если текст выражения лямбды в питоне допускает ссылки на локальный контекст (я насчет этого не в курсе), будет еще лучше.
Re[42]: Создание игр на managed-языках
От: FR  
Дата: 13.05.05 19:22
Оценка: :)
FR>Здравствуйте, WolfHound, Вы писали:

Да еще пример про калькулятор если не нужен jit и замеры, тоже сильно упрощается:
# -*- coding: cp1251 -*-
from math import sin
from math import cos

formula =r"-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234"

print "f(1, 1,) =", eval(compile("lambda asd, qwe : " + formula, "<string>", "eval"))(1, 1)


библиотек кроме math нет, да и кода реально одна строка.
Re[39]: Python vs C#
От: FR  
Дата: 13.05.05 19:22
Оценка: :)
Здравствуйте, eugals, Вы писали:

E>А теперь то же самое с использованием возможностей питона 2.4:

E>
E>file("out.txt", "w").writelines(sorted(file("test.txt")))
E>


Я пока на 2.3 сижу, просто не увидел в 2.4 каких то больших преимуществ из-за которых стоило бы переходить. Да про writelines я забыл, с ним проще

arr = open("test.txt").readlines()
arr.sort()
open("out.txt", "w").writelines(arr)


Еще можно так:
arr = open("test.txt").readlines()
arr.sort()
print >> open("out.txt", "w"), "".join(arr)


Но такой вариант подтормаживает на больших файлах, тогда как первый работает со скоростью сишных программ.
Re[43]: Python vs C#
От: FR  
Дата: 14.05.05 06:31
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>FR wrote:


>> C>Вообще, за такой код (с утечками ресурсов) я бы отрывал головы...

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

C>Да, а если этот кусок кода выполняется в цикле 10000 раз? Что _тогда_

C>будет? А если вместо открытых файлов — соединения с БД (количество
C>которых, кстати, весьма ограничено)?

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

import win32api, os

class Test:
    def __del__(self):
        win32api.MessageBox(0, "test", "test")
        
tst = Test()
Re[44]: Python vs C#
От: Cyberax Марс  
Дата: 14.05.05 06:52
Оценка: +1
FR wrote:

> Если у бабушки будет ... то это уже будет дедушка.

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

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

> деструктроы вызываются(документация это гарантирует). И вот этот

> пример тоже всегда срабатывает:

Деструкторы не всегда вызываются _сразу_ при выходе из блока. Делаем
такой пример:
class Test:
    def crashIt(self):
       cyclic=self
       db_connection=connect_to_database(...)
tst=Test()

Все! Теперь соединение к БД будет существовать до запуска детектора
циклов (или сборщика мусора), а за это время вполне могут быть
израсходованы все соединения к БД.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[46]: Python vs C#
От: Cyberax Марс  
Дата: 14.05.05 06:56
Оценка: +1
FR wrote:

> C>_Уже_ поменяли в Jython и IronPython (или как его там зовут). Когда

> C>выйдет Parrot, то поменяют и в обычном Питоне.
> Как я уже писал разработчики Jython лентяи

Они не лентяи, просто недетерминированая финализация — почти что
фундаментальное свойство GC.

> уже с 2001 года не могут новую версию сделать. А IronPython еще

> глубокая альфа.

В новых версиях поведение деструкторов вряд ли поменяется, так как
подсчет ссылок (который сейчас используется в CPython'е) — чрезвычайно
тормозной.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[45]: Python vs C#
От: FR  
Дата: 14.05.05 07:13
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>FR wrote:


>> Если у бабушки будет ... то это уже будет дедушка.

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

C>У меня большая часть программ работают днями (серверный софт). Даже

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

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

>> деструктроы вызываются(документация это гарантирует). И вот этот

>> пример тоже всегда срабатывает:

C>Деструкторы не всегда вызываются _сразу_ при выходе из блока. Делаем


В том примере необходимости вызова деструкторов сразу после выхода из блока
(вернее строки) нет.

C>такой пример:

C>
C>class Test:
C>    def crashIt(self):
C>       cyclic=self
C>       db_connection=connect_to_database(...)
C>tst=Test()
C>

C>Все! Теперь соединение к БД будет существовать до запуска детектора
C>циклов (или сборщика мусора), а за это время вполне могут быть
C>израсходованы все соединения к БД.

C>Это упрощенный пример, в реальных приложениях такие утечки обычно

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

Я понимаю конечно что иногда очень сильно тянет кого нибудь поучить, сам
этим изредка страдаю, но извини не стоит раздувать из мухи слона, и превращать
вполне корректный пример в повод демонстрировать конец света.
Re[44]: Создание игр на managed-языках
От: WolfHound  
Дата: 14.05.05 09:08
Оценка: +1
Здравствуйте, FR, Вы писали:

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

На что спорим что я на питоне закриптую программу так что ты в ней озвереешь разбираться.

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

Есть очень большая проблема: Отсутствие статической типизации.

FR>Сам не объявит

За то очепятка очень даже может...

FR>Так ты же пользуешся левой утилитой ReSharper?

ReSharper не проверяет код. Он помогает его набивать, модифицировать и осуществлять навигацию. Те это часть IDE, а не компилятора.
Что называется почувствойте разницу.
FR>Раньше и для си был lint очень похож на PyCheker.
Вот только когда пишешь на С++ потребности во всяких lint'ах почемуто не возникает. Может из-за статической типизации?

FR>Проще писать программы, интерфейс файловых объектов стандартен, легко писать процедуры работающие с любыми файловыми объектами,

В .НЕТ тоже решается библиотекой.
FR>при этом для своих файловых объектов не требуется наследование от базового класса.
Сомнительное преймущество.

FR>Я видел скрипты из реальных игр,

Я тоже.
FR>и очень небольшая часть их выглядит также.
Ну не знаю например скрипты в "Vampire: The Masquerade Bloodlines" выглядят так как я показал. И не смотря на то что они написаны на питоне ниодной питоновской мегафичи я там не видел.
FR>Возможностей питона для них тоже вполне хватает,
Я с этим и не спорю вот только стоит ли связываться с питоном если есть C#2
FR>и как плюс они будут короче и понятней, осбенно настроечные скрипты с которыми работают дизайнеры, то есть те кто мало разбирается в кодировании.
Сильно сомневаюсь
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[45]: Создание игр на managed-языках
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.05.05 09:46
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

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

WH>Есть очень большая проблема: Отсутствие статической типизации.

Здесь была большая тема по этому поводу: Типизация
Автор: Quintanar
Дата: 02.03.05

Причем начинал я в ней учавствовать стоя на таких же непримиримых позициях сторонника статической типизации.
Но затем стал более лояльным к таким динамическим языкам как Pyhton (убрать бы все-таки из него структуризацию посредством пробелов!) и Ruby. Имхо, динамическая типизация -- это интересная возможность. Просто нужно к ней по другому подходить. Ни и не для всех задач, имхо, она пригодно. Например, мне было бы стремно писать маршрутизатор SMS-трафика на Ruby именно из-за того, что я не смогу создать достаточное количество unit-тестов, чтобы весь код проверить (а сторонники динамически-типизированных языков часто приводят в качестве довода то, что нельзя доверять коду, который не был протестирован). А в случае статически типизированного языка я хотя бы могу быть уверен в отсутствии синтаксических ошибок даже в самых редкоиспользуемых ветвях моего кода. Но для небольших программ тот же Ruby может дать существенный прирост производительности в кодировании. А если к этому добавить, что сложные задачи можно решать правильно комбинируя простые и маленькие инструменты (т.н. unix way), то получается, что из маленьких Python (Ruby, Perl,...) скриптиков можно строить весьма сложные решения.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[45]: Создание игр на managed-языках
От: FR  
Дата: 14.05.05 10:13
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

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


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

WH>На что спорим что я на питоне закриптую программу так что ты в ней озвереешь разбираться.

Конечно напишешь Но суть в том что создатели java и C# выкинув процедурный стиль просто принуждают из простейших вещей делать криптокод.

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

WH>Есть очень большая проблема: Отсутствие статической типизации.

Чем ее отсутствие помешает преименовыванию методов и т. п.

FR>>Сам не объявит

WH>За то очепятка очень даже может...

FR>>Так ты же пользуешся левой утилитой ReSharper?

WH>ReSharper не проверяет код. Он помогает его набивать, модифицировать и осуществлять навигацию. Те это часть IDE, а не компилятора.
WH>Что называется почувствойте разницу.

и что?

FR>>Раньше и для си был lint очень похож на PyCheker.

WH>Вот только когда пишешь на С++ потребности во всяких lint'ах почемуто не возникает. Может из-за статической типизации?

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

FR>>Проще писать программы, интерфейс файловых объектов стандартен, легко писать процедуры работающие с любыми файловыми объектами,

WH>В .НЕТ тоже решается библиотекой.
FR>>при этом для своих файловых объектов не требуется наследование от базового класса.
WH>Сомнительное преймущество.

угу также как и шаблоны в плюсах

FR>>Я видел скрипты из реальных игр,

WH>Я тоже.
FR>>и очень небольшая часть их выглядит также.
WH>Ну не знаю например скрипты в "Vampire: The Masquerade Bloodlines" выглядят так как я показал. И не смотря на то что они написаны на питоне ниодной питоновской мегафичи я там не видел.
FR>>Возможностей питона для них тоже вполне хватает,
WH>Я с этим и не спорю вот только стоит ли связываться с питоном если есть C#2

Может наоборот? Тем более пока C#2 нет, а переносимые варианты появятся еще позже.
А связыватся стоит, так как портировать питон и настраивать под определенную задачу гораздо легче чем шарп, и памяти он кушает намного меньше.

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

WH>Сильно сомневаюсь

зря, только то, что питон подерживает процедурный стиль уже гигантское упрощение, код можно писать без всякой обвязки, и читатся он будет не сложнее чем ini файл.
Re[48]: Python vs C#
От: WFrag США  
Дата: 14.05.05 10:26
Оценка: +1
Здравствуйте, FR, Вы писали:

WF>>Есть вообще мнение, что выгоднее вместо General Purpose Languages использовать DSL и развитие в ближайшем будущем должно идти в сторону удешевления создания DSL.


FR>http://www.iso.ru/journal/articles/print/264.html


До LISP-а ему в этом плане все равно далеко. В случае LISP-а мы имеем:

1) Любой синтаксис, который нам понравится.

2) DSL будет компилироваться (в LISP-код, а затем и в нативный при необходимости), а не интерпретироваться. В том числе есть обширные возможности для оптимизации или применения Partial Evaluation. И это все будет работать при компиляции кода, а не при его выполнении.
Re[47]: Создание игр на managed-языках
От: LSL  
Дата: 14.05.05 11:30
Оценка: +1
Здравствуйте, Козьма Прутков, Вы писали:

КП>Но он ориентирован на разработку

КП>корпоративных приложений, автоматизации бизнеса, а не утилит и игр.

C# Language Specification: C# is intended to be a simple, modern, general-purpose, object-oriented programming language.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Re[50]: Python vs C#
От: WFrag США  
Дата: 14.05.05 11:32
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

>> 1) Любой синтаксис, который нам понравится.

>> 2) DSL будет компилироваться (в LISP-код, а затем и в нативный при
>> необходимости), а не интерпретироваться. В том числе есть обширные
>> возможности для оптимизации или применения Partial Evaluation. И это
>> все будет работать при компиляции кода, а не при его выполнении.

C>3) Lots of Incredibly Stupid Parentheses


Нет, это конфликтует с первым пунктом. Я же написал — любой синтаксис Если вдруг скобочки не устраивают.
Re[48]: Создание игр на managed-языках
От: GlebZ Россия  
Дата: 14.05.05 11:33
Оценка: :)
Здравствуйте, eao197, Вы писали:

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

Так я не понял, это хорошо или плохо?

С уважением, Gleb.
Re[48]: Создание игр на managed-языках
От: WolfHound  
Дата: 14.05.05 11:33
Оценка: -1
Здравствуйте, eao197, Вы писали:

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

Дело в том что для питона что есть хардкодинг что его нет всеравно придется все отлажывать на всю катушку ибо этот дурак не требует объявления переменных. Помнится из-за такой ошибки (правда там был другой язык но с тойже проблемой) упал какойто космический корабль. Ну опечатался программер в одном месте с кем не бывает, а компилятор сволочь пропустил...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[47]: Создание игр на managed-языках
От: FR  
Дата: 14.05.05 11:44
Оценка: +1
Здравствуйте, Козьма Прутков, Вы писали:

КП>Трурль wrote:

>> Здравствуйте, WolfHound, Вы писали:
>> Поставим вопрс по-другому. Стоит ли связываться с C#, если есть питон?
КП> стоит ли шить сапоги если мы уже умеем плести лапти?
.........
КП>Итого, всему свое место в жизни

Угу только лапти запросто могут превратится в сапоги и наоборот в зависимости от решаемой задачи.
Re[48]: Создание игр на managed-языках
От: Козьма Прутков Россия  
Дата: 14.05.05 11:45
Оценка: -1
LSL wrote:
> Здравствуйте, Козьма Прутков, Вы писали:
>
> КП>Но он ориентирован на разработку
> КП>корпоративных приложений, автоматизации бизнеса, а не утилит и игр.
>
> C# Language Specification: C# is intended to be a simple, modern, general-purpose, object-oriented programming language.
угу. И фото с рекламного проспекта
К тому же я имел в виду не только и не столько сам язык сколько .NET в
целом (без него шарп ведь не живет). Ну не будешь ты на C# писать
драйвера. Не будешь, пожалуй, писать и софт типа СУБД, веб-серверов и
т.п. — для этого есть C++. Не будешь писать поделку на 5 строк, которая
обработает текстовый лог используя регулярное выражение и что-нибудь
тебе сообщит — это удел скриптовых языков. Он предназначен для быстрой,
эффективной, дешевой разработки приложений. И с этой задачей справляется
на 5. А то, что язык general purpose — так это ежу понятно: он же не
заставляет тебя оперировать какими-то встроенными знаниями о целевой
области, только общепринятыми конструкциями и типами. Лом тоже general
purpose, хоть гвозди забивай, но это не означает, что пора выкинуть
шампуры и шашлык жарить на нем.
Ох, чтой-то я уже про шашлык вспомнил?
Posted via RSDN NNTP Server 2.0 beta
Да хранит вас господь в сухом прохладном месте...
Re[48]: Создание игр на managed-языках
От: Козьма Прутков Россия  
Дата: 14.05.05 12:06
Оценка: :)
FR wrote:
> Угу только лапти запросто могут превратится в сапоги и наоборот в зависимости от решаемой задачи.
типа, пиво — хорошая водка
нет, дружище, из лаптей хреновые сапоги получатся: хоть ты их резиной
заверни, а все равно в дождь промокнешь. Аналогично как из сапог —
хреновые лапти: не повесишь ты на стенку на даче полаченные сапоги, ну
не красиво
Posted via RSDN NNTP Server 2.0 beta
Да хранит вас господь в сухом прохладном месте...
Re[48]: Создание игр на managed-языках
От: Трурль  
Дата: 14.05.05 12:46
Оценка: :)
Здравствуйте, FR, Вы писали:

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

Лучше сравнивать кеды и сапоги.
Re[51]: Python vs C#
От: Cyberax Марс  
Дата: 14.05.05 12:46
Оценка: +1
WFrag wrote:

> C>3) Lots of Incredibly Stupid Parentheses

> Нет, это конфликтует с первым пунктом. Я же написал — любой синтаксис
> Если вдруг скобочки не устраивают.

Мне С++ный, пожалуйста... А на практике — LISP получается

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[50]: Создание игр на managed-языках
От: WolfHound  
Дата: 14.05.05 12:53
Оценка: :)
Здравствуйте, FR, Вы писали:

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

Вот скажи мне на кой черт нужны PyChecker'ы если есть нормальные языки которые и без PyChecker'ов такой код не пропустят?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[43]: Создание игр на managed-языках
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 14.05.05 15:42
Оценка: +1
G>>Да правда чтоли? VB со своим IDispatch, JScript, PHP, Perl и ваш любимый C# c контейнерами Object-ов — типизированны по самое нехочу?
WH>С++, C#2...

Можно услышать о применении майнстримового C#2?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[58]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 14.05.05 18:21
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Gaperton wrote:


>> C>Я пробовал. Все делается весьма просто — экспортируются свои объекты в

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

C>А нафиг? Мне хватает однопоточного.

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

>> Кстати, VB — это не DSL. Чтобы сделать его похожим на DSL, попробуй

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

C>VBA — это сам по себе DSL, с достаточно широким доменом.

Ну какой это Domain Specific Language. Это обычный General Purpose Visual Basic, которому ты можешь поправить объектную модель. И она там, кстати, убога — нет наследования реализации. Что очень и очень плохо. А препроцессор и постпроцессор кода ты вставить туда не можешь, т.е. ты не можешь изменить вид программы и в общем случае заставишь пользователя делать ручками больше работы. Какой там DSL... Для простых задач это все канает, но для реализации серьезного DSL это не подходит.

>> C>Агащаз. Даже отладчик типа VBAшного — это недели работы, автокомплит и

>> C>среда разработки — месяцы.
>> Eclipse.
C>Ява не умеет OLE, например.
"OLE, OLE — это просто слезы" (с). А оно нужно, если пишешь на яве? Но если очень хочется, то, например,
1) Есть COM-CORBA прокси. А CORBA ява умеет.
2) Есть прямой Java-.NET interop от сторонних производителей.
3) В конце концов есть нативные интерфейсы, через которые можно все. Только нафига?
Re[56]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 14.05.05 18:40
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>И какие в этом преимущества? Точно так же, берем обычный

C>рекурсивно-нисходящий парсер, пишем для него грамматику DSLя и
C>транслятор в целевой язык (Java, например). Трудозатраты примерно такие же.

Так, в качестве заметки. DSL совершенно не обязаны быть текстовыми. Вполне допустимо (а на практике очень даже допустимо) наличие графических DSL.
... << RSDN@Home 1.1.4 beta 7 rev. 454>>
AVK Blog
Re[57]: Python vs C#
От: WolfHound  
Дата: 16.05.05 06:33
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>А ReSharper сможет работать с вашим собственным языком и достанется вашим клиентам бесплатно?

Собственный язык не обезателен см ниже.
А ReSharper это дополнительная мегафича за отдельные деньги.
G>Вы, батенька, вообще в курсе, что такое DSL?
Domain-Specific Language
Вобще говоря чтобы создать DSL не обязательно создавать новый язык.
Мозги + библиотека + пара кодогенераторов и получаем DSL как правило мало уступающей созданию нового языка.
Но имеющий огромные преймущества а именно мощьный отладчик, интелисенс,... а елси поставить еще и внешние примочки типа ReSharper'а то вобще
G>Кстати, я работая на С++ прекрасно обхожусь без вашего ReSharpera. И неудержимой тяги писать его аналог не испытываю.
Я тоже не испытывал пока не попробовал. Вобщем ReSharper это наркотик такой.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[42]: Создание игр на managed-языках
От: vdimas Россия  
Дата: 16.05.05 08:09
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

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


FR>>>А отсутствие типизпции может быть и преимуществом.

WH>>Да правда чтоли? Интересно почему тогда весь мейнстрем типизированый по самое нехочу?
G>Да правда чтоли? VB со своим IDispatch, JScript, PHP, Perl и ваш любимый C# c контейнерами Object-ов — типизированны по самое нехочу?

Насчет VB, использование позднего связывания без причины считается у программистов VB грубой ошибкой. Пара таких проколов, и VB программист пойдет на воздух.
Re[62]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 16.05.05 10:41
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>Gaperton wrote:


>>>> Впрочем, в этом смысле должно быть не хуже Питона. Ну и, ктати, если

>>>> тебе в будущем понадобится несколько инстансов VBA runtime в одном
>>>> процессе — придется вешаться.
>> C>На это я уже наткнулся
>> А говоришь, не нужен многопоточный режим .
C>А он мне не нужен, мне было нужно несколько инстансов VBA в одном процессе.
Нужен, ибо в этом режиме как раз можно включать несколько инстансов VBA в одном процессе, в чем и состоит его основная польза. Впрочем, не нужен и не нужен, твое дело.

>>>> Только нафига?

>> C>Угу, получится что все приложение будет написано на C++ с
>> запускальщиком
>> C>на Java.
>> Нет, если делать не через зад, а по человечески, то получится
>> приложение на Java c native интерфейсами на С++ к COM-объектам.
C>Теоретик.... OLE — это ведь не просто три буквы, это и определенная
C>организация приложения, и КУЧА интерфейсов. Все это скрещивать с Явой —
C>ну уж нет, лучше на старом добром С++.
Да где уж нам до практиков.
1) COM для вас превратится в три не простых, а очень веселых буквы (разрастание кода вдвое), как только выльется в "определенную организацию приложения" на "старом добром с++".
2) Java — это не просто четыре буквы, но тоже вполне определенная организация приложения.

Впрочем, переубеждать вас не буду — мне в каком-то смысле на руку, что вы (и другие) пишете именно так.
Re[63]: Python vs C#
От: WolfHound  
Дата: 17.05.05 14:15
Оценка: +1
Здравствуйте, _vovin, Вы писали:

_>Вот, недавно, записал пример наркотического сеанса (4.23МБ):

_>http://www.smalltalk.ru/downloads/DolphinBouncingBalls.zip
Все это конечно круто но смаллталк не имеет будущего. И причина в том что ребята заломили слишком много за среду.

Ожидаемая стоимость — $6'995 на разработчика с 1 годичной поддержкой и апгрейдами. Пользователи версий IBM VA Smalltalk имеющие поддержку смогут обновится до Instantinations' VA Smalltalk за $1'495. Пользователи не имеющие поддержки, а так же пользователи конкурирующих диалектов смогут перейти на VAST 7 за $1'995.

7К баксов при наличии бесплатных средств разработки под жабу и шарп это приговор.
Это никто кроме фанатиков покупать не станет.
Да и тягаться с пробивной мощью микрософта и сана дохлый номер.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[64]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 17.05.05 14:28
Оценка: +1
WolfHound wrote:

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

>
> _>Вот, недавно, записал пример наркотического сеанса (4.23МБ):
> _>http://www.smalltalk.ru/downloads/DolphinBouncingBalls.zip
> Все это конечно круто но смаллталк не имеет будущего. И причина в том что ребята заломили слишком много за среду.
>

> Ожидаемая стоимость — $6'995 на разработчика с 1 годичной поддержкой и апгрейдами. Пользователи версий IBM VA Smalltalk имеющие поддержку смогут обновится до Instantinations' VA Smalltalk за $1'495. Пользователи не имеющие поддержки, а так же пользователи конкурирующих диалектов смогут перейти на VAST 7 за $1'995.

> 7К баксов при наличии бесплатных средств разработки под жабу и шарп это приговор.
> Это никто кроме фанатиков покупать не станет.
> Да и тягаться с пробивной мощью микрософта и сана дохлый номер.

Dolphin Smalltalk — $350.

К тому же, кто у нас когда покупал Delphi Enterprise или Visual Studio
Professional? Студенты используют бесплатно, а кто покупает, тому цена
по боку. Тем более если поставить ее рядом с ценой на Oracle, WebSphere,
etc.

Будущее есть, но в нише. А причина — совсем даже не в цене.
Posted via RSDN NNTP Server 1.9
Re[69]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.05.05 15:28
Оценка: :)
Здравствуйте, _vovin, Вы писали:

>> Ты кажется не понял. Вот возьмем к примеру янус. Он довольно сильно популяризует платформу среди посетителей RSDN. А теперь задай себе вопрос — мог бы янус быть написанным на ST?


_>Естественно мог бы. Хоть на брэйнфаке. Если ты действительно спрашиваешь

_>о теоретической возможности.

Нет конечно. Речь исключительно о возможности практической.

_>Если же речь идет о вероятности этого

_>события, то это совсем другой вопрос.
_>Ну и я не вижу связи между ценой среды и янусом.

Связь очень простая — отсутствие бесплатных средств разработки это однозначно приговор.
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[49]: Python vs C#
От: FR  
Дата: 18.05.05 05:35
Оценка: +1
Здравствуйте, _FRED_, Вы писали:

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

C>>>Они не лентяи, просто недетерминированая финализация — почти что
C>>>фундаментальное свойство GC.

FR>>Угу, но они вполне могли сделать неявный using.


_FR>Не спасаёт Не редко требуется что-то вроде

_FR>
_FR>  // Do something...
    
_FR>  {
_FR>    CWaitCursor wait;
_FR>    // Do something...
_FR>  }
    
_FR>  // Do something...
_FR>

_FR>И юзинг, ИМХО, сильно нагляднее.

Лучше всего в D, добавил auto и получил гарантированный вызов деструкторов при выходе из зоны.
А про неявный using я писал не вообще а в контексте CPython — Jython, так как в CPython GC реализован подсчетом ссылок, то для объекта у которого не остается ссылок сразу вызывается деструктор, в Jython этого нет.
Re[73]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.05.05 09:22
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>Как пользователь RSDN NNTP скажу: поддержка NNTP в RSDN слегка

C>кривовата, но Янус еще более неудобен.

Нет в жизни щастия.
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[67]: Python vs C#
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 18.05.05 13:24
Оценка: :)
WH>>Именно в цене. Кому нужен мегакрутой язык если для него нет специалистов? Правильно никому.
WH>>А специалистов при таких ценах на среду не будет. Ибо студенты народ бедный.
S> Все зависит от предметной области. 1С относительно недавно, но количество программистов растет с каждым днем.
S> И относительно не бесплатен

Опен-соурсе рулит, однозначно
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[68]: Python vs C#
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.05.05 14:26
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

WH>>>Именно в цене. Кому нужен мегакрутой язык если для него нет специалистов? Правильно никому.

WH>>>А специалистов при таких ценах на среду не будет. Ибо студенты народ бедный.
S>> Все зависит от предметной области. 1С относительно недавно, но количество программистов растет с каждым днем.
S>> И относительно не бесплатен

ANS>Опен-соурсе рулит, однозначно

Вообще то 1С наполовину Опен-соурсе. Это касается конфигураций под различные задачи.
А вот реального конкурента для небольших предприятий увы не видно. Толи рекламы мало толи еще чего. А сегмент рынка ооочень перспективен.
Что касается общих решений то они пока малоэффективны прежде всего в типовых решениях задач под которые должны быть заточены инструменты и должно быть начальное решение (многие мегабайты кода), поддержка итд.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[77]: Python vs C#
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 18.05.05 16:13
Оценка: +1
ANS>>Если программа не запускается под поддерживаемой(!) ОС, то фича это или баг — вопрос натурально философский. Как по мне, то в 21 веке прикладных программ не работающих из под простого пользователя быть уже не должно.

AVK>Расскажи это МС, которая сделала так, что СОМ сервер можно зарегистрировать только из под администратора.


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

AVK>Некоторым удобно.


AVK>Проблема ровно одна — при этом янус лишится одного очень вкусного свойства, а именно deploy by copy.


Да я не настаиваю. Просто этот фактор — одна из тех одёжек по которым я встречаю программы (и провожаю).

ЗЫ А что вообще Зверёк скажет? Имеет даный факт отношение к юзабилити или нет?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[73]: Python vs C#
От: WolfHound  
Дата: 19.05.05 06:42
Оценка: -1
Здравствуйте, L.C.R., Вы писали:

LCR>Зайди в "коллеги улыбнитесь" — там шикарная подборка 19 гениальных заблуждений в науке и технике. Так что здравый смысл не канает

Сколько лет смаллтолку?... И сколько лет шарпу?... А теперь сравни популярность.

LCR>Шаг в сторону: как ты считаешь, нужно ли обычному программисту (ремесленнику практически (!)) вдохновение?

Тем кто пишет бизнес код оно только мешает.
Я бизнескод не пишу и ремеслиноком не являюсь
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[78]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.05.05 08:34
Оценка: +1
Здравствуйте, Andrei N.Sobchuck, Вы писали:

AVK>>Расскажи это МС, которая сделала так, что СОМ сервер можно зарегистрировать только из под администратора.


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


Разумеется. Но при этом о развертывании без инсталлятора речь не идет. Так что тут нужно выбирать — либо простота развертывания, либо возможность работы не из под администратора. Мне первое показалось более важным.

AVK>>Проблема ровно одна — при этом янус лишится одного очень вкусного свойства, а именно deploy by copy.


ANS>Да я не настаиваю. Просто этот фактор — одна из тех одёжек по которым я встречаю программы (и провожаю).


Вобщем наверное да. А в частности цели у проекта несколько иные.
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[74]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 19.05.05 15:22
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

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


LCR>>Зайди в "коллеги улыбнитесь" — там шикарная подборка 19 гениальных заблуждений в науке и технике. Так что здравый смысл не канает

WH>Сколько лет смаллтолку?... И сколько лет шарпу?... А теперь сравни популярность.
На вопросы ответил, сравнил. Что предлагается делать дальше?
Re[43]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 18:23
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>А вот задача копирования группы файлов элегантнее решается на языке командной строки DOS (не говоря уже о более продвинутых шеллах).

S>Кстати, раз уж речь зашла:
S>
S>sort < out.txt > out2.txt
S>

S>)

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

Дотнет же сдель дает ко всему прочему еще и то приемущество, что недостающую функциональность можно сварганить на нем же сомом. При этом производительность получается сравнимая с С++-ной, а скорость разработки с Питоном и Руби (а то и выше за счет отладчика, рефакторинга и IDE).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 18:47
Оценка: -1
Здравствуйте, WFrag, Вы писали:

WF>До LISP-а ему в этом плане все равно далеко. В случае LISP-а мы имеем:


WF>1) Любой синтаксис, который нам понравится.


WF>2) DSL будет компилироваться (в LISP-код, а затем и в нативный при необходимости), а не интерпретироваться. В том числе есть обширные возможности для оптимизации или применения Partial Evaluation. И это все будет работать при компиляции кода, а не при его выполнении.


Как сказать. С одной стороны макросы Лиспа — это действительно мощьное средство. Но "любой синтаксис" — это явное преувеличение. От моря скобок ты не избавишся.

Что до компиляции, то опять же списки более медленны чем массивы и жрут больше памяти. По сравнению с Питоном может что-то и можно получить. Но по сравнению со связками вроде XML + статически типизированный язык с хорошим компилятором или некое средство метапрограммия вроде генераторов парсеров плюс опять же статически типизированный язык с хорошим компилятором ты получишь только более сложное и медленное решение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[53]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 18:55
Оценка: :)
Здравствуйте, WFrag, Вы писали:

WF>Я думаю, потому что никому нафиг не надо C++. Изображать LISP-ом C++ синтаксис — совершенно бесполезное занятие.


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

WF>Вот тебе Pascal вместо C++:


WF>http://arxiv.org/abs/cs.PL/0409016


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

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

WF>И делается это проще, чем, например комбинация: XML->XML Parser->DOM Model->Lots of Java code->CGLIB->Java byte code для какого-нибудь DSL, например, для ORM mapping-а. А если отбросить парсер и оставить скобочный синтаксис — так и еще проще, не нужно XML в скобки превращать


Ага. Если отбросить рельность, то все просто и делается за два часа.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[70]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 19:32
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

AVK>Нет конечно. Речь исключительно о возможности практической.


Для не коммерческого использования Смолток можно наюыбать. Это не проблема. Проблема в том, что для человека знакомого с Дельфи или с С++ Смолток — это верх полоых извращений. Все раком начиная от среды и заканичивая мозгами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[71]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 20:09
Оценка: -1
Здравствуйте, Gaperton, Вы писали:

G>Здесь идет речь о твоем собственном профессионализме, как разработчика.


Напомню, что обсуждение профессионализма может привести в баню. Советую эту тему не развивать.

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


Он шлифуен свой проффесианлоизм не меньше некторых. Просто шлифует его с пользой для общества. Например, утилита для создания бэкапов на РСДН сделана им.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 20:41
Оценка: +1
Здравствуйте, _vovin, Вы писали:

_>Мое и не только мнение — сколько не смотри, а вкус блюда не узнаешь не

_>попробовав.


А ты уверен, что это я не попробовал, то что ты предлагаешь, а не ты то что я?

_>Тут дело в способе мышления, а не в знании конструкций и паттернов.


Намикашь, что у кого-то он убогий?

_>http://www.livejournal.com/users/behrk/318434.html

_>Человек стал работать со смолтоком после того, как устроил голосование
_>какой новый язык стоит изучить. Так что мнение можно считать
_>не-"фанатическим".

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

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


Папа! Как же так? ... есть, а слова нету? (с)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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[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[47]: Python vs C#
От: FR  
Дата: 20.05.05 04:37
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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


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


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


Простые задачи быстрее и проще решать на удобных языках. К тому же задачи делятся не только на простые и сложные есть и средние которые с успехом решаются тем же питоном.При обработке текстов и питон и перл показывают неплохую скорость.
Ты думаешь бизон нельзя подключить к питону? К тому же для питона кроме него есть еще несколько парсеров.
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
Re[49]: Создание игр на managed-языках
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.05.05 07:31
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


E>>Не знаю, Влад. В области компонентного подхода ничего не могу сказать.


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


Имхо, это не проблема, а огромное достоинство. Без RSDN я варюсь в собственном соку и вижу перед собой только ограниченный круг задач и способов их решений. А на RSDN за время моего участия в нем я очень много для себя узнал.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[48]: Python vs C#
От: FR  
Дата: 20.05.05 09:38
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

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


FR>>Понятно меня просто смутило то что файл читается как бинарный без корректировки концов строк.А так оно почти дословно перепишется:


AVK>Ну то есть никаких преимуществ Питон на этой задачке не дает? Кстати, что насчет кодировки?


Почему никаких, чуть чуть есть, код короче немножко и не пришлось вручную функцию писать. а по кодировке никаких проблем(и изменений в коде функции)
import codecs
.....................
print FillFromHashToDisk(codecs.open("data.txt", "rb",  "utf_8"))
Re[43]: Python vs C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.05.05 09:40
Оценка: +1
Здравствуйте, FR, Вы писали:

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

Это ты про остальные четыре строки, из которых две — это } ?
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[50]: Создание игр на managed-языках
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.05.05 09:54
Оценка: +1
Здравствуйте, _vovin, Вы писали:

_>2 года, то твои два запуска среды смолтока будут смотреться не очень. =)


...

_>Молодец, погавкал на неотносящееся к делу замечание.


Рекомендую сбавить обороты.
... << RSDN@Home 1.1.4 beta 7 rev. 456>>
AVK Blog
Re[43]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.05 18:17
Оценка: :)
Здравствуйте, FR, Вы писали:

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


Ясно, начинаем искать отмазки. А на то чно код значительно проще плевать.

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


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


Что за манера вмето аргументов включать заезжанные пластинки. Ты тут уже всем доказал, что разницы между Питон и Шарпом особой нет. А я тебе больше скажу, что и писать на Шарпе быстрее, так как чахлая командрая строка Питона не идет ни в какое сравнение с РеШарпером и студией 2005. Да и читать проще, так как не нужно разгадывать краксворды на тему какой у переменной должен быть тип, правильно ли сделано присвоение, какоей метод вызовется в этот раз и т.п. Лично я себя не раз ловил на мысли, что трачу на это кучу времени. Если метод полиморфен по дизану, то хотя бы ясно за что страдашь, но зачем страдать за идею?

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


Во-во. Между тем Шарпа для этого хватает. Хотя и плюсы тоже намного проще подключаются.

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

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

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


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

В том то все и дело, что Шарп сравнивается с Питоном и Руби по простоте написания кода, и с С++ по скорости. И там, и там у него есть слабыве места. Но они довольно не значительные. А вот кумулятивный эффект выходит очень даже значительный.

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


На игрушки? Да, качай и играйся. Самая известная http://arenawars.krawall.de/com/phpBB2/index.php

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


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


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

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


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

FR>Мне Руби не нравится тем что на нем легко писать write only код, на питоне это сложнее.


На руби можно писать намного более элегантный код. Незнаю, что ты там в нем усмотрел "райт-онли". А плохой код можно писать на чем угодно. Это как раз не сложно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[46]: Python vs C#
От: FR  
Дата: 21.05.05 09:00
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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


VD>Значит у нас разная практика. И она за доказательства не канает. Я бы вообще не стал использовать Питон при сложной текстовой обработке. Мазохизм не мой стиль.


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

FR>>При обработке текстов скорость питона часто близка к сишной (программа же 90% времени сидит в строковых библиотеках).


VD>Агащазблинъ. Близка к сишной может быть только скорость выполнения сишных библиотек в Питоне. Как только ты начинашь хоть что-то делать с текстом в самом Питоне, то сразу получишь многократное отставание.


Практика (широкое использование языков типа питона, перла и т. п. для обработки текстов) показывает что скорость вполне приемлемая.
Re[44]: Python vs C#
От: FR  
Дата: 21.05.05 09:41
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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


VD>Ясно, начинаем искать отмазки. А на то чно код значительно проще плевать.


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


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


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


VD>Что за манера вмето аргументов включать заезжанные пластинки. Ты тут уже всем доказал, что разницы между Питон и Шарпом особой нет. А я тебе больше скажу, что и писать на Шарпе быстрее, так как чахлая командрая строка Питона не идет ни в какое сравнение с РеШарпером и студией 2005. Да и читать проще, так как не нужно разгадывать краксворды на тему какой у переменной должен быть тип, правильно ли сделано присвоение, какоей метод вызовется в этот раз и т.п. Лично я себя не раз ловил на мысли, что трачу на это кучу времени. Если метод полиморфен по дизану, то хотя бы ясно за что страдашь, но зачем страдать за идею?


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

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


VD>Во-во. Между тем Шарпа для этого хватает. Хотя и плюсы тоже намного проще подключаются.


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


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

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

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


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


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

VD>В том то все и дело, что Шарп сравнивается с Питоном и Руби по простоте написания кода, и с С++ по скорости. И там, и там у него есть слабыве места. Но они довольно не значительные. А вот кумулятивный эффект выходит очень даже значительный.


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


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


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


Ну самые известные питоные проекты это Zope www.zope.org и движок Google (как дать на него ссылку не знаю), вообще сайты не так и редко на питоне работают(например еще www.sf.org) из того что я использую это порты wxWindows, несколько IDE и SCONS

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


VD>Ты так и не смог это доказать. Твой род задач — это халтурное программирование, мелкая автоматизация и т.п. Все это можно делать и на том же Шарпе. Причем получается даже быстрее.


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

FR>>Мне Руби не нравится тем что на нем легко писать write only код, на питоне это сложнее.


VD>На руби можно писать намного более элегантный код. Незнаю, что ты там в нем усмотрел "райт-онли". А плохой код можно писать на чем угодно. Это как раз не сложно.


Дело не в этом. Я смотрел примеры, слишком много закорючек, напоминает перл и форт
Re[50]: Python vs C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.05.05 07:24
Оценка: +1
Здравствуйте, FR, Вы писали:
FR>Со всем этим я согласен при условии что на VB сидит и работает разаработчик — программист. Если же скрипт должен писать(или править) специалист не программист (это и есть ситуация для компьютерных игр) то наоборот лучше все максимально ограничить и упростить.
Ограничения еще никогда никому ничего не упрощали. Упрощение — это предоставление максимума функциональности в готовом к употреблению виде. Попробую подлиннее:
У нас есть задача А и задача Б.
Задача А встречается в природе в 100 раз чаще, чем задача Б.
Подход номер 1 состоит в том, что наша среда предлагает решение задачи A в одну строку (один клик мышкой — по вкусу).
Решение задачи Б при этом занимает 1500 строк, пишется на другом языке с другими правилами, при этом в большинстве случаев ошибка в любой из этих 1500 строк состоит во внезапной смерти приложения с невнятным сообщением об ошибкe "Что-то сломалось". Фактически, потенциальный барьер настолько высок, что его можно считать бесконечным. Ни один разработчик не станет тратить 800 часов личного времени на освоение параллельной технологии только ради того, чтобы выделить цветом одну строку в гриде.

Подход номер 2 состоит в том, что наша среда предлагает решение задачи A в одну строку (один клик мышкой — по вкусу). Решение задачи Б потребует, конечно, освоения несколько более глубокого пласта знаний, но его можно сделать на том же языке, уложившись в 150 строк. При этом значительным подспорьем являются исходники (все на том же языке!) для решения задачи А. Поскольку задача Б является всего лишь более экзотической версией задачи А, которая не укладывается в заранее предусмотренные рамки.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[51]: Python vs C#
От: FR  
Дата: 23.05.05 07:42
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

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

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

Может не стоит так сильно обобщать?
Мне уже кажется что каждый из нас разговаривает сам с собой Я тебе про одну ситуацию, ты мне про совершенно другую.
Re[50]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 24.05.05 15:28
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

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


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

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

Вообще-то, это ты начал приводить "популярность" в качестве доказательства "крутизны" языка. "Cуществование" — аргумент совершенно такого же порядка, но здесь автор очевидено имел в виду тот факт, что на скриптовых языках все-таки пишут, и пишут много. А вообще — не надоело еще третью фундаментальную проблему IT решать?
Re[52]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.05.05 20:57
Оценка: +1
Здравствуйте, FR, Вы писали:

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


ОК...

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


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

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


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

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

"Скрипты" тут могут играть роль неких компонентов позволяющий расширять возможности игры не модифицируя движка. Заниматься этой задачей все равно должен программист. Только в отличии от системного программиста занимающегося вопросами отрисовки и т.п. этот программист должен заниматься вопросами разработки ИИ, управления объектами мира игры и т.п. В общем — это два программиста с разной специализаций. И это вовсе не обязательно тоже лицо что занимается разработкой внешнего вида уровня или моделей.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[54]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.05.05 20:57
Оценка: +1
Здравствуйте, FR, Вы писали:

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


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

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

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

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

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


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


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

ЗЫ

Кстати, для игр хорошим аналогм может служить 1С. Т.е. некая высокоуровневая среда заточенная под определенные цели. Каждый участник процесс работает на своем уровне. Системщик на уровне ядра (движка). Прикладник создает "конфигурации" (т.е. конкретные игры). А дизайнеры уже создают на "конфигурации" конкретные уровни. И упаси бог от программирования не программистами или от дизайна программистами. Пусть каждый развивает свой талант.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Python vs C#
От: WolfHound  
Дата: 13.05.05 08:25
Оценка:
Здравствуйте, FR, Вы писали:

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

Значит надо смотреть что они там делают.

FR>так ты сам должен лучше меня знать

А я вот не знаю просвети не разумного.

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

Это в каком это месте на питоне писать проще чем на C#? Просвети пожалуйста. И еще не забывай что для C# есть такие мегарулезы как ReSharper у меня по началу создавалось впечатление что эта штука мои мысли читает.
А если Влад доведет до рабочего состояния R# то это вобще будет супер.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>

13.05.05 16:35: Ветка выделена из темы Создание игр на managed-языках
Автор: WolfHound
Дата: 11.05.05
— AndrewVK
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: Python vs C#
От: WolfHound  
Дата: 13.05.05 09:02
Оценка:
Здравствуйте, FR, Вы писали:

WH>>А я вот не знаю просвети не разумного.

FR>знаешь
Нет. Не знаю.

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

Примеры в студию. Только мериться будем с C#2
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.05.05 10:28
Оценка:
Здравствуйте, FR, Вы писали:

FR>По объему кода, вот простейшая программка считывает файл построчно и выводит его в другой файл отсортированным по строкам:

FR>
FR>arr = open("test.txt").readlines()
FR>arr.sort()

FR>out = open("out.txt", "w")
FR>for line in arr:
FR>    print >> out, line,
FR>


А закрывать файлы кто будет?
... << RSDN@Home 1.1.4 beta 7 rev. 453>>
AVK Blog
Re[38]: Python vs C#
От: GlebZ Россия  
Дата: 13.05.05 11:49
Оценка:
Здравствуйте, FR, Вы писали:

FR>
FR>formula =r"-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
FR>-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
FR>-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
FR>-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
FR>-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234"
FR>

Внушает. Только не понял, что ты тут имел ввиду. А точнее что должен делать калькулятор?

С уважением, Gleb.
PS: простота названий переменный qwe и asd бесподобна.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[39]: Python vs C#
От: FR  
Дата: 13.05.05 12:14
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


FR>>
FR>>formula =r"-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
FR>>-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
FR>>-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
FR>>-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234\
FR>>-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234-(asd-qwe)*3*3*asd/(asd-sin(qwe)+5/asd)-123.234"
FR>>

GZ>Внушает. Только не понял, что ты тут имел ввиду. А точнее что должен делать калькулятор?

Это выражение которое нужно вычислить

GZ>С уважением, Gleb.

GZ>PS: простота названий переменный qwe и asd бесподобна.

ну это не я придумал, выражение взято из другой ветки.
Re[39]: Python vs C#
От: FR  
Дата: 13.05.05 12:14
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


FR>>По объему кода, вот простейшая программка считывает файл построчно и выводит его в другой файл отсортированным по строкам:

FR>>
FR>>arr = open("test.txt").readlines()
FR>>arr.sort()

FR>>out = open("out.txt", "w")
FR>>for line in arr:
FR>>    print >> out, line,
FR>>


AVK>А закрывать файлы кто будет?


GC
Вообще на питоне если на файл ссылок нет он сразу после использования закрывается.
Re[39]: Python vs C#
От: FR  
Дата: 13.05.05 12:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


FR>>По объему кода, вот простейшая программка считывает файл построчно и выводит его в другой файл отсортированным по строкам:

WH>Функции readlines в библиотеке .НЕТ нет по этому мы ее напишем.
WH>
WH>        static IEnumerable<string> Lines(Stream stream)
WH>        {
WH>            using (StreamReader reader = new StreamReader(stream))
WH>                for (string line; (line = reader.ReadLine()) != null; )
WH>                    yield return line;
WH>        }
WH>

WH>
FR>>arr = open("test.txt").readlines()
FR>>arr.sort()
WH>
WH>            List<string> lines;
WH>            using (Stream file = File.OpenRead("text.txt"))
WH>                lines = new List<string>(Lines(file));
WH>            lines.Sort();
WH>

WH>
FR>>out = open("out.txt", "w")
FR>>for line in arr:
FR>>    print >> out, line,
WH>
WH>            using (TextWriter file = File.CreateText("out.txt"))
WH>                foreach (string line in lines)
WH>                    file.WriteLine(file);
WH>

WH>Отсутствие типизации и необходимости объявлять переменные в питоне я считаю большим недостатком.

Код все равно больше по объему.
А отсутствие типизпции может быть и преимуществом.


FR>>Суммирование чисел из файла(в каждой строке файла одно число):

WH>Опять библиотека...

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

WH>Да будут операторы

WH>
WH>        delegate T Operator<T>(T l, T r);
WH>        interface IMathOperators<T>
WH>        {
WH>            Operator<T> Add { get; }
WH>            Operator<T> Sub { get; }
WH>            Operator<T> Mul { get; }
WH>            Operator<T> Div { get; }
WH>        }
WH>        class MathOperatorsInt : IMathOperators<int>
WH>        {
WH>            public Operator<int> Add { get { return delegate(int l, int r) { return l + r; }; } }
WH>            public Operator<int> Sub { get { return delegate(int l, int r) { return l - r; }; } }
WH>            public Operator<int> Mul { get { return delegate(int l, int r) { return l * r; }; } }
WH>            public Operator<int> Div { get { return delegate(int l, int r) { return l / r; }; } }
WH>        }
WH>        static Dictionary<Type, object> MathOperatorsMap = new Dictionary<Type, object>();
WH>        static IMathOperators<T> MathOperators<T>()
WH>        {
WH>            return (IMathOperators<T>)MathOperatorsMap[typeof(T)];
WH>        }
WH>        static Program()
WH>        {
WH>            MathOperatorsMap.Add(typeof(int), new MathOperatorsInt());
WH>        }
WH>

WH>Теперь сделаем недостающие функции
WH>
WH>        delegate T Parse<T>(string s);
WH>        static IEnumerable<T> Map<T>(Stream stream)
WH>        {
WH>            Parse<T> parse = (Parse<T>)Delegate.CreateDelegate(typeof(Parse<T>),
WH>                typeof(T), "Parse");
WH>            foreach (string line in Lines(stream))
WH>                yield return parse(line);
WH>        }
WH>        static T Sum<T>(IEnumerable<T> numbers)
WH>        {
WH>            Operator<T> add = MathOperators<T>().Add;
WH>            T val = default(T);
WH>            foreach (T number in numbers)
WH>                val = add(val, number);
WH>            return val;
WH>        }
WH>

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

WH>
WH>    using (Stream file = File.OpenRead("text.txt"))
WH>        Console.WriteLine(Sum(Map<int>(file)));
WH>


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

WH>Это тоже решается библиотекой.

В примере на питоне все решается без библиотек.

WH>А самое главное что все что ты привел очень синтетические задачи не имеющие с реальностью ничего общего.


Так давай реальные примеры, лучше в виде постоновки небольших задач.
Re[40]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.05.05 12:34
Оценка:
Здравствуйте, FR, Вы писали:

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


http://msdn2.microsoft.com/library/bwabdf9z(en-us,vs.80).aspx
... << RSDN@Home 1.1.4 beta 7 rev. 453>>
AVK Blog
Re[40]: Создание игр на managed-языках
От: WolfHound  
Дата: 13.05.05 12:46
Оценка:
Здравствуйте, FR, Вы писали:

FR>Код все равно больше по объему.

И что с того если все это за меня автокомплит набил?
FR>А отсутствие типизпции может быть и преимуществом.
Да правда чтоли? Интересно почему тогда весь мейнстрем типизированый по самое нехочу?

FR>В первом примере никаких библиотек не использовалось только встроенные возможности языка.

Те в язык встроели работу с файлами?
FR>В этом же примере показана возможность программировать в функциональном стиле и шарпу тоже не мешало бы такое ввести в стандартные библиотеки
Зачем?
Елси мне очень сильно приспичет пописать на функциональном языке то я возьму функциональный язык. Благо их на .НЕТ портировано до чертиков.

FR>В примере на питоне все решается без библиотек.

Ну не встроели в C# вызов соответствующих функций фреймворка... беда то какая.

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

Тема была про скрипты в играх. А для чего в играх используются скрипты? Правильно чтобы объекты в игре что-то делали.
class World
{
    public IEnumerable<GameObject> GetObjects(Position pos, float range)
    {
        foreach (GameObject obj in objects)
            if (obj.Pos.DistanceTo(pos) < range)
                yield return obj;
    }
}
class Bomb : GameObject
{
    public void Detonation()
    {
        foreach (GameObject obj in world.GetObjects(Pos, detonationRange))
            obj.Damage(detonationDamage);
    }
}
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[40]: Python vs C#
От: GlebZ Россия  
Дата: 13.05.05 12:57
Оценка:
Здравствуйте, FR, Вы писали:

FR>Это выражение которое нужно вычислить

Thanks. Уже понял. Нашел исходное сообщение.здесь
Автор: FR
Дата: 14.10.04


FR>ну это не я придумал, выражение взято из другой ветки.

И это нашел.здесь
Автор: WolfHound
Дата: 24.04.04


С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[41]: Python vs C#
От: eugals Россия  
Дата: 13.05.05 13:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


FR>>Вообще на питоне если на файл ссылок нет он сразу после использования закрывается.


AVK>Т.е. GC запускается на каждую строчку кода?


такого GC как в CLR — нет.
Банальный счетчик ссылок. Как только ob_refcnt становится равным нулю — объект дестроится.
Правда слегка оптимизирован: если у объекта нет деструктора, то он не free-ится а помещается в специальный список, который чистится пакетно — при переполнении.
... << RSDN@Home 1.1.4 beta 5 rev. 395>> {WinAmp: Whitney Houston — I Wanna Dance With Somebody (Who Loves Me)}
Re[42]: Python vs C#
От: eugals Россия  
Дата: 13.05.05 13:31
Оценка:
Здравствуйте, eugals, Вы писали:

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


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


FR>>>Вообще на питоне если на файл ссылок нет он сразу после использования закрывается.


AVK>>Т.е. GC запускается на каждую строчку кода?


E>такого GC как в CLR — нет.

E>Банальный счетчик ссылок. Как только ob_refcnt становится равным нулю — объект дестроится.
E>Правда слегка оптимизирован: если у объекта нет деструктора, то он не free-ится а помещается в специальный список, который чистится пакетно — при переполнении.

Плюс к этому есть опциональный cycle detector
... << RSDN@Home 1.1.4 beta 5 rev. 395>> {WinAmp: Alan Jackson — Let It Be Christmas}
Re[42]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.05.05 13:33
Оценка:
Здравствуйте, eugals, Вы писали:

AVK>>Т.е. GC запускается на каждую строчку кода?


E>такого GC как в CLR — нет.

E>Банальный счетчик ссылок.

Как в VB6?
... << RSDN@Home 1.1.4 beta 7 rev. 453>>
AVK Blog
Re[41]: Python vs C#
От: FR  
Дата: 13.05.05 18:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>FR wrote:


>> AVK>А закрывать файлы кто будет?

>> GC
>> Вообще на питоне если на файл ссылок нет он сразу после использования
>> закрывается.

C>Это если в Питоне используется подсчет ссылок вместо настоящего GC, что

C>далеко не всегда правда.

Просто разработчики Jython ленивые


C>Вообще, за такой код (с утечками ресурсов) я бы отрывал головы...


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

C>--

C>С уважением,
C> Alex Besogonov (alexy@izh.com)
Re[42]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.05.05 18:42
Оценка:
Здравствуйте, FR, Вы писали:

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


А если сразу же после записи в файл попытаться его открыть на запись по новой?
... << RSDN@Home 1.1.4 beta 7 rev. 454>>
AVK Blog
Re[43]: Python vs C#
От: FR  
Дата: 13.05.05 19:31
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


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


AVK>А если сразу же после записи в файл попытаться его открыть на запись по новой?


Если ссылок на файл нет то CPython (основная реализация питона) закроет файл сразу после выхода из строки например тут

arr = open("test.txt").readlines()

после выполнения строки файл уже будет закрыт. Тут есть небольшой UB, так как документация не гарантирует такое поведение для всех реализаций. Но уже очень много кода написано полагаясь на такое поведение так что менять его вряд ли будут.
Re[41]: Создание игр на managed-языках
От: _doctor Финляндия http://agilesoftwaredevelopment.com
Дата: 13.05.05 20:43
Оценка:
Здравствуйте, WolfHound, Вы писали:

FR>>А отсутствие типизпции может быть и преимуществом.

WH>Да правда чтоли? Интересно почему тогда весь мейнстрем типизированый по самое нехочу?
Потому что в мейнстриме важно случайно не сложить число со строкой.
Думаю, именно поэтому Питон и является языком со строгой типизацией. Просто она динамическая
Вот в VB, скажем, строку с числом сложить не проблема, "компилятор" даже не пискнет
Chief Software Engineer,
Scrum Master, Symbian
Re[39]: Python vs C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.05.05 05:03
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


FR>>По объему кода, вот простейшая программка считывает файл построчно и выводит его в другой файл отсортированным по строкам:

WH>Теперь сделаем недостающие функции
WH>
WH>        delegate T Parse<T>(string s);
WH>        static IEnumerable<T> Map<T>(Stream stream)
WH>        {
WH>            Parse<T> parse = (Parse<T>)Delegate.CreateDelegate(typeof(Parse<T>),
WH>                typeof(T), "Parse");
WH>            foreach (string line in Lines(stream))
WH>                yield return parse(line);
WH>        }
WH>        static T Sum<T>(IEnumerable<T> numbers)
WH>        {
WH>            Operator<T> add = MathOperators<T>().Add;
WH>            T val = default(T);
WH>            foreach (T number in numbers)
WH>                val = add(val, number);
WH>            return val;
WH>        }
WH>

Здесь можно было чуть сэкономить. Функция преобразования стрима в строковый енумератор уже есть. Насколько я помню, есть также генерик делегат Transform.
Соответственно, можно написать простейший метод
public static IEnumerable<R> Transform<T, R>(IEnumerable<T> source, Transform<T, R> transform)
{
    foreach(T t in source) yield return transform(t);
}

и воспользоваться им вот так:
    using (Stream file = File.OpenRead("text.txt"))
        Console.WriteLine(Sum(Transform<string, int>(Lines(file))));

WH>Это тоже решается библиотекой.
WH>А самое главное что все что ты привел очень синтетические задачи не имеющие с реальностью ничего общего.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[39]: Python vs C#
От: Трурль  
Дата: 14.05.05 05:25
Оценка:
Здравствуйте, eugals, Вы писали:

E>А теперь то же самое с использованием возможностей питона 2.4:

E>
E>file("out.txt", "w").writelines(sorted(file("test.txt")))
E>


Чисто для прикола:
"out.txt" 0: t[<t: 0: "text.txt"]
Re: Python vs C#
От: Andir Россия
Дата: 14.05.05 05:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

Просто в тему: Python с типизацией под Mono http://boo.codehaus.org/

С Уважением, Andir!
Re[42]: Python vs C#
От: Cyberax Марс  
Дата: 14.05.05 05:58
Оценка:
FR wrote:

> C>Вообще, за такой код (с утечками ресурсов) я бы отрывал головы...

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

Да, а если этот кусок кода выполняется в цикле 10000 раз? Что _тогда_
будет? А если вместо открытых файлов — соединения с БД (количество
которых, кстати, весьма ограничено)?

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[44]: Python vs C#
От: Cyberax Марс  
Дата: 14.05.05 06:00
Оценка:
FR wrote

> Тут есть небольшой UB, так как документация не гарантирует такое

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

_Уже_ поменяли в Jython и IronPython (или как его там зовут). Когда
выйдет Parrot, то поменяют и в обычном Питоне.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[40]: Python vs C#
От: FR  
Дата: 14.05.05 06:32
Оценка:
Здравствуйте, Трурль, Вы писали:

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


E>>А теперь то же самое с использованием возможностей питона 2.4:

E>>
E>>file("out.txt", "w").writelines(sorted(file("test.txt")))
E>>


Т>Чисто для прикола:

Т>
Т>"out.txt" 0: t[<t: 0: "text.txt"]
Т>


Ruby?
По моему питон читабельней, хотя Ruby тоже не плох
Re[41]: Python vs C#
От: FR  
Дата: 14.05.05 06:32
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

FR>>Не надо по деревьям лазить, достаточно брать любую небольшую утилитку активно работающую с текстовыми файлами, объем кода будет сильно меньше чем на плюсах или шарпе, близко к объему на перле, но в отличии от перла не write-only а вполне читабельный код.
S>Угу. А вот при рисовании линий на экране лого порвет этот ваш питон как тузик грелку.

from turtle import *

clear()
forward(40)
left(90)
forward(40)
left(90)
forward(40)
left(90)
forward(40)


Re[41]: Python vs C#
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.05.05 06:57
Оценка:
Здравствуйте, FR, Вы писали:

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


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


E>>>А теперь то же самое с использованием возможностей питона 2.4:

E>>>
E>>>file("out.txt", "w").writelines(sorted(file("test.txt")))
E>>>


Т>>Чисто для прикола:

Т>>
Т>>"out.txt" 0: t[<t: 0: "text.txt"]
Т>>


FR>Ruby?


Не похож.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[47]: Python vs C#
От: FR  
Дата: 14.05.05 07:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>FR wrote:


>> C>_Уже_ поменяли в Jython и IronPython (или как его там зовут). Когда

>> C>выйдет Parrot, то поменяют и в обычном Питоне.
>> Как я уже писал разработчики Jython лентяи

C>Они не лентяи, просто недетерминированая финализация — почти что

C>фундаментальное свойство GC.

Угу, но они вполне могли сделать неявный using.

>> уже с 2001 года не могут новую версию сделать. А IronPython еще

>> глубокая альфа.

C>В новых версиях поведение деструкторов вряд ли поменяется, так как

C>подсчет ссылок (который сейчас используется в CPython'е) — чрезвычайно
C>тормозной.

Наверно из-за этого Jython с настоящим GC работает медленее чем CPython.
Re[43]: Python vs C#
От: FR  
Дата: 14.05.05 07:23
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

FR>>from turtle import *
S>Боюсь, что как только заходит речь об import, то практически любой язык общего назначения будет выглядеть одинаково. Разница только в количестве и разнообразии доступных библиотек.

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

S>Мериться составом RTL в этом смысле не очень показательно. Показательно сравнивать затраты на подготовку этих библиотек; или сравнивать состав стандартной поставки с точки зрения некоторой группы задач. Ну, вот скажем, Cw на порядок лаконичнее C# при работе с XML и SQL. А вот задача копирования группы файлов элегантнее решается на языке командной строки DOS (не говоря уже о более продвинутых шеллах).


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

S>Кстати, раз уж речь зашла:

S>
S>sort < out.txt > out2.txt
S>

S>)

так чем же плох питон если на нем эта задача решается практически так же просто, и просто решаются задачи которые на любом шеле неразрешимы.
Re[42]: Создание игр на managed-языках
От: WolfHound  
Дата: 14.05.05 07:45
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Да правда чтоли? VB со своим IDispatch, JScript, PHP, Perl и ваш любимый C# c контейнерами Object-ов — типизированны по самое нехочу?

С++, C#2...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[40]: Python vs C#
От: WolfHound  
Дата: 14.05.05 07:45
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здесь можно было чуть сэкономить. Функция преобразования стрима в строковый енумератор уже есть. Насколько я помню, есть также генерик делегат Transform.

S>Соответственно, можно написать простейший метод
Я библиотеку .NET2 еще не изучал. Времени нет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[40]: Python vs C#
От: WolfHound  
Дата: 14.05.05 07:45
Оценка:
Здравствуйте, FR, Вы писали:

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

Любимый прием местных философов подменить тему разговора... Мы же вроде о скриптах в играх говорили, а не об обработки текстовых файлов.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: Python vs C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.05.05 07:48
Оценка:
Здравствуйте, FR, Вы писали:
FR>Так питон тем и удобен что очень много упаковано в его стандартные библиотеки. Там же тот же принцип что и в плюсах все что возможно вынести в библиотеку выносится.
Гм. Это "много" — настолько относительная штука, господа...
Тем, кто пишет обработку текста, нужна среда со встроенными средствами на эту тему. Кстати, тоже занятная штука. Кодировки, детектирование, аппер/ловер, паттерн матчинг ака регекспы...
Тем, кто пишет математику, библиотека без комплексных чисел и матричной алгебры покажется децким лепетом.
Ну и так далее.
Я в этом плане человек темный. Насколько мне известно, наиболее полным покрытием предметной области обладает Java. Там вообще сложно придумать область, для которой нет готового стандарта, его референс имплементации, а также пары из коммерческого и некоммерческого решений.

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

Смотря что писать.
Понимаешь, если у меня стоит задача сортировать список строк, то можно написать язык из одной команды. Которую для упрощения обозначить символом "пробел" — по нему промахнуться труднее. И на олимпиаде по сортировке списка строк рвать конкурентов в разы. А когда мы говорим о general purpose языке программирования, на первый план выезжают способы повторного использования и их стоимость, в терминах как разработки (производительность), так и эксплуатации (быстродействие). Я пока не убедился в значительном преимуществе питона в этом плане над альтернативными языками.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[46]: Python vs C#
От: WolfHound  
Дата: 14.05.05 07:50
Оценка:
Здравствуйте, FR, Вы писали:

FR>Я понимаю конечно что иногда очень сильно тянет кого нибудь поучить, сам

FR>этим изредка страдаю, но извини не стоит раздувать из мухи слона, и превращать
FR>вполне корректный пример в повод демонстрировать конец света.
Ничего никуда не превращается, а просто демонстрируется порочность данной практики.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[41]: Python vs C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.05.05 08:16
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Я библиотеку .NET2 еще не изучал. Времени нет.
я тоже.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[41]: Python vs C#
От: FR  
Дата: 14.05.05 08:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

WH>Любимый прием местных философов подменить тему разговора... Мы же вроде о скриптах в играх говорили, а не об обработки текстовых файлов.

Не я виноват что тему переместили и обозвали "Python vs C#".
Re[45]: Python vs C#
От: FR  
Дата: 14.05.05 08:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

FR>>Так питон тем и удобен что очень много упаковано в его стандартные библиотеки. Там же тот же принцип что и в плюсах все что возможно вынести в библиотеку выносится.
S>Гм. Это "много" — настолько относительная штука, господа...
S>Тем, кто пишет обработку текста, нужна среда со встроенными средствами на эту тему. Кстати, тоже занятная штука. Кодировки, детектирование, аппер/ловер, паттерн матчинг ака регекспы...

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

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

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

может быть

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

S>Смотря что писать.

это да.

S>Понимаешь, если у меня стоит задача сортировать список строк, то можно написать язык из одной команды. Которую для упрощения обозначить символом "пробел" — по нему промахнуться труднее. И на олимпиаде по сортировке списка строк рвать конкурентов в разы. А когда мы говорим о general purpose языке программирования, на первый план выезжают способы повторного использования и их стоимость, в терминах как разработки (производительность), так и эксплуатации (быстродействие). Я пока не убедился в значительном преимуществе питона в этом плане над альтернативными языками.


Пока ты будешь писать свой пробельный язык я давно уже решу эту же задачу одной строкой кода в питоне. Разработку питон сильно ускоряет.
Re[41]: Python vs C#
От: Трурль  
Дата: 14.05.05 08:35
Оценка:
Здравствуйте, eugals, Вы писали:

E>
E>bash$ sort text.txt > out.txt
E>


Уел! Но, сугубо флейма для, изменим постановку задачи. Пусть требуется вывести перестановку, упорядочивающую файл.
"out.txt" 0: $< 0: "text.txt"

А как это будет на bash?
Re[46]: Создание игр на managed-языках
От: WolfHound  
Дата: 14.05.05 09:55
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Поставим вопрс по-другому. Стоит ли связываться с C#, если есть питон?

Да стоит.
1)C# статически типизирован что позволяет отловить множество ошибок еще до тестирования.
2)Если все делать на C# то интеграция скриптов и основного кода получится автоматически и без оверхеда.
3)Для C# существуют мощные IDE с возможностью рефакторинга и прочими вкусностями.
4)C# исполняется быстрее.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[42]: Python vs C#
От: eugals Россия  
Дата: 14.05.05 10:03
Оценка:
Здравствуйте, Трурль, Вы писали:

Т> Пусть требуется вывести перестановку, упорядочивающую файл.

Т>
Т>"out.txt" 0: $< 0: "text.txt"
Т>

"перестановка, упорядочивающая файл"?
Что тут написано? Попробовал подсунуть этот текст Эрлангу и Хаскелю — они его не поняли. Какой ещё язык Гапертон знает? Clean что ли?
... << RSDN@Home 1.1.4 beta 5 rev. 395>> {WinAmp: Andrew Lloyd Webber — The Last Supper}
Re[46]: Создание игр на managed-языках
От: WolfHound  
Дата: 14.05.05 10:06
Оценка:
Здравствуйте, eao197, Вы писали:

E>Имхо, динамическая типизация -- это интересная возможность.

Нет она как парашют. В подавляющем большинстве случаев только мешается. Но иногда без нее никак. Вот на эти иногда возможностей .НЕТ болие чем достаточно.
E>Просто нужно к ней по другому подходить.
К ней вобще по возможности не нужно подходить.
E>Ни и не для всех задач, имхо, она пригодно. Например, мне было бы стремно писать маршрутизатор SMS-трафика на Ruby именно из-за того, что я не смогу создать достаточное количество unit-тестов, чтобы весь код проверить
E>(а сторонники динамически-типизированных языков часто приводят в качестве довода то, что нельзя доверять коду, который не был протестирован).
С этим никто не спорит вопрос в необходимом объеме тестов и времени на их прогонку.
E>А в случае статически типизированного языка я хотя бы могу быть уверен в отсутствии синтаксических ошибок даже в самых редкоиспользуемых ветвях моего кода.
И многих семантических.
E>Но для небольших программ тот же Ruby может дать существенный прирост производительности в кодировании.
Ты на шарпе с решарпером писал?
E>А если к этому добавить, что сложные задачи можно решать правильно комбинируя простые и маленькие инструменты (т.н. unix way), то получается, что из маленьких Python (Ruby, Perl,...) скриптиков можно строить весьма сложные решения.
Вот только без интеграционных тестов оно всеравно работать не будет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[47]: Python vs C#
От: FR  
Дата: 14.05.05 10:14
Оценка:
Здравствуйте, WFrag, Вы писали:

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


FR>>Пока ты будешь писать свой пробельный язык я давно уже решу эту же задачу одной строкой кода в питоне. Разработку питон сильно ускоряет.


WF>Да, зато DSL (Domain Specific Language) по времени выгоднее. Стоимость старта определенно выше, зато из-за того, что DSL лучше подходит под решение задачи (собственно, для этого он разрабатывается), стоимость разработки на DSL ниже.


WF>Есть вообще мнение, что выгоднее вместо General Purpose Languages использовать DSL и развитие в ближайшем будущем должно идти в сторону удешевления создания DSL.


http://www.iso.ru/journal/articles/print/264.html
Re[47]: Создание игр на managed-языках
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.05.05 10:18
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


E>>Просто нужно к ней по другому подходить.

WH>К ней вобще по возможности не нужно подходить.


Прикольно. Но это, имхо, вопрос религии.

E>>Ни и не для всех задач, имхо, она пригодно. Например, мне было бы стремно писать маршрутизатор SMS-трафика на Ruby именно из-за того, что я не смогу создать достаточное количество unit-тестов, чтобы весь код проверить

E>>(а сторонники динамически-типизированных языков часто приводят в качестве довода то, что нельзя доверять коду, который не был протестирован).
WH>С этим никто не спорит вопрос в необходимом объеме тестов и времени на их прогонку.

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

Хотя лично я уверен, что есть масса случаев, когда unit-тесты или автоматические integration- или regression-тесты просто неприменимы. Иметь в таких случаях поддержку со стороны статически типизированного языка -- это очень большой плюс.

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

WH>Ты на шарпе с решарпером писал?

Нет. Я сейчас на C++ и vim . А сложные куски программ сначала на бумаге пишу -- зато потом и рефакторинг не нужен

E>>А если к этому добавить, что сложные задачи можно решать правильно комбинируя простые и маленькие инструменты (т.н. unix way), то получается, что из маленьких Python (Ruby, Perl,...) скриптиков можно строить весьма сложные решения.

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

А вообще-то я сам двумя руками за статическую типизацию. Просто если с умом применять динамически типизированные языки, то можно получить хорошие девиденды.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[44]: Создание игр на managed-языках
От: Козьма Прутков Россия  
Дата: 14.05.05 10:23
Оценка:
FR wrote:
> Угу я вот недавно задолбался править одну Java утилитку, на каждый чих нагородили классов, в этих {} уже как в лисповских скобках начал путатся, если бы переписать это хоть на си, не говоря уже о питоне в процедурном стиле было бы намного проще.
кто ж спорит: низкокачественный код можно на чем угодно написать. И не
потому, что java плоха, а потому что руки у автора кривы Ну, либо
написано нормально, а чтец не привык к языку
Posted via RSDN NNTP Server 2.0 beta
Да хранит вас господь в сухом прохладном месте...
Re[49]: Python vs C#
От: Cyberax Марс  
Дата: 14.05.05 10:45
Оценка:
WFrag wrote:

> 1) Любой синтаксис, который нам понравится.

> 2) DSL будет компилироваться (в LISP-код, а затем и в нативный при
> необходимости), а не интерпретироваться. В том числе есть обширные
> возможности для оптимизации или применения Partial Evaluation. И это
> все будет работать при компиляции кода, а не при его выполнении.

3) Lots of Incredibly Stupid Parentheses

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[48]: Создание игр на managed-языках
От: LSL  
Дата: 14.05.05 11:41
Оценка:
Здравствуйте, eao197, Вы писали:

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

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

Mono для сабжа очень даже достаточно.

http://www.axiom3d.org/Default.aspx?tabid=27&amp;g=posts&amp;t=1536
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Re[49]: Python vs C#
От: FR  
Дата: 14.05.05 11:44
Оценка:
Здравствуйте, WFrag, Вы писали:

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


WF>>>Есть вообще мнение, что выгоднее вместо General Purpose Languages использовать DSL и развитие в ближайшем будущем должно идти в сторону удешевления создания DSL.


FR>>http://www.iso.ru/journal/articles/print/264.html


WF>До LISP-а ему в этом плане все равно далеко. В случае LISP-а мы имеем:


WF>1) Любой синтаксис, который нам понравится.


ты ссылку до конца прочитал?

WF>2) DSL будет компилироваться (в LISP-код, а затем и в нативный при необходимости), а не интерпретироваться. В том числе есть обширные возможности для оптимизации или применения Partial Evaluation. И это все будет работать при компиляции кода, а не при его выполнении.


Так тут тоже компилируется в байт код питона.

Вообще мне лисп не нравится лучше тогда форт взять
Re[47]: Создание игр на managed-языках
От: FR  
Дата: 14.05.05 11:45
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>FR wrote:


>> WH>На что спорим что я на питоне закриптую программу так что ты в ней

>> озвереешь разбираться.
>> Конечно напишешь Но суть в том что создатели java и C# выкинув
>> процедурный стиль просто принуждают из простейших вещей делать криптокод.

C>Объясните, что вы понимаете под "процедурным стилем"? Код с глобальными

C>переменными и фукнциями?

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

>> WH>Есть очень большая проблема: Отсутствие статической типизации.

>> Чем ее отсутствие помешает преименовыванию методов и т. п.

C>Вот такой код:

C>
C>class Test
C>    def test_method(self):
C>       ...
C>...
C>tst=some_external_function()
C>tst.test_method()
C>

C>Предположим, что код класса "Test" и переменная tst расположены в разных
C>файлах в большом проекте из 5000 классов. Как нам теперь переименовать
C>метод test_method в new_test_method?

C>В языках со статической типизацией все просто — переименовываем метод и

C>компилируем программу, а потом по сообщениям об ошибках находим все
C>точки использования метода test_method. Или если язык достаточно просто
C>(типа Java или C#), то IDE может проанализировать код и заменить все без
C>перекомпиляции.

так и в питоне можно запустить PyChecker и получить тоже AttributeError: Test instance has no attribute 'test_method'

>> WH>Что называется почувствойте разницу.

>> и что?

C>А то, что с ReShaper'ом или IDEA "производительность" получается ничуть

C>не хуже, чем у питонистов.

>> WH>Сомнительное преймущество.

>> угу также как и шаблоны в плюсах

C>Темплейты в С++ — это огромное его преимущество, и ничуть не сомнительное.


обобщенное программирование в питоне тоже.

>> Может наоборот? Тем более пока C#2 нет, а переносимые варианты

>> появятся еще позже.

C>Переносимый вариант (Mono) выйдет через пол-года.


А разве C#2 от ms уже вышел?

>> А связыватся стоит, так как портировать питон и настраивать под

>> определенную задачу гораздо легче чем шарп, и памяти он кушает намного
>> меньше.

C>Не факт.


Если судить по играм то факт.

>> FR>>и как плюс они будут короче и понятней, осбенно настроечные

>> скрипты с которыми работают дизайнеры, то есть те кто мало разбирается
>> в кодировании.
>> WH>Сильно сомневаюсь
>> зря, только то, что питон подерживает процедурный стиль уже гигантское
>> упрощение, код можно писать без всякой обвязки, и читатся он будет не
>> сложнее чем ini файл.

C>Только если при этом он будет делать примерно то же, что и "hello world".


ты контекст отслеживай, я говорил про настроечные скрипты в играх, это "умный" ini файл.
Re[49]: Создание игр на managed-языках
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.05.05 11:45
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

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

А другой взорвался на старте из-за того, что управляющий софт был написан на статически типизированной Ada...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[51]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 14.05.05 11:51
Оценка:
Здравствуйте, WFrag, Вы писали:

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


>>> 1) Любой синтаксис, который нам понравится.

>>> 2) DSL будет компилироваться (в LISP-код, а затем и в нативный при
>>> необходимости), а не интерпретироваться. В том числе есть обширные
>>> возможности для оптимизации или применения Partial Evaluation. И это
>>> все будет работать при компиляции кода, а не при его выполнении.

C>>3) Lots of Incredibly Stupid Parentheses


WF>Нет, это конфликтует с первым пунктом. Я же написал — любой синтаксис Если вдруг скобочки не устраивают.

+1. Взять хотя бы упомянутый Синклером Logo. Это диалект лисп .
Re[50]: Создание игр на managed-языках
От: GlebZ Россия  
Дата: 14.05.05 11:58
Оценка:
Здравствуйте, eao197, Вы писали:

E>Хорошо, что есть Моно и дотГНУ.

E>Плохо:
E> — то, что Microsoft официально не занимается портированием .NET и C# на другие платформы сама ;
А я бы сказал что наоборот хорошо. Чем меньше Microsoft будет вмешиваться в сам Net, тем лучше. Как уже говорилось, что покрытие предметной области в Java наиболее полное. И не последнюю роль в этом играли именно третьи фирмы и опенсорс и отсутствие монополии типа Microsoft. Когда у тебя в конкурентах Microsoft, на рынке делать нечего.
E> — то, что VladD2 и теперь уже WolfHound прибегают к аргументу, что линукс их не интересует
Это их проблемы. (хотя честно, сам работаю только на wintel).

С уважением, Gleb.
PS: вот если бы они коды JIT открыли, вот тогда Net компиляторы в натив начали бы плодится как грибы.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[51]: Создание игр на managed-языках
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.05.05 12:07
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


E>>Хорошо, что есть Моно и дотГНУ.

E>>Плохо:
E>> — то, что Microsoft официально не занимается портированием .NET и C# на другие платформы сама ;
GZ>А я бы сказал что наоборот хорошо. Чем меньше Microsoft будет вмешиваться в сам Net, тем лучше. Как уже говорилось, что покрытие предметной области в Java наиболее полное. И не последнюю роль в этом играли именно третьи фирмы и опенсорс и отсутствие монополии типа Microsoft. Когда у тебя в конкурентах Microsoft, на рынке делать нечего.

Может быть. Хотя вот у Java сама Sun заботиться о том, чтобы при выходе новой версии Java весь новый JDK сразу был доступен на всех официально поддерживаемых Sun-ом платформах. Кроме того, именно Sun позиционирует Java как кроссплатформенное решение (хотя Java -- это сама по себе платформа ) А в случае с Microsoft-ом, во-первых, такого позиционирования со стороны самого Microsoft-а нет и, во-вторых, как следствие, после выхода очередной версии .Net будет проходить некоторое время пока Моно и дотГНУ подтянуться. Да и опыт GNU Classpath показывает, что тяжеловато за Sun-ом угнаться в отдельной реализации JDK.

Поэтому мне, как стороннему наблюдателю за спорами C# vs something интересно читать про достоиства .Net/C#, но из-за необходимости быть портабельным я не рассматриваю сейчас .Net/C# как серьезную альтернативу C++/Java и даже Python/Perl/Ruby.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[50]: Создание игр на managed-языках
От: Трурль  
Дата: 14.05.05 12:08
Оценка:
Здравствуйте, eao197, Вы писали:

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


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


E>А другой взорвался на старте из-за того, что управляющий софт был написан на статически типизированной Ada...

Тот, о котором пишет WolfHound, тоже статически типизированный.
Re[47]: Создание игр на managed-языках
От: FR  
Дата: 14.05.05 12:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


FR>>Конечно напишешь Но суть в том что создатели java и C# выкинув процедурный стиль просто принуждают из простейших вещей делать криптокод.

WH> Может уже пора писать в объектно-ориентированом стиле?

Не везде выгодно писать в ОО стиле.

FR>>Чем ее отсутствие помешает преименовыванию методов и т. п.

WH>Ну попробуй переименовать функцию some принимающею три параметра типов int, float, string сласса foo. Причем так чтобы ничего не поломалось ни при каких наворотах в коде.

У питона своя специфика, но все таки не вижу проблем для написания такой утилиты.

WH>>>ReSharper не проверяет код. Он помогает его набивать, модифицировать и осуществлять навигацию. Те это часть IDE, а не компилятора.

WH>>>Что называется почувствойте разницу.
FR>>и что?
WH>А то что ReSharper не берет на себя функции компилятора по проверки программы на наличие ошибок.

так и для питона можно сделать тоже.

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

WH>Не знаю как там у тебя но у меня при малейшей нестыковки программа просо не компилируется. И не нужны мне никакие варнинги.


то есть ты всегда выставляешь level 4 и "Treat Warnings As Error"?

FR>>Тем более пока C#2 нет,

WH>Уже есть бета 2
FR>>а переносимые варианты появятся еще позже.
WH>Микрософт перенесет его везде где есть винда очень быстро. А всякие линухи лично меня не волнуют.

понятно
консоли тоже?

FR>>А связыватся стоит, так как портировать питон

WH>Ну для того чтобы портировать .НЕТ надо только прекомпилировать JIT и GC под конкретную платформу. А библиотеки те что чисто managed портируются автоматически.
FR>>и настраивать под определенную задачу гораздо легче чем шарп,
WH>Это чем же?

тем что гораздо компактнее, и сразу написан портируемым.

FR>>и памяти он кушает намного меньше.

WH>Ой да брось ты. .НЕТ жрет памяти сколько винде не жалко. Но как только винде понадобится память .НЕТ ее отдает еще до того как винда потянит свои ручки к свопу.



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

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

Угу, только программа на питоне будет гораздо меньше чем эти несколько мегабайт.

FR>>код можно писать без всякой обвязки, и читатся он будет не сложнее чем ini файл.

WH>Очень обманчивое "преймущество". Взять тотже "Vampire: The Masquerade Bloodlines" блин все руки надо пообравать этим горе программерам которые эти скрипты писали.
WH>Замет все задается строками и магическими числами. И так везде.

А что ты еще хотел от дизайнеров?

WH>
WH>def mercurioFight():
WH>    npc = Find("Mercurio")
WH>    pc = __main__.FindPlayer()
WH>    state = pc.GetQuestState("Astrolite")
WH>    if(state == 5):
WH>        npc.SetModel("models/character/npc/unique/Santa_Monica/Mercurio/Mercurio.mdl")
WH>        npc.SetDisposition("Neutral", 1)
WH>        teleporter = Find("healthy_mercurio_spot")
WH>        teleporter.Teleport()
WH>        script = Find("mercurio_turn_around")
WH>        script.StartSchedule()
WH>        trigger = Find("mercurio_angry_talk_trigger")
WH>        trigger.Enable()
WH>        journal = Find("mercurio_journal")
WH>        journal.ScriptUnhide()
WH>        sparklies = Find("journal_sparklies")
WH>        sparklies.ScriptUnhide()
WH>    if(__main__.IsDead("Mercurio")):
WH>        npc.Kill()
WH>

WH>Представляю сколько времени они это отлаживали... Ведь одна опечатка в одном строковом литерале и...

вряд ли долго, очень помогает интерактивность, поменял что-то и сразу видно, часто без перезапуска приложения.
Re[49]: Создание игр на managed-языках
От: FR  
Дата: 14.05.05 12:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

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

Насчет необявленных переменных, на такой код:
from random import random

if random() < 0.001: 
    print x

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

Насчет корабля ошибка была в том что вместо запятой поставили точку, программа была на фортране, подобная ошибка легко допускается и на си.
Re[51]: Создание игр на managed-языках
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 14.05.05 12:19
Оценка:
Здравствуйте, Трурль, Вы писали:

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


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


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


E>>А другой взорвался на старте из-за того, что управляющий софт был написан на статически типизированной Ada...

Т>Тот, о котором пишет WolfHound, тоже статически типизированный.

А про какие аварии вообще идет речь?

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

P.S. Лично я последние два случая знаю только из программиского фольклера (в смысле, что сам не читал каких-либо статей, где утвердалось бы именно такая причина катастрофы).
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[52]: Создание игр на managed-языках
От: Трурль  
Дата: 14.05.05 12:33
Оценка:
Здравствуйте, eao197, Вы писали:

E>Еще был какой-то случай, когда в программе на Фортране при написании константы вместо десятичной точки поставили запятую.

Вот это оно и есть.
Re[43]: Python vs C#
От: Трурль  
Дата: 14.05.05 12:43
Оценка:
Здравствуйте, eugals, Вы писали:

E>"перестановка, упорядочивающая файл"?

Ну, вывести номер наименьшей строки, потом следующей,...
Re[48]: Создание игр на managed-языках
От: WolfHound  
Дата: 14.05.05 12:53
Оценка:
Здравствуйте, FR, Вы писали:

FR>Не везде выгодно писать в ОО стиле.

Не везде это числодробилки, а вот скрипты очень даже выгодно.

FR>У питона своя специфика, но все таки не вижу проблем для написания такой утилиты.

Ну попробуй написать утилиту которая переименует функцию Foo в классе Some1
class Some1:
    def Foo(self):
        print "hello1"

class Some2:
    def Foo(self):
        print "hello2"

def Bar(obj):
    obj.Foo()

obj1 = Some1()
Bar(obj1)

obj2 = Some2()
Bar(obj2)


FR>то есть ты всегда выставляешь level 4 и "Treat Warnings As Error"?

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

WH>>Микрософт перенесет его везде где есть винда очень быстро. А всякие линухи лично меня не волнуют.

FR>понятно
FR>консоли тоже?
Мне почемуто кажется что оно там таки будет.

FR>тем что гораздо компактнее, и сразу написан портируемым.

А! Ну-ну.

FR>Угу, только программа на питоне будет гораздо меньше чем эти несколько мегабайт.

Будет гораздо больше если добавить объем юнит-тестов.

FR>А что ты еще хотел от дизайнеров?

Я бы им объяснил как и почему именно так надо писать. И приложил бы максимум усилий чтобы осложнить хардкодинг.

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

Интерактивность и Vampire: The Masquerade Bloodlines вещи не совместимые.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[48]: Создание игр на managed-языках
От: Cyberax Марс  
Дата: 14.05.05 13:18
Оценка:
FR wrote:

> C>Объясните, что вы понимаете под "процедурным стилем"? Код с глобальными

> C>переменными и фукнциями?
> Нет скоре то что сильно любят Вирт и Дейкстра, код без глобальных
> переменных и goto, хорошо структуированный.

Хороший процедурный код (например код на языке С в Subversion, GTK,
GIMP) почти не отличается от ОО-кода по своей сути.

> C>Вот такой код:

> C>
>
>C>class Test
>C> def test_method(self):
>C> ...
>C>...
>C>tst=some_external_function()
>C>tst.test_method()
>C>
>
>
> C>Предположим, что код класса "Test" и переменная tst расположены в
> разных
> C>файлах в большом проекте из 5000 классов. Как нам теперь переименовать
> C>метод test_method в new_test_method?
> так и в питоне можно запустить PyChecker и получить тоже
> AttributeError: Test instance has no attribute 'test_method'

А _откуда_ PyChecker узнает, что some_external_function возвращает
переменную типа Test? Язык-то динамический.

В С++ тип декларируется в описании переменной.

> C>Темплейты в С++ — это огромное его преимущество, и ничуть не

> сомнительное.
> обобщенное программирование в питоне тоже.

Нету его там в нормальном. Есть name-based polymorphism, который по сути
тоже есть в шаблонах С++, это используется для CRTP (Curously Recurring
Template Pattern).

> C>Переносимый вариант (Mono) выйдет через пол-года.

> А разве C#2 от ms уже вышел?

Через два месяца. Разработка Mono2 идет параллельно с MSами, релиз
планируют на осень.

> C>Не факт.

> Если судить по играм то факт.

А есть игры с C# для скриптов (для сравнения)?

> C>Только если при этом он будет делать примерно то же, что и "hello

> world".
> ты контекст отслеживай, я говорил про настроечные скрипты в играх, это
> "умный" ini файл.

В современных играх — уже не просто ini-файл.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[52]: Создание игр на managed-языках
От: Cyberax Марс  
Дата: 14.05.05 13:21
Оценка:
eao197 wrote:

> P.S. Лично я последние два случая знаю только из программиского

> фольклера (в смысле, что сам не читал каких-либо статей, где
> утвердалось бы именно такая причина катастрофы).

Для Ариан-5 можно найти в Сети pdf-ку с отчетом.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[44]: Python vs C#
От: eugals Россия  
Дата: 14.05.05 13:28
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Ну, вывести номер наименьшей строки, потом следующей,...

python -c "for _, i in sorted(map(reversed, enumerate(file('test.xsl')))): print i" > out.txt

GNUшные утилиты плохо знаю и разбираться сейчас некогда
... << RSDN@Home 1.1.4 beta 5 rev. 395>> {WinAmp: Andrew Lloyd Webber — The Last Supper}
Re[45]: Python vs C#
От: eugals Россия  
Дата: 14.05.05 13:37
Оценка:
Здравствуйте, eugals, Вы писали:

Т>>Ну, вывести номер наименьшей строки, потом следующей,...

E>
E>python -c "for _, i in sorted(map(reversed, enumerate(file('test.xsl')))): print i" > out.txt
E>


Ошибочка. Лучше так:
python -c "for _, i in sorted((s, i) for i, s in enumerate(file('text.txt'))): print i" > out.txt
... << RSDN@Home 1.1.4 beta 5 rev. 395>> {WinAmp: Andrew Lloyd Webber — The Last Supper}
Re[50]: Python vs C#
От: WFrag США  
Дата: 14.05.05 13:39
Оценка:
Здравствуйте, FR, Вы писали:

WF>>1) Любой синтаксис, который нам понравится.


FR>ты ссылку до конца прочитал?


Да вроде бы...

Например, хочу синтаксис паскаля Или я что-то в статье не понял.
... << RSDN@Home 1.1.4 beta 6a rev. 438>>
Re[48]: Создание игр на managed-языках
От: WolfHound  
Дата: 14.05.05 13:50
Оценка:
Здравствуйте, eao197, Вы писали:

WH>>Ты на шарпе с решарпером писал?

E>Нет. Я сейчас на C++ и vim .
А ты попробуй.
Допустим пишем так
    class Test
    {
        int m_Int1;
        int m_Int2;
        int m_Int3;
        int m_Int4;
    }

Далие нажимаем пару кнопок и получаем реализацию конструктора
        public Test(int int1, int int2, int int3, int int4)
        {
            m_Int1 = int1;
            m_Int2 = int2;
            m_Int3 = int3;
            m_Int4 = int4;
        }

Нажимаем еще пару кнопок и получаем реализацию свойства
        public int Int4
        {
            get { return m_Int4; }
            set { m_Int4 = value; }
        }

Причем обращения к m_Int4 заменяются на Int4

Или скажем понадобился нам какойто класс например Thread.
Делаем следующие действия
1)Набираем thr
2)Нажимаем ctrl+alt+space и получаем список всех классов которые начинаются на thr
3)Выбераем Thread
После этого решерпер сам вставит в начало исходника
using System.Threading;


А еще он в реальном времени подсвечивает в коде ошибки и предупреждения. Болие того для многих ошибок он предлагает варианты лечения. И я эту фичу постоянно использую.
Например пишу какойто код и мне понадобилось создать новую функцию которая чтото сделает с строкой и интом и возвратит флоат.
            int i;
            string s;
            float f=Foo(i, s);

нажимаю пару кнопок и получаю
        private float Foo(int i, string s)
        {
            throw new NotImplementedException();
        }

красота

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

E>А сложные куски программ сначала на бумаге пишу -- зато потом и рефакторинг не нужен

Мне с этим гораздо проще. Не понравилось имя класса нажал несколько кнопок и переименовал его во всей программе. Причем эта штука опционально может переименовывать не только сам тип но и переменные этого типа.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[53]: Python vs C#
От: WolfHound  
Дата: 14.05.05 13:58
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Я думаю, потому что никому нафиг не надо C++. Изображать LISP-ом C++ синтаксис — совершенно бесполезное занятие.

WF>Вот тебе Pascal вместо C++:
WF>http://arxiv.org/abs/cs.PL/0409016
А отладчик и автокомплит на этом DSL работать будут?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[49]: Создание игр на managed-языках
От: FR  
Дата: 14.05.05 13:58
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


FR>>Не везде выгодно писать в ОО стиле.

WH>Не везде это числодробилки, а вот скрипты очень даже выгодно.

смотря какие скрипты.

FR>>У питона своя специфика, но все таки не вижу проблем для написания такой утилиты.

WH>Ну попробуй написать утилиту которая переименует функцию Foo в классе Some1
WH>
WH>class Some1:
WH>    def Foo(self):
WH>        print "hello1"

WH>class Some2:
WH>    def Foo(self):
WH>        print "hello2"

WH>def Bar(obj):
WH>    obj.Foo()

WH>obj1 = Some1()
WH>Bar(obj1)

WH>obj2 = Some2()
WH>Bar(obj2)
WH>


Это проблема не из-за того что в питоне динамическая типизация, а из-за того что функция Bar обобщеная, то же самое будет и в плюсах с шаблонами, в принципе вполне разрешима и в плюсах(частичной специализацией) и в питоне(динамическим определнием типа внутри Bar).

FR>>то есть ты всегда выставляешь level 4 и "Treat Warnings As Error"?

WH>Нет. Я всеголишь не использую небезопасные конструкции доставшиеся в наследство от С.
WH>А если этим не пользоваться то С++ строготипизированый язык.


понятно ты просто не видишь эти варнинги.

WH>>>Микрософт перенесет его везде где есть винда очень быстро. А всякие линухи лично меня не волнуют.

FR>>понятно
FR>>консоли тоже?
WH>Мне почемуто кажется что оно там таки будет.

Угу лет через 5 — 10.

FR>>тем что гораздо компактнее, и сразу написан портируемым.

WH>А! Ну-ну.

FR>>Угу, только программа на питоне будет гораздо меньше чем эти несколько мегабайт.

WH>Будет гораздо больше если добавить объем юнит-тестов.

вряд-ли

FR>>А что ты еще хотел от дизайнеров?

WH>Я бы им объяснил как и почему именно так надо писать. И приложил бы максимум усилий чтобы осложнить хардкодинг.



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

WH> Интерактивность и Vampire: The Masquerade Bloodlines вещи не совместимые.

не знаю не видел.
Re[51]: Создание игр на managed-языках
От: FR  
Дата: 14.05.05 13:58
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

WH>Вот скажи мне на кой черт нужны PyChecker'ы если есть нормальные языки которые и без PyChecker'ов такой код не пропустят?

Зато много чего другого пропустят.
Нажать на Check ни чем ни сложнее чем на Compile.
Re[53]: Python vs C#
От: Cyberax Марс  
Дата: 14.05.05 14:13
Оценка:
WFrag wrote:

> C>Мне С++ный, пожалуйста... А на практике — LISP получается

> Я думаю, потому что никому нафиг не надо C++.

Мне, например, вот надо

> Изображать LISP-ом C++ синтаксис — совершенно бесполезное занятие.


Говорили "любой", а выходит что кроме замен на инфиксные операции и
переименований некоторых функций, дальше вся синтаксическая гибкость
Лиспа и не идет.

> Вот тебе Pascal вместо C++:

> http://arxiv.org/abs/cs.PL/0409016
> И делается это проще, чем, например комбинация: XML->XML Parser->DOM
> Model->Lots of Java code->CGLIB->Java byte code для какого-нибудь DSL,
> например, для ORM mapping-а.

И причем здесь ORM? Просто так, чтобы к слову? В той же Hibernate'е XML
используется только для того, чтобы задавать настройки, то есть в
качестве такого продвинутого ini-файла. Лисп там ну абсолютно никакой
разницы бы не сделал.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[50]: Создание игр на managed-языках
От: WolfHound  
Дата: 14.05.05 14:17
Оценка:
Здравствуйте, FR, Вы писали:

FR>Это проблема не из-за того что в питоне динамическая типизация, а из-за того что функция Bar обобщеная, то же самое будет и в плюсах с шаблонами, в принципе вполне разрешима и в плюсах(частичной специализацией) и в питоне(динамическим определнием типа внутри Bar).

Да в питоне все обобщенное ибо типизация динамическая вот собственно и все. Вот и конец рефакторингу.

FR>понятно ты просто не видишь эти варнинги.

Предположение не верное. У меня естих варнингов нет.

WH>>Будет гораздо больше если добавить объем юнит-тестов.

FR>вряд-ли
Будет. Никуда не денится. Ибо надо же типизацию везде проверить.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[54]: Python vs C#
От: WFrag США  
Дата: 14.05.05 14:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А отладчик и автокомплит на этом DSL работать будут?


Разумеется, нет. Работы наверняка ведутся, но я ничего внятного не скажу — не встречал.
... << RSDN@Home 1.1.4 beta 6a rev. 438>>
Re[50]: Создание игр на managed-языках
От: Cyberax Марс  
Дата: 14.05.05 14:22
Оценка:
FR wrote:

>WH>class Some1:

>WH> def Foo(self):
>WH> print "hello1"
>
>WH>class Some2:
>WH> def Foo(self):
>WH> print "hello2"
>
>WH>def Bar(obj):
>WH> obj.Foo()
>
>WH>obj1 = Some1()
>WH>Bar(obj1)
>
>WH>obj2 = Some2()
>WH>Bar(obj2)
>WH>
>
>
> Это проблема не из-за того что в питоне динамическая типизация, а
> из-за того что функция Bar обобщеная, то же самое будет и в плюсах с
> шаблонами, в принципе вполне разрешима и в плюсах(частичной
> специализацией) и в питоне(динамическим определнием типа внутри Bar).

1. В C# эта проблема не возникнет _вообще_ (если функция Bar не будет
использовать reflection для вызова obj.Foo).
2. В С++ аналогичный код:
struct Some1
{
    void Foo() {cout<<"hello1\n";}
};
struct Some2
{
    void Foo() {cout<<"hello2\n";}
};
template<class T> void Bar(T& t)
{
    t.Foo();
}

Some1 obj1;
Bar(obj1);
Some2 obj2;
Bar(obj2);

после переименования Foo в классе Some1 откажется компилироваться.
3. Питоновская программа упадет во время исполнения.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[54]: Python vs C#
От: WFrag США  
Дата: 14.05.05 14:32
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Мне, например, вот надо


Я имею ввиду, изображать C++ на LISP.

>> Изображать LISP-ом C++ синтаксис — совершенно бесполезное занятие.


C>Говорили "любой", а выходит что кроме замен на инфиксные операции и

C>переименований некоторых функций, дальше вся синтаксическая гибкость
C>Лиспа и не идет.

Почему? Хитрость простая. Текст на DSL-языке — это просто строка, макрос может сделать с ней (в compile-time) все, что угодно — в том числе распарсить язык и отобразить в "скобочки" (которые в свою очередь разворачиваются другими макросами в низкоуровневый код).

C>И причем здесь ORM? Просто так, чтобы к слову? В той же Hibernate'е XML

C>используется только для того, чтобы задавать настройки, то есть в
C>качестве такого продвинутого ini-файла. Лисп там ну абсолютно никакой
C>разницы бы не сделал.

Настройки — это тоже язык. Только в случае Java нам остается только интепретатор — загрузчик настроек. А в случае LISP мы могли бы его компилировать (вернее сумму настройки+модельные классы+бизнес логика) получая исключительно исполняемый код. И не нужно грузить настройки — они "вкомпилируются" в программу (Partial Evaluation во всей красе).

То есть даем на вход модельные классы+настройки (маппинг), получаем исполняемый код, заточенный под данные классы и настройки (грубо говоря, выполнение конкретных SQL выражений в нужных местах).
... << RSDN@Home 1.1.4 beta 6a rev. 438>>
Re[49]: Создание игр на managed-языках
От: FR  
Дата: 14.05.05 14:45
Оценка:
Здравствуйте, Cyberax, Вы писали:


>> так и в питоне можно запустить PyChecker и получить тоже

>> AttributeError: Test instance has no attribute 'test_method'

C>А _откуда_ PyChecker узнает, что some_external_function возвращает

C>переменную типа Test? Язык-то динамический.

Сначала он импортирует все модули и все что можно проанализировать анализирует,
Потом все таки запускает программу, и тоже анализирует.

C>В С++ тип декларируется в описании переменной.


>> C>Темплейты в С++ — это огромное его преимущество, и ничуть не

>> сомнительное.
>> обобщенное программирование в питоне тоже.

C>Нету его там в нормальном. Есть name-based polymorphism, который по сути

C>тоже есть в шаблонах С++, это используется для CRTP (Curously Recurring
C>Template Pattern).

однако это не мешает легко писать на питоне обобщенный и повторно используймый код


>> C>Не факт.

>> Если судить по играм то факт.

C>А есть игры с C# для скриптов (для сравнения)?


Не знаю. Есть игры целиком написанные на шарпе.

>> C>Только если при этом он будет делать примерно то же, что и "hello

>> world".
>> ты контекст отслеживай, я говорил про настроечные скрипты в играх, это
>> "умный" ini файл.

C>В современных играх — уже не просто ini-файл.


В современных играх скрипты используются для разных целей, в том числе и для создания умных ini, и для описания логики игровых объектов и для реализации GUI.
Re[55]: Python vs C#
От: WolfHound  
Дата: 14.05.05 14:49
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>А ты пробовал когда-нибудь встроить в свою программу среду разработки от MS и сделать из этого DSL?

Именно этим я сейчас и занимаюсь. При том вполне успешно.
G>Хотя бы специально для этого предназначенный Visual Basic for Applications? А ты попробуй. Тогда понятно станет, почему большинство производителей предпочитают так не делать, не покупаясь на замануху вроде отладчика и автокомплита. Все эти мульки в результате проще самому написать.
Написать аналог ReSharpera? Да вы батенька .

G>Кстати, предупреждая ответы в духе "а вот .NET" — проект Visual Studio for Applications.NET свернут осенью прошлого года. Нет никакого дотнета . А прежде чем предлагать с каждой копией продукта тащить полноценный VS.NET подумайте о том, как это будет лицензироваться и сколько будет стоить вашему клиенту.

0$ Ибо есть есть экспресы.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[51]: Создание игр на managed-языках
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 14.05.05 14:57
Оценка:
Здравствуйте, GlebZ, Вы писали:

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


Очень вряд ли. К примеру дженерики без JIT не реализуемы принципиально.
... << RSDN@Home 1.1.4 beta 7 rev. 454>>
AVK Blog
Re[52]: Создание игр на managed-языках
От: GlebZ Россия  
Дата: 14.05.05 15:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


AVK>Очень вряд ли. К примеру дженерики без JIT не реализуемы принципиально.

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

С уважением, Gleb.
... << RSDN@Home 1.1.4 beta 4 rev. 358>>
Re[55]: Python vs C#
От: Cyberax Марс  
Дата: 14.05.05 15:21
Оценка:
Gaperton wrote:

> <http://arxiv.org/abs/cs.PL/0409016&gt;WH&gt;А отладчик и автокомплит на

> этом DSL работать будут?
> А ты пробовал когда-нибудь встроить в свою программу среду разработки
> от MS и сделать из этого DSL? Хотя бы специально для этого
> предназначенный Visual Basic for Applications? А ты попробуй.

Я пробовал. Все делается весьма просто — экспортируются свои объекты в
контекст VBA и все работает. Что характерно, работает без проблем —
отлаживать и писать код для автоматизации в VBA очень удобно.

> Тогда понятно станет, почему большинство производителей предпочитают

> так не делать, не покупаясь на замануху вроде отладчика и
> автокомплита. Все эти мульки в результате проще самому написать.

Агащаз. Даже отладчик типа VBAшного — это недели работы, автокомплит и
среда разработки — месяцы.

> Кстати, предупреждая ответы в духе "а вот .NET" — проект Visual Studio

> for Applications.NET *свернут *осенью прошлого года. Нет никакого
> дотнета . А прежде чем предлагать с каждой копией продукта тащить
> полноценный VS.NET

Мы спрашивали у МС — нам сказали, что по VSIP можно будет поставлять
урезанную Студию. А те же VS Express вполне себе маленькие по объему.

> подумайте о том, как это будет лицензироваться и сколько будет стоить

> вашему клиенту.

$10000 на компанию — вполне нормальная цена.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[46]: Создание игр на managed-языках
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 14.05.05 15:35
Оценка:
FR>>>Раньше и для си был lint очень похож на PyCheker.
WH>>Вот только когда пишешь на С++ потребности во всяких lint'ах почемуто не возникает. Может из-за статической типизации?

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


Не знаю, чем раньше lint занимался, но lint в VW ST (называемый Code Critic) выдаёт предупреждения при использованию некоторых конструкций (напр. переопределено "=", но не "hash"; переменная объекта перекрыта временной переменной; слишком длинный метод и пр.). слыхал, что такая штука есть и в IDEA. Так что, думаю, что нужен
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[47]: Создание игр на managed-языках
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 14.05.05 15:35
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>Переносимый вариант (Mono) выйдет через пол-года.

Интересно, чем всё закончится. Как я понимаю, то у господина деИказы с доведением до ума начатых проектов не очень.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[52]: Создание игр на managed-языках
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 14.05.05 15:35
Оценка:
E>А про какие аварии вообще идет речь?

E>Я говорил об Ариан 5, который при старте взорвался.

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

А один военный корабль вообще на буксире тащить пришлось. Из-за деления на ноль
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[51]: Создание игр на managed-языках
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 14.05.05 15:39
Оценка:
WH>Да в питоне все обобщенное ибо типизация динамическая вот собственно и все. Вот и конец рефакторингу.

Занятно, что, как и конец, начало у рефакторинга с динамической типизации. Диалектика.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[56]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 14.05.05 15:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Gaperton wrote:


>> <http://arxiv.org/abs/cs.PL/0409016&gt;WH&gt;А отладчик и автокомплит на

>> этом DSL работать будут?
>> А ты пробовал когда-нибудь встроить в свою программу среду разработки
>> от MS и сделать из этого DSL? Хотя бы специально для этого
>> предназначенный Visual Basic for Applications? А ты попробуй.

C>Я пробовал. Все делается весьма просто — экспортируются свои объекты в

C>контекст VBA и все работает. Что характерно, работает без проблем —
C>отлаживать и писать код для автоматизации в VBA очень удобно.

А ты попробуй движок VBA в многопоточном режиме (в этом режиме свои объекты ты туда вставить не сможешь).
Кстати, VB — это не DSL. Чтобы сделать его похожим на DSL, попробуй добавить препроцессор и постпроцессор (интересно, как ты вообще это сделаешь, сохранив встроенный редактор и отладчик). Попробуй именить тулбары, меню. Сделать полноценное решение с DSL при помощи VBA настолько трудоемко, что сравнимо с написанием всего с нуля.

>> Тогда понятно станет, почему большинство производителей предпочитают

>> так не делать, не покупаясь на замануху вроде отладчика и
>> автокомплита. Все эти мульки в результате проще самому написать.

C>Агащаз. Даже отладчик типа VBAшного — это недели работы, автокомплит и

C>среда разработки — месяцы.

Eclipse.
Re[55]: Python vs C#
От: Cyberax Марс  
Дата: 14.05.05 15:43
Оценка:
WFrag wrote:

> C>Говорили "любой", а выходит что кроме замен на инфиксные операции и

> C>переименований некоторых функций, дальше вся синтаксическая гибкость
> C>Лиспа и не идет.
> Почему? Хитрость простая. Текст на DSL-языке — это просто строка,
> макрос может сделать с ней (в compile-time) все, что угодно — в том
> числе распарсить язык и отобразить в "скобочки" (которые в свою
> очередь разворачиваются другими макросами в низкоуровневый код).

И какие в этом преимущества? Точно так же, берем обычный
рекурсивно-нисходящий парсер, пишем для него грамматику DSLя и
транслятор в целевой язык (Java, например). Трудозатраты примерно такие же.

> C>И причем здесь ORM? Просто так, чтобы к слову? В той же Hibernate'е XML

> C>используется только для того, чтобы задавать настройки, то есть в
> C>качестве такого продвинутого ini-файла. Лисп там ну абсолютно никакой
> C>разницы бы не сделал.
> Настройки — это тоже язык.

Да, называется XML.

> Только в случае Java нам остается только интепретатор — загрузчик

> настроек. А в случае LISP мы могли бы его компилировать (вернее сумму
> настройки+модельные классы+бизнес логика) получая исключительно
> исполняемый код.

Вы всерьез считаете, что генерация прокси-классов и метаинформации из
описания — это самая большая часть ORM?

В Hibernate'е, кстати, можно mapping задавать прямо из Java-кода в
runtime'е при желании.

> И не нужно грузить настройки — они "вкомпилируются" в программу

> (Partial Evaluation во всей красе).

А что это даст, необходимость перекомпиляции при изменении настроек?
Спасибо, не надо.

> То есть даем на вход модельные классы+настройки (маппинг), получаем

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

Есть и для Java такие системы. В JDO, например, специальный компилятор
по mapping'у инструментирует байт-код скомпилированных классов.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[56]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 14.05.05 15:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


G>>А ты пробовал когда-нибудь встроить в свою программу среду разработки от MS и сделать из этого DSL?

WH>Именно этим я сейчас и занимаюсь. При том вполне успешно.
G>>Хотя бы специально для этого предназначенный Visual Basic for Applications? А ты попробуй. Тогда понятно станет, почему большинство производителей предпочитают так не делать, не покупаясь на замануху вроде отладчика и автокомплита. Все эти мульки в результате проще самому написать.
WH>Написать аналог ReSharpera? Да вы батенька .
А ReSharper сможет работать с вашим собственным языком и достанется вашим клиентам бесплатно? Вы, батенька, вообще в курсе, что такое DSL? Кстати, я работая на С++ прекрасно обхожусь без вашего ReSharpera. И неудержимой тяги писать его аналог не испытываю.

G>>Кстати, предупреждая ответы в духе "а вот .NET" — проект Visual Studio for Applications.NET свернут осенью прошлого года. Нет никакого дотнета . А прежде чем предлагать с каждой копией продукта тащить полноценный VS.NET подумайте о том, как это будет лицензироваться и сколько будет стоить вашему клиенту.

WH>0$ Ибо есть есть экспресы.
Это, конечно, меняет дело.
Re[50]: Создание игр на managed-языках
От: Cyberax Марс  
Дата: 14.05.05 15:46
Оценка:
FR wrote:

> C>А _откуда_ PyChecker узнает, что some_external_function возвращает

> C>переменную типа Test? Язык-то динамический.
> Сначала он импортирует все модули и все что можно проанализировать
> анализирует,
> Потом все таки запускает программу, и тоже анализирует.

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

> C>Нету его там в нормальном. Есть name-based polymorphism, который по

> сути
> C>тоже есть в шаблонах С++, это используется для CRTP (Curously Recurring
> C>Template Pattern).
> однако это не мешает легко писать на питоне обобщенный и повторно
> используймый код

А необобщенный (чиста конкретный) код на Python'е писать можно?

> C>В современных играх — уже не просто ini-файл.

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

Да, поэтому и важна их отлаживаемость и удобство написания.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[57]: Python vs C#
От: Cyberax Марс  
Дата: 14.05.05 17:35
Оценка:
Gaperton wrote:

> C>Я пробовал. Все делается весьма просто — экспортируются свои объекты в

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

А нафиг? Мне хватает однопоточного.

> Кстати, VB — это не DSL. Чтобы сделать его похожим на DSL, попробуй

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

VBA — это сам по себе DSL, с достаточно широким доменом.

> C>Агащаз. Даже отладчик типа VBAшного — это недели работы, автокомплит и

> C>среда разработки — месяцы.
> Eclipse.

Ява не умеет OLE, например.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[56]: Python vs C#
От: WFrag США  
Дата: 15.05.05 03:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>И какие в этом преимущества? Точно так же, берем обычный

C>рекурсивно-нисходящий парсер, пишем для него грамматику DSLя и
C>транслятор в целевой язык (Java, например). Трудозатраты примерно такие же.

Правда? Сомневаюсь.

Вот, кстати, можно эксперимент провести. Недавно на Lambda-the-Ultimate был предложен Cellang в качестве примера (http://staff.vbi.vt.edu/dana/ca/cellular.shtml).

Хороший такой этюд для программистов.
... << RSDN@Home 1.1.4 beta 6a rev. 438>>
Re[59]: Python vs C#
От: Cyberax Марс  
Дата: 15.05.05 10:22
Оценка:
Gaperton wrote:

> C>А нафиг? Мне хватает однопоточного.

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

Да, с предварительной трансляцией в P-код.

> Впрочем, в этом смысле должно быть не хуже Питона. Ну и, ктати, если

> тебе в будущем понадобится несколько инстансов VBA runtime в одном
> процессе — придется вешаться.

На это я уже наткнулся

> C>VBA — это сам по себе DSL, с достаточно широким доменом.

> Ну какой это *Domain Specific *Language.

VBA — это DSL, а домен у него — автоматизация оффисных приложений,
причем для этих целей его вполне хватает.

>>> C>Агащаз. Даже отладчик типа VBAшного — это недели работы, автокомплит и

>>> C>среда разработки — месяцы.
>>> Eclipse.
> C>Ява не умеет OLE, например.
> "OLE, OLE — это просто слезы" (с). А оно нужно, если пишешь на яве?

Да, нужно. Нужны фичи типа возможности вставлять в наш документ
диаграммы из Excel'я или вставлять наши документы в Ворд.

> 1) Есть COM-CORBA прокси. А CORBA ява умеет.


И при этом работает со всеми OLE-интерфейсами (которые с Automation не
совместимы), маршалирует графические вызовы и т.п.? Не верю.

> 2) Есть прямой Java-.NET interop от сторонних производителей.


Нафиг мне .NET сдался? Он тоже не умеет OLE.

> 3) В конце концов есть нативные интерфейсы, через которые можно все.

> Только нафига?

Угу, получится что все приложение будет написано на C++ с запускальщиком
на Java.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[60]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 15.05.05 16:00
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> Впрочем, в этом смысле должно быть не хуже Питона. Ну и, ктати, если

>> тебе в будущем понадобится несколько инстансов VBA runtime в одном
>> процессе — придется вешаться.

C>На это я уже наткнулся


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

>> C>VBA — это сам по себе DSL, с достаточно широким доменом.

>> Ну какой это *Domain Specific *Language.
C>VBA — это DSL, а домен у него — автоматизация оффисных приложений,
C>причем для этих целей его вполне хватает.
DSL — это когда ты свой язык делаешь для задачи. Где у тебя предметная область поддерживается на уровне языковых конструкций. Это не случай VBA — там ты всего-лишь имеешь возможность кастомизировать библиотеку. Если тебе этого хватает — это замечательно, но от этого VBA не становится DSL.

>>>> C>Агащаз. Даже отладчик типа VBAшного — это недели работы, автокомплит и

>>>> C>среда разработки — месяцы.
>>>> Eclipse.
>> C>Ява не умеет OLE, например.
>> "OLE, OLE — это просто слезы" (с). А оно нужно, если пишешь на яве?

C>Да, нужно. Нужны фичи типа возможности вставлять в наш документ

C>диаграммы из Excel'я или вставлять наши документы в Ворд.

>> 3) В конце концов есть нативные интерфейсы, через которые можно все.

>> Только нафига?

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

C>на Java.
Нет, если делать не через зад, а по человечески, то получится приложение на Java c native интерфейсами на С++ к COM-объектам. Но ты не подумай, я совсем не советую тебе использовать Java для твоей задачи. Просто хочу донести до тебя мысль, что со всем этим микрософтным добром халявы не будет. Мы год назад через это проходили, и пришли к выводу что с теми же затратами можно было и свою среду разработки со своим языком слабать. Только рисков меньше, и результат именно тот, который ты ожидаешь. Без сюрпризов.
Re[61]: Python vs C#
От: Cyberax Марс  
Дата: 15.05.05 16:43
Оценка:
Gaperton wrote:

>>> Впрочем, в этом смысле должно быть не хуже Питона. Ну и, ктати, если

>>> тебе в будущем понадобится несколько инстансов VBA runtime в одном
>>> процессе — придется вешаться.
> C>На это я уже наткнулся
> А говоришь, не нужен многопоточный режим .

А он мне не нужен, мне было нужно несколько инстансов VBA в одном процессе.

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


Уже давно решили, обошлись одним VBA

>

> C>VBA — это DSL, а домен у него — автоматизация оффисных приложений,
> C>причем для этих целей его вполне хватает.
> DSL — это когда ты свой язык делаешь для задачи. Где у тебя предметная
> область поддерживается на уровне языковых конструкций.

Именно. В VBA на уровне "языковых конструкций" (формочек, модулей
кода...) поддерживается автоматизация приложений, VBA как раз под это и
был заточен.

>>> Только нафига?

> C>Угу, получится что все приложение будет написано на C++ с
> запускальщиком
> C>на Java.
> Нет, если делать не через зад, а по человечески, то получится
> приложение на Java c native интерфейсами на С++ к COM-объектам.

Теоретик.... OLE — это ведь не просто три буквы, это и определенная
организация приложения, и КУЧА интерфейсов. Все это скрещивать с Явой —
ну уж нет, лучше на старом добром С++.

> Но ты не подумай, я совсем не советую тебе использовать Java для твоей

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

Мы тоже смотрели, VBA мне лично не особо нравится. Но вот в том-то и
дело, что других решиений _НЕТ_. Есть VSIP (еще не очень дозревший) и
есть несколько сред аля-VBA (спроси у Vlad'а). Ни одна из них не
поддерживает user-friendly (а это для нас главное) редактирование
формочек и кода.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[58]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 16.05.05 07:30
Оценка:
WolfHound wrote:
> G>Кстати, я работая на С++ прекрасно обхожусь без вашего ReSharpera. И неудержимой тяги писать его аналог не испытываю.
> Я тоже не испытывал пока не попробовал. Вобщем ReSharper это наркотик такой.

ReSharper это полный аналог возможностей IDEA, или еще что-то уникальное?
Posted via RSDN NNTP Server 1.9
Re[51]: Создание игр на managed-языках
От: FR  
Дата: 16.05.05 07:41
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>FR wrote:


>> C>А _откуда_ PyChecker узнает, что some_external_function возвращает

>> C>переменную типа Test? Язык-то динамический.
>> Сначала он импортирует все модули и все что можно проанализировать
>> анализирует,
>> Потом все таки запускает программу, и тоже анализирует.

C>Это значит "вернутся на клетку 1", то есть мы не можем убедится в

C>корректности программы пока ее не запустим.

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

>> C>Нету его там в нормальном. Есть name-based polymorphism, который по

>> сути
>> C>тоже есть в шаблонах С++, это используется для CRTP (Curously Recurring
>> C>Template Pattern).
>> однако это не мешает легко писать на питоне обобщенный и повторно
>> используймый код

C>А необобщенный (чиста конкретный) код на Python'е писать можно?


можно, если осторожно

>> C>В современных играх — уже не просто ini-файл.

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

C>Да, поэтому и важна их отлаживаемость и удобство написания.


Угу только почему-то отлаживатся и писать на питоне очень удобно, парадокс?
Вот к примеру прототипирование у меня сейчас посчти полностью на питоне, и даже когда надо отладить какой ни будь достаточно сложный алгоритмически кусок кода, быстрее получается сделать это на питоне, и потом переписать например на C++.
Re[59]: Python vs C#
От: Cyberax Марс  
Дата: 16.05.05 07:42
Оценка:
_vovin wrote:

>> G>Кстати, я работая на С++ прекрасно обхожусь без вашего ReSharpera.

> И неудержимой тяги писать его аналог не испытываю.
>> Я тоже не испытывал пока не попробовал. Вобщем ReSharper это наркотик
> такой.
> ReSharper это полный аналог возможностей IDEA, или еще что-то уникальное?

Почти полный, его пишут те же люди, что и IDEA. Хотя по сравнению с IDEA
он часто глючит.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[64]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 16.05.05 12:05
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет, у нас код из-за COM не разрастается (используем Comet вместо ATL),

C>да и организация интерфейсов в OLE достаточно разумная.

Хм, Comet, говоришь? Ща посмотрим...
Re[50]: Создание игр на managed-языках
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.05.05 14:26
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

WH>>нажимаю пару кнопок и получаю

WH>>
WH>>        private float Foo(int i, string s)
WH>>        {
WH>>            throw new NotImplementedException();
WH>>        }
WH>>

WH>>красота

ANS>Столько сложностей и всё ради того, чтобы получить ошибку времени выполнения!

Ну, кстати да. По идее, туда надо емиттить
private float Foo(int i, string s)
{
  #error Missing method body for private float MyClass.Foo(int, string);
  // throw new NotImplementedException(); 
}
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[51]: Создание игр на managed-языках
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.05.05 14:56
Оценка:
Здравствуйте, Sinclair, Вы писали:

ANS>>Столько сложностей и всё ради того, чтобы получить ошибку времени выполнения!

S>Ну, кстати да. По идее, туда надо емиттить
S>
S>private float Foo(int i, string s)
S>{
S>  #error Missing method body for private float MyClass.Foo(int, string);
S>  // throw new NotImplementedException(); 
S>}
S>


И в результате ничего не скомпилируется, пока не напишешь реализацию всех методов.
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[52]: Создание игр на managed-языках
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.05.05 15:29
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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

Именно. В чем цель и состоит. А то при массовом рефакторинге можно и забыть тело-то приписать. Так и доедет до юнит-тестирования недописанным
Можно и warning — по вкусу. Это просто уж совсем параноидальная опция — требует вручную пойти и раскомментировать throw, выкосив еррор. ъ.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[53]: Создание игр на managed-языках
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.05.05 15:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>Именно. В чем цель и состоит. А то при массовом рефакторинге можно и забыть тело-то приписать. Так и доедет до юнит-тестирования недописанным

Это не рефакторинг, это написание нового кода.
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[42]: Python vs C#
От: dimon0981 США  
Дата: 16.05.05 16:49
Оценка:
C>>Вообще, за такой код (с утечками ресурсов) я бы отрывал головы...

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


Угу закроются. Давайте вообще перестанем файлы закрывать, , они "полюбому закроются на выходе", или при Segmentation fault.
Пусть ОС заботится о закрытии файлов, как сборщик мусора заботится о мертых ссылках.
Re[60]: Python vs C#
От: L.C.R. Россия lj://_lcr_
Дата: 16.05.05 22:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> ReSharper это полный аналог возможностей IDEA, или еще что-то уникальное?


C>Почти полный, его пишут те же люди, что и IDEA. Хотя по сравнению с IDEA

C>он часто глючит.

5 копеек (с): как пишут на сайте IntelliJ, некоторые фичи невозможно реализовать в качестве плагина для VS, поэтому в перспективе они планируют собственную IDE под C#. Если это будет IDEA-like, то это просто здорово.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[61]: Python vs C#
От: L.C.R. Россия lj://_lcr_
Дата: 16.05.05 22:39
Оценка:
_vovin,

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


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

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

Кроме null.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[43]: Python vs C#
От: FR  
Дата: 17.05.05 07:38
Оценка:
Здравствуйте, dimon0981, Вы писали:

C>>>Вообще, за такой код (с утечками ресурсов) я бы отрывал головы...


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


D> Угу закроются. Давайте вообще перестанем файлы закрывать, , они "полюбому закроются на выходе", или при Segmentation fault.

D>Пусть ОС заботится о закрытии файлов, как сборщик мусора заботится о мертых ссылках.

ОС тут не причем. При выходе из модуля вызовутся деструкторы которые и закроют файлы.
Re[44]: Python vs C#
От: Cyberax Марс  
Дата: 17.05.05 07:40
Оценка:
FR wrote:

> D> Угу закроются. Давайте вообще перестанем файлы закрывать, , они

> "полюбому закроются на выходе", или при Segmentation fault.
> D>Пусть ОС заботится о закрытии файлов, как сборщик мусора заботится о
> мертых ссылках.
> ОС тут не причем. При выходе из модуля вызовутся деструкторы которые и
> закроют файлы.

То есть: "при выходе из модуля"? Будут ли вызваны деструкторы даже при
наличии циклов?

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[45]: Python vs C#
От: FR  
Дата: 17.05.05 08:05
Оценка:
Здравствуйте, Cyberax, Вы писали:

>> ОС тут не причем. При выходе из модуля вызовутся деструкторы которые и

>> закроют файлы.

C>То есть: "при выходе из модуля"? Будут ли вызваны деструкторы даже при

C>наличии циклов?

Если GC разрулит циклы то вызовутся. А так как в данном конкретном случае на объекты модуля нет внешних ссылок, то разрулится 100%.
Re[63]: Python vs C#
От: L.C.R. Россия lj://_lcr_
Дата: 17.05.05 11:36
Оценка:
_vovin,

_>Да все они давно обсуждены.


Дык я и хочу узнать, где они обсуждены... Искал-искал, ничего не нашёл. Про нуль только помню.

_>Я же сказал, что у каждого свой наркотик.

_>Просто из-за своего наркотика у меня бОльшая аллергия к другому более
_>грязому наркотику.

Да ява в общем-то и не претендовала на то чтобы быть проводником в астральный мир. Просто нормальный инструмент для нормальных задач. Типичный мэйнстрим. Про недостатки тоже осведомлён вполне. Мне просто интересно, что для тебя является существенным недостатком. Что мешает?

_>Вот, недавно, записал пример наркотического сеанса (4.23МБ):

_>http://www.smalltalk.ru/downloads/DolphinBouncingBalls.zip

Интересно
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[65]: Python vs C#
От: WolfHound  
Дата: 17.05.05 14:47
Оценка:
Здравствуйте, _vovin, Вы писали:

_>Будущее есть, но в нише. А причина — совсем даже не в цене.

Именно в цене. Кому нужен мегакрутой язык если для него нет специалистов? Правильно никому.
А специалистов при таких ценах на среду не будет. Ибо студенты народ бедный.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[66]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 17.05.05 15:02
Оценка:
WolfHound wrote:

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

>
> _>Будущее есть, но в нише. А причина — совсем даже не в цене.
> Именно в цене. Кому нужен мегакрутой язык если для него нет специалистов? Правильно никому.
> А специалистов при таких ценах на среду не будет. Ибо студенты народ бедный.

Нет, не то. Из всех наших смолтокеров я не знаю ни одного, которому
понадобилось что-то покупать, чтобы изучить и программировать на
Smalltalk-е. То же можно сказать и про дельфистов.
Posted via RSDN NNTP Server 1.9
Re[66]: Python vs C#
От: L.C.R. Россия lj://_lcr_
Дата: 17.05.05 15:08
Оценка:
WolfHound,

_>>Будущее есть, но в нише. А причина — совсем даже не в цене.

WH>Именно в цене. Кому нужен мегакрутой язык если для него нет специалистов? Правильно никому.
WH>А специалистов при таких ценах на среду не будет. Ибо студенты народ бедный.

Ты не учитываешь силу голого энтузиазма и открытых исходников. А она ненулевая по меньшей мере
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[67]: Python vs C#
От: WolfHound  
Дата: 17.05.05 15:20
Оценка:
Здравствуйте, L.C.R., Вы писали:

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

По сравнению с силой гигабаксов микрософта и сана...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[67]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.05.05 15:22
Оценка:
Здравствуйте, _vovin, Вы писали:

_>Нет, не то. Из всех наших смолтокеров я не знаю ни одного, которому

_>понадобилось что-то покупать, чтобы изучить и программировать на
_>Smalltalk-е. То же можно сказать и про дельфистов.

Ты кажется не понял. Вот возьмем к примеру янус. Он довольно сильно популяризует платформу среди посетителей RSDN. А теперь задай себе вопрос — мог бы янус быть написанным на ST?
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[68]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 17.05.05 15:25
Оценка:
AndrewVK wrote:

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

>
> _>Нет, не то. Из всех наших смолтокеров я не знаю ни одного, которому
> _>понадобилось что-то покупать, чтобы изучить и программировать на
> _>Smalltalk-е. То же можно сказать и про дельфистов.
>
> Ты кажется не понял. Вот возьмем к примеру янус. Он довольно сильно популяризует платформу среди посетителей RSDN. А теперь задай себе вопрос — мог бы янус быть написанным на ST?

Естественно мог бы. Хоть на брэйнфаке. Если ты действительно спрашиваешь
о теоретической возможности. Если же речь идет о вероятности этого
события, то это совсем другой вопрос.
Ну и я не вижу связи между ценой среды и янусом.
Posted via RSDN NNTP Server 1.9
Re[66]: Python vs C#
От: FR  
Дата: 17.05.05 15:31
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


_>>Будущее есть, но в нише. А причина — совсем даже не в цене.

WH>Именно в цене. Кому нужен мегакрутой язык если для него нет специалистов? Правильно никому.
WH>А специалистов при таких ценах на среду не будет. Ибо студенты народ бедный.

Вроде же есть бесплатные версии, тот же Squeak.
Re[70]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 17.05.05 15:32
Оценка:
AndrewVK wrote:

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

>
>
>>>Ты кажется не понял. Вот возьмем к примеру янус. Он довольно сильно популяризует платформу среди посетителей RSDN. А теперь задай себе вопрос — мог бы янус быть написанным на ST?
>
>
> _>Естественно мог бы. Хоть на брэйнфаке. Если ты действительно спрашиваешь
> _>о теоретической возможности.
>
> Нет конечно. Речь исключительно о возможности практической.
>
> _>Если же речь идет о вероятности этого
> _>события, то это совсем другой вопрос.
> _>Ну и я не вижу связи между ценой среды и янусом.
>
> Связь очень простая — отсутствие бесплатных средств разработки это однозначно приговор.

Squeak — бесплатный.
VW NC — некоммерческий.

BottomFeeder — свободный rss reader с открытыми исходниками.
Для Squeak-а есть куча софта. Если SqueakMap приравнять к RSDN (очень
условно), то сам Squeak — это янус.
Posted via RSDN NNTP Server 1.9
Re[44]: Python vs C#
От: dimon0981 США  
Дата: 17.05.05 16:02
Оценка:
Здравствуйте, FR, Вы писали:

D>> Угу закроются. Давайте вообще перестанем файлы закрывать, , они "полюбому закроются на выходе", или при Segmentation fault.

D>>Пусть ОС заботится о закрытии файлов, как сборщик мусора заботится о мертых ссылках.

FR>ОС тут не причем. При выходе из модуля вызовутся деструкторы которые и закроют файлы.


Я вообще эту мысль развиваю для любых языков. ОС полюбому закроет, не куда она не денется.
Re[48]: Python vs C#
От: _FRED_ Черногория
Дата: 17.05.05 20:56
Оценка:
Здравствуйте, FR, Вы писали:
C>>Они не лентяи, просто недетерминированая финализация — почти что
C>>фундаментальное свойство GC.

FR>Угу, но они вполне могли сделать неявный using.


Не спасаёт Не редко требуется что-то вроде
  // Do something...
    
  {
    CWaitCursor wait;
    // Do something...
  }
    
  // Do something...

И юзинг, ИМХО, сильно нагляднее.
under «*none*»,
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
Help will always be given at Hogwarts to those who ask for it.
Re[45]: Python vs C#
От: FR  
Дата: 18.05.05 03:58
Оценка:
Здравствуйте, dimon0981, Вы писали:

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


D>>> Угу закроются. Давайте вообще перестанем файлы закрывать, , они "полюбому закроются на выходе", или при Segmentation fault.

D>>>Пусть ОС заботится о закрытии файлов, как сборщик мусора заботится о мертых ссылках.

FR>>ОС тут не причем. При выходе из модуля вызовутся деструкторы которые и закроют файлы.


D>Я вообще эту мысль развиваю для любых языков. ОС полюбому закроет, не куда она не денется.


Так как ты слишком назойливо это повторяешь, то только могу предположить что ты или не работал или уже позабыл, что есть хорошие языки которые при правильном использовании, в отличие от новомодных, умеют сами закрывать файлы и освобождать другие ресурсы
Питон в этом отношении ни туда ни сюда. С одной стороны GC реализованный с помощью подсчета ссылок вроде позволяет гарантировать вызов конструкторов, но с другой циклы могут помешать, да и в документации многое невнятно. Вообще нормально все сделано в D можно и GC использовать и автоматический вызов деструкторов.
Re[71]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.05.05 08:41
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Кстати, ничего личного, но мне лично Янус сильно не нравится.


Твое право.

G> Могу по пунктам описать, почему.


Пожалуйста, но в соотв. форуме.

G> От платформы он может скорее оттолкнуть,


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

G> ИМХО, и популяризовать ее не может — альтернативного оффлайнового клиента, т.е. выбора, просто нет, вот им и пользуются.


Почему нет? Есть еще и RSDN NNTP.
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[72]: Python vs C#
От: Cyberax Марс  
Дата: 18.05.05 08:55
Оценка:
AndrewVK wrote:

> G> ИМХО, и популяризовать ее не может — альтернативного оффлайнового

> клиента, т.е. выбора, просто нет, вот им и пользуются.
> Почему нет? Есть еще и RSDN NNTP.

Как пользователь RSDN NNTP скажу: поддержка NNTP в RSDN слегка
кривовата, но Янус еще более неудобен.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[70]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 18.05.05 09:30
Оценка:
WolfHound wrote:

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

>
> LCR>Видишь — ненулевая! Даже по сравнению.
> Дык Апач в отличии от смаллтолка бесплатный. По тому и держится.
> К томуже там написано Across All Domains те включая странички Васей Пупкиных с содержанием
>

> Линух 4ever!!! Мелкософт на свалку!!

> Причем эни это не сами придумали, а наслушались "кулхацкеров".
>
> LCR>Поэтому не вижу смысла фанатеть за мэйнстрим вообще.
> А я не фанатею просто реально смотрю на вещи.
> LCR>Лучше найти себе что-нибудь красивое, и шлифовать своё мастерство одновременно получая и пользу, и удовольствие.
> Ты с этим предложением опоздал. Мне давно не интересно сидеть и что-то просто так шлифовать.
> А получать пользу со смаллталка не реально ибо он нафиг никому не нужен.
> Взять хотябы местного евангилистасмаллталка... на чем он пишет... правильно на жабе
Автор: _vovin
Дата: 16.05.05
.

> Если уж фанатик не может найти работу то как мне простому программеру найти работу на которой можно писать на смаллталке?

Есть разница писать на жаве и писать *только* на жаве. Использование
любых возможностей для заработка это здоровый прагматизм — "А я не
фанатею просто реально смотрю на вещи". Скажем C++ программист может с
успехом делать сайты на PHP.
А то что я пишу на Smalltalk-е, на жаве писалось бы впятеро дольше —
уровень абстракций не тот. А на C++ слишком много времени было бы убито
на мелкие правки, отладку и написание тестов.
Posted via RSDN NNTP Server 1.9
Re[71]: Python vs C#
От: WolfHound  
Дата: 18.05.05 09:56
Оценка:
Здравствуйте, _vovin, Вы писали:

_>А то что я пишу на Smalltalk-е, на жаве писалось бы впятеро дольше — уровень абстракций не тот.

Например?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[72]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 18.05.05 10:07
Оценка:
WolfHound wrote:

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

>
> _>А то что я пишу на Smalltalk-е, на жаве писалось бы впятеро дольше — уровень абстракций не тот.
> Например?

В частности — матричные операции, векторные операции, интегрирование.
Фатически реализован собственный математический DSL. Операторы и
замыкания тут имеют решающее значание.
Posted via RSDN NNTP Server 1.9
Re[73]: Python vs C#
От: WolfHound  
Дата: 18.05.05 10:14
Оценка:
Здравствуйте, _vovin, Вы писали:

_>В частности — матричные операции, векторные операции, интегрирование.

_>Фатически реализован собственный математический DSL.
_>Операторы и
Операторы есть в C#
_>замыкания тут имеют решающее значание.
А что ты замыкать собрался?
Можно пример кода?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[66]: Python vs C#
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.05.05 10:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


_>>Будущее есть, но в нише. А причина — совсем даже не в цене.

WH>Именно в цене. Кому нужен мегакрутой язык если для него нет специалистов? Правильно никому.
WH>А специалистов при таких ценах на среду не будет. Ибо студенты народ бедный.
Все зависит от предметной области. 1С относительно недавно, но количество программистов растет с каждым днем.
И относительно не бесплатен
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[74]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 18.05.05 11:27
Оценка:
WolfHound wrote:

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

>
> _>В частности — матричные операции, векторные операции, интегрирование.
> _>Фатически реализован собственный математический DSL.
> _>Операторы и
> Операторы есть в C#

Как это помогает жаве? Вдобавок *полиморфные* операторы, плюс
возможность их определять в примитивных классах: Float, Integer, Number.

> _>замыкания тут имеют решающее значание.

> А что ты замыкать собрался?

То, что в жаве замыкается с трудом.

> Можно пример кода?


Нет под рукой.
Если видел демку, там был простой пример с замыканиями.
Ну и язык это полдела. Часть времени я провожу в том же стиле, как это
показано в демке — загружаю свой COM server, останавливаю в нужном
месте, инспектирую состояние, изменяю реализацию, добавляю новые методы,
и т.д.
Примерно то же делаю и на жаве, только в рамках веб-приложения под
Tomcat. На каждый чих приходится перегружать приложение — одна
конфигурация поднимается минуты полторы (ногами не бить, проектировал не
я, поэтому и говорю, что убогий язык порождает убогие решения).
Posted via RSDN NNTP Server 1.9
Re[75]: Python vs C#
От: WolfHound  
Дата: 18.05.05 12:00
Оценка:
Здравствуйте, _vovin, Вы писали:

_>Как это помогает жаве?

Жабе никак.
Но ты ее в один ряд с C# поставил. Или я тебя не так понял?
_>Вдобавок *полиморфные* операторы, плюс возможность их определять в примитивных классах: Float, Integer, Number.
Это типа както так? Или как?
    internal struct Matrix
    {}

    internal struct Vector
    {
        private float x;
        private float y;
        private float z;

        public Vector(float x, float y, float z)
        {
            this.x = x;
            this.y = y;
            this.z = z;
        }

        public static Vector operator +(Vector l, Vector r)
        {
            return new Vector(l.x + r.x, l.y + r.y, l.z + r.z);
        }

        public static Vector operator *(Vector l, float f)
        {
            return new Vector(l.x * f, l.y * f, l.z * f);
        }

        public static Vector operator *(Vector l, Matrix m)
        {
            return new Vector(l.x, l.y, l.z);
        }
    }


                Vector v1 = new Vector(1, 2, 3);
                Vector v2 = new Vector(3, 2, 1);
                v1 = (v1 + v2) * 3;
                Matrix m = new Matrix();
                v1 = v1 * m;


>> _>замыкания тут имеют решающее значание.

>> А что ты замыкать собрался?
_>То, что в жаве замыкается с трудом.
Я имел в виду что ты в матричных операциях?

_>Ну и язык это полдела. Часть времени я провожу в том же стиле, как это показано в демке — загружаю свой COM server, останавливаю в нужном месте, инспектирую состояние, изменяю реализацию, добавляю новые методы, и т.д.

Для этого смаллталк не нужен. Достаточно MS VC++ Я свои СОМ серверы так и отлаживал.

_>Примерно то же делаю и на жаве, только в рамках веб-приложения под Tomcat. На каждый чих приходится перегружать приложение — одна конфигурация поднимается минуты полторы (ногами не бить, проектировал не я, поэтому и говорю, что убогий язык порождает убогие решения).

Те кто-то что-то криво напрограммил, а ты это обобщаешь на весь язык?
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[75]: Python vs C#
От: Cyberax Марс  
Дата: 18.05.05 12:03
Оценка:
_vovin wrote:

> Примерно то же делаю и на жаве, только в рамках веб-приложения под

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

В веб-приложениях в TomCat'е прекрасно работает code hotswap, так что
нужно просто правильно настроить среду.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[71]: Python vs C#
От: WolfHound  
Дата: 18.05.05 12:10
Оценка:
Здравствуйте, L.C.R., Вы писали:

LCR>Всё что нужно смоллтоку — это сформировать комьюнити вокруг себя. А я так понимаю, оно уже есть, и вроде как растёт (хотя и медленно). Так что поживём — увидим.

Мечтатель...

LCR>Если ты перестал стремиться к красоте — ты пропал!

Ты за меня не волнуйся. Я какнибудь сам разберусь что мне делать дальше.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[76]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 18.05.05 12:23
Оценка:
Cyberax wrote:
> _vovin wrote:
>
>
>>Примерно то же делаю и на жаве, только в рамках веб-приложения под
>>Tomcat. На каждый чих приходится перегружать приложение — одна
>>конфигурация поднимается минуты полторы (ногами не бить, проектировал не
>>я, поэтому и говорю, что убогий язык порождает убогие решения).
>
>
> В веб-приложениях в TomCat'е прекрасно работает code hotswap, так что
> нужно просто правильно настроить среду.
>

Это "о маленькое" от реальных потребностей. Поэтому и говорю что убого.
Posted via RSDN NNTP Server 1.9
Re[76]: Python vs C#
От: _vovin http://www.pragmatic-architect.com
Дата: 18.05.05 12:48
Оценка:
WolfHound wrote:

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

>
> _>Как это помогает жаве?
> Жабе никак.
> Но ты ее в один ряд с C# поставил. Или я тебя не так понял?

Где?? Для C# я бы привел слегка другой список.

> _>Вдобавок *полиморфные* операторы, плюс возможность их определять в примитивных классах: Float, Integer, Number.

> Это типа както так? Или как?
>
>     internal struct Matrix
>     {}
> 
>     internal struct Vector
>     {
>         private float x;
>         private float y;
>         private float z;
> 
>         public Vector(float x, float y, float z)
>         {
>             this.x = x;
>             this.y = y;
>             this.z = z;
>         }
> 
>         public static Vector operator +(Vector l, Vector r)
>         {
>             return new Vector(l.x + r.x, l.y + r.y, l.z + r.z);
>         }
> 
>         public static Vector operator *(Vector l, float f)
>         {
>             return new Vector(l.x * f, l.y * f, l.z * f);
>         }
> 
>         public static Vector operator *(Vector l, Matrix m)
>         {
>             return new Vector(l.x, l.y, l.z);
>         }
>     }
> 
> 
>                 Vector v1 = new Vector(1, 2, 3);
>                 Vector v2 = new Vector(3, 2, 1);
>                 v1 = (v1 + v2) * 3;
>                 Matrix m = new Matrix();
>                 v1 = v1 * m;
>

>


Это для примера единственный метод Number>>abs или AbstractMatrix>>+.
Сравни с Math.abs(int), Math.abs(long), Math.abs(float), Math.abs(double).
Думаю каждый программист вынужден был хотя бы раз написать свой класс
StringUtils. Вот в текущем жававской проекте вижу целых два StrUtils.

Так у меня большинство операций определено в классе AbstractMatrix, а в
RectangularMatrix, SquareMatrix и Vector переопределены только
специфичные. А у тебя вон Vector полностью налопачен вручную — таков удел.

>

>>>_>замыкания тут имеют решающее значание.
>>>А что ты замыкать собрался?
>
> _>То, что в жаве замыкается с трудом.
> Я имел в виду что ты в матричных операциях?

В основном это касается векторов — в большинстве случаев от них нужно
поведение контейнера.

>

> _>Ну и язык это полдела. Часть времени я провожу в том же стиле, как это показано в демке — загружаю свой COM server, останавливаю в нужном месте, инспектирую состояние, изменяю реализацию, добавляю новые методы, и т.д.
> Для этого смаллталк не нужен. Достаточно MS VC++ Я свои СОМ серверы так и отлаживал.

Совершенно не катит, сам с MSVC работаю плотно. Убогие возможности по
инспектированию/модификации объектов, изменению кода и управлению стеком
вызовов.

>

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

Да, я такой ужасный — заметил тенденцию, что на кривом языке жава
создаются в среднем более кривые библиотеки и приложения.
Это можно было бы объяснить тем, что у смолтокеров в среднем уровень
выше. Но вопрос в том, где причина, а где следствие. Наблюдал несколько
раз, как уже опытный программист очень быстро поднимал свои скилзы в
ООП, стоило ему попрактиковаться на Smalltalk.
Posted via RSDN NNTP Server 1.9
Re[73]: Python vs C#
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 18.05.05 13:10
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>Как пользователь RSDN NNTP скажу: поддержка NNTP в RSDN слегка
C>кривовата, но Янус еще более неудобен.

У меня RSDN NNTP через мозила-сандербёд треды не держал. Уж лучше Янус. Хотя Янус это у меня единственная пользовательская прога, которую нужно запускать из-под администратора. Под простым пользователем не идёт. Все другие проги у которых был этот баг благополучно ушли в мусорку.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[74]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.05.05 14:33
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Хотя Янус это у меня единственная пользовательская прога, которую нужно запускать из-под администратора. Под простым пользователем не идёт. Все другие проги у которых был этот баг благополучно ушли в мусорку.


Это не баг, это особенности СОМ и UrlMon. Я лично вижу 2 пути обхода:
1) Добавить ключик, который блокирует регистрацию протокола. Но при смене версий придется этот ключик руками отключать и включать.
2) Отказаться от поддержки протокола вне процесса януса.
3) Вынести регистрацию протокола в инсталлятор.

Лично мне все три способа не очень нравяться.
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[75]: Python vs C#
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 18.05.05 15:01
Оценка:
ANS>>Хотя Янус это у меня единственная пользовательская прога, которую нужно запускать из-под администратора. Под простым пользователем не идёт. Все другие проги у которых был этот баг благополучно ушли в мусорку.

AVK>Это не баг, это особенности СОМ и UrlMon. Я лично вижу 2 пути обхода:


Если программа не запускается под поддерживаемой(!) ОС, то фича это или баг — вопрос натурально философский. Как по мне, то в 21 веке прикладных программ не работающих из под простого пользователя быть уже не должно. Я вношу свою лепту не пользуясь такими програмами. С янусом вопрос простой — регулярно ходить на сайт не удобно (особенно учитывая отсутсвие на сайте поддержки пользовательских профилей, в которых, хотя б, запоминались прочитанные месаги), nntp — без тредов фиг вспомниш где видел хоть что-то интересное (держались бы треды остался б на nntp). Янус — с ним временно приходится мирится, но это пока интерес к сайту не остыл. Попробовать что ли через RSS читать?

AVK>1) Добавить ключик, который блокирует регистрацию протокола. Но при смене версий придется этот ключик руками отключать и включать.

AVK>2) Отказаться от поддержки протокола вне процесса януса.

На кой ляд он вообще нужен?

AVK>3) Вынести регистрацию протокола в инсталлятор.


С этим то какие проблемы? Всё равно инсталятор есть.

AVK>Лично мне все три способа не очень нравяться.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[69]: Python vs C#
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 18.05.05 15:01
Оценка:
ANS>>Опен-соурсе рулит, однозначно
S> Вообще то 1С наполовину Опен-соурсе. Это касается конфигураций под различные задачи.

Это та половина, которая имеет принципиальное значение.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[70]: Python vs C#
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.05.05 15:15
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>>Опен-соурсе рулит, однозначно

S>> Вообще то 1С наполовину Опен-соурсе. Это касается конфигураций под различные задачи.

ANS>Это та половина, которая имеет принципиальное значение.


Не совсем понял про принципиальное значени. Сами конфигурации на самом деле по трудозатратам и проектировании могут превосходить сам движек 1С (конфигурирование, выполнение кода итд кторая сама по себе ноль без конфигураций).
Ребята хотять создать свой движек,
http://1l.w4b.ru/
http://www.vtools.ru/2c.htm
но пока Опен-соурсе движется медленно
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[71]: Python vs C#
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 18.05.05 15:25
Оценка:
ANS>>Это та половина, которая имеет принципиальное значение.

S> Не совсем понял про принципиальное значени. Сами конфигурации на самом деле по трудозатратам и проектировании могут превосходить сам движек 1С (конфигурирование, выполнение кода итд кторая сама по себе ноль без конфигураций).


движок сам по себе нафик никому не сдался.

S> Ребята хотять создать свой движек,

S> http://1l.w4b.ru/

http://1l.w4b.ru/?news_detail=80
Питон. Еслиб на C# писали, может у них что и получилось бы, а так труп, однозначно

S> http://www.vtools.ru/2c.htm

S> но пока Опен-соурсе движется медленно

я ж и говорю. не плотют за движок.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[72]: Python vs C#
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 18.05.05 15:47
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>>>Это та половина, которая имеет принципиальное значение.


S>> Не совсем понял про принципиальное значени. Сами конфигурации на самом деле по трудозатратам и проектировании могут превосходить сам движек 1С (конфигурирование, выполнение кода итд кторая сама по себе ноль без конфигураций).


ANS>движок сам по себе нафик никому не сдался.


S>> Ребята хотять создать свой движек,

S>> http://1l.w4b.ru/

ANS>http://1l.w4b.ru/?news_detail=80

ANS>Питон. Еслиб на C# писали, может у них что и получилось бы, а так труп, однозначно
Вот здесь позволю несогласится. Основная задача у них это использование текущих конфигураций, а там аля васик, питон походит, правда как они его собираются использовать. Кроме всего прочего они хотят сделать межплатформенный движек ориентированный прежде всего на SQL.
Вторая проблема, это атрибуты неопределенного типа (Object). Так, что не факт, что затея труповая, во всяком случае в проекте 2С их интерпритатор превосходит в 1С, но в большинстве случаев все упирается в БД.
Вот если бы создали свое хранилище со своим сервером и выполнение объектной модели на сервере (аля хранимых процедур, но с применением объектного кода) то тогда выбор манагед языка с применеием вариантов аля Delphi позволило бы ускорить методы проведения (транзакций), отчетности со сложной иерархией применяя навигацию аля локальные БД не прибегая к услугам клиента.
Тогда бы и за движек платили, а пока ....

S>> http://www.vtools.ru/2c.htm

S>> но пока Опен-соурсе движется медленно

ANS>я ж и говорю. не плотют за движок.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[72]: Python vs C#
От: L.C.R. Россия lj://_lcr_
Дата: 18.05.05 18:40
Оценка:
WolfHound,

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


LCR>>Всё что нужно смоллтоку — это сформировать комьюнити вокруг себя. А я так понимаю, оно уже есть, и вроде как растёт (хотя и медленно). Так что поживём — увидим.

WH>Мечтатель...
Зайди в "коллеги улыбнитесь" — там шикарная подборка 19 гениальных заблуждений в науке и технике. Так что здравый смысл не канает

LCR>>Если ты перестал стремиться к красоте — ты пропал!

WH>Ты за меня не волнуйся. Я как нибудь сам разберусь что мне делать дальше.
Гхм. Ну рад за тебя.

Шаг в сторону: как ты считаешь, нужно ли обычному программисту (ремесленнику практически (!)) вдохновение? Можешь конечно не отвечать, а назвать это злостным оффтопом и удалить сообщение, но всё-таки?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[39]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 00:35
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


FR>>По объему кода, вот простейшая программка считывает файл построчно и выводит его в другой файл отсортированным по строкам:

WH>Функции readlines в библиотеке .НЕТ нет

Все есть:

string[] lines = Array.Sort(File.ReadAllLines(@"C:\boot.ini"));



WH>Отсутствие типизации и необходимости объявлять переменные в питоне я считаю большим недостатком.

+++++++++100


FR>>Суммирование чисел из файла(в каждой строке файла одно число):

WH>Опять библиотека...
WH>Да будут операторы
WH>
WH>        delegate T Operator<T>(T l, T r);
WH>        interface IMathOperators<T>
WH>        {
WH>            Operator<T> Add { get; }
WH>            Operator<T> Sub { get; }
WH>            Operator<T> Mul { get; }
WH>            Operator<T> Div { get; }
WH>        }
WH>        class MathOperatorsInt : IMathOperators<int>
WH>        {
WH>            public Operator<int> Add { get { return delegate(int l, int r) { return l + r; }; } }
WH>            public Operator<int> Sub { get { return delegate(int l, int r) { return l - r; }; } }
WH>            public Operator<int> Mul { get { return delegate(int l, int r) { return l * r; }; } }
WH>            public Operator<int> Div { get { return delegate(int l, int r) { return l / r; }; } }
WH>        }
WH>        static Dictionary<Type, object> MathOperatorsMap = new Dictionary<Type, object>();
WH>        static IMathOperators<T> MathOperators<T>()
WH>        {
WH>            return (IMathOperators<T>)MathOperatorsMap[typeof(T)];
WH>        }
WH>        static Program()
WH>        {
WH>            MathOperatorsMap.Add(typeof(int), new MathOperatorsInt());
WH>        }
WH>

WH>Теперь сделаем недостающие функции
WH>
WH>        delegate T Parse<T>(string s);
WH>        static IEnumerable<T> Map<T>(Stream stream)
WH>        {
WH>            Parse<T> parse = (Parse<T>)Delegate.CreateDelegate(typeof(Parse<T>),
WH>                typeof(T), "Parse");
WH>            foreach (string line in Lines(stream))
WH>                yield return parse(line);
WH>        }
WH>        static T Sum<T>(IEnumerable<T> numbers)
WH>        {
WH>            Operator<T> add = MathOperators<T>().Add;
WH>            T val = default(T);
WH>            foreach (T number in numbers)
WH>                val = add(val, number);
WH>            return val;
WH>        }
WH>

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

WH>
WH>    using (Stream file = File.OpenRead("text.txt"))
WH>        Console.WriteLine(Sum(Map<int>(file)));
WH>


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

WH>Это тоже решается библиотекой.

Не он, в данном случае, тебя функциональными фичами Питона пытался накормить. Видимо незнал, что кое-что можно и на Шарпе. Тут отвечать нужно как-то так :

int sum = 0;
Array.ForEach(File.ReadAllLines(@"C:\data.txt"), delegate(string elem) { sum += int.Parse(elem); });


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

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

WH>А самое главное что все что ты привел очень синтетические задачи не имеющие с реальностью ничего общего.


+1
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[47]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 00:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>4)C# исполняется быстрее.


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

E>Здесь была большая тема по этому поводу: Типизация
Автор: Quintanar
Дата: 02.03.05


Ну, там частенько понятия подменяли. Все же динамическая типизация и отсутствие указания типов в коде — это не одно и то же. Вывод типов в ФЯ достиг очень высокого уровня и может порой казаться динамической типизацией, но при этом все же остаеются почти все приемущества статической типизации. А вот приемущества истенно динамической типизации при сравнении ее с компонентным подходом и хорошего качества ООП я так и не увидил. Я плохо смотрел?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[47]: Создание игр на managed-языках
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.05.05 06:11
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А вот приемущества истенно динамической типизации при сравнении ее с компонентным подходом и хорошего качества ООП я так и не увидил. Я плохо смотрел?


Не знаю, Влад. В области компонентного подхода ничего не могу сказать.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[71]: Python vs C#
От: WolfHound  
Дата: 19.05.05 06:42
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Здесь идет речь о твоем собственном профессионализме, как разработчика.

Плавный перешод на личности
G>Его предлагается "шлифовать". Тебе это не интересно (о чем ты заявил) — не занимайся.
Мне не интересно заниматься чемто абстрактным. Реализация реальных задач позволяет это делать на порядки эффективней.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[40]: Python vs C#
От: FR  
Дата: 19.05.05 07:18
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Не он, в данном случае, тебя функциональными фичами Питона пытался накормить. Видимо незнал, что кое-что можно и на Шарпе. Тут отвечать нужно как-то так :


VD>
VD>int sum = 0;
VD>Array.ForEach(File.ReadAllLines(@"C:\data.txt"), delegate(string elem) { sum += int.Parse(elem); });
VD>


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


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

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


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

WH>>А самое главное что все что ты привел очень синтетические задачи не имеющие с реальностью ничего общего.


VD>+1


так я просил чтобы что-то реальное привели, но не дождался.
Re[47]: Создание игр на managed-языках
От: _vovin http://www.pragmatic-architect.com
Дата: 19.05.05 08:03
Оценка:
VladD2 wrote:
> Здравствуйте, eao197, Вы писали:
>
> E>Здесь была большая тема по этому поводу: Типизация
Автор: Quintanar
Дата: 02.03.05

>
> Ну, там частенько понятия подменяли. Все же динамическая типизация и отсутствие указания типов в коде — это не одно и то же. Вывод типов в ФЯ достиг очень высокого уровня и может порой казаться динамической типизацией, но при этом все же остаеются почти все приемущества статической типизации. А вот приемущества истенно динамической типизации при сравнении ее с компонентным подходом и хорошего качества ООП я так и не увидил. Я плохо смотрел?

Мое и не только мнение — сколько не смотри, а вкус блюда не узнаешь не
попробовав.
Тут дело в способе мышления, а не в знании конструкций и паттернов.

http://www.livejournal.com/users/behrk/318434.html
Человек стал работать со смолтоком после того, как устроил голосование
какой новый язык стоит изучить. Так что мнение можно считать
не-"фанатическим".
Posted via RSDN NNTP Server 1.9
Re[41]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.05.05 08:13
Оценка:
Здравствуйте, FR, Вы писали:

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


Не в порядке флейма, а интересу ради. Как на Питоне будет выглядеть решение задачки из сообщения Re[2]: Хочу стать .Net-чиком
Автор: AndrewVK
Дата: 03.04.05
?
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[42]: Python vs C#
От: FR  
Дата: 19.05.05 08:30
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Не в порядке флейма, а интересу ради. Как на Питоне будет выглядеть решение задачки из сообщения Re[2]: Хочу стать .Net-чиком
Автор: AndrewVK
Дата: 03.04.05
?


Я не совсем понял про длину ключей и значений, в приведенном примере длины же не корректны. В общем сформулируй более понятно задачу и желательно кусочек реальных данных.
Re[43]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.05.05 09:05
Оценка:
Здравствуйте, FR, Вы писали:

FR>Я не совсем понял про длину ключей и значений, в приведенном примере длины же не корректны.


Вроде корректны.

FR> В общем сформулируй более понятно задачу и желательно кусочек реальных данных.


Данные это собственно файл свойств рабочей копии Subversion. Вот реальный пример:
K 16
rsdn:auto-deploy
V 5
false
K 4
ssss
V 37
efwrweagf
tgfrh
trs
ht
rsh
trs

K 12
svn:keywords
V 42
Author LastChangedDate LastChangedRevision
END
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[79]: Python vs C#
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 19.05.05 09:07
Оценка:
AVK>Разумеется. Но при этом о развертывании без инсталлятора речь не идет. Так что тут нужно выбирать — либо простота развертывания, либо возможность работы не из под администратора. Мне первое показалось более важным.

Сделай опцию. Типа "регистрировать при старте или нет". Плюс, при ошибке регистрации прога должна таки запускатся.

Впрочем, всё завязал, завязал...
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[80]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.05.05 09:26
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Сделай опцию. Типа "регистрировать при старте или нет".


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

ANS> Плюс, при ошибке регистрации прога должна таки запускатся.


Согласен.
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[44]: Python vs C#
От: FR  
Дата: 19.05.05 09:26
Оценка:
Здравствуйте, AndrewVK, Вы писали:

Еще вопросы: перевод строки считается за символ? Или чтение построчное?
Если построчное то данные не могут начинатся с K V или END?
Файл должен быть корректным в том отношении что у каждого ключа есть значение?

Эти вопросы возникли потому что я вижу не стыковку тут:

V 37
efwrweagf
tgfrh
trs
ht
rsh
trs

K 12

тут ни как ни набирается 37 символов.

Извини за назойливость, для меня задача полностью абстрактна.
Re[45]: Python vs C#
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 19.05.05 09:40
Оценка:
FR>V 37
FR>efwrweagf
FR>tgfrh
FR>trs
FR>ht
FR>rsh
FR>trs

FR>K 12


FR>тут ни как ни набирается 37 символов.


я так понял, что подсчет побайтовый, а не побуквенный. если перевод строки 2 ьайта, то получается
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[45]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.05.05 10:27
Оценка:
Здравствуйте, FR, Вы писали:

FR>Еще вопросы: перевод строки считается за символ? Или чтение построчное?


Я тебе реальные данные привел. Погляди сам.

FR>Если построчное то данные не могут начинатся с K V или END?


Могут.

FR>Файл должен быть корректным в том отношении что у каждого ключа есть значение?


Да.

FR>Эти вопросы возникли потому что я вижу не стыковку тут:


FR>V 37

FR>efwrweagf
FR>tgfrh
FR>trs
FR>ht
FR>rsh
FR>trs

FR>K 12


FR>тут ни как ни набирается 37 символов.


Вот рабочий алгоритм на первом шарпе:
private void FillFromHashToDisk(string file, IDictionary props)
{
    string currentKey = "";
    using (StreamReader sr = new StreamReader(file))
        while (true)
        {
            string tag = sr.ReadLine();
            if (tag == "END")
                return;
            string[] parts = tag.Split(' ');
            if (parts[0] == "K")
                currentKey = ReadCharBlock(int.Parse(parts[1]), sr);
            else if (parts[0] == "V")
                props[currentKey] = ReadCharBlock(int.Parse(parts[1]), sr);
        }
}

private static string ReadCharBlock(int length, StreamReader sr)
{
    char[] buffer = new char[length];
    sr.Read(buffer, 0, length);
    return new string(buffer);
}


Да, забыл сказать — кодировка в файле UTF8.
... << RSDN@Home 1.1.4 beta 7 rev. 455>>
AVK Blog
Re[72]: Python vs C#
От: Gaperton http://gaperton.livejournal.com
Дата: 19.05.05 13:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


G>>Здесь идет речь о твоем собственном профессионализме, как разработчика.

WH>Плавный перешод на личности
Это не переход на личности. Это не наезд. Мне показалось, что ты неправильно понял пост, на который отвечаешь. Я хотел акцентировать твое внимание на том, что в этом посте речь идет о личном профессионализме — твоем, моем — чьем угодно, который надо "шлифовать". В то, что ты отказываешься это делать (а ты это написал) я не верю — кто будет так себя оговаривать?
G>>Его предлагается "шлифовать". Тебе это не интересно (о чем ты заявил) — не занимайся.
WH>Мне не интересно заниматься чемто абстрактным. Реализация реальных задач позволяет это делать на порядки эффективней.
В последнем я с тобой полностью согласен. Не согласен с первым — тем самым ты отрицаешь положительное влияние теории на практику. Касательно языков — многим кажется, например, что знакомство с языками вроде Смоллтока улучшает способности к ОО дизайну даже если твой основной язык Java или C#. Думаю, мы все равно останемся каждый при своем мнении.
Re[41]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 15:58
Оценка:
Здравствуйте, FR, Вы писали:

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


Не особо то. Но можно и проще:
foreach (string value in File.ReadAllLines(@"C:\data.txt"))
  sum += int.Parse(elem);


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

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

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

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


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


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


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

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



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

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

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


ЗЫ

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

Кстати, если уж говорить о подобных языках, то лучше обратить внимание на Руби. С производительностью у него еще хуже чем у Питона, да и проблемы почти те же, но вот многие решения намного олее мощьны (если можно так выразиться).Те же континюэйшоны в Руби сделаны на пять с плюсом. Анонимные блоки очень кратики и элегантны. И многое другое. Но опять те же проблемы, что и у Питона.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[44]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 18:38
Оценка:
Здравствуйте, FR, Вы писали:

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


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

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


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

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


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

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

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

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

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

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


А вот использование:
arguments = new Arguments();
if (arguments.ParseArgumentsWithUsage(args))
    Work();
...

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


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

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


С чего бы это? Простые задачи можно решать на любом языке. А сложные требуют фрэймворков. Ты на своем Перле и Питоне задолбашся серьезный парсер писать. А я его и на С с каким-нить Бизоном в раз сварганю. А по скорости так они оба в даун уйдут что по сравнеию с С, что по сравнению с C#.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[55]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 18:56
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Разумеется, нет. Работы наверняка ведутся, но я ничего внятного не скажу — не встречал.


Да, да. В следующем году будет 50 лет как...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[61]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 19:18
Оценка:
Здравствуйте, _vovin, Вы писали:

_>Тогда наркотики у каждого свои. Использую IDEA полтора года, но выкинул

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

Дык, отличительной особенностью РеШарпера является язык для которого он создан.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[73]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 19:37
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>AndrewVK wrote:


>> G> ИМХО, и популяризовать ее не может — альтернативного оффлайнового

>> клиента, т.е. выбора, просто нет, вот им и пользуются.
>> Почему нет? Есть еще и RSDN NNTP.

C>Как пользователь RSDN NNTP скажу: поддержка NNTP в RSDN слегка

C>кривовата, но Янус еще более неудобен.

Видимо все так. На всех не угодишь. Но то что вы все здась. И то что половина вас на NNTP, а половина на Янусе свидетельствует о том, что всех в общем устраивает положение дел. Что же до пополяризации... все это (сайт, ннтп, янус) сделано на Шарпе и дотнете. И аналогичной по кассу и широте возожностей реализации на:
* Смолтоне.
* Питоне.
* Лиспе.
* С++.
* и т.п.

Нет. Сделано все это перерывах между фрэмами и работой. Работой надо признаться довольно плотной за реальные и отнюдь не малый деньги.

Далее каждый делает для себя выводы или ищет оправдания.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[75]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 19:39
Оценка:
Здравствуйте, AndrewVK, Вы писали:

ANS>>Хотя Янус это у меня единственная пользовательская прога, которую нужно запускать из-под администратора. Под простым пользователем не идёт. Все другие проги у которых был этот баг благополучно ушли в мусорку.


AVK>Это не баг, это особенности СОМ и UrlMon.


Извини, но сто раз говорено, что регистрировать ком-объекты нужно при инсталяции, ане при запуске. Это все от лени и отсутсвия времения. Да и можно было бы преежить и без всех этих UrlMon.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[77]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 19:41
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Проблема ровно одна — при этом янус лишится одного очень вкусного свойства, а именно deploy by copy.


1. При наличии инсталлятора — это не проблема.
2. Можно просто проверять, что регистрация уже есть и не пытаться сделать ее еще раз. Тогда запустив один раз Янус из под Админа можно будет потом пользоваться из под любого пользователя.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[80]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 19:43
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Сделай опцию. Типа "регистрировать при старте или нет". Плюс, при ошибке регистрации прога должна таки запускатся.


Дык, а что сразу "сделатй" сделай сам. Все в ваших руках.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[67]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 19:44
Оценка:
Здравствуйте, L.C.R., Вы писали:

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


Ага. Если подпитывается ненавестью (а стоотвественно и бабками) крупных игроков на рынке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[69]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 19:48
Оценка:
Здравствуйте, L.C.R., Вы писали:

LCR>Видишь — ненулевая! Даже по сравнению.


Гы.

1. Неткрфт — это мягко говоря пристрастная статистика. Меряем количество веб-страничек студентов и количество коммерческих сайтов и делаем выводы...
2. Апачь кормят дай дорогу. Вот кто нить РШарп так подкормил бы...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[71]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 20:04
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Напрасно преуменьшаешь долю Apach + Linux. Она выше даже за вычетом Васей Пупкиных. Можно у Gartner и IDC глянуть — просто так лень, но готов заключить пари — и я достану сведения.


Вот и дал бы ссылочку, а не делал многозначительные намеки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[68]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 20:12
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

S>> Все зависит от предметной области. 1С относительно недавно, но количество программистов растет с каждым днем.

S>> И относительно не бесплатен

ANS>Опен-соурсе рулит, однозначно


На что мне не нравится 1С, но надо признать, что такие выкрики звучат просто смешно даже на фоне 1С-а.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[61]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 20:13
Оценка:
Здравствуйте, L.C.R., Вы писали:

LCR>5 копеек (с): как пишут на сайте IntelliJ, некоторые фичи невозможно реализовать в качестве плагина для VS, поэтому в перспективе они планируют собственную IDE под C#. Если это будет IDEA-like, то это просто здорово.


Одна из следующих версих студии будет сама менеджед-приложением. Так что не факт.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 20:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Любимый прием местных философов подменить тему разговора... Мы же вроде о скриптах в играх говорили, а не об обработки текстовых файлов.


А чё? Вот R#, например, прекрасно справляется с обработкой текстовых файлов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.05.05 20:24
Оценка:
Здравствуйте, Andir, Вы писали:

A>Просто в тему: Python с типизацией под Mono http://boo.codehaus.org/


Точнее сказать под CLR.

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

E>Не знаю, Влад. В области компонентного подхода ничего не могу сказать.


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

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


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

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


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

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

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

В общем, пусть рассцветают все цветы. Но мне хватит и тех, что растут у меня на грядке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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[51]: Создание игр на managed-языках
От: IT Россия linq2db.com
Дата: 20.05.05 03:34
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>ВМВаре


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

VD>ЦИГВИН


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

Влад, если у тебя нет латиницы на компе, то давай мы для тебя нарисуем переводчик из кирилицы в латиницу
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Если нам не помогут, то мы тоже никого не пощадим.
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[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]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.05.05 06:59
Оценка:
Здравствуйте, FR, Вы писали:

FR>Понятно меня просто смутило то что файл читается как бинарный без корректировки концов строк.А так оно почти дословно перепишется:


Ну то есть никаких преимуществ Питон на этой задачке не дает? Кстати, что насчет кодировки?
... << RSDN@Home 1.1.4 beta 7 rev. 456>>
AVK Blog
Re[78]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.05.05 07:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>1. При наличии инсталлятора — это не проблема.


Ну кому как.

VD>2. Можно просто проверять, что регистрация уже есть и не пытаться сделать ее еще раз.


Это весьма непросто. Придется много кода руками долбить.
... << RSDN@Home 1.1.4 beta 7 rev. 456>>
AVK Blog
Re[76]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.05.05 07:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Извини, но сто раз говорено, что регистрировать ком-объекты нужно при инсталяции, ане при запуске. Это все от лени и отсутсвия времения.


Лень тут не при чем. Для добавления в инсталлер нужно всего навсего добавить 2 строчки в nsis-скрипт. На шарпе кода регистрации больше.
... << RSDN@Home 1.1.4 beta 7 rev. 456>>
AVK Blog
Re[47]: Создание игр на managed-языках
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.05.05 07:17
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


VD>Папа! Как же так? ... есть, а слова нету? (с)


Нету-нету.
Автор: vdimas
Дата: 19.05.05

[quote]
Microsoft подводит сильно. У нас релиз в середине лета, в конце прошлой осени я строил планы выпуска на 2.0
Придется толкать первую версию на 1.1
[/quote]
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[51]: Создание игр на managed-языках
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 20.05.05 07:31
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


Нет, Влад. Ситуация немного другая.

Насколько я смог заметить, ты здесь являешься чуть ли не самым активным пропагандистом .Net-а. В этом нет ничего плохого, имхо. Но вот когда ты, например, мне объясняешь, что .Net -- это круто, то хотелось бы, чтобы ты учитывал то обстоятельство, что для меня очень важным критерием является переносимость. И здесь .Net пока (пока?), имхо, сильно проигрывает как Java, так и C++, так и Python, Ruby, Perl,... Поэтому было бы более объективно, если бы ты в разсказах про .Net делал оговорку, что это ориентированно, в первую очередь, на Windows. И, как следствие, не пытался переманивать в .Net тех, которые занимаются кроссплатформенной разработкой (возможно ли это? )

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


VD>В общем, пусть рассцветают все цветы. Но мне хватит и тех, что растут у меня на грядке.

+1
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[69]: Python vs C#
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 20.05.05 07:33
Оценка:
S>>> Все зависит от предметной области. 1С относительно недавно, но количество программистов растет с каждым днем.
S>>> И относительно не бесплатен

ANS>>Опен-соурсе рулит, однозначно


VD>На что мне не нравится 1С, но надо признать, что такие выкрики звучат просто смешно даже на фоне 1С-а.


Чего сказать то хотел? Что открытость тамошних конфигураций для модификации не является фактором успеха?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[48]: Создание игр на managed-языках
От: WolfHound  
Дата: 20.05.05 07:48
Оценка:
Здравствуйте, Borisman2, Вы писали:

B>Кстати, одним из главных преимуществ Питона я считаю встроенный тип данных — "словарь" (mapping, hashtable, как Вам больше нравится). Это не пустяк, это ОЧЕНЬ и ОЧЕНЬ серьезное преимущество.

Мда.. это действительно супер аргумент...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[48]: Python vs C#
От: eugals Россия  
Дата: 20.05.05 08:28
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ну то есть никаких преимуществ Питон на этой задачке не дает? Кстати, что насчет кодировки?


import codecs                            # в принципе, эти две строчки можно заменить одной:
StreamReader = codecs.getreader("UTF-8") # from encodings.utf_8 import StreamReader

def readKeys(fl):
    for line in StreamReader(fl):
        if line.startswith("END"):
            break
        try: code, value = line.split()      
        except ValueError: continue
        if   code == "K":
            currentKey = value
        elif code == "V":
            yield (currentKey, value)
        
keys = dict(readKeys(file("data.txt", "rb")))
print keys
... << RSDN@Home 1.1.4 beta 5 rev. 395>> {WinAmp: ДДТ\Юрий Шевчук — Расстреляли рассветами}
Re[49]: Создание игр на managed-языках
От: _vovin http://www.pragmatic-architect.com
Дата: 20.05.05 08:44
Оценка:
VladD2 wrote:
> Здравствуйте, _vovin, Вы писали:
>
> _>Мое и не только мнение — сколько не смотри, а вкус блюда не узнаешь не
> _>попробовав.
>
>
> А ты уверен, что это я не попробовал, то что ты предлагаешь, а не ты то что я?

Ну скажем, если взять мой опыт *плотной* работы в шарпе — 1 год, жаве —
2 года, то твои два запуска среды смолтока будут смотреться не очень. =)

>

> _>Тут дело в способе мышления, а не в знании конструкций и паттернов.
>
> Намикашь, что у кого-то он убогий?

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

>

> _>http://www.livejournal.com/users/behrk/318434.html
> _>Человек стал работать со смолтоком после того, как устроил голосование
> _>какой новый язык стоит изучить. Так что мнение можно считать
> _>не-"фанатическим".
>
> О... Если новички будут выбирать язык программирования по глосованию на нашем сайте, то все программисты на територии бывшего СССР будут писть на С++ и Шарпе.

Молодец, погавкал на неотносящееся к делу замечание.
Смысл в том, что он не был фанатом, ему просто люди посоветовали. После
этого он своими мозгами дошел до подобной оценки. Так что ее можно
рассматривать как *объективную*, насколько это применимо к оценке языков
людьми.
Posted via RSDN NNTP Server 1.9
Re[49]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.05.05 09:55
Оценка:
Здравствуйте, FR, Вы писали:

FR>Почему никаких, чуть чуть есть, код короче немножко


Это все фигня, особенно если учесть что ты опустил указание кодировки.

FR> и не пришлось вручную функцию писать.


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

FR> а по кодировке никаких проблем(и изменений в коде функции)

FR>
FR>import codecs
FR>.....................
FR>print FillFromHashToDisk(codecs.open("data.txt", "rb",  "utf_8"))
FR>


Это отступление от условий задачи. В условиях было сказано что в качестве аргументов передается имя файла, а не поток. Да ты сам написал что перевел почти дословно, и именно дословный перевод я и увидел.
... << RSDN@Home 1.1.4 beta 7 rev. 456>>
AVK Blog
Re[50]: Python vs C#
От: FR  
Дата: 20.05.05 11:35
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


FR>>Почему никаких, чуть чуть есть, код короче немножко


AVK>Это все фигня, особенно если учесть что ты опустил указание кодировки.


У тебя в коде и в условиях задачи тоже нет указания кодировки.


FR>> и не пришлось вручную функцию писать.


AVK>Опять вопросы библиотеки. Мне интересна была способность к выражению алгоритмов, а не то какие функции в питоне есть. Если тебе так хочется я моуг привести решение на шарпе в несколько строк, которое потребует гору кода на питоне. Только это ни о чем не говорит.


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

FR>> а по кодировке никаких проблем(и изменений в коде функции)

FR>>
FR>>import codecs
FR>>.....................
FR>>print FillFromHashToDisk(codecs.open("data.txt", "rb",  "utf_8"))
FR>>


AVK>Это отступление от условий задачи. В условиях было сказано что в качестве аргументов передается имя файла, а не поток. Да ты сам написал что перевел почти дословно, и именно дословный перевод я и увидел.


фигня:
import codecs

def FillFromHashToDisk(FileName):
    fin = codecs.open(FileName, "rb",  "utf_8")
    props = {}
    while True:
        parts = fin.readline().split(' ')
        if parts[0][:3] == "END": break
        if parts[0] == "K":
            key = fin.read(int(parts[1]))
        elif parts[0] == "V":
            props[key] = fin.read(int(parts[1]))
    return props        
        
print FillFromHashToDisk("data.txt")
Re[51]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.05.05 11:53
Оценка:
Здравствуйте, FR, Вы писали:

AVK>>Это все фигня, особенно если учесть что ты опустил указание кодировки.


FR>У тебя в коде и в условиях задачи тоже нет указания кодировки.


В дотнете UTF-8 по умолчанию.

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


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

AVK>>Это отступление от условий задачи. В условиях было сказано что в качестве аргументов передается имя файла, а не поток. Да ты сам написал что перевел почти дословно, и именно дословный перевод я и увидел.


FR>фигня:

FR>
FR>import codecs

FR>def FillFromHashToDisk(FileName):
FR>    fin = codecs.open(FileName, "rb",  "utf_8")
FR>    props = {}
FR>    while True:
FR>        parts = fin.readline().split(' ')
FR>        if parts[0][:3] == "END": break
FR>        if parts[0] == "K":
FR>            key = fin.read(int(parts[1]))
FR>        elif parts[0] == "V":
FR>            props[key] = fin.read(int(parts[1]))
FR>    return props        
        
FR>print FillFromHashToDisk("data.txt")
FR>


Ну вот никакой экономии и нет. Те же яйца вид в профиль.
... << RSDN@Home 1.1.4 beta 7 rev. 456>>
AVK Blog
Re[52]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.05 16:14
Оценка:
Здравствуйте, IT, Вы писали:

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


VD>>ВМВаре


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


. Ладно... вдруг кто не угодал — VMware.

VD>>ЦИГВИН


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


Тады скажу по научному CygWin — http://www.cygwin.com.

IT>Влад, если у тебя нет латиницы на компе, то давай мы для тебя нарисуем переводчик из кирилицы в латиницу


Лучше автаматический. И щоб ошибки поправлял.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[52]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.05 16:47
Оценка:
Здравствуйте, eao197, Вы писали:

E>Насколько я смог заметить, ты здесь являешься чуть ли не самым активным пропагандистом .Net-а. В этом нет ничего плохого, имхо. Но вот когда ты, например, мне объясняешь, что .Net -- это круто, то хотелось бы, чтобы ты учитывал то обстоятельство, что для меня очень важным критерием является переносимость.


Каждый отталкивается от своих предпосылок. Я как бы не скрываю, что все возможности дотнета можно получить только на МС-ых платформах. На других же дотнет пока что в стадии CLR + BCL (стандартная библиотека) ну и что бох подаст .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.05 17:51
Оценка:
Здравствуйте, FR, Вы писали:

FR>Почему никаких, чуть чуть есть, код короче немножко и не пришлось вручную функцию писать. а по кодировке никаких проблем(и изменений в коде функции)


Тю... Чуть-чуть? А где же "гораздо короче" и "радикально чернее?" .

А теперь представь себе, что код написан с помощью решарпера или 2005-ой студии. Итого молучаем более быстрое написание заведомо более надежного кода. А твое "чуть-чуть" опять заключается в том, что кое что уже встроено в библиотеку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[79]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.05 18:19
Оценка:
Здравствуйте, AndrewVK, Вы писали:

VD>>2. Можно просто проверять, что регистрация уже есть и не пытаться сделать ее еще раз.


AVK>Это весьма непросто. Придется много кода руками долбить.


Сложно проверить наличие ключа в реестре?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[46]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.05 18:38
Оценка:
Здравствуйте, FR, Вы писали:

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


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


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


Еще убедительнее! Повторение слова сахар лучший способ борьбы с ожирением. А чужие аргументы фильруй. Оно и верно. Это првильно.

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


FR>А на Шарпе всегда можно?


Без сомнений. Это универсальный язык с эффетивным компилятором. В том то вся и суть.

FR>Так и на питоне почти всегда можно,


Ключевое слово здесь "почти", я так понимаю. Ну, ну. Что же у Питона что не библиотека, так костыль на С написанный? Видимо мошь языка так велика, что ее приберегают на сладкое.

FR>да и не вижу ничего плохого в использовании для этого С++.


Ну, то есть ты бы не заметил приемущества если бы библиотеки для Питона можно было бы писать на самом Питоне и при этом не страдали бы ни эффективность разработки, ни эффективность компиляции?

Однако месье любитель извращений. (с)

FR>А библиотека у питона действительна очень неплохая столько всего впихнуто в не очень большой объем.


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

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

FR>
FR>from optparse import OptionParser

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

FR>(options, args) = parser.parse_args()
FR>


FR>

FR>Да на С++ тоже есть готовое решение boost::program_options

Ага и сразу же бежим писать юнит тесты. Ты вообще разницу между декларативным описанием и императивным заданием понимашь?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.05 18:42
Оценка:
Здравствуйте, FR, Вы писали:

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


Значит у нас разная практика. И она за доказательства не канает. Я бы вообще не стал использовать Питон при сложной текстовой обработке. Мазохизм не мой стиль.

FR>При обработке текстов скорость питона часто близка к сишной (программа же 90% времени сидит в строковых библиотеках).


Агащазблинъ. Близка к сишной может быть только скорость выполнения сишных библиотек в Питоне. Как только ты начинашь хоть что-то делать с текстом в самом Питоне, то сразу получишь многократное отставание.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[52]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.05.05 18:43
Оценка:
Здравствуйте, FR, Вы писали:

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


Повезло вот и не нашел. Не повезет и будешь пол дня за бабочками гоняться.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[80]: Python vs C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.05.05 18:58
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Это весьма непросто. Придется много кода руками долбить.


VD>Сложно проверить наличие ключа в реестре?


Сложно определить какой ключ проверять.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
AVK Blog
Re[47]: Python vs C#
От: FR  
Дата: 21.05.05 09:00
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


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


VD>Еще убедительнее! Повторение слова сахар лучший способ борьбы с ожирением. А чужие аргументы фильруй. Оно и верно. Это првильно.


Если будум грызтся в том же тоне далеко уйдем.


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


FR>>А на Шарпе всегда можно?


VD>Без сомнений. Это универсальный язык с эффетивным компилятором. В том то вся и суть.


FR>>Так и на питоне почти всегда можно,


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


Мощи языка хватает, вот производительности не всегда.

FR>>да и не вижу ничего плохого в использовании для этого С++.


VD>Ну, то есть ты бы не заметил приемущества если бы библиотеки для Питона можно было бы писать на самом Питоне и при этом не страдали бы ни эффективность разработки, ни эффективность компиляции?


Вообще мне наплевать на чем написана библиотека.

VD>Однако месье любитель извращений. (с)


все относительно

FR>>А библиотека у питона действительна очень неплохая столько всего впихнуто в не очень большой объем.


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


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


VD>Ага и сразу же бежим писать юнит тесты. Ты вообще разницу между декларативным описанием и императивным заданием понимашь?


Понимаю, но тут почти без разницы. Использовать также просто.
Re[50]: Python vs C#
От: FR  
Дата: 21.05.05 09:00
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Почему никаких, чуть чуть есть, код короче немножко и не пришлось вручную функцию писать. а по кодировке никаких проблем(и изменений в коде функции)


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


ну до коммунизма пока далеко

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


Угу студия и решарпер просто незаменимы при написании программ длиной в пару строк, дают гигантское ускорение, я думаю процентов 500 точно
Re[43]: Создание игр на managed-языках
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 22.05.05 11:04
Оценка:
_>>Вот в VB, скажем, строку с числом сложить не проблема, "компилятор" даже не пискнет

VD>Зависит от Option Strict


Влад, ты это про какой VB? Я ж совсем недавно ставил "на пробу" VB6. Где там выставить этот самый "Option Strict" или куда вписать сию фразу, и чтобы на неё не вылетала ошибка компиляции я не нашёл.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[44]: Создание игр на managed-языках
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.05.05 20:14
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Влад, ты это про какой VB?


Про любой.

ANS>Я ж совсем недавно ставил "на пробу" VB6. Где там выставить этот самый "Option Strict" или куда вписать сию фразу, и чтобы на неё не вылетала ошибка компиляции я не нашёл.


Option Strict вписывается в верху файла. Опции в настройках среды всего лишь добавляют эту опцию в новые файлы.

ЗЫ

Вообщк-то можно было и в хэлп поглядеть.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[51]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.05.05 20:14
Оценка:
Здравствуйте, FR, Вы писали:

FR>Угу студия и решарпер просто незаменимы при написании программ длиной в пару строк, дают гигантское ускорение, я думаю процентов 500 точно


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


ЗЫ

В общем, согласен. Признаю... для написания "Хэлоу, уорд" Питон является идиальным средством.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.05.05 20:14
Оценка:
Здравствуйте, FR, Вы писали:

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


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


FR>Доказать тут что-либо практически невозможно


Если не пытаться, то безусловно.

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


Ага. Весма.

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


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

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



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

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


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

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


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

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

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


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

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

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


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

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

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


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


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

VD>>В том то все и дело, что Шарп сравнивается с Питоном и Руби по простоте написания кода, и с С++ по скорости. И там, и там у него есть слабыве места. Но они довольно не значительные. А вот кумулятивный эффект выходит очень даже значительный.


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


Тебе уже 100 раз повторили:
1. Значитально более выская производительность.
2. Отсуствие необходимости применения более низкоуровневых языков.
3. Отличный отладчик.
4. Отличные средства рефакторинга.
5. Отличная IDE.

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

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


Ну, давай эти свои примеры сюда. Посмотрим вместе. Боюсь, это опять голословные утверждения. Все что я видел на Руби было очень даже элегантно.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[48]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.05.05 20:14
Оценка:
Здравствуйте, FR, Вы писали:

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


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

VD>>Ага и сразу же бежим писать юнит тесты. Ты вообще разницу между декларативным описанием и императивным заданием понимашь?


FR>Понимаю, но тут почти без разницы. Использовать также просто.


После отладки. Деларативность исключает ошибки.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[47]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.05.05 20:14
Оценка:
Здравствуйте, FR, Вы писали:

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


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

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


Ну, для чего-то неприменно. Вот только зачем себя загонять в рамки без необходимости?
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[46]: Python vs C#
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 23.05.05 03:39
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


Видимо, FR имел ввиду префиксы, которые Ruby использует для обозначения глобальных переменных, атрибутов объектов и атрибутов классов:
Variables                                     Constants and     
Local         Global      Instance  Class     Class Names     
-----------------------------------------------------------
name          $debug      @name     @@total   PI     
fishAndChips  $CUSTOMER   @point_1  @@symtab  FeetPerMile     
x_axis        $_          @X        @@N       String     
thx1138       $plan9      @_        @@x_pos   MyClass     
_26           $Global     @plan9    @@SINGLE  Jazz_Song

но на самом деле это кажется неудобным только сначала. Когда начинаешь писать на Ruby, это становиться только преимуществом: например, не нужно использовать префиксы m_ для имен атрибутов классов. И даже простые средства подсветки синтаксиса (без интелектуальной привязки к языку) позволяют легко расцвечивать разные имена в разные цвета -- особенно это полезно для различия имен локальных переменных/функций и имен классов/констант/модулей.
А лично я префикс $ использовал только при обращении к стандартным глобальным переменным, т.к. свои глобальные переменные не вводил -- это противоречит структурному программированию.

Гораздо важнее другое. Некоторые операции имеют side effects и засовывают либо по-умолчанию извлекают значения из специальных глобальных переменных. Такой подход позволяет программировать на Ruby в стиле Perl-а:
while gets           # assigns line to $_
  if /Ruby/          # matches against $_
    print            # prints $_
  end
end

Соглашусь с тем, что для новичков в Ruby это будет write-only код. Поэтому я сам так не пишу. Поскольку есть более удобные способы. Например, те же самые действия можно выполнить одной строкой:
ARGF.each { |line|  print line  if line =~ /Ruby/ }



Информация взята из книги Programming Ruby.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[45]: Создание игр на managed-языках
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 23.05.05 04:27
Оценка:
ANS>>Я ж совсем недавно ставил "на пробу" VB6. Где там выставить этот самый "Option Strict" или куда вписать сию фразу, и чтобы на неё не вылетала ошибка компиляции я не нашёл.

VD>Option Strict вписывается в верху файла. Опции в настройках среды всего лишь добавляют эту опцию в новые файлы.


Влад, я выделил.

VD>ЗЫ


VD>Вообщк-то можно было и в хэлп поглядеть.


Наверное, то был просто не правильный VB6
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[52]: Python vs C#
От: FR  
Дата: 23.05.05 06:17
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Угу студия и решарпер просто незаменимы при написании программ длиной в пару строк, дают гигантское ускорение, я думаю процентов 500 точно


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


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

VD>ЗЫ


VD>В общем, согласен. Признаю... для написания "Хэлоу, уорд" Питон является идиальным средством.


Да, это чистая правда, но не вся правда
Re[49]: Python vs C#
От: FR  
Дата: 23.05.05 06:34
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


Скрипты в играх большей частью пишут(или правят при настройке) дизайнеры, это гораздо хуже чем начинающие программисты , тут чем проще тем лучше.
Re[48]: Python vs C#
От: FR  
Дата: 23.05.05 06:34
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


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

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


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


А писать все на C# это не загонять себя в рамки?
Re[47]: Python vs C#
От: FR  
Дата: 23.05.05 06:34
Оценка:
Здравствуйте, eao197, Вы писали:


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


Угу я как их увидел, так и испугался
Re[48]: Python vs C#
От: L.C.R. Россия lj://_lcr_
Дата: 23.05.05 06:40
Оценка:
FR,

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


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


Эти префиксы обязательны?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[48]: Python vs C#
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 23.05.05 06:46
Оценка:
Здравствуйте, FR, Вы писали:

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



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


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


Зря. После начала программирования на Ruby на них так же мало обращаешь внимания, как на структурирование программы пробелами в Python.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[49]: Python vs C#
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 23.05.05 06:47
Оценка:
Здравствуйте, L.C.R., Вы писали:

LCR>FR,


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


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


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


Да. И, имхо, это хорошо.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[49]: Python vs C#
От: FR  
Дата: 23.05.05 06:50
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

Со всем этим я согласен при условии что на VB сидит и работает разаработчик — программист. Если же скрипт должен писать(или править) специалист не программист (это и есть ситуация для компьютерных игр) то наоборот лучше все максимально ограничить и упростить.
Re[49]: Python vs C#
От: FR  
Дата: 23.05.05 06:53
Оценка:
Здравствуйте, eao197, Вы писали:

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


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


Если бы мне первым попался на глаза Ruby а не Python, я сейчас возможно также думал бы
Вообще есть и более страшные вещи, например Icon
Re[50]: Python vs C#
От: Трурль  
Дата: 23.05.05 07:09
Оценка:
Здравствуйте, FR, Вы писали:

FR>Если бы мне первым попался на глаза Ruby а не Python, я сейчас возможно также думал бы

FR>Вообще есть и более страшные вещи, например Icon
А че Icon? Очень даже ничего.
Re[56]: Python vs C#
От: WFrag США  
Дата: 23.05.05 12:52
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

Ну и в таком духе.
... << RSDN@Home 1.1.4 beta 6a rev. 438>>
Re[54]: Python vs C#
От: WFrag США  
Дата: 23.05.05 12:52
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

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


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

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


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

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


Для меня код выглядит write-only, однако я полагаю, что причина в моем малом опыте реализации парсеров и компиляторов (ну и названия переменных мне там не нравятся . Можно просто спросить автора, сколько у него заняло реализация этого чуда.
... << RSDN@Home 1.1.4 beta 6a rev. 438>>
Re[47]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.05.05 21:03
Оценка:
Здравствуйте, 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 <...>)


Дык ты же эти правила и создашь. Кстати, не так давно все холивары были С++ вс. что-то там. Но видимо что-то меняется в этом мире.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[57]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.05.05 21:03
Оценка:
Здравствуйте, WFrag, Вы писали:

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


WF>Чего 50 лет?


Лисп.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[55]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.05.05 21:03
Оценка:
Здравствуйте, WFrag, Вы писали:

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


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

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


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


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

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


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

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


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


Дык есть же EBNF в котором все намного понятнее и проще. А время... есть ведь еще время на поддержку и развитие. Оно обычно дороже.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[50]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.05.05 21:03
Оценка:
Здравствуйте, FR, Вы писали:

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


Сдается мне что дешевле обучить человека как следует программировать чем пытаться закрыть его ламерство. Все равно пишется код. Если уж создается среда для дизайнера, то там вообще не должно быть кода. Код должен писаться программистами и использоваться дизайнерами как компонент (черный ящик со свойствами).
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[52]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.05.05 21:03
Оценка:
Здравствуйте, FR, Вы писали:

FR>Может не стоит так сильно обобщать?

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

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

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

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

Ну, а скрипты должны быть уже неким хакерским средством для крутых выкрутасов. А идиальным было бы если бы скрипт в итоге пораждал тот же компонет который просто расширял бы возможности дизайнера.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.05.05 21:03
Оценка:
Здравствуйте, FR, Вы писали:

FR>Да надо было сразу делать как Гаптерон предлагал но лень.

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

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

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


Нет. Да и у дотнета Шарп не единственный выбор.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[56]: Python vs C#
От: WFrag США  
Дата: 24.05.05 01:31
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

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


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

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

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


Я не пойму каким ты образом EBNF выполнять собрался. То что там приведено — вполне самостоятельный язык. Ты можешь написать на нем что-нибудь, обрамить макросом pasqualish (ну и заэскейпить еще надо) и получишь программу. Обрамление делается автоматически. Получаем что можно писать на этом языке совершенно не вдаваясь в скобочки LISP-а с одной стороны, и имея желаемый DSL — с другой.
... << RSDN@Home 1.1.4 beta 6a rev. 438>>
Re[58]: Python vs C#
От: WFrag США  
Дата: 24.05.05 01:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Лисп.


Дык речь не про LISP шла, а про некое средство разработки DSL, обладающее определенными качествами.
... << RSDN@Home 1.1.4 beta 6a rev. 438>>
Re[51]: Python vs C#
От: FR  
Дата: 24.05.05 07:23
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


Дизайнер не программист, он профессионал в своей области. Код который пишется очень специфичен, и черных ящиков там хватает. Среду для дизайнера без кода почти нереально сделать, этот редактор может получится сложнее чем вся остальная игра, кроме того задавать логику визуально не проще чем на скрипте(я видел несколько "конструкторов" игр, освоить их не проще чем скрипт а возможности гораздо уже).
Re[53]: Python vs C#
От: FR  
Дата: 24.05.05 07:23
Оценка:
Здравствуйте, VladD2, Вы писали:

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


FR>>Может не стоит так сильно обобщать?

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

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

VD>

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

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

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

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


расшифруй что ты тут понимаешь под словом компонент, а то слишком напоминает волшебную палочку
Re[48]: Python vs C#
От: FR  
Дата: 24.05.05 07:23
Оценка:
Здравствуйте, 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 меняется
Re[48]: Python vs C#
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.05.05 07:30
Оценка:
Здравствуйте, 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
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[49]: Python vs C#
От: FR  
Дата: 24.05.05 08:30
Оценка:
Здравствуйте, eao197, Вы писали:


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


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


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

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


Так у меня тоже когда пишу на питоне с этим проблем нет, они только у Влада появляются
Re[50]: Python vs C#
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.05.05 08:42
Оценка:
Здравствуйте, 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, ни с чем-либо еще.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[51]: Python vs C#
От: FR  
Дата: 24.05.05 09:31
Оценка:
Здравствуйте, 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 на любом языке будет довольно страшно, хотя если дашь формат входной строки могу попробовать на питоне переписать, мне кажется будет чуть проще.
Re[52]: Python vs C#
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.05.05 09:36
Оценка:
Здравствуйте, 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" }
Весь файл состоит из таких строк. Пустых строк нет.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[53]: Python vs C#
От: FR  
Дата: 24.05.05 10:41
Оценка:
Здравствуйте, 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


Да еще как сортируется вывод я не понял, поэтому просто вывел.
Re[54]: Python vs C#
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 24.05.05 10:44
Оценка:
Здравствуйте, 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>Да еще как сортируется вывод я не понял, поэтому просто вывел.


Почти тоже самое. Только нужно, чтобы вывод был отсортированный.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[49]: Python vs C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.05.05 20:57
Оценка:
Здравствуйте, 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 меняется


Отнюдь.
... << RSDN@Home 1.1.4 beta 7 rev. 457>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[64]: Python vs C#
От: EvilChild Ниоткуда  
Дата: 27.05.05 13:47
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет, у нас код из-за COM не разрастается (используем Comet вместо ATL),

C>да и организация интерфейсов в OLE достаточно разумная.

Можешь поделиться впечатлениями об использовании Comet?
С точки зрения дизайна он мне показался красивее ATL'я.
Re[66]: Python vs C#
От: EvilChild Ниоткуда  
Дата: 30.05.05 10:01
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Работает нормально, никаких претензий. Единственное НО: его

C>кодогенератор лучше не использовать для неOLE-интерфейсов.

Ты имеешь в виду его tlb2h?
Он у меня споткнулся на объектной модели ворда, как вы такие вещи объезжаете?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.