Притежава доста приятен интерфейс за нови постове с live preview, Media Uploader, drafts, въобще всичко, което за сега смятам, че би било нужно за бързо и лесно писане на постове:

Това, което е интересно, обаче е, че на страницата имаше учтиво написан текст, който споделяше, че услугата ми е не-платена, но за мое улеснение мога да си активирам следващия месец с едно бутонче, като потвърждавам, че в рамките на 3 дни ще платя задължението. Едно кликване по-късно отново бях разкачен от рррое-то и на следващо закачане вече имах интернет.

Учтиво и цивилизовано решение.

Основната причина да се отделят време и ресурси за изучването на толкова ограничен език е, че това е най-“first class“ начинът за изграждане на приложения, които се интегрират добре и native в операционната система. Има Ruby && Python bindings, но аз лично винаги съм имал особено мнение за биндингите – API-то е насилствено приведено към някакъв език, без да е разработено с идеологията и най.добрите практики за езика.

Всъщност, езикът е доста приятен и се усвоява лесно. Добре е да се отбележи, че положението до голяма степен е както при .NET – езикът е безполезен без runtime-a, предоставен от операционната система. Надстройка е на С, тоест всяка една конструкция валидна в С е валидна и в Objective-C. Бидейки надстройка, обаче, той добавя доста разнообразна функционалност, концентрирана най-вече околко обектно ориентираният дизайн.
ООП елементите се основават на Smaltalk, което го отличава от С++ подобията. Изпълнявайки се в runtime е доста динамичен. Почти всичко възможно се оставя за определяне в runtime. Дори обръщанията на един обект към методи на друг обект (съобщения/messages) се свързват чак при изпълнение (което позволява доста любопитни гимнастики, като програмно подменяне на извикван метод). Съществен недостатък на този подход е големият overhead – изпращането на messages между обекти би могло да бъде до 3 пъти по-бавно от извикването им в С++.
Архитектурата на съобщенията и методите, също така не позволява operator/function overloading – метод с едно име в един обект не може да се предефинира с различни аргументи и стойности за връщане.
Съществена разлика е, че всичко, освен основните типове (int, float, etc) и C структурите е обект. Не могат да се създават неща на стека. Което е причина за още малко overhead.
Поради използването на runtime е нужно всеки обект да може да комуникира по някакъв унифициран начин с него. За това всеки обект трябва да е пряк или косвен наследник на root обект, който знае как да комуникира с runtime-a. Такъв по default е NSObject (до някъде подобно на Object в Жаба).
Тук е моментът да спомена, че, както при много други езици множествено наследяване няма, но има различни начини за подобие на подобно поведение.

Синтаксисът, като цяло малко се различава от повечето езици.

Съществена разлика спрямо голяма част от ООП езиците е, че обектите не извикват методите си директно, а обменят съобщения по между си.
Когато кодът се компилира името на метода се заменя от уникален индентификатор, който си има тип – SEL. Тъй като езикът е динамичен и много неща се случват чак по време на изпълнение, така и селекторите могат да се модифицират. Нищо не пречи на базата на някакви конкретни условия и логика даден селектор да бъде подменен в реално време от друг обект, например, по начин, който би бил неизвестен по време на компилация.

Друга интересна концепция са категориите. Това, което те правят е да добавят функционалност под формата на методи към съществуващи класове без да ги наследяват и без да е нужен техния код. Добавените методи са валидни за всички инстанции на класа в рамките на конкретното приложение и са неразличими от истинските член методи. Неприятното е, че ако се добави метод с името на съществуващ, то го замества напълно и няма как да се извика оригиналният метод.

Протоколите са местният еквивалент на множествено програмиране. Джавистите веднага ще ги познаят като подобие на Interfaces. Протоколът дефинира редиа методи, част от тях може да са required за имплементиране, част може да са optional.

