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

И если "священные войны" между сторонниками Carbon и Cocoa все еще продолжаются, значит у каждой из сторон аргументы далеко не исчерпаны, и все далеко не так просто. И те, и другие - Маковские программисты, иногда с просто космическим и неохватным кругозором. За их плечами - опыт десятилетий побед и поражений.

Автор этой статьи - убежденный сторонник Cocoa. Сторонник Carbon написал бы другое и иначе. Но...

"Магия..."

Главное достоинство объектно-ориентированного программирования: сложные программные комплексы разрабатываются с его помощью быстрее и проще. На порядок порядков, радикально и ощутимо. Пусть это всего лишь "еще одна методика".

Во времена, когда для записи чисел использовались римские цифры, самые банальные арифметические операции требовали концентрации и многолетней тренировки. Арабская (на самом деле, индийская) позиционная система записи чисел - тоже всего лишь методика. Но как все упростилось, благодаря ей!

Объектно-ориентированный подход к программированию настолько эффективен, что даже его частичное внедрение в повседневную практику приносит ощутимую пользу. Пусть иерархии классов и объекты существуют только в исходном коде программного прдукта (например, как в Си++), а в окончательном коде, реально работающем на клиента, от всех этих умностей не остается и следа - все равно.

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

В настоящих бескомпромисных средах ООП гибкость и универсальность достигаются практически "за так". В программном продукте живут и взаимодействуют настоящие объекты, аналог примитивных живых существ, умеющие понять друг друга и поступить по ситуации. Примером такой среды объектно-ориентированной среды, вот уже 30 лет (!), служит SmallTalk.

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

Что бы перемножить a и b, надо объектам a и b (допустим, оба объекта - класса Integer) сообщение, присваивающее им значения, затем объекту a сообщение "умножить", с объектом b в качестве параметра. Звучит ужасающе, правда?

Зато более сложные, но грамотно придуманные и написанные, объекты разберутся между собой чуть ли не сами, поведут себя "по умному" без сложных и громоздких надстроек - гибкость и универсальность запредельные. Возможности "Смолтолк" потрясали воображение: разработчик языка Алан Кей успешно обучал ему самых обычных школьников, живших в Пало Альто по соседству с Исследовательским центром корпорации Ксерокс (PARC), и школьники разрабатывали в нем программы, заставлявшие мэтров программирования уважительно снимать шляпы...

Один из этих школьников (Брюс Хорн) несколько лет спустя оказался в команде разработчиков первого Мака. Только представьте себе: у человека в возрасте 22 лет был семилетний опыт разработки графических пользовательских интерфейсов в самой мощной объектно-ориентированной среде того времени, и десяток успешных больших программ!

В руках опытного программиста SmallTalk сиял настолько ярко, что некоторые компании (например, Intel - и другие) даже выпускали экспериментальные процессоры, "знающие Смолтолк". А Брэдли Кокс, в 1982-83, скрестил Си и Смолтолк, продукт этого скрещивания вскоре получил название Objective-C... Мотивы у него были те же, что и у инженеров Intel - увлечение Смолтолком.

Честные и непредвзятые рассказы о Смолтолк (эмоциональные: в такую красивую технологию невозможно не влюбиться даже сейчас) звучали как фантастические магические сказки. К ним относились скептически, потому что (многие отлично знали это по своему опыту) так не бывает, что бы что-то важное и стоящее было еще и увлекательно и занимательно. Важное, считалось тогда, обязательно скучное и трудное для понимания.

А когда речь заходила о Смолтолке и его... скажем так, о его цене - все становилось на свои места.

"Цена"

На мощных компьютерах (со специально разработанными для них процессорами) программы, написанные на Смолтолк, работали медленно - разве что, в пределах приличий. Речи не могло идти о переносе всей этой "магии" на массовые персональные компьютеры с обычными "ширпотребовскими" дешевыми элементами.

Медлительность: вот плата за многократное усиление возможностей разработчика. Оно и понятно - помните пример с умножением? А если надо перемножить несколько сотен чисел?

Код, написанный на Смолтолке, на порядки медленнее кода, написанного на "нормальном" языке программирования.

Objective-C - гибрид Смолтолка и обычного Си. Objective-C умеет практически все, что умеет Смолтолк, но при этом в десятки раз быстрее. И тем не менее...

Код, написанный на Objective-C, медленнее кода на чистом Си или на Си++. Потому что вызов метода Objective-C требует в 2-3 раза больше времени, чем обращение к обычной подпрограмме Си (или обращение к методу Си++, которое в работающей программе превращается в точно такое же обращение к подпрограмме).

