Честно говоря, для меня ситуация противоположная — хорошо знаком с Руби, а на Питоне писал небольшие скрипты. Ну, есть довольно много сходств.
Оба языка — объектно-ориентированны, в Руби есть миксины (интерфейсы с реализацией), можно подменить реализацию любого метода в классе (к том числе и в стандартной библиотеке), причем данную подмену можно сделать как для всех объектов класса, так и только для конкретного объекта. Наверняка в Питоне степень свободы сравнима.
В обоих языках есть широкая поддержка лямбда-функций и замыканий, в обоих целочисленный тип умеет «расширяться», когда не хватает разрядности машинного слова, в обоих сообществах есть «текущий» релиз — 2.7 для Питона и 1.8.7 для Руби (оба они страдают наличием GIL, кстати) — и релиз «светлого будущего» — 3.0 и 1.9 — с поддержкой Unicode и прочими плюшками.
Сходств очень много, некоторое время назад был даже такой полушутливый проект Unholy — компилятор Руби в Питон: github.com/whymirror/unholy
Так что, честно говоря, я ожидал, что у Питона на LLVM есть все шансы быть успешным.
В свое время пару лет назад «пересаживал» один проект с «голых» потоков (wait(), notifyAll()) на java.util.concurrent. Не пожалел ни минуты потраченного времени — код стал гораздо чище, понятнее другим разработчикам (особенно тем, кто только-только приходил в проект), а самое главное — избавились от всех дедлоков и лайвлоков.
Так что всем, кто до сих пор увяз в старом конкурентном коде, я настоятельно советую посмотреть хотябы в сторону j.u.c (а лучше — Clojure и/или Akka).
Тем, кто по какой-то причине не может перейти на Java 5 (да, знаю полно таких мест), напоминаю, что есть вполне рабочий и проверенный временем бэкпорт: backport-jsr166.sourceforge.net/
На самом деле, рассуждения автора о нерациональности применения LLVM для компиляции Питона кажутся по меньшей мере странными, особенно на фоне успехов Rubinius за последнюю пару лет. Изначально для JIT-компиляции Rubinius использовал GNU-Lightning, но затем они пересели на LLVM и остались весьма довольны результатами. Насколько я могу судить, Python и Ruby очень похожи с точки зрения внутреннего представления. Поэтому странно, что одному языку LLVM подошел, а другому — нет.
С точки зрения производительности Rubinius соперничает с YARV (Ruby 1.9) и JRuby и стабильно опережает MRI (традиционный интерпретируемый Руби), при этом сами разработчики утверждают, что целенаправленно над производительностью они не работают, а все улучшения появляются попутно во время работы над совместимостью с основной реализацией языка и с его следующей версией.
Примерно с июня прошлого года Опера Мини — мой основной браузер, с телефона выхожу в инет чаще, чем с компьютера (За исключением, разве что, работы — в офисе, конечно, гуглю с рабочей машины). Из недостатков в первыю очередь могу назвать неудобство набора — экранные клавиатуры оставляют желать лучшего. Как следствие, пользуюсь интернетом в основном в режиме «чтения», если и пишу что-то, но на Stackoverflow.com.
Я правильно понимаю, что это — реализация MVC на Эрланге? Темплейтинг выглядит вполне удобочитаемым, но остается вопрос, как обрабатываются случаи посложнее. Например, на практике часто возникает задача отображать данные в виде списка или таблицы, но случай, когда данных нет, требуется обрабатывать особо. Например, в случае с Java и JSTL код темплейта оказывается весьма тяжеловесным, и я, признаться, не встречал особенно выдающихся альтернатив.
Обычным ответом в таких случаях являются всевозможные вариации partials, часто предлагается писать свой компонент и вставлять его на страницу в виде тэга. Но на мой взгляд это не самое оптимальное решение: на сложных страницах код темплейта превращается в суп из спец-тегов на каждый чих. Конечно, с точки зрения server-side разработчика все может казаться вполне удобным, благодаря применению таких вот тэгов-модулей. Но с точки зрения фронт-энда это просто кошмар: любая правка верстки превращается в бесконечный перебор этих маленьких фрагментов HTML в поисках того самого, код которого надо изменить.
Я пока не встретил достойного решения проблемы темплейтинга и с удовольствием бы услышал о рекомендациях сообщества по этому поводу.
Да, по идее как раз все наоборот должно быть: телефонам — минимальный необходимый функционал, чтобы трафик сильно не есть, а на десктопе — какие-то дополнительные возможности. А то получается что-то совершенно несуразное — на мобильниках требуется два реквеста вместо одного, да еще и первым реквестом тянется вся телега jQuery со всем хозяйством (например, с воркэраундами для ие6 — зачем это на мобильниках?).
В общем, то, что сегодня называется jQuery Mobile лучше назвать jQuery UI Mobile — все равно там в основном компоненты для мобильного интерфейса и поддержка touch.
Скажите, а в сторону YUI3 не смотрели? У YUI есть билдер developer.yahoo.com/yui/3/configurator/ — можно собрать только ту функциональность, которая вам лично нужна. Грузится все через комбо-url с cdn Yahoo! — один реквест на JS и один — на CSS (если нужен). При переходе с ветки 2.х на 3.х одной из целей разработчиков как раз было разбиение крупных функциональных блоков на мелкие модули — чтобы грузить на страницу как можно меньше лишнего кода. Может быть результат получится не такой маленький, как ваш, но и далеко не 100 с лишним килобайт, как в jQuery. По характеру YUI 3 больше напоминает jQuery или MooTools.
А я пользуюсь Оперным почтовым клиентом для корпоративной почты. На прошлом рабочем месте по умолчанию стоял Evolution, на текущем — Thunderbird. Ноя все равно переопределяю — меня покупает то, что почта остается во вкладке браузера. У меня несколько вкладок — Opera m2, Gmail, Yahoo Mail — рядом открыты, и мне удобно, что вся почта в браузере. Опять же, не надо отдельный почтовый клиент запущенным держать.
У меня есть ощущение, что в какой-то момент возникнет стандарт расширений для браузеров. Chrome и Safari используют для них Javascript. В Mozilla такие расширения можно писать, используя JetPack. Теперь вот и Опера переносит в расширения свои наработки по Widget Specification — а там тоже все на Javascript.
У меня обновление в ветке 10.6х работает — в первый раз оно показывает диалог: мол, доступна новая версия — качать ее? А внизу в диалоге галка — больше не спрашивать, качать и ставить самому. После этого обновление работает почти как в Хроме, т.е. принудительно.
Разница в том, что Хром качает новую версию в распакованном виде и хранит ее параллельно с текущей. А при следующем запуске браузер работает из новой версии. Опера скачивает инсталятор, и при следующем запуске он включается с предопределенными параметрами и перетирает папку Оперы в Program Files.
Плюс в том, что на винте не лежат две версии браузера параллельно, а минус — в том, что при апдейте перед запуском браузера приходится немного ждать.
В Линуксе апдейт приходит средствами пакетного менеджера, так что там таких заморочек нет. Как на Маке с апдейтами, не в курсе.
А можно фидбэк сразу по адресной строке: раньше на «зеленых» страницах в адресной строке писалось имя компании и имя домена для «желтых», а теперь просто слово Trusted или Secure соответственно. Нужно нажимать на падлок, чтобы посмотреть, что за домен — неудобно.
Ладно, пусть воюют. Интересно, а мого таких, кто импортировали бы свой контакт лист из GMail в Facebook и обратно? FB мне постоянно подсовывает плашки, мол, импортируй контакты, а я что-то смысла не вижу.
Тор Норби в одном из последних подкастов делился своим опытом перехода с HG (когда он был в Оракл) на Git (теперь он работает в Гугле). Считает киллер-фичей Гита возможность склеить несколько патчей в один коммит. Например, работаете вы над каким-то таском, добились какого-то рабочего состояния и решили выложить изменения. А потом оказалось, что код грязноват, мб где-то идет отклонение от style-guides или какие-то debug выводы остались. Все прочистили, сделали красиво и опять закоммитили. Так вот, в Git можно взять эти два чейнджсета и объединить в один — как будто код с самого начала писался чистенько и по стандартам. В результате, говорит он, все чейнджсеты оказываются по делу, что особенно важно в большом проекте, когда их в целом очень много.
Не жалуются? — да постоянно, то на Реддите, то на ХН, то в группе разработчиков всплывают обсуждения. Нравится нововведение далеко не всем, а многие находят его совершенно неудобным.
Оба языка — объектно-ориентированны, в Руби есть миксины (интерфейсы с реализацией), можно подменить реализацию любого метода в классе (к том числе и в стандартной библиотеке), причем данную подмену можно сделать как для всех объектов класса, так и только для конкретного объекта. Наверняка в Питоне степень свободы сравнима.
В обоих языках есть широкая поддержка лямбда-функций и замыканий, в обоих целочисленный тип умеет «расширяться», когда не хватает разрядности машинного слова, в обоих сообществах есть «текущий» релиз — 2.7 для Питона и 1.8.7 для Руби (оба они страдают наличием GIL, кстати) — и релиз «светлого будущего» — 3.0 и 1.9 — с поддержкой Unicode и прочими плюшками.
Сходств очень много, некоторое время назад был даже такой полушутливый проект Unholy — компилятор Руби в Питон: github.com/whymirror/unholy
Так что, честно говоря, я ожидал, что у Питона на LLVM есть все шансы быть успешным.
Так что всем, кто до сих пор увяз в старом конкурентном коде, я настоятельно советую посмотреть хотябы в сторону j.u.c (а лучше — Clojure и/или Akka).
Тем, кто по какой-то причине не может перейти на Java 5 (да, знаю полно таких мест), напоминаю, что есть вполне рабочий и проверенный временем бэкпорт: backport-jsr166.sourceforge.net/
С точки зрения производительности Rubinius соперничает с YARV (Ruby 1.9) и JRuby и стабильно опережает MRI (традиционный интерпретируемый Руби), при этом сами разработчики утверждают, что целенаправленно над производительностью они не работают, а все улучшения появляются попутно во время работы над совместимостью с основной реализацией языка и с его следующей версией.
Обычным ответом в таких случаях являются всевозможные вариации partials, часто предлагается писать свой компонент и вставлять его на страницу в виде тэга. Но на мой взгляд это не самое оптимальное решение: на сложных страницах код темплейта превращается в суп из спец-тегов на каждый чих. Конечно, с точки зрения server-side разработчика все может казаться вполне удобным, благодаря применению таких вот тэгов-модулей. Но с точки зрения фронт-энда это просто кошмар: любая правка верстки превращается в бесконечный перебор этих маленьких фрагментов HTML в поисках того самого, код которого надо изменить.
Я пока не встретил достойного решения проблемы темплейтинга и с удовольствием бы услышал о рекомендациях сообщества по этому поводу.
В общем, то, что сегодня называется jQuery Mobile лучше назвать jQuery UI Mobile — все равно там в основном компоненты для мобильного интерфейса и поддержка touch.
Разница в том, что Хром качает новую версию в распакованном виде и хранит ее параллельно с текущей. А при следующем запуске браузер работает из новой версии. Опера скачивает инсталятор, и при следующем запуске он включается с предопределенными параметрами и перетирает папку Оперы в Program Files.
Плюс в том, что на винте не лежат две версии браузера параллельно, а минус — в том, что при апдейте перед запуском браузера приходится немного ждать.
В Линуксе апдейт приходит средствами пакетного менеджера, так что там таких заморочек нет. Как на Маке с апдейтами, не в курсе.
Как??? Как вам это удалось?