Objective-C, Ruby i Cocoa – Czyli niczego ciekawego się stąd nie dowiesz.
Moja całkowicie amatorska przygoda z programowaniem zaczęła się się od Visual Basic'a (na początku 6 lecz z szybką migracją na .NET). Dalej przyszła kolej na Ruby i Pythona jednocześnie. Praca z nimi ograniczała się do prostych skryptów i używania frameworków, Merb czy też odpowiednio dla Pythona Django. Nigdy wcześniej nie dotknąłem języka pochodnego od C (PHP się liczy? :D ) ani o podobnych założeniach, nigdy nie bawiłem się w programowanie na 'niższym' poziomie, aż do dni ostatnich, kiedy wypadało napisać coś na nowo zdobytą platformę.
Jeśli chodzi o pisanie aplikacji okienkowych pod Mac OS jako pierwszy pod rozwagę pada zestaw Objective-C + Cocoa. Opcji jest jeszcze kilka zarówno po stronie języka jak i toolkita GUI, ale na początek wziąłem się za te wyżej wymienione.
Kolega przerabiając C++ na Pol.Śl. opowiadał mi jakie to wskaźniki nie są fajne i inne dziwne rzeczy, które jak już zrozumiałem to były dla mnie oczywiste ze względu na Ruby czy jaką to fajną klasę do obsługi właściwości nie napisał, że aż mnie zdziwienie złapało, że nie ma takich rzeczy z miejsca w języku, gdy ja używam attr_accessor i jest. Nigdy nie rozumiałem idei nagłówków i… byłem szczęśliwy, że mogę po prostu pisać kod i widzieć efekty z każdą dodaną linijką.
Po paru dniach, kilku 'Hello World' i innych TestApp'ach dogłębnie załapałem wskaźniki, nagłówki, MVC i poczytałem trochę o zarządzaniu pamięcią. W zasadzie wszystko co z pomocą manuali pozwala na napisanie czegoś co robi coś konkretnego i można to nazwać aplikacją.
Koleżanka z pewnych przyczyn ostatnimi czasy na GG siedzi cały czas ukryta, jednak gdy siada przed komputerem sprawdza co nowego na ePulsie. To podsunęło mi pomysł na pierwszą użyteczną porcję kodu. Po całym dniu bojów napisałem prosty tool, który wyświetla mi ikonkę na górnej belce reprezentującą jej status na rzeczonym serwisie. W pełni filozoficznie, obiektowo 'itetakie'. Tutaj zakończył się mój rozwój w kwestii Obj-C na najbliższy czas.
Przyzwyczajony do tego, że wszystko mam na miejscu, dostęp do całej gamy iteratorów, do tego, że mogę przypisać do zmiennej co chcę bez żadnego deklarowania i do wielu innych rzeczy, dzięki którym kod w Ruby po prostu się pisze i ten kod po prostu działa nie mogłem się przełamać, by brnąć w to dalej.
W takiej sytuacji nie szło się nie zainteresować RubyCocoa. Szybko więc przepisałem mojego szpiega. Urzekła mnie pełna współpraca z XCode oraz Interface Builderem. Możliwość pisania w ulubionym języku przy zachowaniu wszystkich właściwości 'natywnej' aplikacji dla Mac OS.
W grupie, w której pracujemy nad projektami używamy Merba, więc możliwość załadowania do aplikacji wybranej biblioteki ORM czy nawet uruchomienia całego środowiska frameworku to potęga jeśli chodzi o integrację strony z interfejsem okienkowym.
To wszystko kieruje me zainteresowanie właśnie na RubyCocoa. Teraz, gdy emocje związane z poznawaniem Mac OS'a opadły, gdy mam wolne do grudnia jeśli chodzi o pracę i trochę więcej czasu ze względu na inne mniej ważne rzeczy prawdopodobnie odbije się to na tym blogu. Pierwsza notka na temat RubyCocoa już w przygotowaniu. :)
Komentarze
Na mnie Cocoa też zrobiła pozytywne wrażenie. Gdzieś widziałem prezentację z rubyconf, cudne :), chyba na confreaks.com
Jeśli można się wtrącić, to PHP to pochodzi z Perla. Interpreter został co prawda napisany później na „czysto” w C, tak samo zresztą, jak interpretery Pythona i z zapewne Rubiego (nie jestem pewien tego ostatniego, ale podejrzewam).
W ogóle co to za pomysł porównywać języki skryptowe z C/C++ itp. przecież to zupełnie do innych rzeczy są-były stworzone, a po za tym, bez C/C++ nie powstałby Ruby czy Python, C# itp…
Hmmm, ale składnia PHP chyba była wzorowana na C? Fakt – nie sprawdzałem tego.
Języków nigdzie nie porównałem. Jak już coś to wykazałem właśnie tę różnicę i podjąłem wyboru czego prawdopodobnie będę używał na polu aplikacji okienkowych.
Ruby MRI jest napisane w C/C++ (albo tylko jednym z nich). Ale sam język nie wzoruje się na C/C++.
Wiele języków ma składnie wzorowaną na C.
@Sebastian Nowak, a czego to się tyczy? :)
Kiedyś na google techtalks widziałem prezentacje tego fscript.org , co wydaje się bardziej naturalne na maku.
Hmmm. Ten F-Script zdaje się robić dokładnie to co zrobiłem przed chwilą z Ruby. Po prostu kolejny język skryptowy… z wrapperem do Obj-C.
Parę minut temu skończyłem kawałek kodu, który wyświetla 5 ostatnich filmików z subskrybowanych na YT kanałów: http://pastie.org/261316 . Jutro tutaj opiszę całość, bo wbrew pozorom nie jest to takie oczywiste( nie było dla mnie).
Widzę coraz więcej Maków pojawia się na Joggerze – może ktoś skorzysta. :)
Chodziło mi o to, że fscript, jest oparte na objc i smalltalku, więc tylko dlatego wydawało się jakieś naturalniejsze.
Wspaniale, że pokażesz jakiś przykład. Obrazki i kod to najlepsze uzupełnienie tekstu ;)
Ja osobiście jakiś czas temu zainteresowałem się PyObjC, czyli mostem Python-Cocoa. Po kilku dniach bojów stwierdziłem jednak, że przed takimi zabawami należy poznać Cocoa w wersji natywnej. W chwili obecnej uczę się zarówno Objective-C jak i Cocoa. Postanowiłem w tym celu przepisać jeden z własnych projektów pochodzących z czasów PyObjC na aplikację natywną i powiem jedno – wg mnie nie ma lepszego połączenia niż Objective-C i Cocoa.
Faktem jest, że języki skryptowe znacznie przyspieszają pracę nad kodem (chociażby ze względu na rzeczony brak konieczności deklarowania zmiennych czy automatyczne zarządzanie pamięcią), ale jakoś bardziej odpowiada mi praca w środowisku natywnym dla mojej platformy. Zbudowana aplikacja na Mac OS X po prostu działa, bez konieczności martwienia się o wersje interpretera czy też obecność dodatkowych modułów. Niestety py2app (packager z PyObjC) niezbyt dobrze radzi sobie z zewnętrznymi modułami itp, przez co pojawiają się problemy przy przenoszeniu aplikacji między systemami… Jako, że docelowo planuję się zajmować programowaniem na OS X komercyjnie to tym bardziej muszę wszystko robić z myślą o kompatybilności.
Pozdrawiam i życzę powodzenia w używaniu RubyCocoa.
Dodaj komentarz