안드로이드가 오픈이라서 좋긴 하지만, 또 어떤 면에서는 안좋다고 생각 합니다.
자유도가 높으면, 그 만큼 여러 변종(?)들이 생길 가능성이 많습니다.
리눅스를 예로 들어보면 그렇지요.레드햇 리눅스, 무슨 무슨 리눅스... 참 많죠. 잉. ^^;
각 핸폰 제조사들이 자기들만의 특색을 집어넣다 보면, 위피(WIPI)처럼 각 사의 안드로이폰에 맞게 여러개의 SW를 준비해야된다는 문제가 발생할 수 있다고 생각합니다.
지금 안드로이드에 여러 버전이 있고, 버전끼리 서로 호환이 안된다고 들었습니다.
지금은 이렇다 저렇다 말하는 것보다 좀 더 시간을 두고 기다려봐야 겠지만...
그래서 저는 안드로이드용 SW 대신 아이폰 용 SW 개발을 선택했습니다.
안드로이드는 좀 더 기다려 보려구요. ^^
아이폰이 처음 나왔을 때 왜 개발자들이 몰렸을까요. 새로운 시장이 열렸기 때문입니다. 지금은 돈이 된다해서 모두 몰려 경쟁이 심합니다. 이젠 왠만한 개인 개발자가 발붙일 곳이 있을지. 안드로이는 이제 막 장이 생겼습니다 그런 의미에서는 개인 개발자들에겐 시기적으로 기회일 수 있습니다. 이미 큰 시장에서 기존 기라성같은 업체들과 경쟁하느냐 아니면 아직 작지만 성장가능성을 보고 뛰어드느냐는 개발자의 선택이겠지요.
애초에 단일기종을 위한 플랫폼(?)과 여러기기를 위한 플랫폼의 차이이니.. VM을 사용하는게 더 안드로이드에 맞을 지도 모르죠. 그리고 오픈소스를 위한 오픈소스에 의한 것도 있고요.
그리고 안드로이드도 native code로 개발이 가능합니다. UI는 어쩔 수 없이 java를 사용해야 하지만 말이죠..
아직 안드로이드는 시장이 활성화되지 못한점도 있으니 지금으로 비교는 시기상조라고 생각이 듭니다.
안드로이드도 다음 버전엔 좀더 신경쓴다고도 했고요.. 하지만 너무 잦은 업데이트가 짜증이 나긴합니다.
게임 아니라면 큰 차이 없을겁니다. 속도 문제는... 개발 환경은 자바가 대부분의 개발자에게 익숙하고요. 그리고 dalvik 은 흔히 말하는 vm 과는 다릅니다. 속도 그렇게 느리지 않습니다. 보안 이슈 문제도 있지만 프로그램 하나 죽었을 때 시스템 전체가 죽는걸 막기 위해서 사용하죠. 샌드박스랑 비슷하다고 보셔도 됩니다.
그리고 자바니까 당연히 vm 에서 돌아가는거죠 -_-) (자바가 무조건 자바 가상머신에서 도니까요) dalvik은 모바일용으로 가볍게 만들어진 거라고 보시면 됩니다.
OS X용 Objective-C도 Native가 아닙니다. Java의 VM이 Objective-Pascal에서 나온 것을 모르시나 봅니다. Java의 경우 ARM5 이후로는 가속기가 달려 있구요.
재미있는 점은 Dalvik은 JIT가 없고, MIDP는 JIT가 있습니다. 또한 ARM의 자질라 가속기능까지 쓸 수 있어서 원래 속도보다 빠르고, 강력하게 구동이 가능합니다.
또한 OS X의 Objective-C보다 MIDP 3.0이 더 기능이 많습니다. ㅎ
어디가서 Java라서 기능이 부족하고, 느리다라고 하면 상대방의 비웃음 밖에...
(ANSI 기반으로 스탠다드 API로만 비교하자면, Java만큼 API가 많은 언어는 아직까지 지구에 없습니다...) 웹브라우저내 자원이 제한되는 애플릿에서 돌아가는 Java로 아직 인식하시는 분들이 많군요..
안드로이드 마켓에는 일단 게임류 개발이 저조할 겁니다. 아이폰이나 팜프리에서 가볍게 100메가씩 넘겨주는 3D 게임들을 개발하자니 내장메모리 제한이 첫번째 걸림돌이고, 안드로이드 기기별로 3D 사양이 천차만별이라 특정기종 전용게임을 만들어야 하는데 그러면 안드로이드의 시장이 크다는 의미 자체가 무색해져 버립니다.
모바일 앱 돈되는 분야중 하나가 게임인데, 이런 식이면 간단한 퍼즐게임 말고는 개발하기가 어렵게 될 겁니다. 메모리 제한도 다음 버전의 안드로이드가 시장에 나오는 올해 말 정도에나 해결될테니... 이런 식이면 당분간 안드로이드 플랫폼은 구글전용앱이 기본탑재되고 약간의 자유도가 있는 고성능 피쳐폰 플랫폼으로 전락하게 될지도 모르겠습니다.
애플이 objectiveC를 들고 나온 이유가 플랫폼의 위치 강화를 위해서라고 생각합니다. 지금 몰리는건 돈이 되니까 당연한건데, 나중에 빠져나오는게 쉽지 않을 수 있다는점도 고려해야 할것 같습니다. 멀티 플랫폼 개발이 대세가 되니, 이를 방어하기위해 개발 플랫폼을 최대한 차별화하는 마케팅방식이죠. 개인적으로는 안드로이드가 이기기를 바라는 편입니다. 리눅스쪽에도 파이가 좀 떨어지기를 바라면서요.
복잡하다고 말씀드린건 게임을 말씀드린겁니다 사실^^ 자바에서는 게임엔진이 올라가기 힘들지요, 물론 WAP같은곳에서는 자바가 좋습니다만, 개인사용자 어플리케이션 분야에서는 사용하기 어렵습니다. 오히려 C/C++이 좋지요. 아이폰에선 기존에 C/C++로 짜여진 라이브러리나 코드들을 Obj C코드와 같이 그대로 재사용이 가능합니다. 예를들어 카메라 어플들은 기존의 수많은 jpeg와 png라이브러리등에서 파생되어 나오는 형태들입니다.
코르바님// 네 오브젝트 파스칼과 혼동을 한 거 같네요.
하지만, 몇 분들이 얘기하시는 리버싱에 대해서는 고정된 관념을 가지신 거 같아서 몇 가지 첨언합니다. Objective-C는 Smalltalk-style messaging syntax 형식입니다. 또한 Interpreted language로 Java와 유사하게 Dynamic typing을 지원하구요. Dynamic typing은 JIT 당시 Type이 결정되는 형식을 취합니다. Java의 경우는 반대로 Interpreted+Compiler language이지만, Dynamic typing을 지원하지 않지요. 즉, 오해를 불러일으키는 형태를 정정하자면, Objective-C는 견고한 Native Code로 컴파일되는 형태가 아닙니다. gc와 Dynamic typing은 견고한 Compiler로 compile된 Native Code에서 도입하기 쉽지 않은 형태임은 아실 겁니다. 반대로 Java의 경우에도 Dalvik의 경우 표준 Java의 ByteCode의 어셈블 결과물과 다르고, GCJ 처럼 기계어로 변환하는 Compiler가 존재하므로 단지 자바는 인터프리터 언어다 혹은 컴파일 언어다라고만 한정할 수 없는 것과 같습니다.
끝으로.. Java(Dalvik VM의 결과물을 포함하여) 역시 어셈블 코드가 나옵니다. 자바의 최종 결과물이 그저 ByteCode라고만 생각하시니 자바는 디컴파일링이 쉬운 견고하지 못한 ByteCode만 최종 결과물이라고 생각하시는 경우가 있는 듯 하네요. Source가 없이 ByteCode만 BCEL과 같은 구조에서는 디컴파일시 어셈블로 디버깅 메시지를 뽑을 수도 있습니다. :) 위 형태는 이클립스와 넷빈즈에서 가능합니다. 또한, High Performance Compiled로 Java를 컴파일 할 때는 Process Time에서 어셈블로만 결과가 나옵니다. (당연하겠지요) 결론적으로 Objective-C로 개발을 해 보고, 최종 결과물이 뽑혀 나왔던 형태로 유추하였을 때 분명 이 녀석은 견고한 타입의 Compiler가 아닐 것이라고 생각합니다.
ANDRE518님// 그렇군요, 자바가 그런식으로도 적용이 가능하군요^^ Obj-C는 제가 보았을때도 견고한타입의 컴파일러가 아닌 것 같습니다. 사실 스몰톡이나 LISP같은 느낌을 많이 가지고 있지요. 다이렉트한 1:1 매칭인 C/C++과는 다르게 런타임시에 여러 타입에 대해 신경써줘야 할게 많은 언어입니다. 개인적으로는 C++을 선호합니다^^ Obj-C는 메모리 직접잡고 가지고 놀기가 귀찮아서요^^ 그래도 퍼포먼스면에서 Obj-C > Java라는 생각은 지울수가 없네요^^;;
ADRE518님 // Objective-C 2.0에 gc가 추가 되었지만 비교적 최근의 일입니다.
Objective-C가 제공하는 개념은 Dynamic typing이 아니라 Dynamic binding으로 봐야 할 것 같습니다.
동적메세징은 Native로도 충분히 구현 가능한 개념이고 그 외에는 strong type language로 봐야 합니다.
Smalltalk의 Native 컨셉이라고 보시면 될 것 같습니다.
SmallTalk의 Native컨셉이라는게 아마 가장 좋은 의견인거 같습니다.
맥 클래식 버젼에서 초창기 개발언어 및 API가 오브젝트 파스칼이었던건 사실이지만.
네이티브 버젼이었죠..
VM이라는건 아마도 스몰토크 상용화된 머신중에선 선구자격이지 싶구요.
objC는 괄호밖의 C와 괄호안의 스몰토크라고 생각하면 가장 정확한 표현이 아닐까 싶군요;
그냥 스몰토크 따다가 C랑 섞어서 VM이 아닌 네이티브하게 돌리려고 만든 언어이지 않을까...
ANDRE518님 // Obj-C는 네이티브 코드를 생성하는 게 맞습니다. 때문에 맥용 유니버설 바이너리의 구조를 예로 보면 x86과 PPC용 바이너리를 각각 만들어 줘야 되는 식입니다. 언급하신 Obj-C가 인터프리티드 랭기지라는 부분도 잘못된 내용으로 보입니다. 근본적으로 Java와는 방향이 다르다고 볼 수 있고, C와 Java를 비교한다면 C에 훨씬 가깝다고 볼 수 있죠.
개인적으론... 자바로 작성된 제품들이 느린 것은 시간이 지나면서 하드웨어 성능이 뒷받침해 주면 자연스럽게 해소될 거라는 얘기를 자바가 알려진 이후로 계속 들어왔지만, 십수 년이 지난 지금에도 자바로 만들어진 조금만 덩치가 크다 싶은 제품들은 빠르다는 느낌을 받은 적이 없는 것이 자바에 대한 부정적인 이미지를 계속 가지고 가게 만드는군요.
사실 요즘 vm계열 언어나 스크립트가 워낙 성장을 해서 Native code를 생성하는 언어의 위상이 크게 준 것은 사실입니다.
나름 Native code를 생성하기를 좋아하는 사람들이 이에 대한 반발로 편한 언어를 만들려 노력하는 움직임은 보입니다.
D언어의 탄생이나 Objective-C 2.1에서 추가된 Block개념만 봐도 아 정말 Native 계열도 많이 쓸만해 졌구나 싶습니다.
굳이 죽었다 깨나도 Native구현이 힘든 요소를 꼽으라면 lexical closure 정도일 것 같습니다.
안드로이드는 apk 파일만 구하면 땡이다...라는 게 아이폰과는 꽤 다른 느낌입니다.
아무것도 모르는 초짜라도 링크 하나만 주면 뚝딱 하고 사지도 않은 유료어플이 막 설치되어 버리니...
마켓에 올려서 돈받고 파는 게 매력적일 리가 없죠 아직은...
구글이 해결해야 할 아주 시급한 것들 중 하나라고 봐요.
j_bz님 // 바이너리에 class 정보가 들어 있다는 것으로는 Dynamic Typing의 기준이 되지 못합니다.
C++에서도 RTTI를 키면 그렇게 되고 java와 c#에도 강력한 reflection기능이 있습니다.
하지만 위의 언어들은 Dynamic Typing을 지원하지 않는 언어입니다.
쉬운 판단기준으로 변수 선언 시 type을 지정하는 언어는 Dynamic Typing을 지원한다고 보기 힘듭니다.
objective-c에서 가비지 콜렉터가 도입된건 정말로 최근의 일이고 심지어 아이폰에서는 쓸수도 없습니다. 다이나믹한 메시지를 처리해주는건 좋인데 언어자체가 자바에 비해서 많이 스테이틱하기에 오히려 깐깐한건 C에 가깝습니다.
재밌는건 문법을 보면 심하게 자바와 비슷한 점을 많이 찾을수 있는데 사실 자바가 objective-c의 영향의 많이 받은 언어지요..(자바보다 역사가 깁니다)
그리고 코코아 프레임웍을 쓰다보면 속도가 많이 유구되는 부분은 하단레이어 부분은 (Quartz2D,db, file, network)등은 objective-c도 아니고 그냥 c라이브러리가 혼재되서 많은 개발자들이 어플의 속도를 빠르기 위해서 귀찮지만 하위 레이어에 작업을 직접 해주기도 합니다..(objective-c코드가 확실히 c코드에 비해서 느리고 메모리 많이 먹는건 사실입니다...)
그리고 objective-c가 맥플랫폼에 된건 도입된건 잡스가 next step시절 가지고 있었던 next의 라이브러리가 베이스 언어가 objective-c였기에 거의 필연적으로(?) osx로 맥 os에 따라 들어가되 된것입니니다. 알고보면 만만지 않은 역사를 가지고 있지요;;
오픈된게 이긴다는 것은 정의는 이긴다라는 약간 상황 안가봐면서 하는 얘기하고 비슷하달까..
쓸 폰인 없는데 어플이 무슨 소용있겠습니까 ^^
j_bz님// 자바라서 복잡한 앱을 만들기 어렵다니요. 모르는 분들은 진짜라고 믿습니다.
애플도 구글의 앱들을 가져다 쓰는 상황에서 전망은 좀 이르죠
우리나라만해도 이제 통신사별로 한기종씩 나온건데.
윈7모바일 나올때까지 노키아 블랙베리 팜 빼고는 단말기회사들이 전부 안드로이드라는게 무서운거죠 ㅎㅎ.
자유도가 높으면, 그 만큼 여러 변종(?)들이 생길 가능성이 많습니다.
리눅스를 예로 들어보면 그렇지요.레드햇 리눅스, 무슨 무슨 리눅스... 참 많죠. 잉. ^^;
각 핸폰 제조사들이 자기들만의 특색을 집어넣다 보면, 위피(WIPI)처럼 각 사의 안드로이폰에 맞게 여러개의 SW를 준비해야된다는 문제가 발생할 수 있다고 생각합니다.
지금 안드로이드에 여러 버전이 있고, 버전끼리 서로 호환이 안된다고 들었습니다.
지금은 이렇다 저렇다 말하는 것보다 좀 더 시간을 두고 기다려봐야 겠지만...
그래서 저는 안드로이드용 SW 대신 아이폰 용 SW 개발을 선택했습니다.
안드로이드는 좀 더 기다려 보려구요. ^^
구글에서도 호환성을 위해 정책을 달리 한다는거 같던데, 그 소식이 어디에 있었는지 기억이 잘;
성능상의 문제면...이건 벤치마크라도 찍어봐야할듯합니다...
(임베디드 시장에서는 c++도 느리다고 c를 쓰는곳이었으니까요..)
그리고 안드로이드도 native code로 개발이 가능합니다. UI는 어쩔 수 없이 java를 사용해야 하지만 말이죠..
아직 안드로이드는 시장이 활성화되지 못한점도 있으니 지금으로 비교는 시기상조라고 생각이 듭니다.
안드로이드도 다음 버전엔 좀더 신경쓴다고도 했고요.. 하지만 너무 잦은 업데이트가 짜증이 나긴합니다.
안드로이드가 돈이 되면 개발하는 것 자체야 그리 큰 선택은 아닙니다.
안드로이드는 dalvik vm 에서 돌게 되는데 ... VM에서 돌리는 건 아무래도 하드웨어 호환성 때문 아닐까요?
윈도모바일과 이번 윈폰 7에 전폭지지를 보내는건 윈도 개발자들이고요...
근데 애플은 개발자 풀이 제일 적었는데도...돈이 되니까 개발자들이 알아서
없던 맥까지 사서 몰리네요;;
개발자의 기술적 취향을 제대로 만족시켜 주지는 못할지 몰라도.
개발에 들어간 노력에 대한 금전적 보상은 확실히 받을수 있게 시장을 잘 꾸며놨지요.
적당히 틀어막아 가면서.
결국 "돈"이 되어야 몰리는거죠; 특히나 직업개발자라면야..
직업은 취미랑은 다르거든요
그리고 자바니까 당연히 vm 에서 돌아가는거죠 -_-) (자바가 무조건 자바 가상머신에서 도니까요) dalvik은 모바일용으로 가볍게 만들어진 거라고 보시면 됩니다.
결국 마켓 자체는 안드로이드가 가장 커질 겁니다. 그때가면 개발자도 몰릴테고요.
자바와 자바스크립트를 잘 구분못하시는 분들이 저런 말씀을 많이 하시죠.
그리고 복잡한 로직을 구현하는데에는 C나 C++보다는 Java가 더 저렴한 비용으로 가능하죠.
재미있는 점은 Dalvik은 JIT가 없고, MIDP는 JIT가 있습니다. 또한 ARM의 자질라 가속기능까지 쓸 수 있어서 원래 속도보다 빠르고, 강력하게 구동이 가능합니다.
또한 OS X의 Objective-C보다 MIDP 3.0이 더 기능이 많습니다. ㅎ
어디가서 Java라서 기능이 부족하고, 느리다라고 하면 상대방의 비웃음 밖에...
(ANSI 기반으로 스탠다드 API로만 비교하자면, Java만큼 API가 많은 언어는 아직까지 지구에 없습니다...) 웹브라우저내 자원이 제한되는 애플릿에서 돌아가는 Java로 아직 인식하시는 분들이 많군요..
윗글 삭제하고 참고링크만 답니다...
http://www.bloter.net/archives/28544
http://blog.flurry.com/bid/31825/iPad-Developer-Support-Continues-to-S
메세지란 개념으로 인해 어느 정도의 속도저하는 있습니다만 Native로 알고 있습니다.
XCode에서 디버거를 찍어보면 어셈블리 코드가 예쁘게 나오거든요.
C/C++라이브러리도 로딩이 가능하구요.... (아이폰도 아마 가능할겁니다)
뭐 그럼 더 할말은 없죠..
COCOA 지원되는 Pascal의 컨셉으로 나온 Objective Pascal은 나온지 얼마 안 된 개념입니다.
모바일 앱 돈되는 분야중 하나가 게임인데, 이런 식이면 간단한 퍼즐게임 말고는 개발하기가 어렵게 될 겁니다. 메모리 제한도 다음 버전의 안드로이드가 시장에 나오는 올해 말 정도에나 해결될테니... 이런 식이면 당분간 안드로이드 플랫폼은 구글전용앱이 기본탑재되고 약간의 자유도가 있는 고성능 피쳐폰 플랫폼으로 전락하게 될지도 모르겠습니다.
java의 경우 jni로 래퍼를 만들어 줘야 하지요.
개발을 하고 나서도 다양한 환경에서 QA를 해야 하는 비용이 크지요.
하지만, 몇 분들이 얘기하시는 리버싱에 대해서는 고정된 관념을 가지신 거 같아서 몇 가지 첨언합니다. Objective-C는 Smalltalk-style messaging syntax 형식입니다. 또한 Interpreted language로 Java와 유사하게 Dynamic typing을 지원하구요. Dynamic typing은 JIT 당시 Type이 결정되는 형식을 취합니다. Java의 경우는 반대로 Interpreted+Compiler language이지만, Dynamic typing을 지원하지 않지요. 즉, 오해를 불러일으키는 형태를 정정하자면, Objective-C는 견고한 Native Code로 컴파일되는 형태가 아닙니다. gc와 Dynamic typing은 견고한 Compiler로 compile된 Native Code에서 도입하기 쉽지 않은 형태임은 아실 겁니다. 반대로 Java의 경우에도 Dalvik의 경우 표준 Java의 ByteCode의 어셈블 결과물과 다르고, GCJ 처럼 기계어로 변환하는 Compiler가 존재하므로 단지 자바는 인터프리터 언어다 혹은 컴파일 언어다라고만 한정할 수 없는 것과 같습니다.
끝으로.. Java(Dalvik VM의 결과물을 포함하여) 역시 어셈블 코드가 나옵니다. 자바의 최종 결과물이 그저 ByteCode라고만 생각하시니 자바는 디컴파일링이 쉬운 견고하지 못한 ByteCode만 최종 결과물이라고 생각하시는 경우가 있는 듯 하네요. Source가 없이 ByteCode만 BCEL과 같은 구조에서는 디컴파일시 어셈블로 디버깅 메시지를 뽑을 수도 있습니다. :) 위 형태는 이클립스와 넷빈즈에서 가능합니다. 또한, High Performance Compiled로 Java를 컴파일 할 때는 Process Time에서 어셈블로만 결과가 나옵니다. (당연하겠지요) 결론적으로 Objective-C로 개발을 해 보고, 최종 결과물이 뽑혀 나왔던 형태로 유추하였을 때 분명 이 녀석은 견고한 타입의 Compiler가 아닐 것이라고 생각합니다.
iHWAN// 처음에 댓글이 자바개발자님들을 Offend하게 해드렸다면 사과드립니다.
Objective-C가 제공하는 개념은 Dynamic typing이 아니라 Dynamic binding으로 봐야 할 것 같습니다.
동적메세징은 Native로도 충분히 구현 가능한 개념이고 그 외에는 strong type language로 봐야 합니다.
Smalltalk의 Native 컨셉이라고 보시면 될 것 같습니다.
맥 클래식 버젼에서 초창기 개발언어 및 API가 오브젝트 파스칼이었던건 사실이지만.
네이티브 버젼이었죠..
VM이라는건 아마도 스몰토크 상용화된 머신중에선 선구자격이지 싶구요.
objC는 괄호밖의 C와 괄호안의 스몰토크라고 생각하면 가장 정확한 표현이 아닐까 싶군요;
그냥 스몰토크 따다가 C랑 섞어서 VM이 아닌 네이티브하게 돌리려고 만든 언어이지 않을까...
건전한 생태계를 만든게 크다고 생각합니다.
윈폰 7은 얘가 주 개발환경이 될거라 하니...어떤식으로 구현될지 궁금하네요.
XNA쪽은 관심없어서 크게 훑어보진 못했는데..본업이 아니다 보니..-_-;;;
C도 짜증나서 인라인 어셈블리 섞어 넣는다는 하드코어 게임개발이 아니고서야
요즘 하드웨어 퍼포먼스에서 버츄얼머신은 용인할 정도의 수준이 아닐까 싶습니다.
그게 아무리 모바일 디바이스라고 해도 말이지요.
1GHz넘어가기 시작하고 있으니..
세월이 참 ^^;
나름 Native code를 생성하기를 좋아하는 사람들이 이에 대한 반발로 편한 언어를 만들려 노력하는 움직임은 보입니다.
D언어의 탄생이나 Objective-C 2.1에서 추가된 Block개념만 봐도 아 정말 Native 계열도 많이 쓸만해 졌구나 싶습니다.
굳이 죽었다 깨나도 Native구현이 힘든 요소를 꼽으라면 lexical closure 정도일 것 같습니다.
아무것도 모르는 초짜라도 링크 하나만 주면 뚝딱 하고 사지도 않은 유료어플이 막 설치되어 버리니...
마켓에 올려서 돈받고 파는 게 매력적일 리가 없죠 아직은...
구글이 해결해야 할 아주 시급한 것들 중 하나라고 봐요.
C++에서도 RTTI를 키면 그렇게 되고 java와 c#에도 강력한 reflection기능이 있습니다.
하지만 위의 언어들은 Dynamic Typing을 지원하지 않는 언어입니다.
쉬운 판단기준으로 변수 선언 시 type을 지정하는 언어는 Dynamic Typing을 지원한다고 보기 힘듭니다.
개발자인 저로써도 '도대체 뭐라는거야'라는 생각만 드는군요
토론하는건 좋은데..
미국에서 미국사람들 잔뜩 모인데서 히브리어로 떠들면 그건 말하는게아니라
소음이 된다는걸 좀 알아주셨으면 좋겠네요.
같은 개발자로써 이건 뭐;;; 이러니 개발자라 그러면 안여돼 오타쿠 떠올리고
왜 개발자들은 체크셔츠만 입고 다니냐는 글이 올라오는지 조금은 알겠네요.;;;
저 위에 어줍잖은 지식으로 끄적거린 리플보단 훨씬 나은데요
재밌는건 문법을 보면 심하게 자바와 비슷한 점을 많이 찾을수 있는데 사실 자바가 objective-c의 영향의 많이 받은 언어지요..(자바보다 역사가 깁니다)
그리고 코코아 프레임웍을 쓰다보면 속도가 많이 유구되는 부분은 하단레이어 부분은 (Quartz2D,db, file, network)등은 objective-c도 아니고 그냥 c라이브러리가 혼재되서 많은 개발자들이 어플의 속도를 빠르기 위해서 귀찮지만 하위 레이어에 작업을 직접 해주기도 합니다..(objective-c코드가 확실히 c코드에 비해서 느리고 메모리 많이 먹는건 사실입니다...)
그리고 objective-c가 맥플랫폼에 된건 도입된건 잡스가 next step시절 가지고 있었던 next의 라이브러리가 베이스 언어가 objective-c였기에 거의 필연적으로(?) osx로 맥 os에 따라 들어가되 된것입니니다. 알고보면 만만지 않은 역사를 가지고 있지요;;
자바라서 쉬운게 아니구요? 흠 ...
쓸수록 쫀득한 재미가 있는게... 자바로 폰게임 잘 때는 이런 느낌 못받았거든요.
애플 얘네는 개발언어도 간지 나는 놈들이구나 싶네요.
그렇죠..;
그래서 C언어가 좋아요...
최대한 타이트하게 리소스를 쥐어 짜는겁니다.
개발 능력이 되는 회사 입장에서는 이래도 되고 저래도 되는 JAVA는 별로입니다.