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

VD>>2. Можно просто проверять, что регистрация уже есть и не пытаться сделать ее еще раз.

AVK>Это весьма непросто. Придется много кода руками долбить.

Сложно проверить наличие ключа в реестре?

Здравствуйте, 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

Ага и сразу же бежим писать юнит тесты. Ты вообще разницу между декларативным описанием и императивным заданием понимашь?

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

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

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

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

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

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

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

Повезло вот и не нашел. Не повезет и будешь пол дня за бабочками гоняться.

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

AVK>>Это весьма непросто. Придется много кода руками долбить.

VD>Сложно проверить наличие ключа в реестре?

Сложно определить какой ключ проверять.

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

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

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

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

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

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

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

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

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

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

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

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

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

VD>Еще убедительнее! Повторение слова сахар лучший способ борьбы с ожирением. А чужие аргументы фильруй. Оно и верно. Это првильно.

Если будум грызтся в том же тоне далеко уйдем.


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

FR>>А на Шарпе всегда можно?

VD>Без сомнений. Это универсальный язык с эффетивным компилятором. В том то вся и суть.

FR>>Так и на питоне почти всегда можно,

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

Мощи языка хватает, вот производительности не всегда.

FR>>да и не вижу ничего плохого в использовании для этого С++.

VD>Ну, то есть ты бы не заметил приемущества если бы библиотеки для Питона можно было бы писать на самом Питоне и при этом не страдали бы ни эффективность разработки, ни эффективность компиляции?

Вообще мне наплевать на чем написана библиотека.

VD>Однако месье любитель извращений. (с)

все относительно

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

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

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


VD>Ага и сразу же бежим писать юнит тесты. Ты вообще разницу между декларативным описанием и императивным заданием понимашь?

Понимаю, но тут почти без разницы. Использовать также просто.

Здравствуйте, 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);
    }    
  }
}

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

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

FR>>Почему никаких, чуть чуть есть, код короче немножко и не пришлось вручную функцию писать. а по кодировке никаких проблем(и изменений в коде функции)

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

ну до коммунизма пока далеко

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

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

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

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

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

VD>Зависит от Option Strict

Влад, ты это про какой VB? Я ж совсем недавно ставил "на пробу" VB6. Где там выставить этот самый "Option Strict" или куда вписать сию фразу, и чтобы на неё не вылетала ошибка компиляции я не нашёл.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Влад, ты это про какой VB?

Про любой.

ANS>Я ж совсем недавно ставил "на пробу" VB6. Где там выставить этот самый "Option Strict" или куда вписать сию фразу, и чтобы на неё не вылетала ошибка компиляции я не нашёл.

Option Strict вписывается в верху файла. Опции в настройках среды всего лишь добавляют эту опцию в новые файлы.

ЗЫ

Вообщк-то можно было и в хэлп поглядеть.

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

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

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


ЗЫ

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

Здравствуйте, 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>Дело не в этом. Я смотрел примеры, слишком много закорючек, напоминает перл и форт

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

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

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

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

VD>>Ага и сразу же бежим писать юнит тесты. Ты вообще разницу между декларативным описанием и императивным заданием понимашь?

FR>Понимаю, но тут почти без разницы. Использовать также просто.

После отладки. Деларативность исключает ошибки.

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

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

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

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

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

Здравствуйте, 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.

ANS>>Я ж совсем недавно ставил "на пробу" VB6. Где там выставить этот самый "Option Strict" или куда вписать сию фразу, и чтобы на неё не вылетала ошибка компиляции я не нашёл.

VD>Option Strict вписывается в верху файла. Опции в настройках среды всего лишь добавляют эту опцию в новые файлы.

Влад, я выделил.

VD>ЗЫ

VD>Вообщк-то можно было и в хэлп поглядеть.

Наверное, то был просто не правильный VB6

Здравствуйте, FR, Вы писали:
FR>Вообще мне наплевать на чем написана библиотека.
Это неверный подход. Потому как он оставляет прикладника человеком второго сорта. Пользоваться готовым ты можешь, а воспроизвести — нет. Та же ситуация была в VB: разработчик был втиснут в жесткие рамки существующих активыксов, по большей части коммерческих. Состряпать свой — это пересесть на С++, язык, требующий совершенно другого уровня владения предметом. Простейшие в VB вещи превращаются в чудовищные конструкции на С++.
Delphi с самого начала предложил использование единого языка для написания как приложений, так и библиотек. Это обеспечило наличие огромного количества бесплатных и почти бесплатных компонент.
Та же система прослеживается в .Net: ты не ограничен в выборе языка. Более того, особых неэффективностей нет ни в одном из них. Поэтому VB-шнику не потребуется осваивать шарп или еще что-то из-под палки. Все фичи FCL (кроме особо системных) он может воспроизвести самостоятельно, не слезая со своего языка. А задачи оптимизации сверх предлагаемой C#/VB встречаются редко, и в таких ситуациях, когда найм отдельного скилластого девелопера для переноса узких мест на unmanaged вполне оправдан.

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

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

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

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

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

VD>ЗЫ

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

Да, это чистая правда, но не вся правда