Най-любопитната тема е Memory Management-a. От една страна от Mac OS X 10.5, насам, има Garbage Collector с всичките му благини и тъпни, от друга, за iPhone, Mac OS 10.x (x<5) и по memory-sensitive заигравания се налага ръчно решение. В С++ всичко е елементарно. Правим си new обект, играем си с него и когато всичко приключи го delete-ваме. Тук нещата са малко по-гъвкави (и усложнени). Въвежда се концепцията за reference counting.
Когато се създаде нов обект той има reference count == 1. Ако се прати retain съобщение count-ът се увеличава с 1. Ако се прати release се намалява с 1. Когато достигне 0 обектът се унищожава. По този начин отговорността по живота на един обект може да се предава нататък по веригата на извикване.
Например, в един обект извикваме метод, който създава нов обект (count == 1) и го праща на друг обект като метод. Другият обект може да го „задържи“ (count == 2), с което казва „Сега аз го ползвам ,никой да не го трие“, докато обектът, който го е създал може да го „освободи“ (count == 1). когато другият метод или обект приключи работата си също го „освобождава“ (count == 0), когато, вече, обектът умира.

По темата може да се говори още много, в нета материали има страшно много, уви, на български не са особено много (поради което донякъде съм писал и тези неша).
Езикът, платформата и runtime-а са страшно гъвкави и като човек с няколко години полупрофесионален опит С++ и 2 години професионален с С# мога да кажа, че за момента това (заедно с чист С за най calculation intensitive частите) е платформата, над която съм се спрял да пиша.

Доста се случи през последните месеци.
На първо време от iTouch преминах на Android. Половин година съм с HTC Dream(G1) и мисля, че на този етап това е телефонът, който най-много ми харесва. Хем линукс, хем Just works(tm) (кога ли и на десктопът ще се случи това (за това по-долу)). „with Google(tm)“ на гърба, пък, вдъхва страхопочитание .

Мигрирах към Mac OS. (с дълга предистория)
Всичко започна с един любопитен софтуерен проект, който движа (и за него по-долу). По начало го разработвах на бившото си TabletPC с Линукс. Пишех го на Qt – любимият си toolkit за мултиплатформени приложения. Още в самото начало се натъкнах на някакъв ужасноо странен и непонятен проблем, който така и не успях напълно да разреша – при стартиране на няколко обекта, които хем се визуализират, хем имат закачено симулационно тяло (симулирам физика – това в друг пост), хем периодично се poll-ват от външен тред, което довежда до 99% CPU Usage от X.org още на седмия обект. Няколко дни не успях да направя каквото и да било след часове работа и всякакви опити, при положение, че от моя страна кодът беше изряден. Тогава точно от любопитство се заиграх с Hackintosh – Mac OS X на нормално РС върху таблета си, с идеята, че би било любопитно ако го подкарам читаво (Mac OS има една от най-страхотните handwriting recognition имплементации, които съм виждал), което, уви, не стана (само едно ядро може да работи, с двете увисва), не ми работеше wifi/bluetooth, батерията караше половин час и т.н. Реших, обаче, да изпробвам платформената независимост на приложението. Тръгна веднага след прекомпилация, но което е по-важно – бъгът след добавяне на няколко симулирани обекта го нямаше. Програмата се държеше страхотно с няколко десетки.
Точно по това време дойде мометът да се вземе и dedicated hardware за софтчето. Веднага подбрах една Hackintosh friendly конфигурация (Mac OS работи върху точно определен епълски хардуер и всякакви други неща се крепят на крехка паяжина от груби хакове), на която инсталирах Leopard 10.5

Там започна бавното ми и безвъзвратно епълизиране. До етап, в който това е единственият OS на всичките ми машини. От Slackware 9.1 насам Линукс е основната операционна система, която съм ползвал. Около година и нещо съм ползвал Gentoo, от още толкова Ubuntu. Слака изоставих някъде около 11.0.

Експериментирал съм с Мас ОС и преди – някъде 2007, на последния десктоп, който съм имал. Не ми работеха редица неща, най-важното – SATA-та, на която имах 500ГБ в дискове, както и звука, което направи начинанието безсмислено и не особено полезно. На няколко пъти съм ползвал различни Мас-ове и като цяло харесвам платформата.
Добре работеща система с Мас ОС, обаче е нещо съвсем различно. Още повече на оторизиран хардуер (и за това надолу).
В последствие си продадох и таблета и станах горд собственик на нов бял Macbook 5,2 (Early 2009).