В Objective-C, как и в Смолтолке, методы - самые обычные куски линейного кода, обычные подпрограммы. Но поскольку объекты реально живут в непредсказуемом заранее мире (важнейшее достоинство настоящего ООП), обращение к ним включает в себя фазу поиска вызванного метода (в специальной таблице методов), и обращение к функции (обычной подпрограмме Си) с вычисленными на предыдущей фазе параметрами. Из чего следует, что даже в самом идеальном случае время, требуемое для отработки сообщения, будет хоть на чуть-чуть, но дольше требуемого для вызова обычной подпрограммы.

Именно этот параметр - время, требуемое для отработки "сообщения" - излюбленный аргумент сторонников Carbon. Параметр, по которому Objective-C уступает даже теоретически, прискорбно естественным образом... Который (на практике) можно измерить, и выразить в микросекундах.

Код на Objective-C медленнее, но вот программы, написанные на этом языке, все чаще оказываются победителями по части реальной, практически полезной скорости...

Неужели и приведения существуют, и волшебник, рисующий магические формулы на песке в одном из бульваров Бульварного кольца - реальность? И нет никакого закона сохранения энергии, если в дело вступают реалии "тонкого мира"? И вечный двигатель до сих пор не изобретен только из-за того, что французская академия наук еще в 19-м веке приняла решение больше никогда не рассматривать заявки на его изобретение?

Может быть. Но наш случай не имеет к магии и нарушению законов физики никакого отношения.

"Как обмануть закон сохранения энергии?"

Природа строго следит за неукоснительным соблюдением своих законов. Никакой полиции не снилась такая эффективность. Все случаи, казалось бы, очевидного их нарушения - обман. Обман зрения, чувств, следствие несовершенства человеческой природы. Обман в хорошем смысле этого слова. Не сказать, чтобы бескорыстный (выступления иллюзионистов приносят неплохой доход), но не подлый и не коварный.

Редкий зритель и в самом деле верит в то, что кролики, извлекаемые из шляпы, и в самом деле пару мнгновений назад были пестрыми лентами. Знает, что это искусный трюк, но исправно апплодирует и платит - и все довольны.

Усредненно и упрощенно, технология разработки программы на Objective-C выглядит так. Программа придумывается и продумывается максимально эффективным способом. То есть, не обращая внимание на второстепенные факторы, авторы конструируют идеальную, стопроцентно объектно-ориентированную "машинку".

Эта "идеальная" машинка воплощается "в металле", то есть, в виде работающего прототипа.

На втором этапе автор добивается правильности и корректности программы. Процесс разработки продолжается. Как и все в нашем мире, сторонники дисциплины и порядка пытаются планировать продвижение этого процесса - но тщетно. Дело это неблагодарное и часто безнадежное. По мере погружения разработчиков в нетривиальную задачу, ее решение претерпевает метаморфозы. Иногда существенные.

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

Когда программный продукт уже почти завершен (в разы быстрее, чем при использовании других подходов и методик), наступает время подготовки его к столкновению с реальной жизнью. Одно из требований к программе - эффективность.

Программа должна делать именно то, для чего она написана; она должна делать это правильно; она должна делать это настолько быстро, насколько нужно или возможно. Между "нужно" и "возможно" есть существенная разница. Компьютер выполняет миллиарды элементарных операций в секунду. Самый шустрый пользователь в мире (шимпанзе, которую в одном из университетов Среднего Запада США студенты приучили к компьютерным играм), успевает в течении секунды инициировать не более 20 действий. Обычный - не более 5-7.

Любая реакция компьютера, произошедшая в течении одной или двух десятых секунды с момента ее инициации, воспринимается пользователем как мнгновенная. Это сотни миллионов элементарных действий процессора. На самом деле, вычислительный комплекс состоит не только из процессора: это десятки всевозможных устройств с разной скоростью реакции, которая зависит от реальной ситуации и конфигурации - некоторые действия, увы, длятся ощутимо дольше, чем 2/10 секунды. Даже в таких случаях быструю реакцию можно... сымитировать.

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

Все по честному... Но обмана, увы, иногда бывает недостаточно.

"Оптимизация"

Итак, программа уже фактически есть. Ее структура сложилась и устоялась. Программа с честью выходит из самых запутанных ситуаций. Она делает то, для чего предназначена - и делает это правильно. Наступает время оптимизации.

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

