Софтовый шоппинг

Есть на свете серьёзные покупки. Например, автомобиль люди (чаще всего) покупают вдумчиво: изучают характеристики, ходят по салонам, сравнивают, изучают результаты тестов. Прямая противоположность им — рутинные покупки вроде молока и хлеба.

Посередине же существует шоппинг — получение удовольствия от спонтанных «удачных покупок». Что такое удачная покупка? Что-нибудь, что сразу понравилось. Или что-то потенциально полезное, но очень дешево. Или что-то, что давно хотел и случайно встретил. Кажется, будто люди ищут в магазине товары, но на самом деле они ищут удовольствие от самого факта покупки.

Эти три рынка совершенно различны. Важно понимать, на какой из них вы хотите попасть с вашим товаром (или мазагином).

Посмотрим на софт. Большинство разработчиков считает, что они продают автомобили: пользователь сначала обнаружит потребность, потом пойдет выбирать, проанализирует варианты и что-то одно купит.

Разумеется, часто так и бывает. Но не нужно забывать и про другие варианты. Например, возьмём MacUpdate Promo: большие (вроде 50%) скидки на программы, которые длятся один день (каждый день продают новую программу). Я подписан на их рассылку, и там регулярно пробегает софт, который очень хочется купить.

Или, например, по статистике подавляющее большинство купленных в App Store iPhone-приложений никогда не запускают второй раз. Когда Apple рекомендовали цены вроде $0,99 или $3,99, думаю, они прекрасно понимали, что делают: магазин, в котором люди будут наслаждаться покупкой, а не удовлетворять возникшие потребности.

Кто-то из блоггеров недавно сравнивал iPhone-приложения с шоколадными батончиками: люди считают нормальным потратить бакс на Snickers и съесть его за две минуты, точно так же нормально потратить бакс на игрушку и поиграться в неё пять минут.

Для шоппинга очень важен user experience, поскольку на самом-то деле у пользователя нет большой потребности. Он сбежит, если вы не будете его развлекать и удерживать. «Самое популярное», «еще часто покупают вот это», отзывы, заказ в один щелчок — всё это вводит пользователя в flow state, при котором он получает удовольствие, а вы — деньги.

В этом часть гениальности iTunes: он делает шоппинг до безобразия простым и неотделимым от прослушивания музыки. Apple успешно развивает рынок в направлении «шоппинг — часть нормального использования софта». В iPhone OS 3.0 можно покупать дополнения из самих приложений; на сцене мы видели демку Sims 3, где в процессе игры можно докупать коллекции вещей, и демку многопользовательской стрелялки, где перед боем можно купить rocket launcher и другой полезный арсенал (за реальные деньги! вы только подумайте!)

Не знаю, как вы, а я считаю это гениальным. Не пропустите возможность встроить шоппинг и в ваши программы. Может, маленькие милые плагинчики? Мелодии или темки? Что-то, что нафиг не нужно пользователю, но зацепит его с первого взгляда. И не забудьте делать некоторые товары более удачными покупками с помощью скидок, featured items, editor’s choice, рейтингов.

(Разумеется, товары не обязаны быть платными. Вы можете зарабатывать деньги за счет популярности или рекламы, или же предлагать смесь платного и бесплатного. Поэтому вас, разработчики open-source, данный метод тоже касается: ничего так не увеличивает популярность, как каталог почти никому не нужных фенечек, которые можно поставить одним кликом.)

Sneak Peak: YourSway Builder

Наша компания отличается еще и тем, что пользуется самописной системой сборки. Когда-нибудь мы доведем её до продукта и будем предлагать другим, как CrashKit, но пока что YourSway Builder — это приватное удовольствие.

Зачем писать своё, когда в мире есть BuildBot’ы и CruiseControl’ы? Чтобы не париться с их поддержкой. Каждая существующая система предполагает, что вы держите настроенный клиент и сервер, и готовы с ними возиться каждый раз, когда вам нужно изменить способ сборки или начать собирать новый проект.

