Názory k článku
MAC OS X je taky unix (3): Dědictví NeXTStepu

nejak nechapu, k cemu je dobre, kdyz je jazyk ciste objektovy ... resp jediny takovy jazyk, ktery jsem dosud poznal, je smalltalk a nenasel jsem u nej zatim zadnou vyhodu treba oproti jave. naopak - vzhledem k tomu, ze jsou promenne netypovane funguje prapodivne code-completion, coz je pro me dost zasadni nevyhoda, dale se mi ani pramalo nelibi reseni ridicich struktur tim, ze podminka je objekt typu boolean s metodami ifTrue,ifFalse atd a cyklu pres metodu do: objektu typu collection - to je podle meho nazoru naprosto silene reseni, ktere nic neprinasi krome zmateni neznaleho programatora :) -ja uz sem si na to pomalu zvykl (bohuzel) ale porad v tom nejak nenachazim tu krasu - spis me to otravuje :D

Nejsem sice dostatetečně znalý Objective C abych mohl vést debatu v rovině specificky tohoto jazyka, ale obecně objektovost jazyka chápu jako ohromné plus. Stačí se podívat o kolik jednodušší je vývoj aplikací pro objektově založené knihovny jako Cocoa, KDE nebo .NET... A to nemluvím o přehlednosti a čistotě kódu. Nakolik je zrovna Objective C správně navrženo nejsem erudován posoudit, ale věřím že když přežilo z dob NeXTStepu a dnes je nejpoužívanějším jazykem na Mac OS X (přestože kdokoliv může zrovna tak dobře použít C++ a Carbon aby dosáhnul stejných výsledků) nejspíš bude mít své přednosti :)

ObjectiveC je opravdu velmi, velmi silný nástroj. Je to síla Smalltalku s rychlostí céčka. Co vím, tak doplňování kódu tam funguje dobře, protože ObjC má interfejsy atd. Ale pořád můžeš jakémukoliv objektu poslat jakoukoliv zprávu. Je to perfektní objektová nadstavba nad čistým céčkem (čili primitivní typy tam normálně jsou).

Doporučuji články Ondřeje Čady ve starých Chipech, případně jeho slavnou hádku s prof. Miroslavam Viriusem (Java vs ObjC vs C++)

Objective C rozhodne neni "ciste objektovy". Je to vlastne "jen" nadstavba C (v podstate se da implementovat jen preprocesorem + knihovny). Ale jsou tam objekty tak, jak by mely byt, zadne zhuverilosti jako "nevirtualni" a "virtualni" metody (fujtajxl).

A code-completion funguje velice dobre, vlastne v ProjectBuilderu jsem se s nim setkal vubec poprve.

No, to máte těžké. Pokud tu krásu nedokážete najít, asi na ni nemáte buňky. To už tak bývá, že každému svědčí něco jiného a že není programovací jazyk ten, aby se zavděčil lidem všem.

Krása Smalltalkovských metod Boolean>>ifTrue: a Boolean>>ifFalse: je v tom, jak eliminují potřeu řídicích struktur a převádějí ji na jednotný mechanismus volání metod. Pokud si člověk uvědomí, jak vlastně ifTrue: a ifFalse: pracují, dojde mu, že si může dělat vlastní řídicí struktury, které jsou neodlišitelné od těch standadních. (Máte chuť kupříkladu na ternární logiku? Tak si ji dopřejte! ;-))

Souvisí s tím i zjednodušení jazyka. Jak se píše třeba tady: "A language is at its best when it is simple enough for people to have a deep enough understanding of it to use it to its fullest potential. This means there should be few different concepts to master, even while improving on the functionality of earlier languages. One of the trickiest parts of language design is knowing what features you don't need." Zjišťuji čím dál tím víc, že s těmito názory nejsem ani zdaleka sám (další krásná zmínka ohledně "features stockpiling" je v R5RS).

