Dotaz: Jak se objektivně rozhodnout pro jazyk: C#, Python, Ruby...?

[Radeq]

Dobrý den, chtěl bych Vás poprosit, zda byste mi poradili, jak se objektivně rozhodnout pro nějaký high-level programovací jazyk.... Programuji v Pythonu, ale momentálně mě ještě zajímají Ruby, C#, Smalltalk (, Ada). Potřebuji jazyk, který by byl brutálně objektový, s nativní podporou Unicode a multiplatformity. Chci psát spíše průměrné aplikace typu Instant Messenger, multimediální přehrávač a spol. Občas také webové stránky. Čili žádné velké početní úkony a práce v GUI. Zároveň by tyto aplikace měly být open-source. Podle čeho se rozhodnout? Všude si člověk může přečíst nekonečné flame, který jazyk je lepší, ale nikde se nic nerozhodne. Nechci flame. Chci nezaujaté a jasné rozdíly mezi těmito jazyky.

Odpovědi

[David Watzke]

To už raději Javu, než C# - vykradenou Javu od Microsoftu.

[Ubuntak]

Vykradena java od MS je jmenuje J# a vznikla tak, ze autori Javy prestali brat drogy a napsali pro MS neco mene uletenyho :)

[Mandarinka]

A objektivně?

[David Watzke]

C++

[diverman]

pyqt nebo pygtk nevyhovuje?

[Ubuntak]

Brutal objektarnu ti da jenom Ruby a C#. Smalltalk a Ada je tak do muzea. Taky kdyz chces torchu hardcore tak je tu stary dobry C++ nebo ObjectiveC. Ale s ohledem na budoucnost bude nejlepsi C#. Java se na mensi aplikace moc nehodi a rekneme si to na rovinu, naklepes 2x vice kodu s rovnakym vysledkem jako v C# :)

[Petr Holík]

C++ patri uz spis mezi assemblery nez mezi vyssi jazyky(bez urazky). Je to dobry na psani ovladacu, jadra linuxu nebo realtime prumyslovejch veci ale hlavne se v tom bezvadne pisou chyby.

O tom by se dalo polemizovat protoze C# ani zdaleka nedosahuje prenostitelnosti javy

Ano pokud pouzivate jako IDE notepad nebo vim ci neco podobneho skutecne potrebujete vic kodu. Jelikoz Java misto OB.n.send pouzije OutputBuffer.next.send coz ji sice vic kodu, ale je citeljensi prehlednejsi a stejne ho za vas napise IDE :)

[trekker.dk]

C++ je dobrý na psaní jádra Linuxu? Vývojáři si to nemyslí...

[Bluebear]

Nemyslí, ale hlavní důvod je IMHO ten, že přepisovat kernel do C++ by byla strašná práce a nepřineslo by to tolik výhod, aby to stálo za to. Kdyby to rozhodnutí padlo na začátku vývoje, snad by to bylo jinak.

[Luboš Doležel (Doli)]

C++ patri uz spis mezi assemblery nez mezi vyssi jazyky(bez urazky). Je to dobry na psani ovladacu, jadra linuxu nebo realtime prumyslovejch veci ale hlavne se v tom bezvadne pisou chyby.

To je s odpuštěním pěkná kravina. Závisí to na tom, jestli děláte kód, který vypadá jako kód C s prvky C++, nebo skutečný C++ kód, který ke zmiňovaným vyšším jazyků nemá moc daleko.

A chyby se dají napsat všude, tady pomohou jen zkušenosti. Když uděláte botu v C#, tak to třeba nebude padat, ale stejně to nebude fungovat.

[ivan]

Chyby se daji udelat vsude, ale v C/C++ muzete udelat chyby, ktere jsou prakticky neodhalitelne. To se samozrejme tyka toho Ccka s prvky C++. Pro vyvoj v C++ na linuxu se musite jeste naucit scriptovat v Makefile, automake, autoconf, sed, awk, m4 a v shell-u. Nez se dostenete k nejakym objektovym navrhum tak uplyne hodne dlouha doba.

C++ se na vyvoj linuxovyho kernelu nepouziva protoze pred programatorem skryva alokaci pameti. To muze byt v kernelu nebezpecne.

[Luboš Doležel (Doli)]

Chyby se daji udelat vsude, ale v C/C++ muzete udelat chyby, ktere jsou prakticky neodhalitelne.

Tak ano, není to pro každého.

Pro vyvoj v C++ na linuxu se musite jeste naucit scriptovat v Makefile, automake, autoconf, sed, awk, m4 a v shell-u.

Blbost a lež.

[Kroko]

a jaký je tedy rozdíl mezi C++ a C# jsem si myslel, že v C++ se dělá hlavně pod tuxem a C# je obdoba C++ vymyšlená od M$ .,...

[kozzi]

Nee C++ neni hlavne pod tuxem, je to i pod woknama tusim ze i samy okna jsou napsany v c++, jinak c++ je kompilovany kdezto c# bezi ve vm myslim.

[R]

Presne tak - Windows su napisane v C a C++. Vo Viste robili niektore veci v C# a bolo to tak brutalne pomale a narocne, ze to museli vsetko prepisat do C++ (to musela byt fakt sila, ked vidim, ake "rychle" je to teraz).

[Bluebear]

C# je spíše obdobou Javy, je výrazně novější než C++.

[Jan Kundrát (jkt)]

Pro vyvoj v C++ na linuxu se musite jeste naucit scriptovat v Makefile, automake, autoconf, sed, awk, m4 a v shell-u. Nez se dostenete k nejakym objektovym navrhum tak uplyne hodne dlouha doba.

Tohle je lez. Existuji krasne generatory makefilu/buildystemy, se kterymi se nauci pracovat i cvicena opice, jako treba scons nebo cmake.

C++ se na vyvoj linuxovyho kernelu nepouziva protoze pred programatorem skryva alokaci pameti.

To neni pravda.

[Jary]

Není pravda co z těch dvou tvrzení? To, že skrývá alokaci - což nechápu co se tím myslí. Řekl bych, že C++ žádnou alokaci neskrývá. Je to to samé jako v C.

Nebo není pravda celá implikace: To, že se C++ nepoužívá, protože skrývá alokaci? Slyšel jsem, že ho (Linus ?) odmítl, protože C++ je tak složité, že ho spousta lidí neumí dobře.

Každopádně je velmi pravděpodobné, že ta věta je konina, ať už celá, nebo jen její část.

[Jan Kundrát (jkt)]

Ani jedna z tech dvou casti neni pravdiva.