Мы, напротив, хотим, чтобы для поднятия билдов нового проекта было достаточно браузера.

На любом компьютере можно запустить клиентское приложение, которое сможет собирать любые проекты, скачивая все нужные пререквизиты. У нас каждый член команды может запросто запустить сборку любых проектов на своем компьютере из своих репозиториев (ибо при использовании DVCS у каждого может быть свой репозиторий).

На страничке в Backpack есть несколько скриншотов, а также описание нашего vision’а. Повторюсь, что в YourSway Builder’е пока есть только то, что было нам совершенно необходимо. Мы им пользуемся во всех проектах, но для публики он еще не готов.

А что вы думаете по поводу билд-систем? Чего вам в них не хватает? В каком виде YourSway Builder был бы вам интересен?

Меньше ветвлений!

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

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

Тут есть две альтернативы. Вариант А: попытаться отправить исключение, если не удалось, записать его в файл, минут через десять считать и попробовать заново. Вариант Б: записать исключение в файл, попробовать его отправить через пару секунд; если не удалось, повторить снова еще позже.

Представьте себе, что мы выбрали вариант А. Тогда, поскольку чаще всего сервер доступен, большой кусок кода, отвечающий за сохранение на диск, установку таймера, загрузку и пр., обычно не используется и не тестируется. А значит:

1. Увеличиваются затраты на автоматизированные тесты и на QA.

2. Рано или поздно вкрадется бага, не отловленная тестами и не пойманная вашим QA-процессом. (Например, всё рушится только под Windows Vista x64, установленной на FAT32-раздел.)

3. Продукт с этой багой вы можете поставить заказчикам и не узнаете о ней, пока заказчик с ноутбуком под Windows Vista x64 на FAT32 не запустит ваш продукт вдали от Интернета.

Сравним с вариантом Б. Исключение всегда сначала записывается, потом устанавливается таймер, он срабатывает, исключение считывается и отправляется. Нормальную (частую) и ненормальную (редкую) ситуации обрабатывает один и тот же код; если он не работает, пользователи закричат об этом сразу же.

Иногда такая «унификация» кода подсказывает дополнительные возможности. Скажем, если программа начнет генерировать тысячи исключений в секунду, отложенная на пару секунд отправка поможет реже обращаться к серверу.

Из нашего правила следуют два важных практических соображения.

Первое. Если вы взвешиваете, добавлять или не добавлять в программу новую опцию, помимо прочего подумайте и о том, сколько придется написать редко исполняющегося кода.

Второе. Когда вы пишете обработку ошибок или каких-то других особых ситуаций, всегда пытайтесь превратить эти особые ситуации в нечто, что исполняется каждый день. Вместо операций «начать» и «продолжить» делайте операцию «начатьИлиПродолжить», вместо событий «завершилось» и «прервано из-за ошибки» делайте событие «остановилось» и т. д.

CrashKit

Мы начинаем ограниченное бета-тестирование CrashKit — веб-приложения, собирающего и показывающего необработанные исключения в ваших продуктах.

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

CrashKit появился совсем недавно, но уже приносит нам огромную пользу, которой мы и спешим поделиться с вами.

В ближайшее время мы введем в строй поддержку целой кучи языков, так что на чем бы вы ни писали, смело шагайте на crashkitapp.appspot.com, оставляйте свой e-mail, и мы в течение месяца пригласим вас участвовать в бета-тестировании.

(Если вам интересно, CrashKit написан на Google App Engine. Он уже некоторое время используется в приложениях, которые мы поставляем клиентам. Хорошо работает поддержка Java/OSGi, в разработке поддержка Java/Servlets и Python/Django, после них будет Ruby on Rails и что-нибудь еще, чего захотят пользователи.)

Совместимость

Название этой операционной системы, созданной маленькой компанией в конце 80-х и установленной сегодня на 8% компьютеров мира, программисты под Mac и iPhone регулярно вспоминают, набирая префикс NS у названий системных классов.