Takhle by šlo pokračovat dál, třeba metatřídy jsou moc šikovná věc...ale pokud říkáte, že to nedoceníte, asi to opravdu nedoceníte... :-)

Ahoj,
byt maca nemamm, tak jsem zaregistroval(asi pred mesicem), ze posledni dostupna verze je 1.5 ! Ne 1.4

Verze čeho přesně? :)

JDK.

Možná v Tigeru... já mám nejaktuálnější Panther (naposledy aktualizovaný před týdnem) a Javu mám 1.4.x

Navíc na webu Applu jasně píšou verzi 1.4.2 :)

V Tigru. Na apple com je ke stazeni binarka 1.5ky JDK, ale defaultne je i k Tigrovi dodavana 1.4.2. 1.5 pro Panthera neni a velmi pravdepodobne nebude.

Docela by me zajimalo jak je na tom eclipsa. Slysel jsem ze na macu je nepouzitelne pomala, navic i nejrychejsi procaky jsou dvakrat pomalejsi nez pro PC, takze pro me mac jako platforma pro vyvoj pada.

Proc pouzivat Eclipse, kdyz mam nativni XCode, ktery umi pracovat i s Javou?

Eclipsu neznám, ale XCode umí Javu velice dobře. Nejrychlejší procáky nejsou ani náhodou pomalejší než PCčka... na těch skutečně nejvyšších stupních výkonu (PowerMac G5 vs. nadupané amd64 třeba) je to spíš nastejno, spíš je G5 rychlejší. Přispívá k tomu hlavně krátká pipeline, vektorová jednotka a pár dalších optimalizací. Na druhou stranu jsou powerpc procesory pomalejší při přepočtu float na integer.

Osobně používám G4 na 1.2ghz (tedy starou generaci procesorů na relativně nízké frekvenci) a rozhodně je všechno mnohem rychlejší než na Linuxovém Athlonu XP 2ghz nebo windowsovém Duronu 1.5ghz. A to je G4 už zastaralá a montuje se jenom do notebooků (kvůli nižší spotřebě proudu).

Na druhou stranu je fakt, že OpenGL na Mac OS X (a tedy i většina her) se svým výkonem nemůže měřit s OpenGL nebo DirectX na PC platformách, ale o tom budu mluvit v jednom z dalších dílů článku ;)

Mozna by bylo dobre, kdybyste sva tvrzeni podporil treba nejakymi cisly. Ja mam pocit ze iMac za 35kKc se vykonem nemuze ani zdaleka rovnat PCcku za 35kKc, a to ani kdyz do toho PCcka
zapocitam cenu nejakeho monitoru.

Zkouseli jsme na iMacu takovy klasicky fixed-point test

time sh -c 'echo 2^1000000 | bc >/dev/null'

Athlon XP 2500+ 11.7s
Itanium 1400 14.1s
Athlon XP 3000+ 8.9s
Athlon FX-51 7.5s
iMac G4 1.6GHz 3m15.8s

a vubec nemam pocit, ze by ten iMac (kupovany koncem minuleho roku za neco pod 40 tisic) byl nejak vykonnejsi nez muj Athlon FX-51 (kupovany bez monitoru koncem _predminuleho_ roku za neco pod 40 tisic). Uz jen to ze ten iMac ma 256MB pameti a FX-51 ma 1GB. Ale i tak je ten iMac _dost_ zdechly.

Kdyztak uvedte nejake testy, ktere jste provadel, a ze kterych snad nejak uvidite, ze by Mac byl rychlejsi nez srovnatelne drahe PC.

-Yenya

Nevím sice co tenhle test říká o výkonu počítače (chápu to správně tak že mac je 20x pomalejší než ty ostatní počítače?) ale už z výsledků bych tipoval že něco jako výkon interpretru shellových scriptů či něco podobného :)