[Petr Holík]

Ano je to trosku nadsazka. Ale z hlediska toho co vas ten programovaci jazyk necha udelat se skutecne C/C++ blizi assemblerum. myslim si to protoze:

1) v C(++) muzete zapisovat do nealokovane pameti aniz by to to vzdy vyvolalo chybu

2) v C(++) muzete si muzete volne prepisovat v pameti cokoliv cimkoliv

2) v C(++) muzete predavat funkci jiny pocet datovych typu nez odpovida prototypu funkce

3) v C(++) muzete pristupovat i za hranice pole mimo indexy

4) v C(++) si za jistych okolnost muzete prepsat kod funkce daty

5) v C(++) existuje nespocet "spinavych triku"

6) mimo jine v C++ muzete volat a modifikovat privatni funkce a metody ( ne normalne ale trikem, takze pokud napr do nejakeho vetsiho projektu pridavate cizi kod muze se klidne stat ze cizi kod kompromituje caou vasi aplikaci i kdyz striktne pouzivate private/public)

7) a vubec tu jeste neuvadim o tom jak je to v C++ s psanim a ladenim vicevlaknochy programu. Vubec nejlepsi je kdyz vam program beha v poradku a pak zjistite, ze kdyz ho nasadite do testovaciho prostredi a zatizite ho, zjistite ze zacina svevolne padat diky chybam soubehu nebo synchornizace vlaken :) to se OPRVADU SPATNE ladi :)

Opravte/doplnte me pokud se mylim

[Messa]

ad 7) - a v jiných jazycích je ladění mnohem lepší?

[Petr Holík]

Dobry den,

nevim presne jak v ostatnich jazycich. Ale napriklad Java vas vsechny tyhle veci nenecha vubec udelat a vyhodi vyjimku.

Psani vicevlaknoveho kodu je zde mnohem jednodussi mimalne proto, ze vlaknove

Nebezpecny kod staci uzavrit mezi synchronized { }

pripadne pokud metoda pracuje s nejakym objektem muze si ho uzamknout. Pokud vlakno neocekavne skonci a necha po sobe zamcene objekty JVM je odstrani atp. (druha vec je to, ze neni dobrym zvykem na to spolehat Netvrdim ze to v C(++) nejde, ale tady vam v tom vyrazne pomaha JVM. (zjednodusene receno)

[happy barney]

hmm, typická java: máme thready + existujú ľudia, čo nevedia správne programovať = serializujme ich (pardon, synchronizujme ...)

[podlesh]

Tohle docela nabudilo mou zvědavost: co se v Java-troll kruzích považuje za správné programovaní při práci s thready?

[happy barney]

... považuje za správné ... ?

rozmýšľať

[podlesh]

A to stačí?

No, zrovna se mi chce na velkou, tak se zkusím pořádně zamyslet a uvidím co ze mě vypadne.

[elviin]

Ja si myslim, ze time to market je u Javy/C#/C++ podobny. To co popisujete jsou ucebnicove priklady problemu, kdyz troll pise v C nebo C++. Normalne se setkavate s jinymi problemy, ktere muzou byt pikantnejsi. V pripade Javy: verze jazyka X verze javac X vlaknovy model X gcc model X verze knihoven X verze target X source. A ant neni zadnej vykvet, to si musi priznat kazdej dlouhodobejsi uzivatel make.

[Luboš Doležel (Doli)]

v C(++) muzete predavat funkci jiny pocet datovych typu nez odpovida prototypu funkce

V C++? Možná tak s extern "C".

v C(++) muzete pristupovat i za hranice pole mimo indexy

Pokud použijete C pole, tak ano. V std::vector vám to s .at(x) neprojde.

v C(++) si za jistych okolnost muzete prepsat kod funkce daty

Do tohoto segmentu se za běhu opravdu může zapisovat?

v C(++) existuje nespocet "spinavych triku"

Tak jasně. U C/C++ se předpokládá rozum programátora, jinde je to víc bezriziková jízda.

a vubec tu jeste neuvadim o tom jak je to v C++ s psanim a ladenim vicevlaknochy programu. Vubec nejlepsi je kdyz vam program beha v poradku a pak zjistite, ze kdyz ho nasadite do testovaciho prostredi a zatizite ho, zjistite ze zacina svevolne padat diky chybam soubehu nebo synchornizace vlaken

Problémy s více vlákny se všeobecně ladí těžko všude. V C++ však záleží jen na vás, jestli si to usnadníte nebo ztížíte.

[Petr Holík]

v C(++) muzete predavat funkci jiny pocet datovych typu nez odpovida prototypu funkce

V C++? Možná tak s extern "C".

V C urcite a v c++ se podle vasi reakce uz poucili, ale pokud se nepletu tak se ani tam nehledi na typovou spravnost a muzete do ukazatele priradit cislo a podobne a do string dat integer :)

v C(++) muzete pristupovat i za hranice pole mimo indexy

Pokud použijete C pole, tak ano. V std::vector vám to s .at(x) neprojde.

Ruku na srdce, kolik programatoru to zna/pouziva? zapis i[3] je proste pohodlnejsi.

v C(++) si za jistych okolnost muzete prepsat kod funkce daty

Do tohoto segmentu se za běhu opravdu může zapisovat?

Nejenom x86/Linuxem je clovek ziv ve spouste operacnich systemu a pripadne arichtektur je to AFAIK mozne.

v C(++) existuje nespocet "spinavych triku"

Tak jasně. U C/C++ se předpokládá rozum programátora, jinde je to víc bezriziková jízda.

To je podobne zduvodneni, jako kdyz reknete ze napojistky nedate kryt, protoze kazdy vi ze je nebezpecne tam sahat :)

a vubec tu jeste neuvadim o tom jak je to v C++ s psanim a ladenim vicevlaknochy programu. Vubec nejlepsi je kdyz vam program beha v poradku a pak zjistite, ze kdyz ho nasadite do testovaciho prostredi a zatizite ho, zjistite ze zacina svevolne padat diky chybam soubehu nebo synchornizace vlaken

Problémy s více vlákny se všeobecně ladí těžko všude. V C++ však záleží jen na vás, jestli si to usnadníte nebo ztížíte.

ano ladi se spatne, ale dulezite je ze v Jave vznikaji mnohme obtizneji. Uz jenom z principu jakym jsou vlakna v jave resena. Pokud to hodne zjednodsim staci vsechny byt jen potencionalne nebezpecne operace obalit synchronized. Mam pocit ze JVM jde dokonce tak daleko ze kod zkouma a pokud se mu, zda ze nehrozi konflikt a ze operace jsou atomicke tak to vypusti. Mozna si to ale s necim pletu nejsem si uz presne jist.

