И даже если поставщик средств разработки внимательно прислушивается к проблемам клиентов, как Metrowerks, и пытается помочь, это не то же самое. Круг посвящённых в интимные подробности совершенно секретных проектов, какие бы меры не принимались для сохранения тайны, неминуемо расширился бы, и это ещё не самая большая беда.

В любом случае, Стив твёрдо решил превратить Project Builder в официальную и самую важную среду разработки для Mac’ов и честно предупредил об этом Metrowerks. Никто не станет мешать продавать CodeWarrior Carbon-разработчикам, но ни о каких соглашениях не может быть речи. Apple нужна собственная адекватная среда разработки, и она у неё будет.

Были только два параметра, по которым Project Builder превосходил CodeWarrior: это цена и разработка Cocoa-приложений. Project Builder был бесплатным, CodeWarrior стоил несколько сотен долларов. И, несмотря на талант и усилия инженеров Metrowerks, их продукт так и не смог даже сравниться с Project Builder в Cocoa, а переходная эпоха, когда почти все программное обеспечение для Mac OS X писалось в Carbon, подходила к своему концу.

Перемены

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

Старые баги, про которые было досконально известно как их обходить, и как вообще не сталкиваться с ними. Вместо них появились новые, незнакомые. Их было намного меньше, но о них я узнал на форуме. Я с ними сталкивался, но принял за особенности поведения.

Не знаю, заступался ли кто-нибудь за Metrowerks в судебном порядке, или все возможные проблемы урегулировали ещё на стадии разработки Xcode, но практически все козырные свойства CodeWarrior были бесстыдно позаимствованы.

Xcode 1.0

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

Хотя Xcode был, пока дело не доходило до каких-то запредельных манипуляций с кодом, абсолютно предсказуем и понятен, несмотря на множество нарушений правил «гуманного» интерфейса. Но это нисколько не мешало. Может, не все правила… нужны?

Своих собственных новшеств в первой версии Xcode было предостаточно. Например, такая утилита как Fix&Continue. Запустив код на исполнение, в некоторых случаях в него можно было внести исправления без остановки исполнения и повторной компиляции.

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

Куда важнее и интереснее подсистема для распределённого построения программ, с помощью которой можно было распределить эту задачу между несколькими Mac’ами, для ускорения процесса. Естественно, подобные технологии не бывают слишком просты, и для относительно небольших проектов не имеют смысла.

А вот операционные системы и сам Xcode строили с её помощью, и сборкой систем занималась целая ферма из сотен Mac’ов. Утилита для этого называлась distcc.

В комплекте с Xcode поставлялись средства для разработки Cocoa-приложений с помощью Java, и полный комплект WebObjects, библиотеки которой тоже теперь были на Java. По моему, переход на Java окончательно добил WebObjects, и это не только моё личное мнение.

А из проблем могу вспомнить только две: проблемы с отладчиком (иногда) и плохую работу системы автоматического дописывания известных среде разработки ключевых слов. Вот это было серьёзно: идентификаторы и в Cocoa, и в Carbon, очень длинные. Имена функций, констант и тому подобное.

Это неслучайно: Apple рекомендовала не гнаться за краткостью, не сокращать слова в идентификаторах и полностью описывать смысл и суть обозначаемого предмета. И сама делала именно это.

Например (и это ещё далеко не самые длинные «ключевые слова»):

NSGetUncaughtException;
NSOutlineViewDataSource.

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

Тем более, как утверждала документация Apple, в Xcode встроена первоклассная утилита, дописывающая эти длинные слова автоматически.

В Xcode 1.0 эта утилита была практически бесполезна. В Xcode 1.5 её почти решили. В наши дни её нет.