Podpořit své tvrzení benchmarky bych samozřejmě mohl a na internetu si jich kdokoliv může najít kolik chce. Faktem ale je, že do těhle čísel se dá zabalit ledacos... stejně jako si MS vytvoří studii ukazující pomalost a děravost Linuxu, může si Apple udělat studii ukazující ohromnou rychlost Applu.

Dám příklad:
Dělám hodně grafiky a používám photoshop; na applu mi filtr radial blur (kráuhové rozmazání) reaguje i v nejlepší kvalitě do vteřiny, na PC (Windows XP) se to počítá cca 6 vteřin. (Tedy PC je 6x pomalejší)

Jenže ouha! teď zkusím komprimovat DivX a zatímco na PC pod Linuxem mi mencoder stíhal jeden díl futuramy za 30 minut, tady to trvá skoro hodinu!
Žeby bylo zpracování MPEG4 na Applu pomalejší? Tak proč mi potom kódování H.264 běží 2x rychleji než pod Linuxem na i686?

Tohle se NEDÁ určit a každý podobný benchmark je jenom důvodem k dalšímu flame. Takže používejte si co chcete, mně osobně se zdá práce na macu nejrychlejší a odezva systému nejkratší a to mi vyhovuje.

"Vykon interpretu shellovych skriptu"? Ten shell se tam vola jen kvuli tomu, abych mohl do /dev/null presmerovat vysledek toho bc(1) a ne zaroven vysledek time(1). Spis bych tipoval ze u Applu maji nejak divne zkompilovane bc.

Ale jak rikam - uvedte nejake srovnani vykonu vcetne pouziteho hardwaru (nejlepe i s porizovaci cenou). Navic myslim ze zrovna Photoshopove filtry nebo kodovani videa neni uplne smerodatne, protoze to muze byt nejaky rucne vyladeny kod na miru konkretnimu procesoru. Zkuste neco, co si muzu stahnout a beznym zpusobem zkompilovat.

Hmm, vase tvrzeni ze "Přispívá k tomu hlavně krátká pipeline, vektorová jednotka a pár dalších optimalizací." je taky dost divne - Athlon nebo treba Itanium maji taky kratkou pipeline, vektorovou jednotku ma dnes uz kazdy, takze zustavame u tech blize nespecifikovanych "dalsich optimalizaci". WTF?

Ano, samozrejme mate pravo na nazor, ze se Vam na Macu pracuje rychleji nez na (blize nespecifikovanem) PC, ale pokud chcete tvrdit, ze obecny Mac je rychlejsi nez obecny Opteron nebo Itanium ("Nejrychlejší procáky nejsou ani náhodou pomalejší než PCčka..."), mel byste to podporit nejakymi fakty. Jak jsem rikal, rychlost odezvy meho FX-51 (v beznem grafickem prostredi) mi prijde podstatne lepsi nez rychlost odezvy iMacu za priblizne stejnou cenu.

-Yenya

Kdyz chcete porovnavat hruby vypocetni vykon procesoru (otazkou je, proc?), IMHO nejlepsi je studovat si TOP500. Urcite je to smerodatnejsi, nez si vyrabet nejaky amatersky test doma.

> otazkou je, proc?

Protoze puvodni prispevek tvrdil, ze jsou rychlejsi. Podle me nejsou.

> nejlepsi je studovat si TOP500.

Top500 obsahuje masivne paralelni stroje. U tech je temer jedno jaky maji procesor, dulezita je konektivita mezi nimi. Navic Top500 meri v podstate nasobeni obrovskych matic, coz na svem pocitaci opravdu temer nedelam (ani tech mensich - hry nehraju).

Ja jsem mel za to ze diskuse neni o superpocitacich ale o tom, jestli Mac/MacOS je lepsi (rychlejsi?) pracovni stanice nez PC (v mem pripade s Linuxem). A to si myslim ze dost jednoznacne neni (rychlejsi urcite ne, u "lepsi" asi zalezi na jake rozhranije clovek zvykly, resp. ochotny si zvyknout).