Omlouvam se za formatovani trosku s tim zapasim :)

[Luboš Doležel (Doli)]

V C urcite a v c++ se podle vasi reakce uz poucili, ale pokud se nepletu tak se ani tam nehledi na typovou spravnost a muzete do ukazatele priradit cislo a podobne a do string dat integer :)

Musíte to ručně "silou" přetypovat. Rozhodně vám to jen tak nepovolí. Asi byste se sám měl něco o C++ naučit, než o něm začnete něco prohlašovat.

Ruku na srdce, kolik programatoru to zna/pouziva? zapis i[3] je proste pohodlnejsi.

Ten, kdo to nezná a dělá v C++, není programátorem v C++. To je prostě blbec.

Nejenom x86/Linuxem je clovek ziv ve spouste operacnich systemu a pripadne arichtektur je to AFAIK mozne.

Nicméně to může vzniknout jen pořádným prasením. Takovým prasením, že se mi tohle ještě nikdy omylem udělat nepodařilo.

To je podobne zduvodneni, jako kdyz reknete ze napojistky nedate kryt, protoze kazdy vi ze je nebezpecne tam sahat :)

Spíš mi ty špinavé triky ukažte.

Pokud to hodne zjednodsim staci vsechny byt jen potencionalne nebezpecne operace obalit synchronized.

A v C++ je zase obalím mutexem. Prašť jako uhoď.

[Petr Holík]

Musíte to ručně "silou" přetypovat. Rozhodně vám to jen tak nepovolí. Asi byste se sám měl něco o C++ naučit, než o něm začnete něco prohlašovat.

Jak jsem psal v C++ ne v C ano :) hodil sem oba jazyky do jednoho pytle, cimz se timto omlouvam.

Ten, kdo to nezná a dělá v C++, není programátorem v C++. To je prostě blbec.

Nezbyva mi nez vam verit. Ale opet v C je to celkem bezna chyba.

Nicméně to může vzniknout jen pořádným prasením. Takovým prasením, že se mi tohle ještě nikdy omylem udělat nepodařilo.

Pokud se nepletu na podobnem principu jsou zalozeny Exploity, Doporucuji knizku Hacking - umění exploitace tam se celkove dozvite mnoho ruznych zajimavych veci a kterych "slusny prohramator" casto nema ani tuseni.

Spíš mi ty špinavé triky ukažte.

Jeden za vsechny: class ucet { public int cokoliv; private int stavUctu; . . . } pokud si vytvorite instanci tridy ucet. Staci pomoci & operatoru vzit adresu objektu ucet pricist sizeof(int) a mate ukazatel na privatni promenou stav uctu. Takze pokud typicky mate nejaky zabezpeceny system a do neho pridavate cizi moduly, nemuzete verit nicemu. To vam java v zivote nedovoli. Nejsem programatorem v C++ takze ten priklad byl pro urcen pro C. Jestli by fungoval i v C++ to reknete vy. Ruznych vsechno moznych spinavych triku je v C hodne. V C++ se domnivam ze take, akorat bohuzel nejsem schopen vam je tady ted abecedne vypsat.

A v C++ je zase obalím mutexem. Prašť jako uhoď.

Nejsem si ted uplne jist jestli mutexy semfory podobny veci nejsou dost platforme zavisle. V jave je to primo prvek jazyka kdezto zde je to prvek OS pokud se nepletu. Stejne tak threadPooly atp. tohle vsehcno vam v jave pobezi nezavisle na systemu, a nemusite psat nekolik ruznych casti kodu pro ruzne systemy a pak delat slozite makefily.

[Deleted [8409]]

Ten příklad nepřeloží ani C, ani C++ překladač. V C ani slovo class není.

Ale beru, že jste chtěl napsat něco takového:

class ucet 
{ 
public:
    int cokoliv;
private:
    int stavUctu;
};

ucet u;

(&u.cokoliv) + 1 = ...;

Ty proměnné můžete obalit do getterů a setterů. C/C++ patří mezi ty nejrychlejší jazyky a nejsou pro každého, takže pokud vám vyhovuje programování v Javě, není co řešit. Ale věřte mi, já bych nechtěl aby byl v Javě napsaný třeba Firefox :)

[Ladicek]

Ale věřte mi, já bych nechtěl aby byl v Javě napsaný třeba Firefox :)

Jistě by to bylo takové zhoršení oproti současnému JavaScriptu?

(Samozřejmě že vím, že to, co na Firefoxu nechcete mít v Javě, je dneska v C++, ale prostě mi to nedalo )

[Petr Holík]

Ano neco takoveho sem mel na mysli jj muzete to jsem pro jednoduchost neuvadel, protoze to nic nemeni na veci ze muzete mimo tridu pomoci tohoto spinaveho triku, menit private polozky te tridy.

Ja osobne bych firefox nechtel vubec... :) To jak je program rychly zavisi hlavne na programatorovy. Jazyk uzrcuje jenom tu hranici kam az se da dostat v pripade toho ze programujete vse optimalne. Mimochodem i v jave se necha psat velmi rychle programy a to dokonce i 3D hry s vyuzitim akcelarace a celoobrazkoveho rezimu staci jenom vedet, jak na to. I kdyz musim objektivne priznant ze pokud budete pouzivat standardni prvky knihoven SWING/AWT je java a desitky procent pomalejsi, ale o stovky procent prenositelnejsi.

K te rychlosti: je zajimave ze PHP/APACHE psany v cecku je mnohonasobne pomalejsi pri obsluhovani pozadavku. Nez napr Tomcat/Java nebo zde pouzivany Jetty/Java. Ta rychlost se skutecne v posledni dobe vyrazne zlepsila zvlast s prichodem JAVA 6. JVM pouziva JIT kompilaci takze nektere casti jsou pri prakladu primo prelozeny do nativniho strojoveho kodu dane platformy a tam skutecne AFAIK temer neni rozdil v rychlosti provadeni. Takze pokud si naprklid v jave udelate nejaky cyklus kde neco budete pocitat myslim se, ze na tom bude Java velmi podobne jako jine kompilovane jazyky. Jinak je to s pametovou narocnosti, jenomze koho dneska zajima(pokud uvazujeme platformu x86)?

