Здравствуйте, FR, Вы писали:
FR>PyChecker не может отловить всех ошибок которые отлавливают хорошие компиляторы статически типизированных языков, в общем недостатки есть, но число таких ошибок сильно уменьшает. Да и не являются подобные ошибки слишком частыми.
Видимо есть разные люди и разные методы программирования. Я вот очень часто пользуюсь помощью компилятора. Серьезный рефакторинг или написание большого логически завершенного кода очень часто заканчивается устранением ошибок найденных компилятором, а потом и ошибок логических (в С++ еще и ошибок втогого порядка).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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, рефлекшон и т.п. — это уже следствие наличия метаинформации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E> — то, что VladD2 и теперь уже WolfHound прибегают к аргументу, что линукс их не интересует
О. Опять я крайний.
Да, это так. Не то чтобы не интересуют. Новости я почитаю с интересом. В форуме с интересом тоже послушаю. Даже иногда подумаю о том, чтобы поставить в ВМВаре Линукс и поглядеть до чего дошел прогресс. Но я так же реально понимаю, что никакого интереса у меня к Линуксу нет. Все что мне от него может понадобиться я обычно получаю используя ЦИГВИН. Да и он мне требуется только ради спортивного интереса. Ну, нет для меня разницы между VC и GCC.
При этом против Линукса я ничего не имею. Даже рад за то что он есть. Все же от отсуствия конкурениции проигрывает в первую очередь потребитель. А я как раз потребитель.
В общем, пусть рассцветают все цветы. Но мне хватит и тех, что растут у меня на грядке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
GZ>А я бы сказал что наоборот хорошо. Чем меньше Microsoft будет вмешиваться в сам Net, тем лучше.
+1
GZ>PS: вот если бы они коды JIT открыли, вот тогда Net компиляторы в натив начали бы плодится как грибы.
Дык Ротор содержит исходники JIT-а. Они конечно урезаны по сравнению с тем, что есть в коммерческом варианте дотнета, но все же... Есть не мало альтернативных джитов для Ротора. К тому же сейчас в недрах МС зреет проект phoenix который, прада, не открыает исходники джита, но предоставляет открытую архитектуру позволяющую расширять оптимизатор кода и джит кому угодно. Сам джит ничего не стоит без оптимизации кода. А этот проект превращает процесс озадния таких оптимизаций в научный и стало быть открытый. Думаю году к 2010 мы увидим небывалый расцвет этой отрасли.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>PyChecker пишет: D:\temp\_tst\p1\tst1.py:4: No global (x) found
Вот, вот. За наличие "global x" и надо отрывать руки создателям языка.
Как показывает практика оные встречются не так редко. Особенно в неумелых руках. А простота Питона и Руби приводят к тому, что как раз в неумелые руки они попадают в первую очередь. А эти руки и про PyChecker ничего обычно не знают.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
VD>Спокойно.
Влад, я спокоен как твой розовый слон!
VD> [высказывание X]
Для меня ява — рабочий инструмент. Не больше, не меньше. Его (инструмент) я уже юзаю довольно давно, и я вижу что он вполне пауэрфул и вместе с тем далёк от совершенства. Однако так хочется хотя бы прикоснуться к этому самому совершенству, особенно когда я сталкиваюсь с чем-то подобным:
Возможно этот рисунок покажется не в тему, но на самом деле я хочу выразить этим одну мысль: нотация решает. В данном случае с помощью простой нотации описана достаточно сложная абстракция. В существующей нотации мэйнстримовых ЯП я вынужден "переводить тысячи тонн словесной руды ради единого слова" (с) Маяковский. Потому и меня, и _Вовина, и возможно ещё кого-то тянет на что-то совсем эдакое .
VD>В общем, .
Конечно,
Здравствуйте, 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 код, на питоне это сложнее.
VD>Как показала моя практика как раз задачи копирования и обработки файлов лучше решать опять жен на полноценных языках программирования. Да пока тебе нужно скопировать несколько файлов, то командная строка проста и достаточна. Но как только нужно прибавить мало мальски сложную логику, то она пасует по полной программе. У полноценного ЯП и возможности по формулированию логики по больше, и возможности по отладке куда шире.
У меня практика показывает что тексты обрабатывать гораздо удобнее скриптами.
VD>Дотнет же сдель дает ко всему прочему еще и то приемущество, что недостающую функциональность можно сварганить на нем же сомом. При этом производительность получается сравнимая с С++-ной, а скорость разработки с Питоном и Руби (а то и выше за счет отладчика, рефакторинга и IDE).
При обработке текстов скорость питона часто близка к сишной (программа же 90% времени сидит в строковых библиотеках).
Здравствуйте, 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>
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Не нужно среды,сейчас подобные задачи чаще всего решаются перлом, питон в этом мало уступает ему, и все что ты перечислил есть в стандартных библиотеках.
VD>С чего бы это? Простые задачи можно решать на любом языке. А сложные требуют фрэймворков. Ты на своем Перле и Питоне задолбашся серьезный парсер писать. А я его и на С с каким-нить Бизоном в раз сварганю. А по скорости так они оба в даун уйдут что по сравнеию с С, что по сравнению с C#.
Простые задачи быстрее и проще решать на удобных языках. К тому же задачи делятся не только на простые и сложные есть и средние которые с успехом решаются тем же питоном.При обработке текстов и питон и перл показывают неплохую скорость.
Ты думаешь бизон нельзя подключить к питону? К тому же для питона кроме него есть еще несколько парсеров.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>PyChecker пишет: D:\temp\_tst\p1\tst1.py:4: No global (x) found
VD>Вот, вот. За наличие "global x" и надо отрывать руки создателям языка.
PyChecker выдает такие сообщения когда обнаруживает попытку использования неинициализированной переменной, так что global здесь просто означает что ничего похоже на x он не нашел.
Здравствуйте, Козьма Прутков, Вы писали:
КП>Трурль wrote: >> Здравствуйте, WolfHound, Вы писали: >> Поставим вопрс по-другому. Стоит ли связываться с C#, если есть питон? КП> стоит ли шить сапоги если мы уже умеем плести лапти? КП>Питон безусловно хорошая вещь (это я по дискуссии сужу), но для своих КП>целей. И как лапти хороши сегодня для сувенира иностранцу, так сапоги КП>для того, чтобы использовать их в качестве обуви. В лаптях конечно тоже КП>можно ходить (ну ходили же наши предки), но не далеко.
Вы когда-нибудь ходили в лаптях, для того чтобы утверждать что в них недалеко уйдешь? КП>Да, конечно, прикольно не иметь статической типизации, все мочить в коде КП>и т.д. Но это вряд ли сильно положительно скажется на простоте поддержки КП>разрабатываемой системы, ее расширяемости, простоте отладки и т.д.
Может сказаться как отрицательно, так и положительно. Статическая типизация vs. динамическая типизация — топик далеко не так ясный, как Вы стараетесь его представить. Особенно в области скриптов для компьютерных игр, где традиционно используются такие языки как Lua КП>Юнит-тесты это хорошо, но строгая типизация — куда более строгий КП>инструмент.
Это Вас кто-то обманул. Те тесты, которые Вы делаете сам, компилятор НИКОГДА не сумеет провести автоматически. КП>И вряд ли отсутствие типизации ускорит разработку, учитывая КП>что юнит-тестов надо написать куда больше, плюс отлаживаться придется КП>дольше.
Насчет юнит тестов тоже не вполне ясно. Время, потраченное на борьбу с типами можно с пользой потратить на написание тестов. Насчет отладки — это я не понял. Почему дольше ? КП>Благо дизайн приложений уже довольно развит,
Это кто сказал ? Это Ваше личное мнение ? КП>что дает КП>дополнительный аргумент в пользу наличия типизации. Такие штуки, КП>наверное, хороши для написания пакета утилит для администрирования и КП>т.п. для собственного пользования. Но писать промышленную систему, КП>которая будет здорово развиваться, я бы на них не стал.
Питон заводами управляет. Производством. Поинтересуйтесь. КП>Что касается библиотеки, то да, .NET предлагает менее развитую в КП>рассмотренных отношениях библиотеку. Но он ориентирован на разработку КП>корпоративных приложений, автоматизации бизнеса, а не утилит и игр. Если КП>есть специфическая потребность — ее надо осмыслить и один раз написать КП>нужную библиотеку. КП>Итого, всему свое место в жизни
Кстати, одним из главных преимуществ Питона я считаю встроенный тип данных — "словарь" (mapping, hashtable, как Вам больше нравится). Это не пустяк, это ОЧЕНЬ и ОЧЕНЬ серьезное преимущество.
Здравствуйте, Козьма Прутков, Вы писали:
КП>И как лапти хороши сегодня для сувенира иностранцу, так сапоги КП>для того, чтобы использовать их в качестве обуви. В лаптях конечно тоже КП>можно ходить (ну ходили же наши предки), но не далеко.
Сапоги хороши для хождения строем. А если надо быстро бежать, то даже лапти получше будут.