Почитав дискуссию "Python vs C#" захотелось сделать некоторую выжимку в целях:
1. Дать возможность читателям конференции быстро ознакомиться с результами дискуссии на тему "Python vs C#", не заставляя их бежать через 334 поста и тратя время на иногда не содержащие конструктивной мысли по теме сообщения.
2. Дать возможность писателям сообщений оценить качество дискусии
3. Ну и конечно дать всем возможность поругать меня за плохой summary.
Несколько комментариев: во-первых я мог пропустить достаточно много умных мыслей по теме "Python vs C#" (сообщений в ветке много, да и глубокая ночь уже); во-вторых, некоторые "умные" сообщения в этой ветке которые на мой взгляд не удовлетворяют заголовку темы "Python vs C#" не вошли в это summary; в-третьих: я старался сделать summary более-менее связным, надеюсь это в какой-то мере получилось.
Python vs C#. Thread summary. (Messages 334)
Ownership and GC
eugals> такого GC как в CLR — нет. [Eсть] банальный счетчик ссылок. Есть детектор циклов (запускается время от времени и убивает зависшие объекты). Правда, этот детектор хорош только если вся программа написана на чистом питоне — безо всяких сиплюсплюсных библиотек
Cyberax> Просто считаются ссылки. Кольцевые структуры потом подбираются настоящим GC.
FR> Если ссылок на файл нет то CPython (основная реализация питона) закроет файл сразу после выхода из строки например тут
arr = open("test.txt").readlines()
после выполнения строки файл уже будет закрыт. Тут есть небольшой UB, так как документация не гарантирует такое поведение для всех реализаций. Но уже очень много кода написано полагаясь на такое поведение так что менять его вряд ли будут.
Cyberax> Деструкторы не всегда вызываются _сразу_ при выходе из блока. Делаем такой пример:
class Test:
def crashIt(self):
cyclic=self
db_connection=connect_to_database(...)
tst=Test()
Все! Теперь соединение к БД будет существовать до запуска детектора
циклов (или сборщика мусора), а за это время вполне могут быть
израсходованы все соединения к БД.
Это упрощенный пример, в реальных приложениях такие утечки обычно
возникают при достаточно сложной структуре, и проявляются обычно при
большой нагрузке.
"Типизация"
FR>А отсутствие типизпции может быть и преимуществом. вот в питоне шаблонами и не пахнет а обобщеный код пишется без проблем.А для решения проблем с нетипизированностью есть специальные утилиты проверяющие корректность кода, например тот же PyChecker
WolfHound> статически типизированые языки позволяют создавать утилиты для рефакторинга. Нука покажи мне аналог ReSharper'а для питона...
FR>Проще писать программы, интерфейс файловых объектов стандартен, легко писать процедуры работающие с любыми файловыми объектами, при этом для своих файловых объектов не требуется наследование от базового класса.
Козьма Прутков> не иметь статической типизации, [...] вряд ли сильно положительно скажется на простоте поддержки разрабатываемой системы, ее расширяемости, простоте отладки и т.д. Юнит-тесты это хорошо, но строгая типизация — куда более строгий инструмент. И вряд ли отсутствие типизации ускорит разработку, учитывая что юнит-тестов надо написать куда больше, плюс отлаживаться придется дольше. Благо дизайн приложений уже довольно развит, что дает дополнительный аргумент в пользу наличия типизации. Такие штуки, наверное, хороши для написания пакета утилит для администрирования и т.п. для собственного пользования. Но писать промышленную систему, которая будет здорово развиваться, я бы на них не стал.
Borisman2> Может сказаться как отрицательно, так и положительно. Статическая типизация vs. динамическая типизация — топик далеко не так ясный, как Вы стараетесь его представить. Особенно в области скриптов для компьютерных игр, где традиционно используются такие языки как Lua
Wolfhound> Вот только без интеграционных тестов оно всеравно работать не будет.
eao197> Так ведь чем больше тестов для статически типизированных программ, тем лучше. Если речь идет о качестве продукта, то вопрос не стоит ни в объеме ни во времени. Здесь этот аргумент сторонников динамически-типизированных языков непоколебим.
Хотя лично я уверен, что есть масса случаев, когда unit-тесты или автоматические integration- или regression-тесты просто неприменимы. Иметь в таких случаях поддержку со стороны статически типизированного языка -- это очень большой плюс.
Vlad2> Все же динамическая типизация и отсутствие указания типов в коде — это не одно и то же. Вывод типов в ФЯ достиг очень высокого уровня и может порой казаться динамической типизацией, но при этом все же остаеются почти все приемущества статической типизации. А вот приемущества истенно динамической типизации при сравнении ее с компонентным подходом и хорошего качества ООП я так и не увидил. Я плохо смотрел?
Andir> Просто в тему:
Python с типизацией под Mono
Refactoring
Wolfhound> [В Resharper] Не понравилось имя класса нажал несколько кнопок и переименовал его во всей программе. Причем эта штука опционально может переименовывать не только сам тип но и переменные этого типа
Допустим пишем так
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();
}
красота
WolfHound> Ну попробуй написать утилиту [на Python] которая переименует функцию 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)
Cyberax>
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. Питоновская программа упадет во время исполнения.
Средства языка
Borisman2> Кстати, одним из главных преимуществ Питона я считаю встроенный тип данных — "словарь" (mapping, hashtable, как Вам больше нравится). Это не пустяк, это ОЧЕНЬ и ОЧЕНЬ серьезное преимущество.
Cyberax> [обобщенное программирование в питоне ] Нету его там в нормальном. Есть name-based polymorphism, который по сути тоже есть в шаблонах С++, это используется для CRTP (Curously Recurring Template Pattern).
VladD2> Вот, вот. За наличие "global x" и надо отрывать руки создателям языка.
Gaperton> Не самый удачный пример. В шарпах нет лямбда-функций, встроенных списков и (соответственно) list comprehensions (for in, использующиеся для преобразований/формирований списков). Если ты построишь пример на этих свойствах языка, C# будет порван. Возьми какой-нибудь алгоритм, выполняющий преобразования деревьев. Не бинарных, а произвольных. Деревья моделируй списками списков. Используй for-in и лямбду (как параметр generic-функциям). Если текст выражения лямбды в питоне допускает ссылки на локальный контекст (я насчет этого не в курсе) ...
FR> [Python лучше C#] по объему кода [которого нужно написать]
Wolfhound> И что с того если все это за меня автокомплит набил?
FR> читать потом этот код тоже автокомплит будет?
WolfHound> Учтитывая особенности человеческого чтения это не есть проблема.
Вопросы применимости
WolfHound> Стоит ли связываться с C#, если есть питон?
Да стоит.
1)C# статически типизирован что позволяет отловить множество ошибок еще до тестирования.
2)Если все делать на C# то интеграция скриптов и основного кода получится автоматически и без оверхеда.
3)Для C# существуют мощные IDE с возможностью рефакторинга и прочими вкусностями.
4)C# исполняется быстрее.
Vlad2> Не... не быстрее... а на много быстрее. Статическая тпизация и компиляция рулят.
eao197> Здесь была большая тема по этому поводу: Типизация.Имхо, динамическая типизация -- это интересная возможность. Просто нужно к ней по другому подходить. Ни и не для всех задач, имхо, она пригодно. Например, мне было бы стремно писать маршрутизатор SMS-трафика на Ruby именно из-за того, что я не смогу создать достаточное количество unit-тестов, чтобы весь код проверить (а сторонники динамически-типизированных языков часто приводят в качестве довода то, что нельзя доверять коду, который не был протестирован). А в случае статически типизированного языка я хотя бы могу быть уверен в отсутствии синтаксических ошибок даже в самых редкоиспользуемых ветвях моего кода. Но для небольших программ тот же Ruby может дать существенный прирост производительности в кодировании. А если к этому добавить, что сложные задачи можно решать правильно комбинируя простые и маленькие инструменты (т.н. unix way), то получается, что из маленьких Python (Ruby, Perl,...) скриптиков можно строить весьма сложные решения
FR> Угу, только программа на питоне будет гораздо меньше чем эти несколько мегабайт
Wolfhound> Будет гораздо больше если добавить объем юнит-тестов.
Vlad2> Тебе уже 100 раз повторили:
1. Значитально более выская производительность.
2. Отсуствие необходимости применения более низкоуровневых языков.
3. Отличный отладчик.
4. Отличные средства рефакторинга.
5. Отличная IDE.
Gaperton> Неплохой подход к сравнению языков приведен у Пола Грэхэма. Там же утверждается неполноценность сравнения языков на основании порстого разложении по фичам (хотя это тоже важно). Тезис — сравнить между собой языки можно только после того, как плотно поработал с ними. Тогда становится очевидно, что язык Х дает больше возможностей, чем язык Y, как более "высокоуровневый". При этом, если на языке X человек не писал, объяснять ему логически, что Х "лучше" и выразительнее — бесполезно, так как фичи — это одно, а общая парадигма, идеология языка, не является простой суммой его фич, это нечто большее. Понять парадигму сложнее, фич для этого недостаточно. Мой пост Clean vs C++, проскакивавший недавно в юморе — сатира на эту тему.
Vlad2> Как показала моя практика как раз задачи копирования и обработки файлов лучше решать опять жен на полноценных языках программирования. Да пока тебе нужно скопировать несколько файлов, то командная строка проста и достаточна. Но как только нужно прибавить мало мальски сложную логику, то она пасует по полной программе. У полноценного ЯП и возможности по формулированию логики по больше, и возможности по отладке куда шире.
Дотнет же сдель дает ко всему прочему еще и то приемущество, что недостающую функциональность можно сварганить на нем же сомом. При этом производительность получается сравнимая с С++-ной, а скорость разработки с Питоном и Руби (а то и выше за счет отладчика, рефакторинга и IDE).
FR> У меня практика показывает что тексты обрабатывать гораздо удобнее скриптами.