Zpet k firefoxu: to ze je psany v C(++) (nevim presne jestli je to ciste C nebo ne) neznamena ze by nesel prepsat do javy. Ale myslim si ze vyvojari Firefoxu kteri maj dost starosti sami se sebou, a doted firefox neprojde ACID 3 testem, je nestabilni ma problemy se spravou pameti. A navic doted pouziva stare renderovaci jadro Gecko( mam pocit ze dokonce zalozene na jadru Z Netscapu). Je ale otazkou co by takove prepsani prineslo, protoze stejne by se asi ne vykreslovani muselo pouzivat JNI enbo nejakje jine platformme zavisle veci. Je to podobne jako s tim co by prineslo prepsani jadra linuxu do C++

[Deleted [8409]]

C++ je mnohem svobodnější jazyk než Java. Programátoři dělají chyby ve všech jazycích a je jen na nich, jak se s problémem poperou. Nic nikou nebrání si udělat v C++ třídy a používat je (nejdou tak lehce implicitně přetypovat), přetížit si operátor [] tak, aby vyhodil vyjímku při přístuju mimo mez, atd.

[Petr Holík]

Ano to zcela nezpochybnitelne. To take od zacatku byt neprimo tvrdim C/C++, ze C resp C++ vas necha udelat temer cokoliv i byt by to melo byt nebezpecne. To je spolecny rys s jazyky typu asembler. Java vas v "vede za rucicku" a nenecha vas udelat nic co by mohlo byt byt jen potencionalne nebezpecne i kdyz napriklad Vy presne vite, ze to tak chcete.

Je to trosku jinaci pristup a jak se ukauzuje neni spatny(mezi nami,neni spatny ani jeden). Ukazte mi nejakou aplikaci v jave, ktera obsahuje Buffer Overflov chyby, nebo chyby formatovaciho retezce atp. Tech je mnohem min(v pripade buffer overflow AFAIK zadne). Je to dan za svobodu.

Nic nikou nebrání si udělat v C++ třídy a používat je (nejdou tak lehce implicitně přetypovat), přetížit si operátor [] tak, aby vyhodil vyjímku při přístuju mimo mez, atd.

Ano nebrani jak jiz bylo receno, C++ je mnohem svobodnejsi jazyk nez java. Ale opet to musim prirovnat k tomu jako kdyz mate dvere bez zamku a spolehate na to, ze se nekrade, ale nic vam nebrani si je primontovat. Pak dopadnete tak ze si budete v pulce prohramu pretezovat a pretypovavat a psat svoje funkce a nakonec budete mit to co ma java implicitne. Neni to zbytecna prace?

[frEon]

v C(++) muzete pristupovat i za hranice pole mimo indexy

Pokud použijete C pole, tak ano. V std::vector vám to s .at(x) neprojde.

Ruku na srdce, kolik programatoru to zna/pouziva? zapis i[3] je proste pohodlnejsi.

to je to samy, jako kdybych rek, ze java je na hovno, protoze neumim pouzivat vyjimkly

[Petr Holík]

to je to samy, jako kdybych rek, ze java je na hovno, protoze neumim pouzivat vyjimkly

Ano mate pravdu je to velmi podobne. S tim rozdilem ze nezanedbatelna cast padu programu v C je pristup za hranice pole

Rekl bych ze ve vetsina jazyku rozlisuje pole podle toho ze ja zanim index a pristupuje se k nemu prez hranate zavorky tzn pole[3] je treti(pripadne 4 prvek pole). Tento dlouhe roky standardni zapis je proste V C nebezpecny. Rekl bych ze cely jazyk C je proste stnadardne nebezpecny, ale pokud vynalozite jiste usili da se v nem psat bezpecne. V jave je to spise opacne standardne je to jazyky bezpecny, a pokud vynalozite jiste usili muzete tam napsat neco co je nebezpecne(i kdyz osobne teda moc nevim jak :)

[-]

A není?

[Ash]

Brutal objektarnu ti da jenom Ruby a C#. Smalltalk a Ada je tak do muzea.

Snad abyste se do toho muzea někdy zašel podívat, jinak byste nemohl napsat takovou nebetyčnou ..nesmysl. Správně měla vaše věta znít:

Brutal objektarnu ti asi da Ruby a C#. O Smalltalku a Adě nic nevím.

[Radeq]

Nejde mi ale tak o to, abyste mi poradili, který jazyk Vám vyhovuje, ale spíš kde získat objektivní srovnání těchto jazyků. A Javu prosim ne... Tou me trapi ve skole a tim pro me taky skonci.

[podlesh]

Co to je objektivní srovnání jazyků?

IMHO nesmysl.

[Bluebear]

Přesně tak. IMHO není možné objektivně zhodnotit programovací jazyky.

Doporučuji prozkoumat všechny jazyky, zjistit si co nejvíc i o dalších, nebát se experimentu a zkusit si v každém něco - tak nejlépe poznáš, který ti vyhovuje.

[Radeq]

Jakto, ze to nejde? To se neda rict, tenhle jazyk má tohle a tenhle to nemá... Tenhle má zase tohle navíc... A tak...

[sheeryjay]

Nelze to proto, že objektivní zhodnocení předpokládá dokonalou znalost všech jazyků a i toho co chcecte. Ve skutečnosti nejspíše stejně chcete subjektivní zhodnocení (přesněji řečeno zjistit to, co bude Vám nejvíce subjektivně vyhovovat).

Každý jazyk má holt svoje plus a mínus a záleží na tom co používáte. Docela dost mohou také udělat užívaná IDE a frameworky (Eric, IDLE, NetBeans, Visual Studio, atd.).

[Radeq]

Jiste, a ja hledam lidi znale techto jazyku, aby mi poradili... Nakonec si samozrejme vyberu subjektivně, ale potrebuju vychazet z neceho objektivniho... vychazet z neciho subjektivniho nazoru bych si mohl dovolit jedine, kdyby ten clovek smyslel stejne jako ja...

[podlesh]

Jakto, ze to nejde? To se neda rict, tenhle jazyk má tohle a tenhle to nemá... Tenhle má zase tohle navíc... A tak...

Ano, takové objektivni hodnocení se nazývá turing-completeness. Pokud je jazyk turing-complete, tak má již (z definice) všechno co potřebuje. Cokoliv navíc jsou jen vymoženosti pro pohodlí programátora, tedy čistě subjektivní záležitost.

Problém je v tom, že všechny jazyky o kterých uvažuješ (a troufám si říci že i všechny o kterých jsi kdy uvažoval) tuto podmínku splňují Takže zbývají jen subjektivní kritéria.

[Radeq]