Оптмизация - точная наука. Сначала необходимо точно и достоверно определить, какая часть исполняемого кода на самом деле (а не по субъективным ощущениям) поглощает наибольшее число драгоценных машинных циклов. С помощью утилиты, называемой "профайлер", время, потраченное программой в разных ее точках на выполнение возложенных на нее обязанностей, измеряется и записывается в электронный журнал.

По результатам замеров выявляются аномалии. Почти всегда выясняется, что у реальности свои взгляды на жизнь. Умом природу не понять - в природу можно только верить.

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

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

Поскольку точно и достоверно известно, что этот кусок должен делать, какие данные могут быть на его входе и выходе, написать эквивалентный код на чисто процедурном языке - не самая сложная задача. Объектная ориентированность при этом, чаще всего, нисколько не нарушается. Пусть это прозвучит крамольно, но на самом деле, даже самый обычный чистый Си содержитв себе все необходимое для объектно-ориентированного программирования...

Даже с учетом фаз отладки и оптимизации, с помощью настоящего объектно-ориентированного языка программы пишется быстро и аккуратно, а по фактическому быстродействию они оказываются вполне сопоставимыми с программами, целиком написанными на "более эффективных" языках программирования.

"Фреймворки"

Не менее чем 99 и 9 в бесконечном периоде процентов современных программ пишется с применением всевозможных библиотек. Еще в 50-е годы прошлого века стало очевидно, что значительная часть исходного кода программ так или иначе повторяется от программы к программе - на переизобретение велосипедов уходит драгоценное время, в этих общих местах каждый раз делаются те же самые ошибки...

Выгода от применения стандартных библиотек при написании кода очевидна, они широко применяются едва ли не самых первых лет софтверной индустрии, но в 80-е годы прошлого века на рынке появились библиотеки особого типа (их назвали "фреймворки", название произвошло от английского слова framework, означающего "каркас", "скелет", "арматура"), которые переворачивали процес написания программ буквально с ног на голову.

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

Первые фреймворки были написаны на объектно-ориентированном Паскале. На специальном варианте этого языка, разработанном Николаусом Виртом (автором нескольких популярных языков программирования, среди которых Паскаль и Модула) по заказу Apple Computer в середине 80-х. Си++ и Objective-C только-только появились на свет, а Паскаль был широко известен и очень популярен.

Среди самых первых фреймворков был и MacApp, продолжающий развиваться и в наши дни. MFC, TCL, PowerPlant - все эти фреймворки, каждая из которых по своему хороша, испытали на себе влияние MacApp. В 90-е MacApp был перенесен в C++.

А в NeXTstep фреймворк (собственно, представлявший из себя саму операционную систему) был написан на Objective-C. Особые свойства этого языка сделали возможным написание сверхсовременного (даже по нынешним меркам) фреймворка с невероятными свойствами.

И почти немедленно инженеры NeXT приступили к оптимизации получившейся библиотеки, добиваясь фантастических результатов. Даже на весьма медленной технике, программы NeXTstep работали хоть и задумчиво (это отмечалось многими), но вполне эффективно для практического использования.

Наследник NeXTstep, Cocoa (настоящий NeXTstep пережил три поколения, четвертое его поколение называлось OPENSTEP, Cocoa 2001-2004 годов можно считать шестым поколением этой технологии... а современную - не меньше чем седьмым или даже восьмым), был предназначен не для узкой благодарной ниши и поклонников - перед разработчиками Mac OS X стояла задача отвоевать Apple место в компьютерной индустрии и занять в ней лидирующее положение. Одним из важнейших пунктов плана была оптимизация Cocoa.

Инженеры Apple поступили примерно по той схеме, которая описана в предыдущем разделе. То, что внешне выглядит как библиотека, написанная на чистом Objective-C, в глубине своей, практически на всех критических (с точки зрения эффективности) местах, на самом деле написана на чистом Си. Помимо оптимизации, этот подход элегантно и самым естественным образом решил возникшую было проблему взаимной совместимости в одной программе кода, написанного для Cocoa, Carbon, BSD - и кода импортированного из всевозможных других сред программирования.

"Другие аргументы против Cocoa"

О том, что библиотеки Cocoa организованы "не так, как у людей", из начинающих не жаловался только тот, на чьем жизненном пути эти библиотеки были первыми. Более того: даже то, что кажется до боли родным и знакомым, на первый взгляд, живет по совершенно другим законам - как привычные и обыденные предметы в "Сталкере" в экранизации Тарковского. А еще Cocoa очень не любит, когда его "гладят поперек шерсти" - то есть, пытаются заставить необычную среду делать то же и так же, как какая-то другая.