-Yenya

Tak v tom případě to řeknu takhle:

Ať už je to HW, nebo Softwarem... Ve věcech které dělám já tj. grafika (Photoshop, Illustrator, Acrobat), nějaká média (střih videa, komprese) a kancelářské věci (MS Office (Ano používám MS Office, kamenujte mně ;) ne vážně, já je musim mít :)) je Macovský noťas nesrovnatelně rychlejší než PC noťas za stejnou cenu.

Do stolních počítačů moc nevidím, protože je nemám rád a nepoužívám, ale za dobrý notebook od Applu jsem dal 27 tisíc, za Acer jsme dali 30 tisíc a přestože má 2x víc paměti a o polovinu lepší frekvenci CPU, stejné aplikace na něm běhají tak pomalu, že na něm členové domácnosti odmítají dělat cokoliv kromě mailu a browsení po webu.

Pokud vám záleží na číslech, násobení matic, nebo testy unixových komponent... prosím. Mně daleko víc vadí mizerný výkon Javy... kromě toho je ale můj low-endový mac rychlý jako blesk. A je mi jedno jestli je to kvůli Velocity Enginu, geniálnímu návrhu XNU, nebo skvrnám na slunci. Hlavně že to funguje :)

P.S s čestnou výjímkou mencoderu... ten je na Mac OS nějak podivně pomalý... řekněte, dělám něco špatně, nebo vážně má být tak pomalý? :)

Myslim, ze zrovna mencoder ma na i686 velmi tvrde rucni asm optimalizace ... na stejnem pocitaci (AMD 64 3000+) mi x86_64 verze mencoderu bezi asi polovicni rychlosti proti i686 verzi ... neverim, ze je to velikosti pointeru - podle me proste a jednoduse chybi optimalizace.

Chapu to dobre tak, ze mencoder bezi na x86_64 vyrazne pomaleji v 64b nez ve 32b rezimu?

Ano. Prinejmensim grabovani z TV karty do lavc kodeku - to je vec u ktere mi ta pomalost dost vadi, protoze mam nastavene filtry aby to v 32b rezimu jelo akorat real-time. Nevim, jestli to plati obecne pro vsechny kodeky, vsechny filtry a po pravde to muze delat i pouze to grabovani ... jestli te to opravdu zajima, muzu to nekdy vyzkouset.

Pouziva Mac OS X stejnou verzi bc jako byla na tech PC?

Zvlastni, ted jsem to sjel na Apple Mac Mini G4 1.2G 256MB RAM a mam to za 19s. Ten Vas iMac musel mit v dobe Vaseho mereni load hodne nad 1.

Teraz:
20:42 up 2 days, 1:47, 2 users, load averages: 0.38 0.39 0.18

$ time sh -c 'echo 2^1000000 | bc >/dev/null'

real 3m10.019s
user 3m4.800s
sys 0m0.750s

$ sysctl -a | fgrep cpufr
hw.cpufrequency: 1599999996

real 0m15.377s
user 0m14.131s
sys 0m0.189s

PoverBook G4 1,6 GHz

Na procesoru VIA EPIA PD6000E (CPU C3 600MHz) trvá tento "testík" minutu a přibližně 20 vteřin. bc je z orig z fedory 3. Předpokládám, že to jablíčko o které se tu všichni hádají nebude 2x pomalejší než můj počítač :-)

Rozhodne nejde o moc rozumny test, nicmene jsem to spustil (na pozadi pri cteni tehle diskuse):

[11] aleph:~% time sh -c 'echo 2^1000000 | bc >/dev/null'
sh -c 'echo 2^1000000 | bc >/dev/null' 25,72s user 0,21s system 97% cpu 26,685 total

iBook G3 800MHz, (r.v. 2002 jako uplny lowend)