Kdyz tedy Turing byl schopny definovat vlastnosti, ktere by mel jazyk splnovat, proc neexistuje nejaky dalsi Lojza, ktery by definoval dalsi vlastnosti a zaradil do nich dalsi jazyky?

[okbob]

Protože Turing byl jen jeden a další se už nenarodil :)

http://en.wikipedia.org/wiki/Alan_Turing

[Jary]

Protože jde o to, co by měl jazyk splňovat aby...

Protože Turing kompletnost je killer vlastnost. Protože když máš něco turing complete, tak to dokáže spočítat cokoliv. Turingův stroj není problém postavit, nasimulovat, analyzovat, protože je jednoduchý.

Objekty ti ve výpočetní síle vůbec nepomůžou. Stejně jako funkce - ty taky nepotřebujeme nutně. Dokonce ani cykly. Stačí nám hýbat hlavou a páskou a měnit na nich políčka tak aby to počítalo a hlava se posouvala tak jak chceme. Takový stroj dokáže spočítat všechno co mu vhodně předhodíš. Co mu předhodíš je tvoje starost a ovlivníš tím délku výpočtu a jak moc pásky bude potřebovat.

Proto je Turing kompletnost objektivní. Přidáním ostatního uděláš jen jazyk bližším lidskému chápání. Třeba přidáním instrukce jmp pro skok na libovolné pole můžeš výrazně zjednodušit zápis programu. Ano. Ale není to nezbytně nutné.

Hmm, takže vlastně takovejch Lojzů bylo... přidali tohle a támhleto a máme funkcionání jazyk. Je jednoduší v něm něco napsat a počítá to rychle, protože to dokáže efektivněji využívat prostředky - svět. Ale nedokáže to spočítat ani o úlohou víc, než turingův stroj, nebo jeho jazyk.

[Radeq]

Jj, ale z mého hlediska je výpočetní výkon jen jedno z kriterií. Zajímají mě i ostatní... Nechci slyšet: Java má nejlepší syntaxi, protože je C-like. Chci slyšet: Java ma C-like syntaxi, Python má zase takovou....

[Messa]

Chci slyšet: Java ma C-like syntaxi, Python má zase takovou....

Tak to je jednoduchý: Wikipedia (Popř. z druhé strany)

[Vašek Lorenc]

Protože Turing kompletnost je killer vlastnost. Protože když máš něco turing complete, tak to dokáže spočítat cokoliv. Turingův stroj není problém postavit, nasimulovat, analyzovat, protože je jednoduchý.

Možná to někomu přijde jako drobnost, ale ani s Turingovým strojem nejde spočítat/naprogramovat cokoliv.. nehledě na to, že implementace nekonečné pásky bývá v současných systémech taky trochu komplikovaná

[Jary]

Ano. Pravda. Trochu se hambím za to, co jsem řekl. Turingovým strojem nespočítáme všecko. Třeba nezjistíme, jestli se je algoritmus skončí. Nějak tenhle problém nemůžu na WPedii najít. Jak se mu říká?

[Vašek Lorenc]

Problém zastavení, resp. halting problem. Od původního tématu diskuse je to ale už hodně mimo ;)

[Petr Holík]

Objektivne srovnat jazyky je mozne, pokud zadate jasna kriteria :) Ale vzhledem k tomu ze si kriteria stanovujete subjektivne, tak se tim objektivnost celeho srovnani trosku nabourava.

Kazdopadne si nemyslim, ze volba jazyka je kriticka. Pokud bude dobre umet kterykoliv pouzivany jazyk, neprohloupite.

Zvazte take pro jakou platformu chcete programovat. S C# je to spatne s prenositelnosti a argument ze exituje Mono rozhodne nobstoji protoze Mono je IMHO pekna hruza. A clovek stravi pulku vyvoje testovanim zda jeho kod bezi i pod Monem.

[podlesh]

Jo a samozřejmě: pokud máš averzi vůči Javě, nemá moc smysl se zabývat C# (Nicméně, to není žádné objektivní hodnocení).

[Radeq]

To je asi fakt... stejně je C Sharp s podporou ostatních platforem na štíru...

[kozzi]

Jedine ruby. A k tvoreni GUI pouzivat Qt. Jo a u ruby je potiz ze nepodporuje implicitne unicode ale od verze 1.9 uz tusim jo a ve verzi 2.0 to bude nejlepsi scriptovaci objektovy jazyk . Jinak aby sis nemyslel ze pisu ruby proto ze je to jazyk ktery me vyhovuje, tak ja vnem neprogramuju ja radeji c++

[Radeq]

Pro Ruby existují QT knihovny?

[kozzi]

Jo existuji proc by nemeli? Jdou i ve windows i v linuxu, pro wokna je tusim i gem. Jinak jmenuje se to qtruby. Ale doporucuji pouzivat qt4

[Honza "tux" Friesse]

Brutálně objektový je určitě Self. Jinak na IM, přehrávač a webové stránky (viz Seaside) je Squeak (tj. Smalltalk) brutálně objektový tak akorát (a to GUI bude taky brutální ).

[Radeq]

To je ironie?

[Honza "tux" Friesse]

Ne.

Smalltalk i Self jsou 100% objektové (všechno je objekt/třída a potom je zajímavá taky metacyrkulární architektura) jazyky, každy s jinou filozofií (třídní x beztřídní). Obě se hodí si vyzkoušet, protože ECMA script je beztřídní a valná většina konvenčních jazyků zase třídní.

Seaside je opravdu kvalitní framework, který autor začal vytvářet pro Ruby, ale zjistil, že je Ruby nevyhovující, tak jej přepsal do Squeaku.

To s tím GUI byla taky pravda. GUI Smalltalku je ... netradiční, ale rozhodně ne špatné. Staví na MVC stejně jako Java Swing (jenže Morphic byl dřív a Swing hodně inspiroval), takže se naučíte jednou a pak bez problémů přejdete na Swing (třeba v zaměstnání).

Squeak je 100% přenositelný mezi Windows, UN*X based stroji a bůhvíčím ješte.

Navíc dělat nový IM, přehrávać v klasických jazycích nemá cenu, protože jich existuje už asi tak 150 000.

Naopak netradiční (což bohužel Smalltalk je) jazyk Vás naučí některé věci, které do tradičních jazyků příjdou až za nějakou dobu.

[Messa]

