Возможности и преимущества использования Objective-C?
=======================================================

 Дорогие друзья,  
  
  

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

Если быть конкретнее, то меня интересуют следующие моменты:  
  
1. Почему Apple выбрала именно этот язык в качестве основного для своей платформы?
2. Какие элементы дизайна языка отражают дизайн самой платформы Cocoa?
3. Какие элементы дизайна Objective-C нравятся лично вам, оказываются очень полезными/незаменимыми в работе, и которых не хватает в каких-нибудь других языках, с которыми вы тоже работаете?

  
  
  

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

Заранее благодарю за ответы. 

 > 1. Почему Apple выбрала именно этот язык в качестве основного для своей платформы?  

  

Потому что Jobs в Apple второй раз пришёл из компании Next, в которой язык был основой платформы. А там он был основой платформы по причине того, что был лучше остальных (в середине-конце восьмидесятых). Джобс, пришедший в Apple, застал нереальный бардак в операционке (Mac OS 8, 9), которая на годы отставала от своих конкурентов (Windows, Linux), не имела нормальной многозадачности, etc. Поэтому он втащил туда половину софтверной составляющей компании Next, чтобы начинать писать операционку не с чистого листа. К моменту прихода Джобса в Apple (1997) C++ не был сильно лучше, чем Objective C (проблемы с ABI, проблемы с метапрограммированием, etc), поэтому даже тогда смысла менять шило на мыло не было.  

  

> 2. Какие элементы дизайна языка отражают дизайн самой платформы Cocoa?  

  

Простоту (single-inheritance) и документированность.  

  

> 3. Какие элементы дизайна Objective-C нравятся лично вам, оказываются очень полезными/незаменимыми в работе, и которых не хватает в каких-нибудь других языках, с которыми вы тоже работаете?  

  

Objective C является самым хорошим языком из семейства С для работе в команде. Явные имена аргументов увеличивают читаемость кода и снижают остроту необходимости и/или свежести документации. Single inheritance, no operator overloading, отсутствие метапрограммирования нивелируют разницу в стилях между членами команды (когда один не понимает другого). Упрощается ревью кода. 

 Про п.1 — насколько я понимаю, когда они выбирали, ничего более толкового не было — в С не было ООП и были проблемы с модульностью, в С++ в то время еще творился нестандартизованный ад, остальное сильно медленнее работало на железе в то время. Objective C был передним краем когда-то. 

 2   

Cocoa – Objective-C фреймвёрк, использующий все особенности языка.   

  

3   

динамическая типизация, блоки, категории, интроспекция и возможность программного изменения объектов и их методов в рантайме, etc. 

 По возможностям практически не уступает C#, но синтаксис первое время может вызывать отторжение.  

  

1. Скорость (нет промежуточного кода) — поэтому у них лучшая графика. tonsky тоже, наверное, прав  