Samozrejme ten nas vysledek na iMacu 1.6GHz je divny, melo by to bezet rychleji, ale je to implicitni bc na implicitni konfiguraci MacOSu. Proc je to pomale se ptejte Applu. Ale kazdopadne je to priklad konkretni veci u ktere mam konkretni opakovane namerene udaje o rychlosti. Uvedte jiny test, chcete-li. Muzeme porovnavat dal.

Nejde mi o to presvedcit puvodniho autora o tom ze on nema pouzivat Mac, jen polemizuji s jeho tvrzenim ze high-end G5 je rychlejsi nez high-end PC, coz je dost velky nesmysl. Hmm, proc asi Apple nepublikuje zadne vysledky na www.spec.org?

-Yenya

Ok, odpovim si sam - na spec.org nic neni, ale nasel jsem treba tohle:

http://www.xbitlabs.com/articles/cpu/display/powerpc-g5_18.html

Nevypada to, ze by G5 1.8 GHz byla rychlejsi nez Opteron 148, a to ani priblizne (dokonce neni rychlejsi ani nez 3GHz P4).

-Yenya

Jeste k tomuto a k clanku celemu: Ja samozrejme ocenuji jak je MacOS konzistentni ve svem navrhu a v uzivatelskem rozhrani a vubec, Objective-C povazuju za vyborny jazyk (rozhodne lepsi nez C++). HW od Applu vypada pekne na pohled a asi se i dobre pouziva, jen je drazsi nez je obvykle a pritom mene vykonny nez je obvykle. A pak je tady navic naprosto nesympaticka firma Apple ktera vetsinou vyviji ryze proprietarni technologie (QuickTime, iTunes, ...) a je ochotna zalovat kazdeho kdo treba zkusi vyrabet HW kompatibilni s jejich OS nebo dokonce kdo zverejni tyden dopredu fotku jejich noveho produktu, nebo kdo vyrobi ke svemu oblibenemu window manageru theme ktere vypada podobne jako Aqua.

-Yenya

K tomu Applu jako nesympaticke firme bych pridal i to, ze z open-sourcu pouzivaji kde co (GCC, BSD, GNU nastroje), ale vubec nic komunite nevraci (co kdyby treba aspon uvolnili patenty na TrueType hinty fontu?). Prijdou me jako pekny vycuranci...

celý kernel a vlastně i celý Darwin jsou open source včetně všeho co do nich apple přidal.

Opravdu? Ja jsem mel za to ze jejich kernel je FreeBSD portovane na jejich platformu a nad mikrojadro Mach. A ani od tech jejich modifikaci nejsou zdrojaky (ale na druhou stranu, opravy chyb a nektere veci se snazi propagovat zpet k FreeBSD).

Byl jsem jeste upozornen, ze situace neni tak cerna - nektere veci Apple uvolnuje, i kdyz to vyvinuli kompletne oni (treba RendezVous). Ale to je spis dano snahou o to, aby se protokol uchytil a bylo mozne ho pouzit i jinde (treba v sitovych tiskarnach a podobne). Celkove ale porad vidim Apple jako spis zapornou firmu.

Hmm, co s tim bc? Mate-li srovnatelny HW, kde vam 2^1000000 nebezi tri minuty, jakou mate verzi bc? Primo od Applu nebo neco co jste si kompilovali sami?

-Yenya

zzen$ time sh -c 'echo 2^1000000 | bc > /dev/null'
real 0m26.383s
user 0m21.313s
sys 0m0.389s
zzen$ sysctl -a | fgrep cpufr
hw.cpufrequency = 999999997
zzen$ w
4:18 up 1 day, 2:16, 2 users, load averages: 0.17 0.20 0.32

G4 1GHz eMac, 2 roky starý, defaultní bc, stejně jako u ostatních předpokládám. OS X 10.4... Ty iMacy v hale jsou skutečně PODIVNě pomalé.