Самой распространенной ошибкой новичков (много лет наблюдаю на Cocoa-форумах за их вопросами и первыми шагами) являются попытки переизобрести то, что уже есть в библиотеке. Классовые библиотеки, увы, никогда не бывают слишком простыми - прежде чем использовать их для написания кода, особенно если это промышленный код, необходимо честно и методично изучить правила, приемы и вплоть до достижения точного и глубокого понимания происходящего, пунтктуально следовать им.

Другой аргумент: Carbon считается единственной адекватной средой для написания кросс-платформенного программного обеспечения. До какой-то степени это здравое суждение, и сама Apple, видимо, разделяет его. Хотя... В большинстве случаев в коде можно выделить более-менее совместимые участки (обычно - алгоритмы, не связанные с пользовательским интерфейсом), и совершенно несовместимые (если не пользоваться MFC Macintosh Edition), это обычно часть кода, отвечающая за интерфейс с пользователем.

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

Третий аргумент (в 1998-99 годах он был самым главным) - необходимость изучения еще одного языка. Objective-C, объектно-ориентированный диалект Си. Обычно объектно-ориентированные языки... сложны. Двойственная природа большинства таких языков (объектно-ориентированный исходный код (и, иногда, объектные файлы, из которых компоновщик строит программы), линейный исполняемый код) существенно усложняет жизнь разработчикам языков - в результате, С++ достаточно сложен для изучения и понимания.

Отсюда и предубеждение против изучения других языков... А между тем, Objective-C не является серьезным препятствием. Любой, владеющий C или С++, справится с изучением Objective-C за неделю-две, не прилагая особых усилий. Доказательства? Попробуйте сами (ссылка на блок "Obj-C, краткий очерк").

Остановимся на вкусовых претензиях к Objective-C. Многие, глядя на исходные коды, написанные на этом языке, вспоминают еще один язык - LISP, который, в шутку, многие расшифровывали как "lots of idiotic silly parenthesis", или "много-много идиотских дурацких скобок". Objective-C, если бы его звали LISP, можно было бы расшифровать с меньшим числом слов-паразитов: "много-много идиотских квадратных скобок". Их и правда много. Ну и что?

В 1996 году инициативная группа инженеров NeXT (Apple унаследовала у NeXT Software юридические права на язык Objective-C) предложила "современный синтаксис" Objective-C, очень похожий на синтаксис таких популярных в то время языков программирования, как C++ и Java. В течении двух лет Objective-C существовал сразу в двух видах, а споры о том, какой из вариантов лучше, грозили перерасти в священную войну. В мае 1998 года, среди участников Всемирной Конференции разработчиков (той самой, на которой был объявлен Carbon), было проведено голосование. 80 процентов голосов (в том числе, и голос автора этой статьи) было отдано за "традиционный стиль".

Он кажется страшноватым и неуклюжим... первые два-три дня. Потом к нему привыкаешь, и он не вызывает никаких проблем и даже неудобств. Главное его достоинство: с момента появления Objective-C++, в одном и том же исходном файле могут пересечься оба объектно-ориентированных диалекта С. Если для Objective-C используется традиционный стиль, куски на С++ и Objective-C легче различать.

"Cocoa сегодня"

Сокращение MVC, некогда забывавшееся большинством студентов почти сразу после экзамена, на котором его незнание могло обернуться плохой оценкой, теперь снова в почете и чуть ли не в моде. Это такая парадигма объектно-ориентированного программирования. Что-то вроде рецепта, или необязательного правила. Согласно этой парадигме, каждый объект в программе относится к одному из трех концептуальных слоев: модель, элемент интерфейса или контроллер. Английское сокращение расшифровывается как "Model-View-Controller".

Модель довольно часто описывает какой-то элемент внешнего мира, и этот факт отражен в ее названии. Кроме внешних объектов (реальных и фантастических, например, схема продаж бакалейных товаров, двигатель авиационного эмулятора), это могут быть и внутрикомпьютерные абстракции (например, строки и массивы, деревья и т.п.). Элементы интерфейса - это то, с чем пользователь сталкивается в процессе работы с программой - окна, кнопки, полосы прокрутки и тому подобное.

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

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

Библиотеки, входящие в Cocoa, пунктуально соблюдают парадигму MVC. В хорошо написанных программах эти несложные правила тоже соблюдаются. Благодаря MVC, как объекты-элементы интерфейса, так и объекты-модели, могут без всякой переделки и изменений использоваться в других частях программы, в других программах, вообще могут быть сведены в библиотеки и либо рапсространяться бесплатно, либо даже продаваться братьям-программистам.

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