Zkus všechno Praktické vyzkoušení bude mnohem lépe strávený čas než čtením všech možných nezaujatých a jasných rozdílů. Prolítnout tutorialy každé té technologie/jazyka je tak na desítky minut... Jinak myslím že není nutné od toho Pythonu nijak rychle utíkat, nic nového a převratně skvělého oproti Pythonu stejně nenajdeš... Nicméně Cs a Ruby ti asi nejvíc zvedne skilly pro případnou "komerční praxi" Co se týče multiplatformity (co si pod tím vlastně představuješ?) a Unicode, tak snad víc než na jazyku záleží na knihovnách, které použiješ. A co C++, to by nebylo?

[Pev]

Já bych též zůstal u Pythonu, případně přepis klíčových částí do C++.

[Michal Vyskočil]

Objektivně se rozhoduješ na základě toho, co chceš dělat a na základě vlastních zkušeností, tedy na čistě subjektivní bázi. Můžeš se to pokusit nazvat objektivním, ale ve skutečnosti je to tak subjektivní, jak jenom může být.

V první řadě je potřeba zjistit, co ti nevyhovuje, nebo chybí v Pythonu. Existuje něco, co zoufale potřebuješ a jazyk to nemá? Pokud ano, co to je. Potom teprve můžeš řešit další jazyky, nicméně primárně se jazyk volí podle projektu, ne naopak. Programovací jazyk je prostředek, jak něco udělat, nikoliv samotný cíl.

Že tu pliveš na Javu je všechno, nejenom objektivní hodnocení. A ano, určitě dokážeš napsat milión "objektivních" důvodů proč ne, nicméně stejně to budou jenom plané kecy, protože zase existuje milión jiných, proč ano.

Není špatné se seznámit se s více jazyky. Já osobně jsem se toho prostřednictvím Smalltalku naučil i dost o Pythonu (předtím jsem ho bral jen jako skriptovátko, potom jsem si uvědomil, že je to objektový jazyk) a můj pokus o naučení se Scheme mi zase pomohl v tom, že dneska umím používat funkcionální konstrukce dostupné v Pythonu ... nicméně jsem se k němu vrátil vždycky zpátky, protože je pro mě nejflexibilnější.

[Pavel Sýkora]

+1

V první řadě je potřeba zjistit, co ti nevyhovuje, nebo chybí v Pythonu.

Jo, to by mně taky zajímalo, zdali něco takového je. Já sice nesnáším Pythonovskou syntaxi - syntaxe Ruby mi přijde daleko lepší, ale to je čistě subjektivní. Objektivně se v obou jazycích programuje nejspíš stejně pohodlně.

... nicméně primárně se jazyk volí podle projektu, ne naopak.

Přesně tak. Budu-li mít za úkol manipulovat s Wordovskými dokumenty, sáhnu nejspíš po Visual Basicu, budu-li počítat s rozsáhlými maticemi komplexních čísel, patrně vyhraje Fortran.

Nezapomeňte také na to, že pohodlí práce s daným prostředím nevytváří jen syntaxe daného jazyka nebo "brutálnost" OOP, ale i kvalita API standardní knihovny, nabídka "third-party" knihoven, prostředky pro ladění programů atd.

[Jary]

Jenže to ty jazyky (a knihovny) musíš znát a umět, aby jsi mohl vybrat ten nejlepší pro projekt.

[Radeq]

Na Pythonu mi nechybi vubec nic... teda krome toho, ze jsem doted nedokazal udelat binarku z meho projektu... mozna mi leda tak vadi, ze vsichni "Pythonists" jsou tak zatvrzely linuxari... Ale bojim se, abych neco neprosvihl, protoze ted se vsude mluvi o Ruby apod....

[happy barney]

kvantita rečí nikdy neznamenala ich kvalitu

btw, odporúčam prečítať si Programming is Hard, Let's Go Scripting..., vybrať si pre vás/teba dôležité vlastnosti a jazyk zvoliť podľa nich

[Radeq]

To se mi libi :) Dekuju (Ja vim, s objektivnosti to pokulhava... Za to tady dostavam pekny kapky...)

[Daniel Kvasnička ml.]

Na Pythonu mi nechybi vubec nic...

No ja nevim, pises, ze chces brutalni objektovost, zavrhujes Javu (proc?) a pises, ze v Pythonu ti nic nechybi -- pritom ten ma do brutalni objektovosti celkem daleko. Jses si jisty, zes tu objektovost a jeji pripadnou brutalitu pobral spravne?

[Messa]

BTW. co vlastně znamená brutální objektovost? Musí být objektem integery, třídy, třídy tříd, nebo i samotný zdrojový kód? Kolik maximálně klíčových slov je povoleno? Je Smalltalk dostatečně brutálně objektový? (A co na to Jan Tleskač?)

[Daniel Kvasnička ml.]

IMHO to neni jen o tom co je a neni objekt. Objekt muze byt vsechno, ale kdyz jazyk neumi rozhrani, povoluje vicenasobnou dedicnost nebo neumoznuje kontrolu viditelnosti vlastnosti a metod, tak to s tou objektovosti nebude tak horke....

(A na vedomost se dava, ze timto rozhodne neprohlasuju Python za spatny jazyk)

[Michal Vyskočil]

IMNHO je objektovostí rozuměno "to, co umí můj oblíbený jazyk".

Souhlasím s chybějící kontrolou přístupu. Koncept rozhraní se dá doimplementovat (Pochopitelně se nechovají stejně, jako ty v Javě, ale to je vzhledem k dynamické povaze Pythonu pochopitelné). A vícenásobná dědičnost? To jako Smalltalk taky není dobrý objektový jazyk, když ji umožňuje?

[Daniel Kvasnička ml.]

Koncept rozhraní se dá doimplementovat (Pochopitelně se nechovají stejně, jako ty v Javě, ale to je vzhledem k dynamické povaze Pythonu pochopitelné).

No prave... doimplementovat. Pak to podle toho vypada

To jako Smalltalk taky není dobrý objektový jazyk, když ji umožňuje?

Vim, ze souhlasit s timhle by pro me znamenalo od nekolika lidi rozsudek pomale mucive smrti Ale ona ta objektovost zavisi asi na dvou hlavnich faktorech -- ten "technicky" (nebo jak to nazvat -- proste objekt je vse na co si vzpomenes), tam je Smalltalk asi na vysi. Ale z toho "analytickeho/navrhoveho/principialniho" pohledu IMNHO vicenasobna dedicnost nema v dobrem objektovem navrhu co delat. Jen podporuje zneuzivani dedicnosti k prostemu sdileni implementace.

[happy barney]

IMNHO vicenasobna dedicnost nema v dobrem objektovem navrhu co delat. Jen podporuje zneuzivani dedicnosti k prostemu sdileni implementace.

