Позвольте добавить свои пять копеек:
1. Писать собственный Logger непрактично. Лучше использовать встроенные возможности Qt (qDebug) или Python (logging). И для того и для другого можно определить обработчики сообщений (Qt — qInstallMsgHandler, Python — logging.handlers).
2. Для потоков лучше написать декоратор, который будет производить всю работу по инициализации и очищению ресурсов. Это вам сильно упростит жизнь — фактически, вы сможете превращать функции из однопоточных в многопоточные, просто приписав к ним этот декоратор. Конечно, при этом они станут асинхронными, но для GUI-приложений зачастую это именно то, что нужно.
Правда тесты довольно-таки староваты, по-хорошему надо бы их прогнать на современных версиях ЯП. Ну и ради справедливости надо добавить что есть JPython (для JVM) и IronPython (для .NET), которые в некоторых случаях могут работать весьма шустро. Я не говорю уже про всякие расширения типа psyco.
По себе скажу, что я вообще уже давно забил на сравнение производительности, т.к. в основном узкие места — это взаимодействия со внешней средой (БД, файловой системой, сетью и т.п.) Есть, конечно, области, где скорость важна — мультимедиа приложения, или реально высоконагруженные сайты. И здесь уже не до религиозных споров — выбираются технологии по возможностям. Но замечу, что YouTube все-таки написан на Python.
С точки зрения скриптовости С# не так уж хорош, прежде всего, потому что он компилируется. И хотя практически все скриптовые языки компилируются в промежуточный байт-код, процесс компиляции C#-проектов намного дольше. Я помню на своей практике, когда не такой уж тяжеловесный ASP.NET-сайт запускался по несколько минут из-за компиляции ASPX-страниц.
И не надо умалчивать другие не особо приятные вещи про ASP.NET — громоздкие ViewState-ы на страницах, которые любят забивать трафик, кошмарные автогенерируемые имена для контролов, и вообще любовь этой платформы к памяти и процессору. Естественно, все это решается, однако для простенького сайта слишком уж много чести, чтобы еще разбираться с такого рода проблемами. У ASP.NET есть своя ниша, но простые сайты на этой технологии точно писать не стоит. Я помню в свое время как мы ковыряли движок DNN, и сколько там понаходили кода только для оптимизации проекта, чтобы он крутился более или менее адекватно, хотя проект по сути достаточно простой.
И про СУБД. Oracle и PostgreSQL позволяют писать хранимые процедуры на Java, причем очень давно, и все уже к этому привыкли. Это так, для общего развития, хотя возможно, вы это и знаете.
Twitter moved to the Java JVM for their server infrastructure (long lived processes) and moved to Scala to program against it (high level language, static typing, functional). Ruby is used on the front-end but wasn't performant or reliable enough for the back-end.
Eclipse+PyDev — практически идеально решение. Возможно, в винде у этой связки и есть какие-то проблемы, у себя и у моих сотрудников в линуксе их вообще ни разу не наблюдал. Отладка тоже работает на ура, хотя некоторые придирки к отладчику все-таки есть, но это мелочевка.
MySQL мы вообще перестали использовать в своих проектах. При интенсивной работы с фикчами он очень существенно тормозит, а они у нас очень много используются в юнит-тестах. Сейчас используем исключительно PostgreSQL.
Вы сами перечислили причины, почему Python ускоряет разработку — на нем проще проектировать грамотную архитектуру, проще ловить баги, проще тестировать. Ну и с разработчиками тоже особо проблем нет из-за низкого порога вхождения, т.е. любой грамотный разработчик сможет писать на Python-е через неделю после его изучения с нуля.
Единственное, хочу отметить про баги. Python — динамически-типизируемый язык, и соотвественно, можно ловить много багов из-за несоответствия типов. Мы для себя эту проблему решили жестким требованием соблюдать 100%-ое покрытие кода.
К сожалению, я тоже не изучал. Естественно, у него есть своя ниша, и думаю, что он больше применим для CGI-скриптов, что подтверждается «Who uses web.py?» секцией на заглавной странице проекта.
Вообще, я не воспринимаю выбор фреймворка как некий религиозный вопрос. Разнообразие проектов существует не просто так, и у каждого есть своя уникальность. Но при этом возникают другие вопросы — времени, денег и усилий. Для кого-то они не важны, например, для студентов или людей, у кого излишек времени и/или денег. Я себе такие растраты позволить не могу и не хочу, поэтому зачастую выбираю именно Django как оптимальный вариант с точки зрения траты ресурсов.
Спасибо, я в курсе. Оптимизация Django-приложений — это отдельная тема, для которой необходимо упоминать такие страшные слова, как memcached, nginx, load balancer, database cluster, replication и т.п. В принципе, все это сказано в презентации Django Con High Performance Django.
Автоматическая админка — это не только автогенерация форм и списков. Это еще и права доступа, аудит, отслеживание целостности, всяческого рода фильтры и поиски. Я не сомневаюсь, что есть готовые решения для любой платформы, но в Django это идет из коробки, и не приходится что-то искать и пробовать.
Не хочу поднимать холивар, а просто выскажу, почему я не использую RoR в своих проектах:
— слабая документация, приходится ковырять кучу ресурсов и смотреть тяжелые скринкасты;
— неинтуитивно понятный ЯП, без привычки иногда читать тяжеловато, особенно если злоупотребляют mixin-ами и другими техниками;
— явные тормоза, даже со свежей версией (по-крайней мере, под линуксом);
— кривой rcov, что в итоге не позволяет мне считать code coverage (сейчас может исправили, но последний раз, когда я смотрел летом, он не работал со свежей версией Ruby);
— нет единообразности в процедурах локализации. То, что предлагается по умолчанию, не столь удобно в использовании.
Я это косвенно упоминал. Фактически, все упомянутые пункты влияют на скорость разработки. С другой стороны, это очень шаткий аргумент, т.к. в некоторых случаях разработка на Django не столь быстра, как на специализированных фреймворках. Например, в том же RoR некоторые вещи можно писать намного быстрее, если сайт полностью совпадает с паттернами проектирования, заложенными в рельсы изначально.
Да, я в свое рассматривал Pylons. В целом, это система, которая связывает другие библиотеки — SQLAlchemy, Genshi и т.п., и в чем-то она напоминает Java Spring. Бесспорно, у Pylons есть свои плюсы, но они перекрываются другими недостатками (по крайней мере в моих глазах): недостаточная зрелость проекта, небогатая документация (это касается не только самого Pylons, но и библиотек, которые он предлагает использовать), отсутствие автоматической админки. Все это повышает порог вхождения, и понижает скорость разработки. А это — потерянные бабки, это трата времени на его изучение молодыми специалистами, это трудноопределимые баги, когда непонятно кто виноват — тот же Genshi, SQLAlchemy или сам Pylons.
1. Писать собственный Logger непрактично. Лучше использовать встроенные возможности Qt (qDebug) или Python (logging). И для того и для другого можно определить обработчики сообщений (Qt — qInstallMsgHandler, Python — logging.handlers).
2. Для потоков лучше написать декоратор, который будет производить всю работу по инициализации и очищению ресурсов. Это вам сильно упростит жизнь — фактически, вы сможете превращать функции из однопоточных в многопоточные, просто приписав к ним этот декоратор. Конечно, при этом они станут асинхронными, но для GUI-приложений зачастую это именно то, что нужно.
www.timestretch.com/FractalBenchmark.html
Правда тесты довольно-таки староваты, по-хорошему надо бы их прогнать на современных версиях ЯП. Ну и ради справедливости надо добавить что есть JPython (для JVM) и IronPython (для .NET), которые в некоторых случаях могут работать весьма шустро. Я не говорю уже про всякие расширения типа psyco.
По себе скажу, что я вообще уже давно забил на сравнение производительности, т.к. в основном узкие места — это взаимодействия со внешней средой (БД, файловой системой, сетью и т.п.) Есть, конечно, области, где скорость важна — мультимедиа приложения, или реально высоконагруженные сайты. И здесь уже не до религиозных споров — выбираются технологии по возможностям. Но замечу, что YouTube все-таки написан на Python.
И не надо умалчивать другие не особо приятные вещи про ASP.NET — громоздкие ViewState-ы на страницах, которые любят забивать трафик, кошмарные автогенерируемые имена для контролов, и вообще любовь этой платформы к памяти и процессору. Естественно, все это решается, однако для простенького сайта слишком уж много чести, чтобы еще разбираться с такого рода проблемами. У ASP.NET есть своя ниша, но простые сайты на этой технологии точно писать не стоит. Я помню в свое время как мы ковыряли движок DNN, и сколько там понаходили кода только для оптимизации проекта, чтобы он крутился более или менее адекватно, хотя проект по сути достаточно простой.
И про СУБД. Oracle и PostgreSQL позволяют писать хранимые процедуры на Java, причем очень давно, и все уже к этому привыкли. Это так, для общего развития, хотя возможно, вы это и знаете.
Позволю себе процитировать:
MySQL мы вообще перестали использовать в своих проектах. При интенсивной работы с фикчами он очень существенно тормозит, а они у нас очень много используются в юнит-тестах. Сейчас используем исключительно PostgreSQL.
Единственное, хочу отметить про баги. Python — динамически-типизируемый язык, и соотвественно, можно ловить много багов из-за несоответствия типов. Мы для себя эту проблему решили жестким требованием соблюдать 100%-ое покрытие кода.
Вообще, я не воспринимаю выбор фреймворка как некий религиозный вопрос. Разнообразие проектов существует не просто так, и у каждого есть своя уникальность. Но при этом возникают другие вопросы — времени, денег и усилий. Для кого-то они не важны, например, для студентов или людей, у кого излишек времени и/или денег. Я себе такие растраты позволить не могу и не хочу, поэтому зачастую выбираю именно Django как оптимальный вариант с точки зрения траты ресурсов.
— слабая документация, приходится ковырять кучу ресурсов и смотреть тяжелые скринкасты;
— неинтуитивно понятный ЯП, без привычки иногда читать тяжеловато, особенно если злоупотребляют mixin-ами и другими техниками;
— явные тормоза, даже со свежей версией (по-крайней мере, под линуксом);
— кривой rcov, что в итоге не позволяет мне считать code coverage (сейчас может исправили, но последний раз, когда я смотрел летом, он не работал со свежей версией Ruby);
— нет единообразности в процедурах локализации. То, что предлагается по умолчанию, не столь удобно в использовании.