Элементы интерфейса были наиболее автоматизированной и самоуправляемой частью MVC с начала 90-х годов прошлого века. Могое, о чем вынужден заботиться программист в большинстве других классовых библиотек, умные объекты NeXTstep (а потом и Cocoa) делали сами. Что удивительно, именно так, как надо - и именно в тот момент, когда от них это требовалось. Тем не менее, написание контроллеров ложилось тяжелым бременем на плечи программистов.

Новая эра в развитии Cocoa началась в 2003 году, одновременно с выходом в свет Mac OS 10.3. В Cocoa появилось несколько классов, представляющих из себя унифицированные контроллеры. Отныне, прямо в конструкторе интерфейсов (Interface Builder), можно "привязать" элемент интерфейса к какой-нибудь переменной в объекте-модели, задать параметры такой связи, и, при соблюдении моделью некоторых несложных правил, во многих случаях запросто обходиться без контроллеров, написанных "вручную".

Как по волшебству, "привязанные" к элементу интерфейса модели изменяют свое состояние в зависимости от его состояния, и наоборот: привязанные элементы интерфейса немедленно узнают об изменениях в связанных с ними моделях, если эти изменения были вызваны "кем-то еще". В зависимости от условий и особенностей конкретной задачи, программист теперь может выбирать между написанием контроллера "полностью ручной работы", использованием комбинации из классов Controller Layer и "самодельного" контроллера, и использованием исключительно стандартных классов.

В 10.4 инженеры Apple покусились на оставшиеся нетронутыми (скорее, ставшие из-за автоматизации контроллерного слоя даже более трудоемкими) классы-модели. Core Data отвечает за сохранение данных на диске, считывание этих данных (максимально эффективным образом), доступ к данным, поиск в данных (с помощью классов-предикатов), и за многое еще.

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

Теперь автоматизация коснулась всех слоев Cocoa, что делает эти библиотеки уникальными. Других таких нет.

"Cocoa завтра"

В конце 90-х прошлого века, видимо, для привлечения Java-разработчиков с других платформ, на Apple был разработан еще один вариант Cocoa, написанный на Java. Насколько это помогло, сказать трудно. Все программисты, с которыми я знаком, лично или заочно, даже в ее лучшие времена считали Cocoa/Java... чем-то второсортным. Даже те, кто "в прошлой жизни" активно писал на Java, в конце концов принялись за изучение Objective-C, и ни разу об этом не пожалели.

Начиная с нынешней версии Mac OS X, вышедшей в 2005 году, Cocoa/Java "помечена черной меткой". Cocoa/Java не рекомендуется использовать для написания промышленного кода. Java-вариант библиотеки поддерживается Apple, но его развитие официально прекращено.

В наши дни все больший интерес вызывают такие удивительные языки, как Python и Ruby. Это интерпретируемые объектно-ориентированные (по "взрослому") языки, очень динамичные и выразительные. В Mac OS 10.5 ожидается появление "официальных" интерфейсов к Cocoa на этих языках.

В Mac OS 10.5 новшеств в Cocoa больше, чем когда-либо прежде. Взять, хотя бы, тот факт, что Cocoa, начиная со следующей версии ОС, становится полностью 64-битным комплексом библиотек...

Кроме тех идей, которые уже нашли свое воплощение в Cocoa ближайшего будущего, у разработчиков масса еще более сумасшедших и интересных замыслов. Подразделения, занимающиеся развитием Cocoa, требуют у HR-отдела все больше и больше специалистов... Наступает, видимо, момент выбора. Точнее, выбор уже давно сделан, и он, судя по всему, не в пользу Carbon.

Ничего личного. Сотни библиотек на С++ и чистом С, как и прежде, останутся в системе. Как и прежде, если возникнет необходимость задать какое-то действие более тонко и специфично, чем это можно сделать с помощью Cocoa, программист волен спуститься в Core Foundation (псевдо-объектно-ориентированную библиотеку на самом чистом Си, какой только есть в природе), которая считается частью Carbon. Значительная часть современного Cocoa, в глубине, скрытой от невооруженного взгляда, написана средствами Core Foundation.

А если потребуется залезть еще глубже, под рукой разработчика все богатства местной юникс-подобной операционной системы Darwin. А с ее помощью - и всех остальных юниксов и "юниксов", какие только есть в мире.