2 и 3 — ответил **arielf**, я с ним согласен. 

 1. Вообще говоря, это для Эпл была трагедия. Не соглашусь с другими комментаторами насчёт того, что выбрать было нечего. Было, и не просто было, а Эпл плотно сидели на технологии [SOM, которая была круче Objective-C](http://forum.pascal.net.ru/index.php?showtopic=32045). Так, нехрупкое ABI появилось в Objective-C лет на 15 позже, чем это было в SOM, и до сих пор в некотором отношении Objective-C уступает по хрупкости. Apple SOM был [улучшенным ответвлением от IBM SOM](http://octagram.name/pub/somobjects/SOMobjects%20for%20Mac%20OS.pdf) и, например, вводил счётчик ссылок для всех объектов, чего не было в IBM SOM. При этом это был не замкнутый в себе язык программирования, а модель, доступная потенциально из любого языка программирования, и я насчитал [11 языков программирования](https://ru.wikipedia.org/wiki/System_Object_Model), которые так или иначе поддерживались в SOM. Флагманским, надо понимать, считался [диалект DirectToSOM C++](http://mirror.informatimago.com/next/developer.apple.com/tools/mpw-tools/compilers/docs/direct_to_som.pdf), который в МакОСе реализовал транслятор Metrowerks CodeWarrior. Это гибрид C++, стоящий в одном ряду с C++/CLI, Objective-C++ и C++/CX, где в один язык трамбуют две иерархии. Собственно Эпл был главным двигателем OpenDoc, кроссплатформенного аналога ActiveX, где вместо COM — SOM. У Эпл был браузер CyberDog, поддерживающий OpenDoc аналогично поддержке ActiveX в Internet Explorer. Кроме OpenDoc, Эпл ещё делали Compound Document Framework, которая в перспективе должна была быть портирована на другие платформы, поддерживаемые SOM. То есть, SOM в экосистеме Эпл до Джобса занимал не последнее место, и многие разработки были завязаны на него, а какие-то из них даже опережали IBM, отвечавшего за порт SOM под другие платформы (Windows, OS/2, AIX). Кроме того, Эпл вкладывались в язык программирования Dylan, диалект Схемы, компилируемый в машинные коды, и имеющий паскалеподобный синтаксис вместо скобочных с-выражений (но с-выражения тоже допустимы). В общем, от недостатка вариантов Эпл отнюдь не страдал. Решающим, на мой взгляд, оказался провал Мак ОС 8 (Копланд) и предательство IBM. Если SOM занимала такое важное место в классической Мак ОС, то и в Копланд это должно было перейти, и, действительно, на тех образах, которые мне удалось найти, есть свидетельства того, что [SOM туда тоже перекочевал](http://octagram.name/pub/somobjects/copland/). Если бы Копланд взлетел, у Эпл получилась бы современная ОС, 32-битная, с вытесняющей многозадачностью и проверенной объектной моделью. Почему Копланд не взлетел, отдельная тема. По слухам, начальство наломало дров, проект слишком часто переделывался, и когда нужно было выпускать следующую версию операционной системы, был слишком сырым (и пришлось выпустить Мак ОС 8.5 , продолжающую классическую линию). Вторая причина — предательство IBM. В 1996-1997х годах от Джавы многим снесло крышу, и IBM тоже. Они поставили все фишки на Джаву, а SOM оставили с закрытым кодом, а чтобы умники от опенсурса не рыпались, как в GNUStep, придавили гроб SOM патентами, которые кончились только в середине 2000х. Вот в таких условиях в Эпл приходит Джобс и привозит в своём обозе Objective-C и OPENSTEP OS. Там была какая-никакая библиотека виджетов, 32-битное ядро с вытесняющей многозадачностью. Из классической Мак ОС удалось перетащить AppleScript и Карбон, но SOM так и остался в истории.  

2. [Низкоуровневая совместимость](http://forum.pascal.net.ru/index.php?showtopic=32045), особенно, после нехрупкого ABI Objective-C 2.0, но при этом трансляция в машинные коды. Благодаря этому приложения могут одновременно и пользоваться благами ООП, и не тащить мегабайты библиотек постоянно, и классы могут расширяться, не ломая совместимость с приложениями. COM, не поддерживая наследование, не смог занять такое же место, как Objective-C и SOM. Больше всех пытались в Mozilla, у них же XPCOM во все поля, но даже и у них вылезли «незамороженные интерфейсы», ломающие совместимость. Из-за этого, если установить, например, iTunes и iCloud на Windows, у них общие библиотеки, как и на Mac OS X, а Thunderbird и FireFox (а также приложения на базе XULRunner) каждый тащит свои мегабайты библиотек. Указанное свойство распространяется не только на Cocoa, но и на библиотеки третьих сторон. В других-то языках надо постоянно перекомпилировать под окружение, а оно возьми, да и не скомпилируйся с первого раза, а в Objective-C и SOM побросал всё вместе, и оно срослось. [То, за что тут хвалят Java](https://zeroturnaround.com/rebellabs/10-reasons-why-java-now-rocks-more-than-ever-part-1-the-java-compiler/), получается доступным в языке, компилируемом в машинные коды. По моей практике библиотеки длинных чисел для I2P, машинные коды иной раз сильно заруливают.  

3. Кроме указанного в 2, лично мне нравится, что Эпл сказала «Нет» трассирующей сборке мусора и «Да» автоматическому счётчику ссылок. На фоне толпы сумасшедших, так и норовящих испоганить трассирующим сборщиком мусора всё, до чего только дойдут их грязные руки, а новые начинания безнадёжно испортить с самого начала, Эпл, будучи корпорацией, внезапно повела себя исключительно адекватно. Сказать трассирующей сборке мусора «Нет!», да ещё с такого высокого уровня! Это ли не чудо. При этом эта возможность адекватнее всего встроена в язык. В Делфи через COM-интерфейсы ARC был десять лет назад, Делфи получился самым удобным языком для COM, но эта возможность, как-то так получилось, так и осталась задвинутой на второй план. В языке Ада умные указатели можно было делать, и делали, но эта возможность так и не стала встроенной в язык, чтоб прямо на access можно было прагму или аспект навесить без заворачивания в Controlled. Objective-C стал первым, и ARC из него пошло в Делфи, правда, до Делфи для Виндоуз и Мак ОС Десять до сих всё никак не может докатиться. Вот не может, и всё тут, ну что ты будешь делать. Так тяжело додуматься, а [если додуматься](https://cs.uwaterloo.ca/research/tr/1997/17/smartp.pdf), так тяжело внедрить, ну так тяжело. Это к слову, почему ARC от Apple был как гром среди ясного неба. Вот нифига себе, у них есть мозги, и они умеют ими пользоваться, и руки у них тоже есть, и растут из правильного места. В то время, как другие мостили дорогу в ад или щёлкали клювом, эти взяли и сделали всё правильно.