riadna blbosť. viacnásobná dedičnosť v reálnom svete jednoducho existuje.

[Daniel Kvasnička ml.]

IMNHO vicenasobna dedicnost nema v dobrem objektovem navrhu co delat. Jen podporuje zneuzivani dedicnosti k prostemu sdileni implementace.

riadna blbosť. viacnásobná dedičnosť v reálnom svete jednoducho existuje.

Priklad?

[Jary]

Třeba já. Po matce jsem zdědil prsa, po otci ... (:

Třeba problém s kruhem a elipsou. http://en.wikipedia.org/wiki/Circle-ellipse_problem

[Ladicek]

Ale pokud se nepletu, tvoje matka i tvůj otec jsou instancemi Člověka. A ty koneckonců taky

[happy barney]

mobilný telefón s rádiom, mp3 prehrávačom, dig. fotoaparátom a usb storage

jasné, poviete "interface 1 2 3 4 5 a všetko vždy implentovať" .. aj za cenu copy-paste programovania, hoci je možná default imlementácia niektorých metód (i.e. sú implementovateľné využitím zvyšných metód)

a ako to vyzerá v jave?

class vsetko implements ... {
  private Telefon telefon;
  private Radio radio;
 ...
  public int xyz_01 (...) { this.telefon.xyz_01 (...); };
  public int xyz_02 (...) { this.radio_02 (...); };
  public int xyz_03 (...) { this.storage.xyz_03 (...); };
}

[Jary]

Příklad mobilný telefón s rádiom, mp3 prehrávačom, dig. fotoaparátom a usb storage je podle mě typický návrhový vzor Composite. Ten sice chápu dost matně, možná protože je ten vzor pojat všude jinak a někde nijak a tak se mi to motá.Vsadil bych ale klobouk na to, že je to kompozit.

A tedy, je li to kompozit, tak vsadím i klobouk, že to vaše řešení je dobré, ale jaksi v C++ by se to řešilo obdobně.

[Daniel Kvasnička ml.]

Příklad mobilný telefón s rádiom, mp3 prehrávačom, dig. fotoaparátom a usb storage je podle mě typický návrhový vzor Composite. Ten sice chápu dost matně, možná protože je ten vzor pojat všude jinak a někde nijak a tak se mi to motá.Vsadil bych ale klobouk na to, že je to kompozit.

IMHO tady nejvic sedi vzor Proxy.

[Daniel Kvasnička ml.]

mobilný telefón s rádiom, mp3 prehrávačom, dig. fotoaparátom a usb storage

A co to je? Je to mobil? nebo radio? nebo mp3 prehravac? Kde je "is-a" relace v tomhle vztahu? (mp3 prehravac i fotak ma svuj vlastni storage -- takze kdyz je proste jen rozsiris obe a jeste k tomu rozsiris primo storage, muzes se velice lehce dostat k diamond problemu, coz je jeden z hlavnich duvodu, proc neni MI dobra vec).

Co to je za tridu "vsetko"? Mel to byt prece telefon s uvedenymi funkcemi, tedy Telefon implementujici dalsi rozhrani a s telem tridy priblizne tak, jak jsi to napsal (bez privatniho Telefonu). Tak to totiz odpovida realnemu svetu. Primarne je to porad telefon. Jen jsou v nem subsystemy, ktere pridavaji dalsi funkce. Mozna to nebude tak "hezke" jako v C++ nebo jinem MI jazyce, ale komponentovost a zapouzdreni zustane dokonale zabezpeceno. Mj. bude mnohem jednodussi ty komponenty vymenovat. Pujde to na rozdil od MI reseni i za behu programu a mnohem jednodussi bude pro vnejsi implementatory doprogramovat svoje komponenty. Flexibilita nesrovnatelna oproti reseni, kdy by trida Vsetko zdedila implementace Telefonu, Radia, Fotaku a Storage zaroven.

[Daniel Kvasnička ml.]

Jinak receno: najdes tolik prikladu, ktere opravdu nejdou jinak vyresit nez pres MI, abys vyvazil negativa MI? Nikoliv.

[happy barney]

jasne, všetky prípady multiple inheritance idú urobiť aj bez nej, len je to veľa zbytočného kódu (viď odpoveď na predchádzajúce). Ale to je už pravidlo (nielen javy) ... všetko "nepodporované" je len umelé navýšenie množstva finálneho kódu.

[Michal Vyskočil]

No prave... doimplementovat. Pak to podle toho vypada

Nějaké konkrétní námitky? Já se teda se zope interface moc nepotkal, takže by mě zajímaly zkušenosti někoho, kdo s nimi dělal víc.

To jako Smalltalk taky není dobrý objektový jazyk, když ji umožňuje?

No a proto jsem napsal, že objektovost je to, co se rozumí pod tím, co umí můj oblíbený jazyk . Ale chápu, že člověk, co se podíval třeba na EJB 2 může jenom děkovat, že v Javě možnost vícenásobné dědičnosti není. Ostatně zrovna tohle ne vždy funguje i v Pythonu Souhlasím, že jde o velice nebezpečnou konstrukci, se kterou se musí zacházet s rozmyslem, ale kvůli tomu bych jí neoznačoval za neobjektovou.

nema v dobrem objektovem navrhu co delat

Tyto globální odsudky nemám příliš v lásce. Zase, určitě existuje milión případů, kdy je násobná dědičnost užitečná, stejně jako milión těch, kdy není.

[Daniel Kvasnička ml.]

Nějaké konkrétní námitky? Já se teda se zope interface moc nepotkal, takže by mě zajímaly zkušenosti někoho, kdo s nimi dělal víc.

Minimalne to, ze nemas sani v zadnem IDE na nejakou rozumnou podporu a ze problem s napr. chybejici implementaci metody zjistis vzdy az pri behu programu. To je napr. oproti Jave dost silna nevyhoda.

Ale chápu, že člověk, co se podíval třeba na EJB 2 může jenom děkovat, že v Javě možnost vícenásobné dědičnosti není.

Obecne neznam moc lidi, co by z EJB skakali radosti

Zase, určitě existuje milión případů, kdy je násobná dědičnost užitečná, stejně jako milión těch, kdy není.

S tim prvnim milionem bych nesouhlasil Jak jsem psal vyse, prinosu IM je zalostne malo na to, aby vyvazily negativa (slozitost implementace, diamond problem, nerespektovani "is-a" vztahu mezi typy).

[happy barney]

Jen podporuje zneuzivani dedicnosti k prostemu sdileni implementace.

he? za túto vetu ste si u mňa vyslúžil ohodnotenie "človek bez informačnej hodnoty"

[Daniel Kvasnička ml.]

Dost tvrda urazka na to, aby jsi ji vyslovil bez vysvetleni. Radim ti to vysvetleni jeste pridat, nebo by sis mohl vyslouzit stavnatejsi prezdivku...

[happy barney]

vysvetlenie? ak zakážeš zdieľanie implementácie, vzniká problém n-násobnej implemetácie (a samozrejme, n-násobenie chýb). jasne, javista odpovie: vyriešim triedou a pluginom. miesto toho, aby predok implementoval default algoritmus bude každý potomok vytvárať default plugin. a aby to bolo modifikovateľné, default plugin vlastne vytvorí len inštanciu iného pluginu ... a že to sú tony kódu? no a? veď IDE to zvládne. a potom múdry jak sovietsky fúrik mudrujú, že ten a ten jazyk je write-only.

chcete príklad na ten default ?
množina porovnaní, stačí implementovať buď väčší alebo menší a výsledky ostatných porovnaní sa dajú vygenerovať.

(typický javista odpovie: máme predsa interface Comparable, prečo by som sa mal zamýšľať nad týmto príkladom?)

[Daniel Kvasnička ml.]

vysvetlenie? ak zakážeš zdieľanie implementácie, vzniká problém n-násobnej implemetácie (a samozrejme, n-násobenie chýb).

Napsal jsem snad, ze chci zakazat sdieleni implementace?! Sdileni implementace je samozrejme u klasicke dedicnosti naprosto normalni a spravne -- za predpokladu, ze dodrzis semantickou vazbu mezi rodicem a potomkem. Co kritizuju je proste sdileni implementace, tzn. dedeni ponorky z ryby jen proto, ze ponorka ma taky metodu plavPodVodou() -- to je proste bordel. A u MI je tenhle problem inherentni.

[Pavel Sýkora]

Spíš je lepší mít všeobecný přehled a umět se požadované rychle naučit/doučit .

Syntaxe zas až tak důležitá není, je to stejně většinou na jedno brdo (OK, alespoň v dané skupině jazyků - ne zrovna C vs. Haskell), k API najdu a zběžně pročtu dokumentaci, pohledám další knihovny, zagooglím, zkusím napsat jednoduchý prototyp nějakého podobného problému a ve výběru jazyka pro projekt mám jasno.

Je pravda, že tímto způsobem ale člověk ten daný jazyk nepozná do těch nejhlubších (nejtemnějších?) zákoutí, takže občas v daném prostředí nenaprogramuje nejefektivnější variantu. Občas se něco musí i přepsat. Mne osobně ale více uspokojuje rychlejší pokrok v projektu a jednodušší kód, než to, že se stávám světovou jedničkou v nějakém jazyce.

[happy barney]

zober si perl, ten si podľa svojich schopností a odhodlaní prispôsobíš ako chceš (viď Lingua::Romana::Perligata).

"Objektovosť" nie je všetko (ono, napr i java je len pseudo-objektový jazyk), dôležitejšie sú imho výrazové prostriedky jazyka (duck typing, autoload, polia/hashe ako súčasť jazyk či dolepené knižnice, ...)

[Jary]

Tohle je velice těžká otázka. Myslím, že lepší, než vybírat si konkrétní jazyk je lepší začít učit se programovat. Učit se algoritmizaci a návrhové vzory. V kterémkoliv Turing-Complete jazyce.

Musíš pochopit, co se dělá jak a proč se to tak dělá. Objektovost podle mě není tak hrozně důležitá vlastnost, jak by se mohlo zdát. Jde jenom o to, že se trochu víc věcí dělá implicidně namísto explicidně. Třeba: každý objekt budeš mít automaticky inicializovaný nějakým konstruktorem a před jeho zapomenutím se zavolá automaticky destruktor.

Ke zváženíhodným jazykům bych přidal D, které se mi docela dost líbí tím, že je to dost javovité - hodně věcí se dělá implicidně a je to překládáno do nativního kódu, tedy žádná virtuální mašina. Umí to myslím nativně používat C knihovny. Podle mě jsou tohle dosti silné argumenty.

[Radeq]

O D jsem doted neslysel... ale budu ho muset take zohlednit...

[Jary]

Málo se o něm ví, jelikož je to velice mladý jazyk. Což je asi jeho hlavní mínus.

Abych se trochu shodil - já v něm napsal jenom hello world. Na víc jsem zatim neměl čas, takže mé názory na něj, podle mě, nejsou dostatečně fundované.

[Jose.]

Když už hledáš kdejakej jazyk tak se podívej na tohle : http://www.rapideuphoria.com/ , vypadá to sice na první pohled podivně ale napsal jsem v tom pár dost velkej projektů a je to kupodivu velice efektivní.

[Hynek (Pichi) Vychodil]

Všechno, co jsi vyjmenoval, jsou imperativní jazyky. To je, jako by ses ptal, jestli je lepší se nechat přejet elektrickou nebo parní lokomotivou. Je v tom rozdíl, ale dopadne to stejně. Z objektových jazyků stojí za úvahu snad jedině smalltalk, protože nevolá "metody", ale zasílá objektům zprávy. Ono samotné OOP je úchylné. Stačí se jen podívat trochu z odstupu na diskusní fóra co programátoři v OOP řeší. Snad nejmarkantnější je, že na každém takovém fóru se objeví úloha typu: Jak vyrobit krompáč, kterému když řeknu, tak se sebere a půjde se uložit do police. To by nebylo tak hrozné, kdyby OOP guru příslušnému začátečníkovi řekli, že chce udělat pitomost, ale to ne. Oni mu začnou vysvětlovat jak takový krompáč co nejlépe vyrobit a nejen to. Ještě mu vysvětlí jak to udělat, aby když ten krompáč z té police dostali, tak aby s ním zároveň získali i fabriku ve které byl ten krompáč vyroben. Víc jak polovina OO design patternů se motá kolem podobných nesmyslů a ten zbytek ještě kolem horších. OOP řeší, jak udržet pořádek a přehled ve špatně designovaných systémech implementovaných nevhodnými prostředky a zastaralými technologiemi. Raději se koukni na něco funkcionálního s podporou multiprocessingu. Třeba Haskel, OZ, JOCaML, Scheme/(Common)Lisp/Arc nebo Erlang.

[Martin]

Moc hezky řečeno.

Jen tak mimochodem, odkdy se tady v poradně smí řešit programátorské a s unixem nesouvisející dotazy?