Nextstep 1.0 появилась в 1989 году после трех лет разработки, имела полностью объектно-ориентированное API с архитектурой model-view-controller, имела ядро Mach и была Unix’ом. Теперь она называется Mac OS X. За прошедшие 20 лет дизайн её API, теперь именующимся Cocoa, мало изменился: всё те же NSApplication, NSView, NSDocument успешно лежат в основе сегодняшних красивых анимированных Mac-приложений. Исходники GNUstep, реализующего Nextstep API 1993 года, можно в наши дни читать вместо (недоступных) исходников Cocoa.

Пользовательский интерфейс Nextstep включал богатый drag’n’drop между приложениями, Dock, инспекторы, общесистемные сервисы, позволяющие приложениям пользоваться услугами друг друга, и «бандлы» — директории, выглядящие как файлы для пользователя и содержащие приложение со всеми зависимостями, которое достаточно просто скопировать на жесткий диск для установки. Всё это знают и любят сегодняшие пользователи маков.

Как относятся в Apple к совместимости? Плохо. Первую революцию они сделали в 2001 году с выходом Mac OS X: старые приложения теперь могли запускаться только в приложенной виртуальной машине, эмулирующей Mac OS 9 (при этом, естественно, выглядели неприглядно и медленно работали). В 2005 году эмулятор почил с выходом OS X 10.4 (итого: 4 года на портирование старых приложений).

Для портирования людям был дан Carbon — C API, почти повторяющее API старой Mac OS 9. Carbon-приложения всегда оставались нежеланными гостями на компьютере: look’n’feel интерфейса OS X, как истинно объектно-ориентированной ОС, реализован в коде Cocoa (да, там можно изменить поведение стандартных элементов управления, просто унаследовавшись от них). Carbon представлял собой еще одну реализацию примерно того же самого интерфейса.

Вторую революцию Apple сделала в 2007 году: Carbon объявлен устаревшим и не будет поддерживать 64-битные приложения. Кадр года: Adobe переписывает Photoshop на Objective C. Называется, а вам слабо такое устроить?

Что приобретено взамен совместимости? Общий уровень приложений платформы: они все обновляются и соответствуют современным стандартам. Это работает по спирали: от более высокого качества приложений увеличиваются ожидания пользователей («никто не запустит программу без большой красивой иконки»), от высокого уровня ожиданий растет качество приложений. Apple создала платформу, в которой качество является более значимым (по сравнению с другими платформами) конкурентным преимуществом, и от этого создатели приложений больше инвестируют в качество.

Вернемся к Nextstep и заметим, что Cocoa является примером архитектуры, которая работает настолько хорошо, что её не нужно менять. Совместимость — не препятствие, так что эксперимент довольно чистый.

Зато NeXT/Apple серьезно относятся к преемственности навыков пользователя. Метафора пользовательского интерфейса Nextstep/OS X не меняется уже 20 лет. Внешний вид окон OS X не меняется 8 лет. Интерфейс приложений развивается эволюционно; Photoshop переписали, но выглядит и работает он так же; вышла новая версия iWork, но она только местами отличается от старой.

Что происходило всё это время в параллельном мире? 1989 год — релиз Nextstep 1.0 — вышла Windows 2.0 без перекрывающихся окон. 1995 год — вышла Windows 95, прощай, все старые навыки. 2001 год — вышла Window XP, теперь вы не узнаете свою панель управления. 2002 год — Microsoft выпускает .NET Framework 1.0, Desktop-приложения на котором до сих пор никто не пишет. Кстати, писать Desktop-приложения вообще не на чем: MFC — поганое уродство, всё остальное до жути низкоуровневое (Win32 API отличается от Cocoa как ассемблер от Питона).