Защо Mac OS?
- Unix
- Стандартен шел – Bash.
- Съвместимост с огромна част от *bsd/linux софтуера. – MacPorts е точно това – Ports за Mac OS. Всичко добре познато от OSS света. Fink е apt-get базираният аналог.
- Консистентност – Каквото и да си говорим, линукс на десктопа си остава сбирщайн. Липсва каквато и да е консистентност в менюта, подредби и поведение в огромна част от програмите. GNOME/KDE, макар и да води до конкурентност и стремеж към иновативност е довело до кошмарен library hell – Amarok под GNOME – Уууужааас. Да не говорим ,че интерфейсът в двете среди е тотално различен. GNOME-ските Human Interface Guidlines се спазват рядко и непълно. За КДЕ не съм сигурен дали съществува нещо подобно.
Под Mac OS такова нещо практически отсъства. Apple също имат Human Interface Guidelines, които, обаче, прилежно се спазват в огромно мнозинство от софтуера за системата. Приложенията са до голяма степен консистентни във външния си вид и клавишните комбинации. Services позволява страхотна интеракция между програми (добавяне на контакти през Опера в Скайп, глобален речник, etc).
- Bundled Software – стандартно идват X11 имплементация (за графичните OSS apps), XCode – страхотно IDE от ранга на Eclipse и Visual Studio, PHP5, Java1.6/1.5, Python, Ruby, apache. С оригиналните машини идва и iLife – iPhoto доста удобно photo library, iWeb (FrontPage на стероиди. На много стероиди), iMovie (MovieMaker на много, много стероиди), GarageBand (FruttyLoops 4 free), iDVD, etc.
- Стабилност – Значително по-стабилна работа от водещите юзърси линукс дистрибуции – ubuntu, fedora, etc. Няма dependancy hell, няма зависващ или рестартиращ се Х, видео драйверите винаги работят с ускорение. Minor ъпгрейдите не са съпроводени с литургия (При всички преходи от Ubuntu 7.10 до 9.04 накрая опирах до чист инстал с евакуиране на Home). Bundled software-a е just works. Не твърдя, че не се скапва, но до сега единствните две програми, които са се нуждаели от force close са Opera и Skype. OS-ът е умирал само с Kernel Panics на Хакинтоша, заради фината паяжина от хакове, която кара ОС-ът да се мисли за истински Мас.
- Опростено eye-candy. Кохерентен, стандартен интерфейс навсякъде. Няколко и ненатрапчиви анимации. Съвсем малко transparency тук таме. SVG икони. Единственото, което ми липсва е wobbly windows – един от много малкото ефекти на Компиз, които ползвах.

Защо набих 1800лв за лаптоп (добре де, взех си ДДС-то)
- Имах много пари за харчене
- Страхотна изработка. Усеща се масивен, здрав. вдигам го за едното ъгълче, нещо, за което не веднъж са ме мразели хора с асуси и престижиота. Не ги обвинявам. Горките китайски машини скърцат сякаш всеки момент ще се разсипят на части
- Вечна батерия. Твърдят, че с WiFi е 5 часа. Вероятно ако е просто включен е възможно. Без ВиФИ, обаче, наистина си ги прави при умерено ползване – например четене. WiFi-то ги сваля на 4 часа. Музика на изключен екран е около 6 часа и половина. Доста добре за 13.3″. при положение, че на 12″ таблет с ужасно много мъки и пестеж си докарвах малко над 3 часа.
- Огромен тъчпад. Който е и мултитъч.
- Най-удобната лаптопска клавиатура, на която съм писал до сега
- Отделна, а не интегриранав видео карта – има само още няколко 13″ модела лаптопи с такива. А ми трябва сериозно графично ускорение за софтчето, над което работя.
- Cool Factor – загладен бял лаптоп със светеща ябълка на гърба.

За сега толкова със завръщането. Ще я видим тая работа с блогването.

Та, ни съм умрел!