Můj soukromý tip je, že to je tou RAMkou, s 256MB je pomalu s podivem, že to nabootuje. Je tam docela hluk a disky v iMacích jsou docela tiché, takže nemusí být slyšet, že celou dobu testu to nehorázně swapuje...

Druhá možnost je, že to je nějaká zvláštnost na G5, zatím tu byly všechny výsledky z G4, jestli se nepletu... Zkusím získat nějaké z G5 PowerMaca...

At tak či onak je ta diskuze asi zbytečná. PPC/Mac rozhodně není paušálně rychlejší x86/PC, ale ani naopak to nejspíš moc platit nebude. HW je možná trochu pomalejší (ovšem zdaleka ne tak šíleně jak ukazují ty testy), nicméně OS to v praxi často docela dorovná/předhoní.

Tak vysledky z G4 1GHz powerbooku: 23sekund. Vysledky z PowerMac G5 dual 1.8GHz: 17 sekund. Panove, s vasimi pocitaci je neco hodne hodne divneho - a muj zhavy kandidat je ta mala RAMka a neustale swapovani (zvlast, kdyz je tam potom nalogovano vic lidi najednou).

S aplem sice nemam zadne zkusenosti. Ale tohle dokazu vysvetlit.
Dlouho jsem pouzival gcc na RS/6000 a musim rict, ze tenhle kompilator generuje
pro PPC velice spatny kod. Bohuzel si stroj s timhle procesorem muze malokdo dovolit, takze se ani nikdo nevenuje optimalizaci kodu pro PPC.
Pokud to bc bylo na Aple kompilovano pomoci gcc, tak ho zkuste zkompilovat necim jinym. Napriklad xlc od IBM muze generovat pro PPC 2x-3x rychlejsi kod.

Ja zrovna sedim u 1.8GHz G4 a ten tvuj cas z 1.6GHz se mi nejak neda, ja to mam za 12.78s, to odpovida 14.4s pri rychlosti 1.6GHz, asi mas neco spatne, kdyz mas 13x vyzssi cas!

Fik

ibook g4, 1,33 GHz, 3/4GB Ram, osx 10.4.1

real    0m17.809s
user    0m15.818s
sys     0m0.180s

Tak ted nevim, jestli to ve skutecnosti neco dokazuje...spis to vypada, na rovnoceny vykon vzhledem k pc...

Na mém AMD Athlonu 1,33Ghz, 256MB Ram, Linux 2.4.26 :

real    0m17.126s
user    0m16.550s
sys     0m0.100s

Opravdu se mi moc nezdá, že by ppc bylo stejně rychlé jak x86. Aspoň jsem měl vždycky zafixováno, že je ppc rychlejší.

ibook G4 - 1Ghz, 768mb ram

real 0m20.466s
user 0m19.733s
sys 0m0.210s

porovnani mitu o frekvencich jsem nasel zde
http://pegasos.jinak.cz/clanky/powerpc/ppc_01_historie.html

Tak jsem to take zkusil...
vim, ze to moc informativni neni, ale jen tak pro predstavu
Macbook Pro
Procesor: 2GHz Intel Core Duo
Memory 2GB DDR2

time sh -c 'echo 2^1000000 | bc >/dev/null'

real 0m10.702s
user 0m10.654s
sys 0m0.040s

pentium m 2ghz :

gentoo 2005.0 (make -O3) -- 9.1 sec
freebsd 5.4 (make -O2) -- 11.6

bc je myslim u oboch rovnake (gnu)

zeby ten rozdiel bol kvoli rozdielnym optimalizaciam ??

eclipse je nepouzitelne pomale na cemkoliv.

souhlas, ale mate neco se stejnou funkcionalitou a mnozstvim pluginu, co by bezelo rychleji (idealne uplne bez javy)?

a propos jak se divate na mnozstvi javy ve dvojkove rade openoffice?

Ty články Ondřeje Čady o objective C je možno stáhnout tady http://www.ocs.cz/text/index.html