2007 год — вышла Windows Vista, прощайте, привычки, теперь всё в новом месте. Зато спиздили еще чуть-чуть гуйни мака, сделали мигающий экраном костыль для безопасности приложений (на маке privilege elevation в приложениях к этому моменту уже много лет как нормально ненавязчиво работало). Вышел Office 2007, его нужно изучать заново. 2009 год — Microsoft в Windows 7 меняет Taskbar на Dock и хвалится этим достижением в блоге. Кстати, Office 2007 Ribbon Bar будет доступна всем приложениям, теперь вам придется заново изучать не только офис.

Зато вы всё еще можете запускать DOS-приложения на Windows Vista. Реймонд Чен в своём блоге высоко воспевает культуру совместимости в Microsoft. Но стоит ли она выпуска инвалидских продуктов? Всё дело в крупно-корпоративном рынке, которому его старые приложения ценнее качества ОС. Возможно, во времена Windows 95 совместимость была необходима и для пользователей: графические интерфейсы стали массовыми именно после Windows 95, и имей она проблемы, этого могло просто не произойти.

Мораль раз: знайте, когда устранять совместимость, иначе она помешает конечному пользователю.

Мораль два: нет так быстро всё меняется в ай-ти; команды под руководством великих людей создают технологии, живущие десятилетиями.

Мораль три: культура качества — ценнейшая штука для любой платформы; без неё корпорации не способны выпускать хорошие продукты, даже если на рынке есть образцы для подражания.

MacWorld 2009: App Store для Mac-приложений?

Позволю себе сделать прогноз на MacWorld 2009: в Mac OS X 10.6 Snow Leopard будет встроена DRM-технология, позволяющая продавать OS X-приложения через App Store наряду с iPhone-приложениями. Хотя некоторые freetards повозмущаются, для большинства это будет очередной реализованной мечтой.

