На этот раз тема ObjC мной затронута на серверной стороне. К сожалению конкретики меньше, больше философии, но, надеюсь, кто-то найдет этот очерк интересным.
И так, в чем смысл примерения Objective-C со стороны сервера, есть ли он вообще и какие преимущества он дает.
С точки зрения скорости работы (тут и далее замеры подтверждены только apache benchmark, и могут не отображать всей сути вещей) Objective-C отстает от полностю компилированного кода на C++, но обходит Python (в лице Django) и PHP. Обходит в синтетическом тесте ab, где реально замеряется только скорость отдачи некешированного материала, так что your mileage may vary.
С другой стороны, веб-ориентированные языки (PHP), и веб-фреймворки (Django, Ruby on Rails) предоставляют разработчику широкий встроенный функционал по решению типичных для веба задач. С помощю того же Django можно достаточно быстро написать код для веб-системы с учетом стройной MVC-логики.
Посмотрим на этот вопрос еще со стороны прочего окружения сервера. Если в качестве ОС выступает OSX Server (на железе или виртуализированный), то в руки разработчика попадает рантайм с множеством готовых решений, вроде бы и для десктопа, но многие из них можно использовать и для серверных приложений. Например для хранения данных и ORM-доступа к ним можно использовать Core Data, для работы с любыми другими процессами (например отдельный comet-сервер, или даже удаленный OSX или iPhoneOS клиент) можно использовать Distributed Objects.
Конечно стоимость использования серверной OSX на несколько порядков выше, чем стоимость хостинга на Linux. «Дешево и сердито» на этой платформе будет достигать Cocotron. Степень покрытия API тут меньше, чем у Cocoa, но общий подход сохранен. А в недостающих местах помогут сторонние библиотеки, ведь ObjC отлично линкуется и с С и с С++. Гугловый CTemplate справится с выводом конечного результата, доступ к данным будет через SQLite Persistent Objects, или прямую линковку к mysql/pgsql. Все прелести динамического рантайма при этом остаются.
Некоторое время назад я уже пробовал сделать базовый веб-фреймворк для решения типичных задач на Objective-C. Прошло много времени с тех пор когда я написал первую строчку кода в этом направлении, и уже можно сделать какие-то выводы.
Писать простые веб-системы на ObjC — дорого (с точки зрения потраченного разработчиком времени). Заметный выигрыш достигается только в скорости работы и потребляемой ОП (на OpenVZ например несколько django-процессов и mysql вместе могут скушать все, дергая OOM по чем зря).
Интересные результаты получаются при написании общих систем для iPhone и веба. Тогда возрастает повторная используемость кода, можно сильно экономить на задачах передачи данных и синхронизации (например веб-система и парное к ней приложение под iPhone). Конечно можно сделать веб-приложение и для iPhone, c применением новых плюшек из HTML5, но у полноценной программы преимущество и в простоте разработки-отладки и в функциональном API.
Еще более интересные результаты — при использовании ObjC на сервере и rich-приложении Cappuccino на клиенте. Преимущества почти все те же, только код надо немного причесывать под objj-вид (с чем отлично справляется cpp — c preprocessor и несколько #define). Можно хранить одну и ту же объектную модель на сервере и веб-клиенте (а так же, потенциально — на desktop-клиентах).
Когда-нибудь ChromeOS будет единственной используемой, все данные будут в туче. А пока многие десктоп-приложения удобнее и функциональнее веб-аналогов, и некоторые задачи проще переносить из веб-интрефейса на десктоп. К примеру, несколько форумов IPB проще модерировать через нативный OSX-клиент, который оперативно может просмотреть необходимые ветки, сделать автомодерацию по ключевым словам, и будет экономно потреблять ОП. Tidy, libxml и libxslt — все представлены в Cocoa, и позволяют писать адаптированные десктоп-варианты сайтов с минимумом затрат. А использование общей логики для сервера и клиента во многих случаях удобно, что может оправдать использование Objective-C и со стороны сервера.
И так, в чем смысл примерения Objective-C со стороны сервера, есть ли он вообще и какие преимущества он дает.
С точки зрения скорости работы (тут и далее замеры подтверждены только apache benchmark, и могут не отображать всей сути вещей) Objective-C отстает от полностю компилированного кода на C++, но обходит Python (в лице Django) и PHP. Обходит в синтетическом тесте ab, где реально замеряется только скорость отдачи некешированного материала, так что your mileage may vary.
С другой стороны, веб-ориентированные языки (PHP), и веб-фреймворки (Django, Ruby on Rails) предоставляют разработчику широкий встроенный функционал по решению типичных для веба задач. С помощю того же Django можно достаточно быстро написать код для веб-системы с учетом стройной MVC-логики.
Посмотрим на этот вопрос еще со стороны прочего окружения сервера. Если в качестве ОС выступает OSX Server (на железе или виртуализированный), то в руки разработчика попадает рантайм с множеством готовых решений, вроде бы и для десктопа, но многие из них можно использовать и для серверных приложений. Например для хранения данных и ORM-доступа к ним можно использовать Core Data, для работы с любыми другими процессами (например отдельный comet-сервер, или даже удаленный OSX или iPhoneOS клиент) можно использовать Distributed Objects.
Конечно стоимость использования серверной OSX на несколько порядков выше, чем стоимость хостинга на Linux. «Дешево и сердито» на этой платформе будет достигать Cocotron. Степень покрытия API тут меньше, чем у Cocoa, но общий подход сохранен. А в недостающих местах помогут сторонние библиотеки, ведь ObjC отлично линкуется и с С и с С++. Гугловый CTemplate справится с выводом конечного результата, доступ к данным будет через SQLite Persistent Objects, или прямую линковку к mysql/pgsql. Все прелести динамического рантайма при этом остаются.
Некоторое время назад я уже пробовал сделать базовый веб-фреймворк для решения типичных задач на Objective-C. Прошло много времени с тех пор когда я написал первую строчку кода в этом направлении, и уже можно сделать какие-то выводы.
Писать простые веб-системы на ObjC — дорого (с точки зрения потраченного разработчиком времени). Заметный выигрыш достигается только в скорости работы и потребляемой ОП (на OpenVZ например несколько django-процессов и mysql вместе могут скушать все, дергая OOM по чем зря).
Интересные результаты получаются при написании общих систем для iPhone и веба. Тогда возрастает повторная используемость кода, можно сильно экономить на задачах передачи данных и синхронизации (например веб-система и парное к ней приложение под iPhone). Конечно можно сделать веб-приложение и для iPhone, c применением новых плюшек из HTML5, но у полноценной программы преимущество и в простоте разработки-отладки и в функциональном API.
Еще более интересные результаты — при использовании ObjC на сервере и rich-приложении Cappuccino на клиенте. Преимущества почти все те же, только код надо немного причесывать под objj-вид (с чем отлично справляется cpp — c preprocessor и несколько #define). Можно хранить одну и ту же объектную модель на сервере и веб-клиенте (а так же, потенциально — на desktop-клиентах).
Когда-нибудь ChromeOS будет единственной используемой, все данные будут в туче. А пока многие десктоп-приложения удобнее и функциональнее веб-аналогов, и некоторые задачи проще переносить из веб-интрефейса на десктоп. К примеру, несколько форумов IPB проще модерировать через нативный OSX-клиент, который оперативно может просмотреть необходимые ветки, сделать автомодерацию по ключевым словам, и будет экономно потреблять ОП. Tidy, libxml и libxslt — все представлены в Cocoa, и позволяют писать адаптированные десктоп-варианты сайтов с минимумом затрат. А использование общей логики для сервера и клиента во многих случаях удобно, что может оправдать использование Objective-C и со стороны сервера.