Velmi zajímavé čtení. Objective C má objekty dotažené dále než v Javě a přitom výsledek je zkompilovaná (=rychlá) binárka. ( Pro nevěřící: opravdu lze jít v objektech dále než v Javě.)

P.S.
PowerPC a Intel processory nelze srovnávat podle frekvence. PowerPC dosahuje stejných výkonů (flops) asi tak na 2/3 frekvenci oproti x86. A ve srovnání AltiVec a MMX/SSE nevychází většinou MMX/SSE jako vítěz.

tj

Mám praktické zkušenosti s obojím a věta

"Velmi zajímavé čtení. Objective C má objekty dotažené dále než v Javě a přitom výsledek je zkompilovaná (=rychlá) binárka. ( Pro nevěřící: opravdu lze jít v objektech dále než v Javě."

je velmi, velmi nepřesná.

Porovnání rychlostí by možná stálo za pokus, overhead zasílání zpráv v Objective C není zanedbatelný a hlavně ho prakticky nelze omezovat. Větší význam než samotný fakt statické kompilace do nativního kódu má (dle mých zkušeností) to, že náročné části kódu se prostě napíší postaru, plain C.

Dále jsou zde věci jako garbage collector nebo bytecode manipulace. Porovnání by asi trochu zabralo víc času. Většina těch rozdílů je dána odlišnou koncepcí a účelem Javy.

Co se týče objektovosti, tak samozřejmě Java není žádný zázrak (a ani nikdy nebyla). Největší rozdíl je absence metod tříd, to opravdu často bolí.

A můžete to nějak doložit? Nevím, kde přesně jsem k té informaci přišel (rozhodně po ní zapátrám znovu!), ale v ObjC by cena message sendu měla být asi jedenapůlnásobkem ceny staického volání funkce. To mi nepřijde až tak nevýhodné...

Omlouvám se za špatné slovo, v tom postu má místo "nedá omezit" být "nedá optimalizovat". Co se týče overheadu, tak ten plyne už z principu funkce a napsal jsem že "není zanedbatelný", což není ani v případě overheadu 50%.

Osobně jsem nikdy neuznával postoje "fuj, to je pomalé" (od "fuj, bytecode interpreter" až po "fuj, virtuální metody" a "fuj, assembler rulez"). Vždy záleží na použití. Některý kód se klidne může interpretovat (zvlášť když se stejně čeká na periferie jako disk, síť či uživatel) a u jiného je každé procento zrychlení znát.

Abych byl trochu konkrétnější (OpenSTEP 4.2, 1999): NSArray a NSDictionary jsou docela pěkné, ale několikrát se mi stalo že jsem si musel na větší zpracování (hlavně při zobrazování) to pěkne vzít do normálního pole normálních struktur a pěkně zpracovat v C. Původní (objektová) varianta na základních pokusných datech byla v pohodě, ale jak se tam pustila radarová data z většího letiště...

Nicméně hlavní pointa toho co jsem napsal je: Výhoda "je to objektové, ale zkompiluje se do binárky, což je rychlejší" je vcelku málo významná. V mnoha situacích to není potřeba, v mnoha to zase nestačí.

"Fuj, assembler rulez" ... tedy, chtel jsem rict ze vlastne souhlasim. "Některý kód se klidne může interpretovat (zvlášť když se stejně čeká na periferie jako disk, síť či uživatel) a u jiného je každé procento zrychlení znát." Proto je pro druhy pripad nejlepsi pouzit assembler. Jazyky, ktere to neumoznuji nebo nejak komplikuji, budou vzdy horsi nez jazyky, ktere to podporuji.

A myslim, ze ve sporu Java x Objective C je tenhle argument na strane objective C ....
... prestoze na druhou stranu samotna kompilace do binarky v dnesni dobe neprinasi prilis velkou vyhodu proti JIT kompilaci hotspotu.