считаете что это стоит снижения проивзодительности? :) Программисты старой закалки иногда до сих пор любят даже строгую типизацию. По той простой причине - что это наводит абсолютный порядок. А вот изменять встроенные типы - путаницу может ввести ещё какую. Да и особого смысла в этом - нет! Ну какоооой смысл? писать 5.yahoo(6) вместо yahoo(5,6)? Это не даёт преимуществ в логике. Это не даёт преимеществ в скорости разработки.
Это может и удобнее в каких-то конкретных случаях. Но эта функциональность легко дублируется простеньким пользовательским объектом =). Спрашивается - надо ли делать числа объектами всегда? Или лучше иметь возможность это сделать когда действительно нужно. И именно когда действительно нужно жертвовать проивзодительностью при работе с базовыми типами?
не придирайтесь к словам. Логика фреймворка и бизнес логика программы две разные вещи. И фреймворки можно сравнивать - какой из них логику самого MVC выполнит быстрее. Естественно при этом бизнес логика не должна быть уж совсем тормознутым узким местом. Но чем плохо - если фреймворк сам по себе очень быстр, даже если бизнес-логика в 100 раз медленнее? )))
я упрекаю руби в том, что питон по скорости написания кода не медленее руби (ну если представить что и тот и тот язык вы знаете от зубов), а вот по скорости питон редко когда меньше чем в 1.5-2 раза медленее руби =). Собственно. Смысл руби?. А то что писать на РОРе такие проекты как twitter - сами девелоперы twitter-а же и говорят "да ну его, надо мигрировать"... +)
Можно конечно писать на ROR+C, но при этом опять таки непонятно - почему не Питон+С, ведь это все же будет быстрее =).
блин да вы же прекрасно понимаете о чем я говорю - ну что за дурацкий флейм =).
да, внутри приложения море кода на C, однако тратиьт время на переписывание модулей питона, которые просто интерфейсят вызовы в библиотеки C нет смысла. Так же весь UI, естественно, не на Си =). А вот темплейтная система - на Си.
я сейчас и вовсе собираюсь начать проект http-сервера на Си, который будет выстраивать MVC/Event фреймворк для пользовательского питоновского кода. Hello World будет выдываваться в 30-50 раз быстрее чем на PHP. Хоть это и не показатель, но тем не менее может получиться создать самый быстрый фреймворк для языка сверх-высокого уровня.
я на это и агитирую. То что писать нужно - на нескольких языках. А до тех пор пока зацикливаетесь на Ruby или чем-то ином - до настоящего профессионала вам будет далеко.. ))
причём. у авторов такого рода статей все изъясняется при помощи таких ценностей, что сразу становится понятно - кроме Ruby, может пишут на PHP, но уж точно не пробовали C/C++/D :)
я писал где-то тут уже вокруг - писать надо на нескольких языках. Нет смысла парсинг конфиг-файла, который при запуске сервера один раз происходит, писать на Си. Но есть смысл писать на Си то, что каждый запрос отнимает, скажем, до 5% общего времени выполнения. Большей частью питон можно разогнать до высоких скоростей, переписывая стандартные модули (которые в большинстве своём на самом питоне) - на Си.
смотрите как можно сравнить по-забавнее: ни один самый популярный проект в одной любой сфере не неписан на Ruby. :). Возможно, с редким исключением, но общая картина такая. Если вы начнёте писать на Ruby, а конкурирующий проект на Python, то у них будет огромное преимущество, особенно если они не будут использовать django, а напишут свой более шустрый и подходящий нуждам фреймворк. Да, они потратят на это раза в 2 больше времени, но не факт что потратив +50% по времени на оптимизацию, вы сможете их догнать =).
это значит что о Си забывать не стоит =). А вот "удобно" без строгой типизации можно и на питоне писать. Так я вот не пойму - зачем ещё более высокоуровневый (т.е. ещё более сверх-высокоуровневый) язык? На питоне скорость разработки чистого кода сравнима с Ruby. Да тоже самое и PHP касается, но он уже не так удобен и логичен. Так за что платятся потраченные такты Ruby? За возможность написать 5.times.. вместо for i in range(5)..?
этож страшно даже подумать - некоторые алгоритмы и штуки на Си могут быть в сотни раз быстрее чем те же на Ruby. Купить 1 сервер или 100? :) Очень конечно примитивная аналогия, но тем не менее.. сейчас я тебя заплюсую.
мастерство - не в том чтобы писать на Ruby. А в том чтобы выбирать правильный инструмент для каждого конкретного случая. Как правило, идеальным вариантом будет смесь из интерпретируемых/компилируемых языков. Часто нужно будет их заставлять свободно общаться между собой.
Скорость разработки же зачастую больше зависит от наличия готовых инструментов. И желания использовать уже написанное, вместо самописного.
Это может и удобнее в каких-то конкретных случаях. Но эта функциональность легко дублируется простеньким пользовательским объектом =). Спрашивается - надо ли делать числа объектами всегда? Или лучше иметь возможность это сделать когда действительно нужно. И именно когда действительно нужно жертвовать проивзодительностью при работе с базовыми типами?
Можно конечно писать на ROR+C, но при этом опять таки непонятно - почему не Питон+С, ведь это все же будет быстрее =).
да, внутри приложения море кода на C, однако тратиьт время на переписывание модулей питона, которые просто интерфейсят вызовы в библиотеки C нет смысла. Так же весь UI, естественно, не на Си =). А вот темплейтная система - на Си.
я сейчас и вовсе собираюсь начать проект http-сервера на Си, который будет выстраивать MVC/Event фреймворк для пользовательского питоновского кода. Hello World будет выдываваться в 30-50 раз быстрее чем на PHP. Хоть это и не показатель, но тем не менее может получиться создать самый быстрый фреймворк для языка сверх-высокого уровня.
причём. у авторов такого рода статей все изъясняется при помощи таких ценностей, что сразу становится понятно - кроме Ruby, может пишут на PHP, но уж точно не пробовали C/C++/D :)
мастерство - не в том чтобы писать на Ruby. А в том чтобы выбирать правильный инструмент для каждого конкретного случая. Как правило, идеальным вариантом будет смесь из интерпретируемых/компилируемых языков. Часто нужно будет их заставлять свободно общаться между собой.
Скорость разработки же зачастую больше зависит от наличия готовых инструментов. И желания использовать уже написанное, вместо самописного.
Короче не знаю. Устало улыбаюсь. )))