Программистам — ниже барьер входа на рынок, не нужно изобретать свой веб-сайт с веб-магазином, серийники, систему лицензирования. (Страшно сказать — вообще никаких серийников. Из моего опыта с app store'ом, DRM рулит.) А пользователям — единый каталог софта, объединяющий лучшее из миров Unix (репозиторий пакетов, откуда можно ставить нужные программы в несколько клавиатурных кликов) и коммерческих приложений.

Самое приятное в этой перспективе — то, что купленные (или, для бесплатных, скаченные) программы запоминаются в iTunes App Store. Если сменить телефон, на новом тут же появятся все программы и настройки, которые были на старом. Распространение принципа на компьютеры сделает апгрейд мака полностью соответствующим известному комиксу авторства Trunks и Soto:

Девять причин перейти на Git

Обновление: см. также пост «Всё, что нужно знать про Git».

Когда-то я рекомендовал CVS, если вы пользуетесь системой контроля версий в основном для резервного копирования, и что-нибудь вроде Mercurial, если видите в этом искусство.

Теперь всё изменилось. Я однозначно рекомендую одну систему контроля версий для любых потребностей: Git.

Причины:

0. Я бы даже не стал упоминать это, но ведь кто-нибудь спросит. Git — распределенная система контроля версий (разумеется). Дальнейшее описывает, почему он лучше Mercurial, Bazaar, darcs и др.

1. Репозиторий остаётся в ваших руках. В CVS, например, файлы имели вразумительный формат, и к ним по большой потребности можно было применить /dev/hands или /usr/bin/perl (что мно-о-ого раз спасало автора этих строк).

Ваши возможности в Git на порядок больше, поскольку весь его высокоуровневый интерфейс — это всего лишь набор скриптов, использующих утилиты низкого уровня в лучших традициях Unix. Теми же утилитами удобно править базу данных и вам. (В крайнем случае можно и руками — вся база хранится в зазипованых текстовых файлах простого формата, имя которых является SHA1-хешем содержимого.)

2. За git-commit --interactive можно продать душу. Этот минималистский консольный интерфейс для выбора входящих в коммит изменений лучше всех виденных мною GUI.

3. Двусторонняя синхронизация с CVS и Subversion. Если работодатель или автор любимого плагина имеет консервативные взгляды, вас это не остановит. (Правда, commit'ы в CVS экспортируются наполовину вручную.)

4. Man, it's sane. Логичный и предсказуемый. Скажем, мне нравится концепция index'а (и записи в него по git-add) и отслеживания перемещений по содержимому (команды вроде svn mv всегда доставляли одни проблемы). Естественно, это субъективная оценка.

5. Теперь есть адекватная версия для Windows. Разумеется, это не преимущество перед другими, но до появления MinGW-порта круг применений был ограничен. (Не попадайтесь на провокации и не качайте версию, которая пытается скомпилировать Git при инсталляции! Это всё проделки Ктулху. Инсталлятор нормальных бинарников работает отлично.)

6. Git умеет строить из себя CVS-сервер, так что ваша любимая IDE будет с ним общаться, как с родным. (С другой стороны, под OS X мне удобнее пользоваться командной строкой, чем поддержкой в IDE.)

7. Git имеет красивый веб-интерфейс out of the box. Я привык выбирать продукты, хорошо работающие из коробки, и это для меня хороший знак. (Ср. с убогой умолчательной темой у Mercurial.)

8. Формат репозитория дружелюбен к rsync, обычному HTTP и backup'ам. Коммиты только добавляют новые файлы, не изменяя существующих. (Не считая файлов-ссылок вроде HEAD и refs/heads/master, но их мало и они очень маленькие.) Файлы репозитория можно раздавать через HTTP любым веб-сервером. Эффективно работает rsync. (Однако: после push'а изменений через тупой протокол на сервере нужно выполнить специальную команду Git, обновляющую некоторые файлы.)

9. Как следует из пункта 1, с использованием низкоуровневых утилит можно писать свои скрипты, делающие что-то интересное и новое. Многие этим воспользовались, так что у Git есть расширения (например, для patch queues, если вам сиё актуально) и альтернативные интерфейсы.

Одним словом, что бы вы ни думали про ядро Linux, за создание Git Линуса Торвальдса точно можно уважать.

Недостаток один — в процессе работы (иногда) требуется вовлечение мозга. Впрочем, всё реже и реже — например, магическое заклинание «git-reset --hard HEAD^» / «git-commit -c ORIG_HEAD» теперь стало частью «git-commit --amend». В любом случае, перед применением Git вам придется разобраться в его внутренностях (вся информация есть в tutorial'е и в man'ах).

Смотрим и наслаждаемся: Linus Torvalds on git (Google Tech Talk).

CVS vs. SVN

(Про историю и возможности CVS и Subversion написано в Wikipedia.)

Относительно CVS/SVN меня спрашивали за последнее время уже раза три, поэтому ниже изложено мое мнение по поводу source control в общем.

Первое. Если на сохранение версий исходных кодов есть время и не жалко сил, я бы посмотрел в сторону нетрадиционных бесплатных систем контроля версий. Например, darcs. (Но есть и множество других. Если вам правда хочется хранение истории видеть частью программистского искусства, не запрещается даже написать свою систему, как Линус Торвальдс. Уж по крайней мере стоит рассмотреть все имеющиеся варианты.)

Поддержка darcs средами разработки весьма плоха, но зато вы имеете возможность записывать в репозиторий часть изменений в файле и обмениваться изменениями между разработчиками, не складывая их в общий репозиторий. (Вообще, это распределённая система со всеми вытекающими. Единого центрального репозитория нет. В darcs каждая рабочая копия — одновременно и branch, и репозиторий.)

Второе. Если вам нужно просто хранить историю версий для большого настоящего проекта со сроками и всеми делами, я бы выбрал CVS. Причина проста и банальна. Если в репозитории случится беда (а она хотя бы раз в год случается), в него можно залезть и поправить всё руками. Руками же можно перенести часть репозитория в другое место, исправить проблему в рабочей копии и т. п.

В сторону Subversion смотреть можно. Однако она ещё крайне молода. Стоит копнуть чуть глубже, например, в сторону нетривиальной настройки прав доступа или перемещений между репозиториями, как всё оборачивается печально. Кроме того, интеграция Subversion с, например, Eclipse чуть хуже, чем интеграция CVS.

У Subversion по сравнению с CVS есть три преимущества.

Первое — атомарные коммиты. Действительно хорошо, однако жить можно и без них. (Пару недель назад двое товарищей по работе начали коммитить в один и тот же репозиторий CVS одновременно. Получилась картина «две змеи, поедающие друг друга». У каждого процесс остановился посередине из-за конфликтов. Но ничего, справились.)

Второе — поддержка переименования файлов. Однако, если вы гонитесь за полным порядком в репозитории, вам Subversion будет мало, а если нет, то удалить старый и добавить новый файл достаточно.

Третье — хранение метаданных. Однако метаданные нужны редко. Встроенные навороты вроде svn:external работают плохо. Другое дело, если у вас есть сторонние утилиты, интегрирующиеся с SVN при помощи свойств.

(Есть также мнение, что Subversion на больших проектах медленно работает, но я не поверю, пока не увижу сам.)

Сравнение возможностей разных систем управления версиями можно найти на Wikipedia.

Declarative does not mean XML

«Декларативный» часто означает «описанный в XML». (Сам XML здесь не принципиален, вместо него можно подставить YAML, ini или любой другой приходящий в голову формат.) Многие люди стали считать, что это обязательное условие, но при этом они упускают из вида феномен под названием DSL.

Декларативность — это стиль описания, а не его формат. Вы можете вызывать набор методов из функции на Java и называть это декларативным описанием. Фактически, многие использования паттерна Builder подходят под это название.

У декларативных описаний внутри кода есть много преимуществ. Их проще реализовать, проще понять, они лучше поддерживаются рефакторингом и в целом больше соответствуют использованию «наиболее простого из подходящих решений». KISS!

When to throw exceptions?

На тему «какие ошибки достойны генерации исключений» написано и сказано столько бреда, что многим людям сложно разобраться и составить своё мнение. Вставлю и я свой комментарий на этот счёт.

Зачем создана обработка исключений?

1. Чтобы каждая функция не занималась обработкой ошибок. Дело в том, что бо́льшая часть кода успешно работает, когда всё идет хорошо, но не знает, что делать, если произошла ошибка. Исключения позволяют сконцентрировать обработку ошибок в одном месте минимальными усилиями программиста. Помимо прочего, это делает код функций более коротким и понятным, т. к. в них описан только успешный сценарий.

2. Исключения невозможно игнорировать, тогда как проверку кода ошибки можно забыть или просто отложить до лучших времен.

Некоторые люди считают, что исключения несут некую смысловую нагрузку и их нужно использовать только тогда, когда программа встречается с чем-то «исключительным» и «ненормальным». Это полный бред.

Во-певрых, то, что ненормально для одного клиента вашего кода, для другого абсолютно в порядке вещей.

Во-вторых, умные люди не видят в исключениях никакой магии. В Python исключения используются для выхода из циклов. В Ruby есть два вида исключений, один из которых специально упрощен для выхода из вложенных подпрограмм. Авторы JRuby (на Java) пытались использовать исключения для эмуляции параллельного исполнения в стиле Ruby.

В стандартной библиотеки C++ исключения кидаются, например, когда не получается открыть файл. Если задуматься, это нормальная ситуация — в 99% случаях вы получаете имя файла от пользователя, окружаете вызов open обработкой исключений и в catch сообщаете пользователю, что имя файла неверно. Если пользоваться логикой «исключения только для случаев, которые не ожидает программа», open должна была бы возвращать bool, а не кидать исключения.

Самое главное, что можно сказать про использование исключений — используйте их по-умолчанию, если только нет противопоказаний. Главное здесь — удобство клиентского кода; если вам кажется, что пользователю может быть удобно обработать какую-то ситуацию отдельно, кидайте исключение.

Случаев, когда исключения использовать не стоит, я вижу три:

1. Ошибка в процедуре, исполняющейся очень большое число раз. Скажем, функция Win32 API TryEnterCriticalSection создана ровно для того, чтобы очень часто вызываться в цикле, а механизм Critical Sections в принципе сделан для ускорения работы программы. Поэтому этой функции стоит возвращает bool (точнее, BOOL), а не кидать исключения. (Разумеется, это если бы функции Win32 API вообще могли бы кидать исключения в стиле C++.)

2. Особая ситуация, которая всегда обрабатывается там же и так же, как и нормальная ситуация. TryEnterCriticalSection могла бы быть подходящим примером, но еще более подходящий вариант — вызов fork() в Unix.

У fork есть три типа возврата: (1) не удалось создать процесс, (2) всё нормально и это родитель, (3) всё нормально и это ребёнок. В случае (2) функия возвращает PID (идентификатор процесса) созданного ребёнка. Можно было бы считать это основным результатом функции, а в случаях (1) и (3) кидать исключения. Однако случай (3) концептуально равноправен со случаем (2) и его обработкой точно занимается тот же самый код, который вызывает fork. Поэтому в третьем случае не стоит кидать исключения, тогда как в первом — стоит.

С другой стороны, например, вызов open для открытия файла сюда не попадает, поскольку обработкой ошибочного ввода пользователя может заниматься основная программа, тогда как open вызывать может какой-нибудь модуль разбора XML-файлов.

3. Если вызвавшая сторона может быть написана на другом языке или не может ловить исключения по другим причинам. Например, функция обработки сообщений в Win32 или обработчик сигналов в Unix не должен кидать исключения, потому что его вызывает операционная система.

PHP5 vs. Python/Ruby

Встретил человека, которого удовлетворяет PHP5. Мне кажется, ему легко живется в этом мире.

Языки с динамической vs. со статической типизацией — это, безусловно, предмет длительного спора. У каждого из них есть свои положительные и отрицательные стороны.

Статическая типизация даёт программисту больше уверенности в коде (иногда ложной).

Динамические языки, во-первых, позволяют выражать мысли естественно (окружающий мир тоже живет по принципам duck typing, а не строгой типизации), во-вторых, уникальной сильной стороной динамических языков является метапрограммирование.

Если вы никогда не занимались метапрограммированием, то для вас вопрос выбора языка сводится только к наличию типов у переменных, то есть фактически к ничему. (Ну, о'кей, к выбору формы выражения мыслей.) Если вы пробовали метапрограммирование на C++ (единственном поддерживающем его статически типизованном языке), то уже поняли, насколько это сложно и непригодно для повседневной деятельности.

Главное преимущество языков с динамической типизацией — применение метапрограммирования и функций высших порядков как основного способа программирования. Динамическая типизация просто делает это возможным.

Что же мы видим в PHP5? Метапрограммирование отсутствует напрочь. Авторы очень старались сделать всё, как у нормальных людей, но так и не поняли самого главного. Более того, они пытаются сделать язык похожим на Java, но только без строгой типизации (что суммирует недостатки обоих подходов в одном языке).

Лично я предпочитаю Ruby, потому что в нем красивее выглядит и метапрограммирование, и применение higher-order functions (благодаря SmallTalk'овским корням). Впрочем, это уже дело вкуса. Пусть метапрограммирование в Питоне выглядит более странно, но оно не менее мощное.

P.S. Помнится, раньше были споры про строгую типизацию, а не про статическую. А вот сегодня я, не морщась, употребляю эти термины почти как синонимы. Десять лет назад меня бы за такое линчевали.

P.P.S. Да, забыл, но впрочем это естественно, зачем говорить о том, чего нет. Функции высших порядков в PHP тоже имеют рудиментарный вид (ну то есть отсутствуют).