> Négy sor az egész, míg a C++ verzió 18 soros. Csakhogy ez nem jelent semmit. A kérdés, hogy milyen kód fordul belőle...
Igen, ez így van. De itt most az elv a fontos. A 4 soros Haskell kódból lefordulhat az optimális kód, míg a C++-osból nem annyira (csak akkor, ha az algoritmust úgy implementáltad. Quicksortra van egy rakat optimalizálási trükk, amit kézzel kell megcsinálni C++-ban, míg Haskellben - elméletben - a fordító odateheti ezeket automatán. De amúgy az igaz, hogy ezek egy jó részét nem teszi oda, szóval C++ simán megveri a Haskell kb. bármiben. Jelenleg.).
> Talán mert a CPU elemi utasításokból építkezik, ezért egy szintén elemi utasításokból építkező nyelvhez viszonylag egyszerűen lehet fordítót írni, míg ehhez meg nem?
Igen, ez így van. Nyilván sokkal bonyolultabb egy jó Haskell fordító (valszeg ilyen még nem is létezik amúgy...), mint egy C++/java.
> Mit kezd a Haskell egy olyan parse-oló algoritmussal, aminek a belsejében egy raklap feltétel és specifikus elágazás van? Sokkal nagyobb kínkeserv lesz megírni és lassabb is lesz.
Ez egyáltalán nem ilyen biztos. Haskellben megírod az illeszkedési szabályokat, és kész vagy (ha olyan a nyelv szerkezete, természetesen). Pont egy olyan példát választottál szerintem, amit jól meg lehet csinálni Haskellel. De nem vagyok szakértője a nyelvnek, szóval lehet tévedek. De az biztos, hogy van egy csomó olyan probléma, amit Haskellben körülményes megcsinálni. De talán majd erre jár valaki, aki jobban ért hozzá, és helyreteszi ezt :)
Optimalizálásról: ezt pont, hogy fordítva van. Ha a CPU egyszerű, akkor a fordítók pont, hogy tudnak rá jó kódot csinálni. Lehet, hogy nem lesz 100% optimális, de közel lesz hozzá. Azért, mert a keresési tér pici. A mostani CPU-kra sokkal bonyolultabb optimális kódot csinálni, mert annyi szabály van. És igen, egy tapasztalt asm programozó ezeket ismeri. Azért nem annyira nagy kaland ez, ha valakinek ez a munkája. Tapasztalatból beszélek, tudnék egy rakat példát mondani, ahol a fordító rendkívül rossz kódot csinál. És mennyit kell vele szívni, mire hajlandó lesz olyan kódot írni, amire már azt mondom, hogy okés, közel van az optimálishoz (hogy aztán egy újabb fordító/fordító verzió újra rosszabb kódot csináljon...). De egyébként ez nyilvánvaló, hacsak rénézel egy C++ fordító benchmarkra: elég nagy különbségeket tudnak felmutatni ugyanarra a kódra a különböző fordítók. Ebből látszik, hogy messze vagyunk még attól, hogy a fordítók az optimálishoz nagyon közeli kódot csináljanak az esetek nagy részében.