Pohádka o dvou programátorech

16.8.2009 22:43 | Přečteno: 6081×

Překlad z anglického mailing listu. Autor Neil W. Rickert. Original lze najít zde

Kdysi dávno, se dvě různé a nesouvicející organizace: "Automated Accounting Applications Association" a "Consolidated Computerized Capital Corporation", rozhodly že potřebují program na dva identické úkoly.

Automated najala programátora-analytika: Alana, aby vyřešil jejich problém.

V Consolidated se rozhodli svěřit tento úkol čerstvě najatému nováčkovi, Karlovi, aby ukázal zda je tak dodbrý jak tvrdí.

Alan, veterán se zkušenostmi z těžkých projektů, se rozhodl použít osvědčenou PQR strukturovanou návrhovou metodologii (PQR structured design methodology). Podle ní požádal vedoucího oddělení o přidělení dalších tří programatorů do týmu. Pak se tým pustil do práce, datlování předběžných reportů a analýz.

Mezitím v Consolidated, Karel přemýšlel o problému. Jeho kolega zaznamenal, že Karel často sedí s kafem a nohami na stole. Občas byl také viděn u svého počítače, ale podle nepravidelného bušení kláves hrál Space Invaders.

Tým v Automated začal psát kód. Programátoři strávili zhruba polovinu času kódováním a testy, zbytek na schůzích o interakci různých modulů řešení.

Ve stejný čas Karlův kolega zaznamenal že Karel konečně vzdal Space Invaders. Místo toho dělil svůj čas mezi popíjení kafe s nohami na stole a čmáráním po papírech. Jeho čmáranice nevipadaly jako Tic-Tac-Toe, ale o moc víc smyslu nedávaly.

Uběhly dva měsíce. Tým v Automated konečně vydal plán časový plán implementace. Za další dva měsíce budou mít testovací verzi programu. A po dalších dvou mesících ladění a úprav by měli mít hotový program.

Karlův vedoucí začal být z Karlova flákání nervózní a rozhodl se s ním promluvit. Ale když přišel do Karlovi kanceláře, zastihl ho v pilném bušení kódu. Proto se rozhodl s rozhovorem posečkat a Karla dále sledovat. K jeho radostnému překvapení Karel vypadá stále více zaneprázdněn. Karel dokonce vynechává obědy a občas zůstává v práci do večera.

Na konci třetího měsíce Karel oznámí ukončení projektu a odevzdá 500-ti řádkový program. Program vypadá čistě napsaný a dělá vše podle specifikace. Navíc má několik features které výrazně zjednodušují použití. Program je otestován a až na jeden rychle opravený překlep pracuje skvěle a je poslán uživatelům.

Tým v Automated dokončil dva ze čtyř hlavních modulů pro jejich program. Tyto moduly jsou podrobeny testům, zatímco tým dokončuje zbylé dva.

Za další tři týdny Alanův tým vydává počáteční verzi s týdením předstihem. Součástí vydání je seznam featur které by měli fungovat. Program je otestován a uživatelé najdou hromadu chyb. Ale jak Alan vysvětlil, toto je očekáváné, jedna se přeci o testovací verzi programu a chyby jsou očekávatelné.

Po dalších dvou měsících, tým dokončil produkční verzi programu. Obsahuje zhruba 2500 řádků kódu. Podle testů splňuje většinu původního zadání. Ale neobsahuje jednu/dvě featury a je hodně vybíravý na formát vstupních dat. Přesto se Automated rozhodne tento program nasadit. Uživatelé si prostě při zadávání dat musejí dát pozor. Program je předán maintanance programátorovy (stará se o údržbu), který možná časem mouchy vychytá.

DODATEK:

Při prvním pohledu byl Karlův nadřízený nadšen. Ale jak se pročítal kódem, zjistil že projekt nebyl zas tak složitý jak si původně myslel. Vlastně to nebyla zas tak velká výzva, ani pro začínajícího programátora.

Karel napsal 5 řádků za den (pozn v korporacích naprosto reálné číslo). Toto je možná trochu nad průměrem, ale s přihlédnutím k jednoduchosti projektu, nic výjmečného. A nadřízený si také pamatoval dva měsíce flákání.

Na konci roku Karel dostal přidáno velmi málo, ani to nepokrylo inflaci. Nikdy nebyl povýšen. Asi po roce vyhořel a dal výpověď.

Alan a jeho tým dostal pochvalu za úspěšné ukončení projektu. jeho nařízený se podíval na kód, po několika minutách zjistil, že splňuje formátování vyžadované společností. Ale rychle vzdal další studium kódu, který vypadal velmi nesrozumitelně. Uvědomil si, že projekt byl daleko složitější než si původně myslel. A ještě jednou pogratuloval Alanovi k úspěšnému projektu.

Tým vyprodukoval 3 řádky kódu denně. To je možná trochu pod průměrem, ale pochopitelné vzhledem k náročnosti úkolu. Alan dostal bonus a povýšení na Systems Analyst jako odměnu.

....Miles 

kcolfer at iol.ie
kieran.colfer at ireland.sun.com
http://ireland.iol.ie/~kcolfer

       

Komentáře

[thingie]

RTFM.

[Riddick]

Wau. Fajne.

[Tomáš Pěnička]

A ještě:

Program je předán maintanance programátorovy

[Roger]

Prihodil bych jeste minimalne tohle a tohle.

[kouby]

Nevím jestli je to pokryto odkazy uvedenými výše, ale "nevipadaly" by se mělo fixnout co nejdříve.

[Bluebear]

Tak to chodí ve společnostech, kde nadřízení nemají technické myšlení (což nemusí být ekvivalentní s tím, že nemají technickou školu). Svrbí mě napsat, že nemají zdravý rozum, ale to by bylo asi trochu úzké pojetí... dejme tomu, že jim chybí určitá složka zdravého rozumu. Ta, která ví, že jednoduché řešení je lepší než komplikované.

Člověk s technickým myšlením si uvědomí, že právě ta jednoduchost řešení svědčí o pochopení problému a tedy i o vysoké kvalitě výsledného kódu, a náležitě uzná kvality programátora.

[okbob]

To ani tak nemusí být o nadřízených. Z určitého úhlu pohledu existují dva styly programování - jeden - korporátní a druhý bych nazval podle druhu programátora "osamělý vlk". Korporátní styl se vyznačuje týmovou prací, extrémní byrokracíí, náklady, implementační dobou. Ještě než se začne programovat, tak se půl roku prodiskutuje, obhajuje se záměr - tým se neobejde bez projektového managera. Styl osamělý vlk je přesný opak.

Výhodou korporátního stylu je zapojení více lidí do realizace - což umožňuje určitou zastupitelnost. Nevýhody jsou v ceně, času, neskutečném množství byrokracie, organizování - na cca 1min vlastního vývoje spočívá 1h režie (můj tip). Výhody a nevýhody vlčího stylu jsou negací výhod a nevýhod korporátního stylu. Jedna z neocenitelných výhod korporátního stylu vývoje je skutečnost, že díky němu spousta lidí nejsou nezaměstnaní.

Záleží na povaze projektu, který styl je pro něj vhodný. Myslím si, že pro rozsahem malé projekty (nemusí se řešit bezpečnost), cca do 1000 řádků a 1 člověko měsíc je výhodnější styl osamělý vlk. U 10 000 řádků už je na místě minimálně malý realizační tým - programátor + tester + quality manager. Nad 10 000 řádků je strategie osamělého vlka rizikem a nad 100 000 řádků je program jedním člověkem nerealizovatelný.

Jinak psát čistě a dobře, stejně tak špatně a nečitelně je možné v obou stylech.

[Tomáš]

Korporátní styl je nutný tam, kde se dělá údržba programu po delší dobu. Program musí umět rychle přečíst a pochopit i ten, kdo ho nepsal. Navíc se s žádnou opravou nesmí změnit jiné chování. Proto ta hromada dokumentace, hlášení chyb, testování a byrokracie jako celek. Navíc ještě musí zbýt prostor na změny na přání zákazníka. Navíc bývá požadavek na  bezpečné programování, což někdy trošku zdržuje. Pokud by velký tým šlapal perfektně, tak se byrokracie srazit řekněme na 50%, ale stejně je to pořád víc, než má osamělý vlk.

Pokud se dělá dobrá analýza, tak se sice na začátku stráví mnoho času všelijakými diskusemi, ale když to skončí, tak je jasné, co se má dělat a jak se to má dělat. Úplně nejhorší je, když se na velkém projektu tyhle schůzky vůbec nedělají  a v půlce implementeace se hodně lidí začne divit (a nejvíc manažeři, kteří analýzu pokládali za plýtvání časem).

[dad]

pracujete v nejake politicke strane? Jste ekonom? Jste zena a nechcete to zde priznat? Jestlize ani jedno nesouhlasi, pak prosim o nasledujici upresneni:

• jak dlouho trva 'delsi doba'
• jak je definovano 'rychle cteni'
• jak velka je 'hromada dokomentace'
• v cem se meri 'zbyly prostor' pro realizaci dodatecnych prani zakaznika
• jak se definuje 'bezpecne' programovani
• jak vypada 'dobra' analyza

 

[Jakub Lucký]

pracujete v nejake politicke strane? Jste ekonom? Jste zena a nechcete to zde priznat? Jestlize ani jedno nesouhlasi, pak prosim o nasledujici upresneni:

LOL LOL

[podlesh]

Tuším že Jidiš na to má speciální slovo: chucpe

[Tomáš]

To je ten fór, že většina z toho se nedá exaktně definovat jako matematický pojem a většinu z toho jsi schopen posoudit až zpětně (t.j. s křížkem po funuse). Proto je taky tak těžké najít dobrého project managera (a obecně střední managment vůbec, nejenom v IT). K bezpečnému programování: záleží to na odvětví, zkus například klíčové slovo MISRA.

[Kvakor]

... dejme tomu, že jim chybí určitá složka zdravého rozumu. Ta, která ví, že jednoduché řešení je lepší než komplikované.

To platí obecně - pro takové lidi je je to kód jako kód a jedinou jim srozumitenou kvalitou je jeho velikost. Převedeno do jiných oborů, pro negramotného by bylo měřítkem kvality knihy počet jejich stránek, pro uměleckého analfabeta velikost plátna obrazu a pestrost barev na něm a pro architeknotického ignoranta by to byla velikost postavené budovy (resp. množství spotřebovaných cihel). To, že je kniha blábol, plátno mazanice a budova neobyvatelné monstrum, nejsou schopni vidět.

Podle mého názoru je člověk, který dostatečně rozumí dannému oboru, schopen použít při jeho posuzování stejné postupy, které používá pro vnímání elegance a krásy. To platí jak v programování, tak třeba v elektronice, konstruktérsví ale i ve fyzice a matematice (viz Mathematical beauty na Wikipedii).

To, co je pro člověka mimo obor jeno pár nesmyslných řádek, je pro programátora elegantní kód, který je efektivní ve své jednoduchosti, naprotomu stovky rádek kódu, které mohou laikovi pripadat působivé, budou pro programátora představovat vrchol ošklivosti, protože hned na první pohled uvidí, jak zbytečně složitý a neefektivní onen program je a že jeho autor musel mít inteligenci vycpaného jezevce, pokud ho netrklo, že namísto stovek řádků mohl to samé udělat s několika řádky kódu*, pokud by si předtím trochu zamyslel.

Jenže čím dál častěji se setkávám s kódem, kde autor měl buďto opravdu inteligenci výše zmíněného jezevce, nebo se mu při návrhu nechtělo vůbec přemýslet a použil z jeho pohledu nejjednodušší řešení, které je ale vysloveně neefektivní a ohyzdné.

V jednom případě jsem se dokonce na to autora ptal, a bylo mi odpovězeno že pokud kód funguje a nemá bezpečnostní díry, nikoho nezajímá jak elegatně je to napsané (pokud jsou dodržena pravidla o tom, jak má kód vypadat), že optimalizaci mu nikdo nezaplatí (ta se dělá, ale jen na rychlost a jen když si zákazník stěžuje, že je to moc pomalé) a že by byl sám proti sobě, protože množsví jím vykonané práce se posuzuje podle velikosti kódu v řádcích.

* Takový kód jsem opravdu zažil, viz můj starší příspěvek.

[xkucf03]

S tím množstvím řádků kódu je to ošidné – ono se sice může zdát, že malý počet řádků je „elegantní“ a větší počet je „neefektivní“, ale může to být i naopak – malý počet řádků může být „naprasený“, autor použil neobvyklé konstrukce jazyka nebo jiné hacky, s cílem minimalizovat počet řádků kódu, jenže tím znepřehlednil kód a velmi ztížil jeho čtení ostatním programátorům. A vedle toho program napsaný na 1,5x více řádků, může být napsaný primitivním jazykem (jako by to psalo dítě ze ZŠ), chybí tam elegantní básnické obraty a složitě rozvinutá souvětí, ale kód je tak přímočarý, že mu rozumí každý (i když je delší, protože s menší (primitivnější) slovní zásobou musíme použít více slov, abychom popsali tutéž skutečnost).

Složitost programu to tedy chce omezovat spíš v úrovni analýzy, např. omezit počet případů, které program ošetřuje, a na úrovni kódu potom řešit počty větvení a cyklů – ale neřešit počet řádek, to je úplně nepodstatný detail.

Pro porozumění je důležitá strukturovanost – když budu číst cizí program, nebudu ho číst jako romád od začátku do konce, podívám se na strukturu balíčků, třídy (pokud je jedná o OOP), na hlavičky metod v těch třídách, na jejich komentáře – ale kolik kódu je uvnitř metody mne většinou nezajímá – důležitý je vstup a výstup metody/funkce, to najdu v komentářích a pokud kód dělá to, co má, nemusím ho vůbec číst (je tedy jedno, na kolik řádek to je napsané).

[alblaho]

To pravé umění je dělat složité věci jednoduše.

Rozepisovat elegantní konstrukce na primitivní operace přehlednosti nikdy nepřidá. Komu dělají problém "chytřejší" konstrukce jazyka, ten se má doučit jazyk. Pro pochopení kódu je potřeba získat "big picture" ne přemýšlet jak fungují uzávěry.

I když uznávám, že v dynamických jazycích (Python, Ruby a.. ano, Perl) je možné dosáhnout zkrácení kódu za cenu špinavých triků (přes eval a spol). Proto korporátní Java nic takového nemá a takový primitivní jazyk je potřeba využívat naplno.

[xkucf03]

Komu dělají problém "chytřejší" konstrukce jazyka, ten se má doučit jazyk.

Třeba v C/C++ nebo v Perlu jde psát právě tím „chytrým“ stylem, kterému málokdo rozumí, nebo mu rozumí na první pohled. Naučit se takové jazyky aktivně (umět psát) není až takový problém, člověk si prostě osvojí základy a věci, které potřebuje, ale naučit se je pasivně (umět číst kód po komkoli) je dost obtížné → a tedy i drahé – a firma nepotřebuje zaměstnávat „geniální“ programátory – potřebuje napsat program, který dělá to, co má, v určitém čase a za udčité peníze. Jsou i projekty, kde se na čas ani peníze nehledí, ale to jsou celkem pokřivené podmínky.

Pro pochopení kódu je potřeba získat "big picture"

K tomu je nejlepší analýza a komentáře, k získání celkového obrazu, jak to funguje, člověk ani nemusí prolézat kód (vnitřky metod, procedur), mělo by mu stačit si přečíst hlavičky metod a měl by mít jasno, co program dělá. Tohle nesouvisí ani tak s počtem řádků nebo programovacím jazyce – spíš se strukturou – když je program dobře strukturovaný, tak mi může být celkem jedno, že ty vnitřky metod jsou naprasené (s cílem minimalizovat počet řádků), stačí, že dělají to, co si přečtu v komentáři (a co čekám podle návratové hodnoty a parametrů).

přemýšlet jak fungují uzávěry.

Zrovna o uzávěrech tu byl nedávno pěkný flame. Pochopit je není moc těžké, ale podle mého jsou právě příkladem toho, jak se dá kód snadno ohackovat a „elegantně zkrátit“ za cenu snížení znovupoužitelnosti a budoucího refaktoringu.

Proto korporátní Java nic takového nemá a takový primitivní jazyk je potřeba využívat naplno.

A tato „primitovnost“ Javy je jedním z důvodů její velké oblíbenosti V podstatě tě donutí psát přehledný kód, kterému rozumí i další programátoři… a to se počítá.

[Bluebear]

A tato „primitovnost“ Javy je jedním z důvodů její velké oblíbenosti V podstatě tě donutí psát přehledný kód, kterému rozumí i další programátoři... a to se počítá.

Tady musím zásadně nesouhlasit. Kdyby platilo, že primitivní kód = srozumitelný kód, psaly by se korporátní programy v jazyce Karel (pro později narozené: to je ten jazyk, v němž hlavní příkazy jsou KROK, VLEVO-VBOK, POLOŽ, ZVEDNI a KDYŽ.)

Pokud píšeš složitější algoritmus, tak je primitivní jazyk cesta do pekel. To, co by se ve vyspělém jazyce vešlo na pět řádků, se v primitivním jazyce musí rozložit na dvacet stránek jednoduchých kroků. Ano, ty jednotlivé kroky jsou snadno pochopitelné, ale zkus si přijít na to, co vlastně dělá celý program!

Kromě toho, strašnou prasárnu můžeš napsat i ve velmi primitivním jazyku. Za dřevních dob neuměly tehdejší interpretry BASICu o moc víc než IF, GOTO, LET, READ, RESTORE a dalo se s tím sestavit bludiště, nad kterým by i expert strávil celé dny.

[alblaho]

Já se do té Javy rád strefuju, ale není to špatný, vyloženě "primitivní" jazyk jako assembler. Je to ořezané, paměťově bezpečné C++, což není málo.

Ale faktem je, že Java drží programátora zkrátka v tom smyslu, že se nelze vymanit z jejich konstrukcí (žádná makra, všechno předepsané). Není to jako Lisp (nebo i Perl), kde si člověk nejprve ušije jazyk na míru a pak teprve dělá v tom svém novém jazyce. Proto všechen Javovský kód vypadá skoro stejně a proto je Java v podnikové sféře tak úspěšná.

[podlesh]

Ono je totiž otázka, co si představíme pod pojmem "primitivní".

Ačkoliv to možná zní na první pohled nezvykle, Java je low-level jazyk. Podobně jako v C, kód se jednoduše a přímočaře přeloží do instrukcí. Celá iluze "high-level" vzniká tím, že se jedná o instrukce virtuálního stroje s poměrně bohatými možnostmi (jako je automatická správa paměti). Nicméně Java nabízí jen minimum konstrukcí navíc.

[Marek Bernát]

Alebo ešte lepšie, keď chceme posudzovať jazyk, je dobré si uvedomiť, že polovica moderných jazykov (všetky založené v nejakom zmysle na C a Pascale) je len odrazom Von Neumannovej architektúry a teda silne zviazané s aktuálnym hardvérom (celá syntax týchto jazykov := / * + -, trochu zobecnený JMP, atď len napodobňuje inštrukcie hardvéru). To môže byť samozrejme výhodou, ak človek potrebuje z hardvéru dostať maximum, ale zasa nevýhodou, ak sa snaží abstraktne myslieť a "vysvetliť počítaču" svoje myšlienky. Na rozdiel od takého LISPu, ktorý má v podstate len listy a obrovské možnosti ich manipulácie a ako taký je ten jazyk na hardvére nezávislý a teda skutočne high-level.

[podlesh]

Ano, tak.

[alblaho]

Tenhleten názor a už ho za sebe hlásám do světa. Java je low-level jazyk nad JVM. Zní to provokativně, ale je to pravda. A asi to mám od tebe.

[kkaarreell]

Není to jako Lisp (nebo i Perl), kde si člověk nejprve ušije jazyk na míru

Muzete mi nekdo lehce naznacit, co se tim presne mysli? Aspon nejake klicove slovo, ktere mam vygooglit a nebo jeste lepe nejaky link. Diky.

[Marek Bernát]

Makro

[kkaarreell]

Diky, slo mi sice vic o ten Perl, nicmene chapu to tak, ze je to neco jako makra preprocesoru pouzivana v C? Nebo to umi neco vic?

[Marek Bernát]

Áno, dokáže to ďaleko viac. Skok je asi ako medzi kalkulačkou a programovacím jazykom Makro v C je len #include / #define / #ifdef, čiže preprocesor s pár príkazmi. V Lispe môžete v makre používať celý jazyk. Analógia v C by bola, že môžete používať #for, #if, #while, #struct, #+, #*, atď. Ak viete, aká sú v makrá v C mocná vec a pritom spočívajú len na pár preprocesorových príkazoch, viete si predstaviť, čo sa stane, keď inštrukcie makra rozšírite na celý jazyk? Dostanete nekonečne veľa možností, ktoré nemáte v žiadnom inom jazyku (to je ten skok kalkulačka -> programovací jazyk). Efektívne ste pomocou toho schopný manipulovať AST programu, takže vlastne vytvoriť nový jazyk. A tu je práve vhodný Lisp, lebo jeho syntax spočíva na stromovom zápise (jeho kód je v podstate krajšia verzia XML), takže vďaku tomu sa dá AST pohodlne modifikovať. (btw, jazyky, ktoré majú rovnaký zápis ako reprezentáciu v pamäti sa volajú homoikonické a je to fakt sila). Ako je to presne v Perle neviem. Viem, že majú niečo ako makrá, takže jazyky sa tam budú dať tvoriť tiež, ale keďže Perl nemá stromovú syntax (ala Lisp), tak to bude zrejme menej príjemné.

[mkoubik]

viete si predstaviť, čo sa stane, keď inštrukcie makra rozšírite na celý jazyk? Dostanete nekonečne veľa možností, ktoré nemáte v žiadnom inom jazyku

Jo, vznikne úplně stejně turing-complete jazyk jako to byl předtím a bude mít naprosto stejné možnosti jako např. brainfuck nebo asm.

[Ladicek]

Tak jo, a teď nám ještě povězte, jaký bude rozdíl ve vyjadřovacích schopnostech

[Marek Bernát]

Čože? Turing-complete je prakticky každý jazyk, ale to neznamená, že sa v ňom rovnako dobre programuje (viď napríklad brainf-fuck), takže je to úplne irelevantná vlastnosť pri posudzovaní jazykov, ergo netuším, prečo to sem ťaháte. O čo skutočne ide, je to, ako dobre dokáže jazyk umožniť programátorovi vyjadriť jeho myšlienky a ako veľmi ho núti vtrepať sa do pravidiel daného jazyka. V brainfucku maximálne, v asm trochu menej, v C ešte menej, no a v tom Lispe máte takmer úplnú slobodu. To, čo dokážete vyjadriť je limitované len Vaším intelektom. Hoci zrovna u Vás to asi nebude nijak slávne...

[xkucf03]

V C++ nejsou ta makra až tak bezmocná – viz např. signály a sloty v Qt.

Tím se z jazyka jiný jazyk než byl původně (C++). U toho Qt to jde ještě akceptovat, protože je to dost rozšířená (a veřejně dostupná) knihovna, ale u malých a soukromých projektů mi takové přetváření jazyka v něco jiného přijde spíš na škodu.

[JS]

Akorat ze signaly a sloty se v Qt neresi makry, ale maji vlastni C++ preprocesor. Takze to jste trochu ustrelil. V Common Lispu by zadny novy preprocesor na takovou vec nebyl potreba.

 

[xkucf03]

Mají vlastní preprocesor (MOC), ale ten se řídí  Q_OBJECT makrem.

[Marek Bernát]

To je ale presne to, o čom hovorím. V primitívnom jazyku si človek musí napísať interpreter/kompilátor/preprocesor (alebo aspoň primitívny string-replace), ktorý je _mimo_ jazyka samotného a snaží sa doplniť jeho chýbajúcu funkcionalitu.

[JS]

Jenom doplnim Marka: Ten jejich prepocesor MOC musi minimalne znat syntaxi tridy. To Lispovy interpret nemusi. Rozhodne MOC neni standardni C preprocesor.

[Marek Bernát]

Obávam sa, že nerozumiem. C++ má iný preprocesor ako C, s väčšou sadou príkazov?

Samozrejme, to je predsa účel. Písať GUI v C++ (alebo akomkoľvek inom general-purpose jazyku) je totiž hlúposť. Preto je rozumné zostrojiť domain-specific jazyk. Tak sa postupuje úplne bežne. Rozdiel medzi Lispom a ostatnými jazykmi je však v tom, že v Lispe si človek ten DSL vytvorí pohodlne a rýchlo, v bežných jazykoch musíš na to napísať nejaký skriptovací jazyk a interpreter/kompilátor, čo obvykle nikomu nestojí za námahu a tak sa použije general-purpose jazyk aj tam, kde je úplne nevhodný.

To ale nie je pretváranie jazyka. Jazyk je to stále ten istý, len rozširuješ jeho možnosti. To je ako povedať, že ked zadefinuješ novú funkciu, tak si zmenil jazyk, lebo základ bol len štandardná knižnica a všetko navyše je už iný jazyk. Ako keby bolo niečo zlé na tom pridávať nové funkcie; pritom s makrami je to rovnaké, len to ide ešte o krok ďalej Ale chápem, že máš problém sa zmieriť s touto rozšíriteľnosťou jazykov. Možno časom ťa tiež osvieti Lispovské poznanie Len tak pre zaujímavosť, ak budeš mať čas, tak si prečítaj tento článok. Je od človeka, ktorý pôvodne tiež nechápal Lisp a používal len C++/Java/C#, ale nakoniec Lisp pochopil, tak sa teraz snaží jeho výhody (na pekných príkladoch ako XML + Ant, čo je zakuklená primitívna verzia Lispu z istého pohľadu). Možno ti to niečo povie, možno nie, ale daj tomu šancu

[Pavel Křivánek]

Neznáš nějaký příklad, který by přesvědčil o výhodnosti lispovských maker i smalltalkera? Pokud možno takový, který vyváží následné komplikace s laděním apod.

[Marek Bernát]

Bohužiaľ nepoznám Smalltalk dostatočne do hĺbky na to, aby som vedel posúdiť, či sa v Smalltalku dajú robiť všetky veci, ktoré sa dajú aj v Lispe. Takže sa Vás proste spýtam: je možné nejako modifikovať AST za behu? Dajú sa rozumne vytvoriť DSL? Nezväzuje ten jazyk príliš svojou syntaxou? Na všetky tie otázky je v Lispe pozitívna odpoveď, tak ma zaujíma, jak je to v smalltalku. Možno až budem vedieť odpoveď na tieto otázky v Smalltalku, tak sa mi podarí skonštruovať nejaký rozumný príklad. Viem, že v Smalltalku sa nejak dá metaprogramovať, ale neštudoval som to takmer vôbec a nikdy som to nepoužil. Rozhodne to chcem tiež časom napraviť, tak keď tak by som Vás poprosil o nejaké hinty + knihy/články.

[Pavel Křivánek]

Takže sa Vás proste spýtam: je možné nejako modifikovať AST za behu?

Na tuto otázku je odpověď komplikovanější, protože Smalltalk je jazyk, kde zdrojové kódy hrají druhořadou roli a má smysl o nich hovořit až na úrovni jednotlivých metod. Se zdrojovými texty metod se pracuje víceméně atomicky a jsou na třídách do značné miry nězávislé. Ale vzhledem k volnosti nakládání s překladačem či kompilovanými metodami a faktu, že přepis Smalltalku do bytekódu je poměrně přímočarý (včetně snadné dekompilace), nebývájí úpravy či analýza kódu metod problém. Bez toho by ostatně Smalltalk těžko tvořil inkrementální prostředí.

Dajú sa rozumne vytvoriť DSL?

Dají. Nejrozšířenějším příkladem je asi smalltalkovský zápis HTML v Seaside. Navíc díky třídě Behavior lze např. vytvářet anonymní třídy (to lze pro DSL s výhodou použít, ale v praxi jsem to viděl asi jen při vytváření prototypové dědičnosti)

Nezväzuje ten jazyk príliš svojou syntaxou?

Výsledek je asi o něco ukecanější než v Lispu, protože většinou tvoří základ volání nějaké zprávy, ale díky literálům pro pole, symboly, výrazová pole a bloky se dokáže v tomto Lispu celkem přiblížit.

"Školní" příklady maker v Lispu, které jsem viděl, se používaly především pro tvorbu vlastních řídících struktur, DSL, či některé manipulace, které ve Smalltalku nemají valný význam. Proto jsem se raději ptám.

 

[Marek Bernát]

Njn, tiež mi to došlo. Takže inak. V Lispe je základom Sexp, všetko je Sexp aj AST sú Sexpy a Lisp ponúka bohaté možnosti ich manipulácie. V Smalltalku je všetko objekt, takže aj AST je objekt (v nejakom zobecnenom zmysle?) a Smalltalk ponúka bohaté možnosti manipulácie objektov (?). Tipujem, že toto je všetko pravda, takže v tomto ohľade je asi Lisp a Smalltalk ekvivalentný.

To som si aj myslel. Pekné. Fakt sa s tým musím zasa pohrať, až bude čas. V seaside som si kedysi vytvoril jednu miniaplikáciu, ale rozhodne som tomu nerozumel, proste som to použil, lebo v Smalltalku sa programuje fakt krásne. OOP rulez

Nič iné ako DSL a riadiace štruktúry (čo sú tiež svojho druhu DSL) ma nenapadá. Ale nie som žiadny expert a rád by som počul nejakého odborníka na CL a zároveň Smalltalk. Aj keď pravdepodobnosť, že sa tu niekto taký vyskytuje je asi nulová

Ale jeden príklad môžeme uvážiť. Ten najklasickejší, priamo zo štandardnej knižnice: LOOP makro. V Lispe som schopný napísať toto:

;;; druhé mocniny nepárnych čísel


(loop

  for i in numbers

  summing (if (oddp i) (* i i) 0))

(Nerozoberajme teraz, že rovnaká vec je vo funkcionálnom programovaní one-liner, chcem len ilustrovať niektoré veci). Vo vnútri loop môžem takto používať ľubovoľnú syntax (vzhľadom k bežej prefixovej syntaxi lispu), ktorá sa mi zrovna hodí do krámu a zároveň aj tú lispovskú. Pokojne by som mohol spraviť niečo ako

(pascal

  i := 1 ;

  k := 1 ;

  n := 10 ;


  repeat

    k := (* k i) ;

    i := (+ i 1) ;

  until (>= i 10))

, teda zmiešanie ľubovoľného jazyka s ľubovoľnou syntaxou a Lispu (má to jeden drobný nedostatok a to ten, že lexémy treba oddeľovať medzerami. Ale to je pri DSL a dobrom návrhu jeho syntaxe aj tak nepodstatné).

Táto voľnosť v syntaxi sa môže zdať nepodstatná (ostatne, celý zvyšok Lispu je prefixový), ale pri DSL to môže podstatne uľahčiť prácu.

Takže celkovo, smalltalk vyzerá ako viacmenej ekvivalentný Lispu, čo sa metaprogramovania týka, ale predefinovanie syntaxe vyzerá byť problém. Toto by ma obzvlášť trápilo pri zápise matematiky v Smalltalku, kde posielanie správ je trochu cez ruku, keď chce človek vyjadriť niečo ako (a + b) * (c + d). V Lispe si proste napíšem makro (math), ktoré bude fungovať ako kalkulačka a som v suchu. V praxi samozrejme takéto veci nemusia zavážiť (málokto potrebuje písať toľko matematiky v kóde, aby potreboval kalkulačku), takže sa až tak nečudujem, že Vám makrá nechýbajú, vzhľadom k ostatným veciam, ktoré Smalltalku ponúka.

[Pavel Křivánek]

Aby nedošlo k nějakým nedorozuměním. Ve Smalltalku až po úroveň metod nelze nemá smysl hovořit o AST, vše po tuto úroveň jsou libovolně manipulovatelné objekty. Samotné metody jsou pole referencující na další objekty, z nichž část jsou čísla reprezentující bytekód. Zdrojový kód není přímou součástí metody, metody pouze _mohou_ odkazovat na svůj zdrojový kód, který se uchovává externě. Přesto i bez přítomných zdrojových kódů zůstávají všechny vlastnosti Smalltalku zachovány včetně možnosti si smalltalkovský kód metod prohlížet, modofikovat a rozšiřovat. AST pro metody existuje pouze v okamžiku překladu každé jednotlivé metody. Stejně jako v Lispu i ve Smalltalku se nerozlišuje kód a data, ale zcela jiným způsobem. Lisp je lexikálně orientovaný.

On je také jistý rozdíl mezi tím, co Smalltalk umožňuje, a tím, co se skutečně používá. Protože jakmile začnete používat věci jako anonymní třídy, připravíte se o komfortní podporu IDE, pokud si ho nepřiohnete

První verze Smalltalku měly co se úpravy syntaxe jazyka širší možnosti, než ten současný, ale jeho autoři raději zvolili cestu, která dovoluje jednodušší a uniformní přístup a tedy snáze vybudovat inkrementální explorativní systém. Takže, abych navázal na jinou část této diskuse, upřednostnili IDE před makry

 

[Marek Bernát]

Aha, ďakujem za upresnenie. Príliš som sa snažil napasovať Lispovské myšlienky na smalltalk

To je fakt, asi je dobré sa zamerať skôr na tú praktickú stránku veci, ako na to, či nejaký jazyk niečo formálne podporuje. Aj keď kto vie. Možno časom sa zmenia trendy a začnú sa používať aj tie momentálne nepoužívané vlastnosti a vtedy budú ľudia radi, že tam sú

No, to je určite jedna z možných ciest. A určite dobrá pre skúseného smalltalkera, ale kým si začiatočník zvykne v tom IDE a pochopí, že to na niečo môže byť dobré, tak asi musí prejsť dlhá doba (súdim teraz podľa svojich skúseností -- pár týždňov som sa so Squeakom hral -- a podľa niektorých diskusií o smalltalku ). Ničmenej, aspoň v mojom prípade viem, že chcem Smalltalk poriadne pochopiť. Je na poradovníku hneď po Lispe

Btw, takže čo sa týka tých výhod makier pre Smalltalkera, keď sa vrátime k tým pôvodným témam. Riadiace konštrukcie sa v smalltalku dajú pohodlne pridať pomocou metód, takže tam je nam to na nič. Ďalej sú vhodné ako abstrakcia často používaných techník, ale tam si asi smalltalk opäť vystačí s abstrakciou na úrovni objektov a správ. Takže v podstate budú hlavnou výhodou asi tie DSL so špeciálnou syntaxou, čo môže a nemusí byť dostatočný dôvod na používanie makier, v závislosti na type problému.

[JS]

Umi to vic, a o dost. Pokud umite Python, doporucuji vam vrele knizku Practical Common Lisp.

Dlouho jsem makra v Lispu nepovazoval za dobrou vec, protoze mi to prislo nebezpecne (kvuli citelnosti). Ale v realu to neni mene citelne nez napsat si vlastni funkci. A postupem casu jsem zjistil, ze mi to treba v Pythonu makra dost chybi.

K te knizce jsem se ale dostal pres jinou zajimavou vlastnost Common Lispu - signaly. Ale zatim bohuzel CL neumim natolik, abych tyto veci (makra, signaly a CLOS) ovladal, ale z toho, co jsem zatim o nich slysel, jsou velmi uzitecne.

[deda.jabko]

Zrovna o uzávěrech tu byl nedávno pěkný flame. Pochopit je není moc těžké, ale podle mého jsou právě příkladem toho, jak se dá kód snadno ohackovat a „elegantně zkrátit“ za cenu snížení znovupoužitelnosti a budoucího refaktoringu.

coze? proboha! kam ten svet speje!

[Marek Bernát]

Presne moje myšlienky. Kiež by sa informatika vrátila o 30--50 rokov späť, kedy v nej skutočne pracovali len ľudia, ktorí jej aspoň trochu rozumeli

[Ladicek]

Jako jeden z klíčových účastníků zmíněného flamu ( ) bych ho zde zkusil shrnout do jedné věty: callbacky jsou extrémně jednoduchý a přitom velice mocný architektonický vzor, jenže Java přímo odrazuje od jejich používání. Nemá to nic společného se znovupoužitelností ani refaktoringem ani ničím jiným, protože už javovské anonymní vnitřní třídy samy o sobě jsou téměř plnohodnotnými lexikálními uzávěry. Jenže s poměrem užitečný kód versus balast většinou asi tak 1:1.

Omlouvám se za off topic a slibuji, že pokud se pod tímto příspěvkem někdo pokusí rozpoutat pokračování zmíněného flamu, nebudu na něj reagovat

[JS]

Vzdycky me pobavi, kdyz Javovi programatori zduvodnuji 3-4x delsi kod tim, ze v budoucnu bude snazsi ho spravovat a refaktorovat. Nehlede na to, ze refaktoring jako takovy je vetsinou prave obchazeni problemu spojenych s timto "snadneji spravovatelnym" stylem programovani.

Obecne cim dal vice dochazim k zaveru, ze se zkratka nevyplati predpokladat neco o budoucnosti. Pokud opravdu nevite, ze neco v budoucnosti budete potrebovat, snazit se to dat do navrhu je podle me holy nesmysl. Vetsinou to tam totiz bude prekazet vice nez to bude k uzitku.

U nas ve firme mohu srovnavat programy stare 30 let v mainframe assembleru a COBOLu, a programy stare 10 let v Jave. Hadejte, ktere se vic prepisuji? Ty v Jave. A to pres vsechny nesmyslne reci o tom, jak je Java vic maintainable.

 

[Jakub Lucký]

Není to tím, že se do Cobolu a ASM nikomu nechce?

[podlesh]

Samozřejmě, COBOL aplikace se přepisují (pokud se přepisují) v Javě nebo .NET

Většinou to ovšem již není potřeba, protože 30 let stará COBOL aplikace již byla přepsána před dvaceti lety. Je to docela normální vývoj - až při provozu aplikace se většinou přijde na to, co vlastně má opravdu dělat a jak má být dimenzovaná.

[JS]

Kupodivu, my do nekterych takovych aplikaci dodavame i novou funkcionalitu. Takze to neni tak, ze by to uz vsechno bylo napsane. A pak mate samozrejme vyvoj platformy (nektere veci v systemu zastaravaji, nektere se meni) a opravy chyb. Pokud to zakaznik zaplati - to neni otazka chce/nechce, jak pise Jakub.

Veci se prepisuji IMHO tehdy, pokud platforma prestava existovat. A to mainframe neprestava, takze neni duvod aplikace prepisovat.

Ale pointa meho prispevku je v necem jinem. Programy v COBOLu a ASM, s kterymi mam tu cest (a spis s temi v ASM), jsou na jednu stranu strasne spagety, na druhou stranu jsou pomerne dost primitivni (vsechno tam najdete, neni to jedna vrstva frameworku nad jinou). Takze se spravuji v necem hure, v necem lepe. A jak je videt, jde to, i kdyz to neni vzdycky uplne pekny pohled.

Podle me se zkratka "maintainovatelnost" Javy strasne precenuje. Kdyz vidim, jake veci menime v tech programech starych 30 let, to neni neco, s cim mohl navrhar od zacatku pocitat. Pokud mate nejakou strukturu treba trid, tak takovahle zmena ji vzdycky strasne rozboura. Proto si opravdu kladu otazku, zda ma smysl navrhovat tridy tak, aby byly "znovupouzitelne", pokud to nove pouziti v budoucnu nikdy neprijde. Pak to je spis opruz navic s takovym navrhem pracovat.

Evoluce je neuprosna. Pokud ji chcete celit (a mit vsechno vzdy krasne navrzene), bude vas to stat velke usili navic. Proto se ty programy v Jave tak prepisuji, protoze tem lidem nedochazi, ze osklive spagety nejsou zase az tak spatna vec.

[JS]

A jeste jsem chtel podotknout, protoze se ty programy v Jave tak casto prepisuji, dusledkem je paradox, ze tento jazyk, ktery je pry vic udrzovatelny, na ukor velikosti kodu, pak spotrebovava vice usili, nez jazyky, ktere tak udrzovatelne nejsou, ale zase se neprepisuji. Takze kde je potom ta udrzovatelnost Javy, kdyz to stoji vice usili?

[xkucf03]

Např. před rokem jsem předělával jeden web, původní byl v Javě a nový taky, ale vypadal úplně jinak, grafiku dělala jiná firma, použil se úplně jiný šablonovací systém a vůbec architektura toho systému se dělala prakticky znova (požadavek byl prostě napsat nový web, ne oprašovat ten starý). Přesto se daly některé komponenty použít a díky refaktoringu se daly napasovat do toho nového systému. V tom novém webu jsme použili více vrstev a EJB. Takže až si za pár let někdo vzpomene, že firma nutně potřebuje nový web, předělá se jen ten xicht, případně ta redakční část systému, ale ty komponenty v pozadí, které dělají nějakou byznys logiku a pracují s daty se mohou klidně zachovat.

Ovšem aby tohle fungovalo, je nutným přepodkladem, aby zákazník měl zdrojáky od své aplikace – a ne si ji nechal dělat od nějakého chytráka, který si zdrojáky nechá (bojí se přece, aby mu jeho úžasnou a geniální práci někdo nezcizil), ale po letech už nejsou a musí se to psát znova tak jako tak

[JS]

Jiste. Ovsem to same dokazete i s rozumne modularne napsanym programem v COBOLu nebo v assembleru (jako ze ty, co jsem ja videl, takove jsou). To, co rikate, totiz nijak nesouvisi s OOP, a jeho udajnymi vyhodami, co se tyka znovupouzitelnosti.

[dad]

takze jsem se konecne dostali ke korenu veci - modularita a s ni spojena delba prace.

O tom, co je modularita by se dalo diskutovat donekonecna, faktem zustava, ze nejvetsi predpoklady vytvaret neco modularne maji strojni inzenyri, protoze jen v tomto oboru se neco takoveho vubec praktikuje (castecne stavari, elektro uz minimalne). A z tech vsech strojnich inzenyru je nakonec jen ca. 10% schopno tvorit modularne. A proto se musime smirit jeste na dost dlouhou dobu se softwarovou krizi a s podobnymi usmevnymi prispevky na netu.

Je ovsem usmevne pozorovat, jak se kazda generace stale a znova upina k nejake 'metodice' v nadeji, ze se pri vyvoji bude moci obejit bez tech par podivinu, kteri tu 'modularitu' maji proste v krvi.

[xkucf03]

Informatika je dnes ale samostatný obor a nepotřebuje si vypůjčovat odborníky z řad strojařů nebo stavařů – to modulární myšlení by mělo být vlastní samotným informatikům (ale neříkám, že tomu tak je, např. většina analytiků, které jsem poznal byli břídilové ).

[podlesh]

Jistě, když je to dobře napsané.

Jinak báječné výhody OOP ohledně znovupoužitelnosti je mýtus z devadesátých let, tomu ještě někdo dnes věří? Nějaké výhody tam opravdu jsou, ale ani zdaleka tak výrazné.

[Marek Bernát]

A máš na mysli OOP všeobecne, alebo OOP ako je implementované a ako sa praktikuje v Jave? To sú totiž dve rozdielne veci, ako je vidieť napríklad z toho, že (ak ma pamäť neklame) Squeak image obsahuje stále niektoré objekty z 80. rokov z nejakého pôvodného smalltalku a veselo sa s tým pracuje (a myslím skutočne objekty, ktoré žijú už 30 rokov, nie len triedy ).

Tie devätdesiate roky skôr naznačujú tú Javu. (Pravé) OOP totiž vzniklo v 60. a v podstate sa vyvíjalo tak do 80.

[podlesh]

Ano, myslím OOP všeobecně, což zahrnuje i OOP v Javě. Teorie zněla (zní) že už základní principy objektového přístupu povedou k lepší modulárnosti a znovupoužitelnosti kódu. Tedy i když se aplikují na procedurální jazyky - a tedy že vůbec není nutný funkcionální přístup. Tím vznikla vlna nadšení, na kterou Sun ve správný čas naskočil se speciálně vytvořeným jazykem (tedy je to opačně než zde mnoho lidí naznačuje, Sun tu vlnu nevyrobil z ničeho).

V praxi se ale ukázalo, že ty výhody nejsou zas tak slavné.

(Žijící objekty ve Smalltalku jsou myslím trochu mimo téma. Bavíme se pořád o psaní kódu.)

Tie devätdesiate roky skôr naznačujú tú Javu. (Pravé) OOP totiž vzniklo v 60. a v podstate sa vyvíjalo tak do 80.

No, 60. je trochu moc, pokud vím tak až 70.

[Marek Bernát]

Ok.

V Java praxi možno. Obecne (Smalltalk) by som to netvrdil.

Nie sú mimo tému. Ide o to, že ešte aj dnes sa píše a modifikuje OOP kód 30 rokov starý a dokonca to ide až tak ďaleko, že nie len triedy sú 30 rokov staré, ale dokonca aj samotné objekty (čo je ešte o úroveň ďalej)

60.

[podlesh]

Veci se prepisuji IMHO tehdy, pokud platforma prestava existovat. A to mainframe neprestava, takze neni duvod aplikace prepisovat.

Věci se přepisují, když někdo rozhodne že se přepíší. Důvody mohou být různé a často je přepis zcela zbytečný.

Ale pointa meho prispevku je v necem jinem. Programy v COBOLu a ASM, s kterymi mam tu cest (a spis s temi v ASM), jsou na jednu stranu strasne spagety, na druhou stranu jsou pomerne dost primitivni (vsechno tam najdete, neni to jedna vrstva frameworku nad jinou). Takze se spravuji v necem hure, v necem lepe. A jak je videt, jde to, i kdyz to neni vzdycky uplne pekny pohled.

Samozřejmě že to jde, když to někdo udělá.

Každopádně, pointa toho příspěvku je, že to máte celé postavené na hlavu (jako obvykle). Argument s "maintainovatelností" Javy bývá používán při porovnávání s vyššími jazyky, tam se má pak smysl bavit o technické stránce věci. Pokud někdo porovnává udržovatelnost Javy a COBOLu jako jazyků, po technické stránce, tak by mě ty argumenty zajímaly. Ještě jsem to neviděl.

Při porovnání s COBOLem to má smysl jen v jediném, netechnickém ohledu: najít programátora v COBOLu je nesrovnatelně těžší než najít programátora v Javě. A to i když se omezíme jen na ty opravdu dobré.

Podle me se zkratka "maintainovatelnost" Javy strasne precenuje. Kdyz vidim, jake veci menime v tech programech starych 30 let, to neni neco, s cim mohl navrhar od zacatku pocitat. Pokud mate nejakou strukturu treba trid, tak takovahle zmena ji vzdycky strasne rozboura. Proto si opravdu kladu otazku, zda ma smysl navrhovat tridy tak, aby byly "znovupouzitelne", pokud to nove pouziti v budoucnu nikdy neprijde. Pak to je spis opruz navic s takovym navrhem pracovat.

Jistě, tomu se říká overengineering a skutečně udržovatelnost zhoršuje (protože dost zhoršuje přehlednost a komplikuje změny). Nic nového pod sluncem. Problém se hlavně zhoršuje, když se někdo drží různých moudrých rad o rozdělení vrstev a nebo "doporučených návrhových vzorů" (zvláště s EJB, to se Sunu opravdu "podařilo"). Tomu se zase říká cargo cult programming.

Evoluce je neuprosna. Pokud ji chcete celit (a mit vsechno vzdy krasne navrzene), bude vas to stat velke usili navic. Proto se ty programy v Jave tak prepisuji, protoze tem lidem nedochazi, ze osklive spagety nejsou zase az tak spatna vec.

Nesmysl, právě naopak. Programy v Javě se přepisují právě proto že se lidé drží toho, že ošklivé špagety jsou špatná věc. A proto, když po čase špagetovost dosáhne určité úrovně, deklarují projekt jako "špatně navržený" a "nutný k přepsání".

Jenomže to je honba za přeludem, v každém programu který se udržuje a upravuje po delší dobu (= doba několikanásobně delší než doba vývoje) se postupně vytváří různé vředy (ať již to jsou "špagety", mrtvé části kódu, atd). Rozumný postoj je takový, že špatná udržovatelnost není důvodem k přepsání. Důvodem k přepsání jsou závažné problémy s výkonem nebo zásadní změna požadované funkcionality v průběhu životnosti programu (to se někdy chybně považuje za "špatnou udržovatelnost").

[JS]

Nevim, proc mi tvrdite, jak se mnou nesouhlasite, kdyz vlastne pak stejne rikate totez. Souhlasim s vami, a je to zjevne uz z meho predchoziho prispevku.

Kazdopadne, abych na vas navazal. Ja povazuji dost veci v Jave za prave takovy overengineering, o kterem mluvite. Tedy, fakticky to udrzovatelnost zhorsuje, protoze to prekazi zmenam.

[podlesh]

Nevim, proc mi tvrdite, jak se mnou nesouhlasite, kdyz vlastne pak stejne rikate totez. Souhlasim s vami, a je to zjevne uz z meho predchoziho prispevku.

No, moc zjevné to není. Jako obvykle se zcela míjíme v tom, co není řečeno a kde je pointa.

Kazdopadne, abych na vas navazal. Ja povazuji dost veci v Jave za prave takovy overengineering, o kterem mluvite. Tedy, fakticky to udrzovatelnost zhorsuje, protoze to prekazi zmenam.

Konkrétně v Javě, nebo v aplikacích co tam máte? Samozřejmě, z praktického hlediska to není rozdíl...

Spíš je zajímavá, otázka, zda by se to zlepšilo výměnou za jiný jazyk, řekněme třeba LISP. Když si představím, že to budou zase dělat stejní lidé...

[JS]

Aplikace, co mame ve firme, nejsou napsane a navrzene az tak spatne, na to, ze je to assembler a na dobu jejich vzniku. Ono ani Javove aplikace nejsou vesmes napsane az tak spatne. Lide vetsinou nejsou az tak spatni, spis nastroje, ktere pouzivaji, nejsou vzdycky optimalni (z ruznych, vetsinou pochopitelnych, duvodu). A nastroje ovlivnuji cely system. 

Napriklad na mainframu se programuje i dnes v assembleru proto, ze veskera systemova API jsou v assembleru. IBM nema prilis motivaci tento stav zmenit, a tedy ji nemaji ani programatori. Ale neni to o tom, ze by byli spatni - to je proste realita. Podobne je to i treba s Javou a XML.

Vymenou za Lisp by se to mozna zlepsilo. Ale holt programatorska kultura (nebo lepe receno kultura pouzivanych nastroju) je jina.

[podlesh]

No, já právě nejsem takový optimista. Už v té Javě je vidět, že ta kultura je z velké části ovlivněná dřívějšími kulturami v C (a C++), přičemž se třeba mohlo jednat o pozitivní věci. Pak se "náhodně" nabalily jiné věci jako je třeba to XML (které v podstatě nemá s Javou nic společného).

Proto si myslím že výměnou za LISP by tolik nevyřešila. Vznikla by nová kultura s novými problémy.

[podlesh]

Ještě bych doplnil jeden klasický citát: Opravdový programátor dokáže psát FORTRANovský program v jakémkoliv jazyce.

PS: Jednoho takového jsem potkal, to bylo peklo po něm rozmotat. Hlavně si pamatovat, v kde jsou použity pro reprezentaci true kladné hodnoty, v kde záporné a kde nula.

[deda.jabko]

I když uznávám, že v dynamických jazycích (Python, Ruby a.. ano, Perl) je možné dosáhnout zkrácení kódu za cenu špinavých triků (přes eval a spol).

kdyby python, ruby a spol. obsahoval rozumne makra, nebylo potreba ani ,,spinavych'' triku.

Proto korporátní Java nic takového nemá a takový primitivní jazyk je potřeba využívat naplno.

z tohoto pohledu je java neuveritelne impotentni jazyk. a jeji nedostatky se snazi spousta lidi schovat za nablyskane IDE. staci si vzit takovou stupiditu jako jsou getter&setters. pokud ma clovek jenom jeden blby objekt s par hodnotama, tak bud se muze otravovat s tim to vsechno vypisovat nebo muze pouzit nejaky generator... krasny priklad nesmyslne redundance povysene na prumyslovy standard.

[xkucf03]

Můžeš také použít veřejné proměnné třídy, ke kterým se dá přistupovat bez getterů a setterů. Sice se to nedoporučuje, ale pokud to tak chceš, Java ti v tom nebrání:

public class MojeTrida {
    public String jmeno;
    public int pocet;
    public String popis;
    public Object nejakyObjekt;

}

Akorát se tím připravíš o zapouzdření a možnost přidat např. validaci (např. číslo musí být větší než nula). Ale pokud takové věci nepotřebuješ, budiž. V čem tě Java omezuje?

A taky bych rád viděl jazyk, kde můžu začít psát takhle jednoduše (viz MojeTrida) a časem k tomu můžu dopsat ty gettery a settery, které mi umožní přidat další funkcionalitu – ale (a to je důležité) aniž bych musel měnit okolní kód – pokud jsem tedy přistupoval k hodnotám jako .jmeno, nechci to teď přepisovat na .getJmeno(). Jde to někde? Něco na tenhe způsob jsem viděl v Eiffelu (ale syntaxe byla dost podivná).

[Bluebear]

A taky bych rád viděl jazyk, kde můžu začít psát takhle jednoduše (viz MojeTrida) a časem k tomu můžu dopsat ty gettery a settery, které mi umožní přidat další funkcionalitu – ale (a to je důležité) aniž bych musel měnit okolní kód – pokud jsem tedy přistupoval k hodnotám jako .jmeno, nechci to teď přepisovat na .getJmeno(). Jde to někde?

Rozhodně to jde v Pythonu, a tipuji, že i v Ruby a dalších jazycích této generace.

[Josef Kufner]

V PHP to jde taky a dokonce několika způsoby.

[vlastikroot]

Jakymi dalsimi krome __get a __set ? Jen se ptam, zajima me to.

[Josef Kufner]

Další možností je třeba ArrayObject a jeho offsetSet/offsetGet – objekt se pak chová jako pole, tj. funguje operátor []. Další možností je __call(), kdy si můžeš napsat "virtuální" getter/setter, který se zavolá, když ten správný nebude definovaný.

[xkucf03]

Jenže PHP je prasárna – to bych si v Javě mohl udělat HashMapu <String, Object> u které bych si překryl metody get(String klíč) a put(String klíč, Object hodnota) a dosáhl bych stejného výsledku. Tím bych degradoval Javu na úroveň PHP a připravil se o výhodu kontroly v době kompilace.

[Josef Kufner]

To není prasárna, tomu se říká dynamická typová kontrola

[xkucf03]

No právě :-P

[benzin]

I Delphi to podporuj jako "property" modifikator kde se nastavi odkud se nacita a kam se uklada. Bud primo do promene nebo pres funkci resp. proceduru.

[...............23]

Také niečo má tuším napríklad C#

[xkucf03]

Jenže v C# to nedopadne o moc líp než v Javě – mají tam properties.

[alblaho]

Napsat property je stejná práce jako napsat getter+setter. Vtip je v tom, že to u C# nemusíš dělat dokud to opravdu nepotřebuješ. V Javě je to buď nebezpečný public přístup navždy, nebo otravný a ve většině případů zbytečný get/set hned od začátku.

[Leoš Literák]

Kdyz mas dobre IDE, tak si v Jave vygenerujes gettery a settery jednou klavesovou zkratkou. Pak nejvice 'zdrzuje' psani javadocu.

[Marek Bernát]

Jak typické, každý druhý argument v prospech Javy je, že v IDE sa to dá ľahko. Jasné, že sa to dá. Keď už chceme používať takéto argumenty, tak ja si napíšem kompilátor LISPu do Javy a jéje, ten mi vygeneruje javovský kód a nebudem musieť písať sám ani riadok Javovské balastu a všetko bude super. Lenže je jasné, že vo výsledku už budem programovať v LISPe a nie Jave, tak isto ako Vy programuje v IDE a nie v Jave

[Leoš Literák]

Co je spatneho na pouzivani prostredku, ktere mi zjednodusuji zivot? Jsem snad horsi programator, kdyz si zapamatuji klavesovou zkratku, ktera mi vygeneruje kus kodu podle sablony? Algoritmy to za mne nevymysli.

[Marek Bernát]

To nebol argument proti Vám, ale proti Jave

[happy barney]

horší programátor? podľa mňa áno. IMHO je rozdiel medzi wizardom na generovanie kódu v tvare:

class AAA {
  private XYZ name;
  /* tony iného kódu */
String get_name () { return self.name };
String set_name (String n) { return self.name = n };
...

a niečím na spôsob:

class AAA {
  private XYZ aaa :with_get_set;
};

btw, prečo horší? pretože obmedzujete svoje myslenie tak, aby ste sa vtrepali do mantinelov svojho nástroja (ktorého schopnosti boli asi prispôsobované schopnostiam štandardného managera ).

[Leoš Literák]

To je co za jazyk? C#?

[happy barney]

pseudojazyk, demonštrácia myšlienky (dá sa rôznymi spôsobmi, v C++ by to dokonca aj skvele vyzeralo, v Perli by to bolo dokonca aj čitateľné ...)

[xkucf03]

OK, zkus napsat v LISPu portál jako je Ábíčko

[Marek Bernát]

To má byť nejaký argument? V LISPe nie je problém podobný program napísať, dokonca oveľa pohodlnejšie ako v Jave. A ak by som fakt nemal čo robiť najbližšíčh desať rokov (ábičko má koľko presne?) a chcelo by sa mi venovať písaniu aplikácií pre web, tak ti ho pokojne napíšem

[Ivan]

 Nedavno jsem potreboval v LISPu neco udelat. Kontretne se jednalo emacs balik pro podporu edistace PL/SQL zdrojaku. Ten modul vzniknul pomoci copy&paste z modulu pro ADA a ten zase vzniknul z modulu pro Pascal. Zadna sranda to nebyla, mel jsem problem se tom nejak zorientovat, LISP nema jmenne prostory a prehlednost kodu zavisi na dodrzovani jmennych konvenci. Behem jedno dne jsem musel spustit grep asi milionkrat. Emacs bohuzel nema prostredky jak vam pomoci s orientaci v kodu.

 

 

[Marek Bernát]

Človeče, spamätajte sa trochu. To, že neovládate Lisp ani Emacs, neznamená, že sú to zlé veci Lisp menové priestory nemá, pretože Lisp nie je jazyk Ale ak už sa bavíme o konkrétnom dialekte, tak Common Lisp má balíky (defpackage) Pre Emacs existuje mód Slime, ktorý má dokonalé prostriedky na orientáciu v kóde (a nielen to, ďalej inšpekciu a kompiláciu sexpov, dopĺňanie funkcií/makier/premenných, a mnoho mnoho ďalšieho). Odporúčam najprv sa niečo naučiť a až potom hovoriť

[xkucf03]

njn, někomu usnadňují život makra, někomu IDE. V čem je problém?

(a o výkon tu nejde, dnes má přeci každý programátor dost výkonný počítač, aby na něm IDE provozoval)

[Marek Bernát]

Problém nie je nikde Len by ma zaujímalo, či si schopný si to IDE poriadne rozšíriť (až na úroveň makier, teda metaprogramovania), keď to budeš potrebovať.

O výkon rozhodne nejde. Ide o to, že Java asi nie je dosť dobrý jazyk po niektorých stránkach, keď je každý druhý argument obhajujúci Javu "s IDE to ide" (pun intended). Ale o tom sme sa už bavili v minulom flejme, nemá zmysel to tu opakovať.

[xkucf03]

IDE si můžeš rozšířit pomocí pluginů, pro Netbeans a Eclipse jich existují spousty a můžeš si snadno napsat vlastní, případně ten zdroják můžeš před kompilací prohnat přes nějaký preprocesor, což ti ty makra obstará i v Javě. Také můžeš použít JSP, což ti umožní snadno vytvářet webové stránky, aniž bys to musel psát v jazyce Java (do ní se to přeloží až dodatečně samo, jako servlet).

BTW: jsem rád, že jsi se nesnažil argumentovat tím, že někdo ten program překládá na nějakém starém serveru, kde si IDE spustit nemůže – ty by byl pěkně hloupý argument :-)

[Marek Bernát]

Tak to môže byť ok. Java + dobré IDE je možno to, čo si ja predstavujem pod dobrým jazykom (ktorý to však má všetko v jednom v nejakom zmysle). Btw, napríklad Lisp je bez dobrého IDE tiež nepoužiteľný, ale z úplne iných dôvodov ako Java. Jednak potrebuje indentáciu, bez toho nie je čitateľný (dôsledok neprítomnosti syntaxe, ale indentáciu potrebuje asi každý jazyk) a ďalej kvôli spôsobu REPL (read-eval-print) interaktívneho vývoja, kedy je dobré dynamicky kompilovať/vyšetrovať/loadovať kód.

JSP je samozrejme jeden z mnohých príkladov DSL. V Jave na to treba ďalší kompilátor, v Lispe stačí makro a navyše má človek väčšiu kontrolu nad všetkým. Ale to zjednodušujem, záleží od problému. Dôležité je už to, že je človek schopný rozoznať potrebu DSL a nesnaží sa produkovať HTML priamo v Jave (čo by bolo vskutku desivé).

[Ladicek]

Ono to s těmi makry a DSL asi nebude tak žhavé. Žádné lispové makro jsem v životě nenapsal, ale stejně si dovoluju odhadnout, že při dosažení určitého stupně složitosti toho jazyka začne být psaní maker a psaní jednoduchého generátoru kódu stejně složité. Zvlášť když máte pro psaní těch generátorů nějaké další DSL, jako je třeba ANTLR Ale třeba jsou v Lispu taky nějaké takové pomůcky?

[Marek Bernát]

Nehovorím, že je to všeliek. Je jasné, že makrá treba používať s mierou. Napríklad tie príklady, čo som sem dával (pascal) sú úplná sprostosť a Lisper by žiadne podobné makro v živote nenapísal (ale bola to len ilustrácia, nešlo o nejakú použiteľnosť) Len je skrátka dobré si byť vedomý toho, kam až sa dá programovací jazyk dotiahnuť. Na pridávanie nových konštrukcií ako všemožných iterátorov, with, atď, a pod. je to proste skvelé (a nielen to, ale ďaleko viac: všetko AOP sa dá výrobou nového makra, pomocou ktorého budeme definovať funkcie priamočiaro do programu pridať. Podobne tiež ľubovoľný opakujúci sa syntaktický balast, ktorý sa však nedá abstrahovať funkciou, ale treba na to novú konštrukciu) a jasne to demonštruje silu oproti ostatným jazykom. Aspoň ja teda neviem o žiadnom podobnom koncepte, ktorý by dovoľoval človeku produkovať abstrakcie v takomto rozsahu (možno s výnimkou OOP). A hlavne ako povedal ESR "LISP is worth learning for a different reason — the profound enlightenment experience you will have when you finally get it. That experience will make you a better programmer for the rest of your days, even if you never actually use LISP itself a lot." Ja som sa tam síce ešte nedostal, ale mám pocit, že sa blížim. Cítim, že Lisp je to pravé. Ale možno sa to už príliš začína blížiť mysticizmu

Čo sa čisto DSL týka, tak nerozumiem tomu argumentu o ANTLR. V Lispe sa predsa DSL tak isto dajú vrstviť. Môžeš si vyrobiť makrá, ktoré píšu makrá, ktoré píšu makrá, ... Neviem si predstaviť ako by mohlo byť jednoduchšie písať celý kompilátor, keď v Lispe už má človek zadarmo k dispozícii read (scanner/lexer/parser v jednom) a stačí mu manipulovať AST (a aj na to si môžeš vyrobiť ďalší DSL). Samozrejme, vyžaduje to, aby aj výsledný jazyk bol zložený zo Sexpov. Ak to nie je žiadúce z nejakého dôvodu, tak už môže byť vhodnejšie napísať zvlášť kompilátor. V každom prípade, v Lispe si človek to makro vyrobí na kolene za pár minút, ak to potrebuje. Neviem ako dlho tebe priemerne trvá výroba kompilátoru minijazyka, ale tipujem, že to bude časovo úplne inde. A hlavne sa to nebude nijak integrovať s pôvodným jazykom. Bude to skrátka úplne na nič a preto sa o to takmer nikto ani nepokúša, lebo písanie kompilátorov je IMHO temná mágia neprístupná aj väčšine pokročilých programátorov. V Lispe si človek napíše kompilátor a ani o tom nemusí vedieť. Nie je to krásne?

[Ladicek]

V Lispe sa predsa DSL tak isto dajú vrstviť. Môžeš si vyrobiť makrá, ktoré píšu makrá, ktoré píšu makrá, ...

Určitě jo, neříkám že ne. Absence syntaxe je největší výhoda Lispu a zároveň jeho největší nevýhoda. Jedna z největších potenciálních výhod DSL je, že program v takovém speciálním jazyce můžeš dát neprogramátorovi a on ho (s trochou štěstí ) pochopí. Odhaduju, že syntaxe na to může mít významný vliv.

Ale, upozorním na to výrazněji, jenom odhaduju. Trochu znám tu stránku "normálních" jazyků (nemohl jsem si pomoct ), tu lispovou vůbec. Mimochodem o té temné magii psaní překladačů… to s tebou jsem se tu nedávno hádal o Parrotu, pravda? Ocituju z webu Allison Randalové:

There's an odd misconception in the computing world that writing compilers is hard. This view is fueled by the fact that people don't write compilers very often. People used to think writing CGI code was hard. Well, it is hard, if you do it in C without any tools. I don't know anyone who writes CGI code in C anymore. If we wrote compilers as often as we write shopping carts, or web forums, or wikis, there would be just as many tools available to make the job easy. (And just like web tools, only 10% of them would be worth using. That's evolution in action.)

[Marek Bernát]

V akom zmysle je to nevýhoda? Snáď len, že je nezvyklé prejsť z infixovej na prefixovú notáciu, ale to je len zvyk a inak?

Ja tiež zatiaľ ako tak ovládam len tie normálne jazyky (je to asi správne slovo ) a s týmito nenormálnymi vecami sa len zoznamujem a ešte dlho zoznamovať budem. Ale každopádne viem, že už nikdy nechcem byť normálny

Myslím, že som to bol ja, rád sa bavím o veciach, ktorých nerozumiem a Parrot tam určite patrí S tými kompilátormi plus mínus súhlas. Netvrdil som, že je to ťažké, len že to väčšine ľudí pripadá ako čierna mágia (to bude ten misconception). Je to programovanie ako každé iné. A správne prostriedky ako automaticky generované lexery určite dosť pomôžu (hoci poznám viac než jedného človeka, ktorý na lex/flex začal nadávať a radšej si napísal lexer vlastný). Ničmenej, na poriadne programovanie kompilátorov človek určite musí aspoň trochu vedieť, čo je to gramatika a čo automat a ovládať formálnu stránku veci. A hoci by to malo byť vo vzdelaní každého dobrého informatika, tak sa nezdá, že by väčšina ľudí v škole z tých prednášok niečo pochytila Takže kompilátory možno nakoniec sú ťažké pre väčšinu programátorov (na rozdiel od toho shopping cartu, kde stačí mať IQ húpacieho koníka).

[deda.jabko]

IDE si můžeš rozšířit pomocí pluginů, pro Netbeans a Eclipse jich existují spousty a můžeš si snadno napsat vlastní,

hezky prikladem, kdy IDE bylo uplne bezzube byly ,,foreach-cykly'' v jave pred verzi 1.5. pokud chtel clovek iterovat pres kolekce... tak zdrojaky musely obsahovat bloky kodu:

Iterator it = foo.iterator();
while (it.hasNext()) {
    Bar o = (Bar)it.next();
    /* a az ted neco delej */
}

ano, vim, i tento kod dokaze eclipse vygenerovat... ale v momente, kdy je potreba udelat najake vnoreni takovych veci... stava se takovy kod hodne neprehlednym...

chudaci programatori museli cekat, az jim proste nekdo konstrukt ,,foreach'' do jazyka dodelal... pokud by v jave byly rozumne makra, mohli by si jej dopsat bez nutnosti cekat na novy velky release jazyka

[Marek Bernát]

Hm, to ale nie je zďaleka len problém Javy. Python tiež čakal (a čaká) na kopu syntaxe pekne dlho (napríklad triviálne Lisp makro WITH). Ktorý nelispovský jazyk vie pridávať takéto konštrukcie bez zásahu do jazyka samotného? Snáď plne OOP jazyky, ktoré implementujú skoro všetko cez posielanie správ to ešte dokážu, ale inak ma už nenapadá žiadny.

[Michal Vyskočil]

Ktorý nelispovský jazyk vie pridávať takéto konštrukcie bez zásahu do jazyka samotného?

Co zrovna takový Python a jeho modul compiler? Příkladem je třeba tahle hezká implementace goto, i když to není zrovna produkční kód (např. to nefunguje v interaktivním režimu), pro ilustraci to stačí.

[Marek Bernát]

No neviem, či to je až tak ružové, spomínam si, že som čítal kedysi od Norviga niečo v zmysle:

>>> parse("2 + 2")
['eval_input', ['testlist', ['test', ['and_test', ['not_test', ['comparison',
 ['expr', ['xor_expr', ['and_expr', ['shift_expr', ['arith_expr', ['term', 
  ['factor', ['power', ['atom', [2, '2']]]]], [14, '+'], ['term', ['factor',
   ['power', ['atom', [2, '2']]]]]]]]]]]]]]], [4, ''], [0, '']]

Ďakujem, neprosím si. Správna odpoveď na parse ("2 + 2") je v mojom slovníku (+ 2 2) a nie tento bordel 

 

[Michal Vyskočil]

Nebyla náhodu původní otázka, který nelispový jazyk to prostě umožňuje? Navíc dělat si z Pythonu srandu s použitím takového příkladu je ze stejného soudku jako trefovat se do Lispu kvůli závorkovému peklu.

import compiler
print compiler.parse("2 + 2")
Module(None, Stmt([Discard(Add((Const(2), Const(2))))]))

(+ 2 2) to sice není, ale tohle je skutečná interní reprezentace. Afaik bude něco velice podobného dělat i Lispová mašina (myslím třeba nějak si označit si konstanty, statementy Lisp bohudík nemá).

[Marek Bernát]

Bola, sorry. Navyše ja proti pythonu nič nemám, nie je to úplne zlý jazyk (hoci niektoré veci ma na ňom vytáčajú). Ale Lisp to nie je (a ani ním nechce byť). Čo presne si predstavuješ pod pojmom zátvorkové peklo? Editáciu Lispu v notepade?

Hm, tak je pravda, že ten Norvigov parse bol asi dosť hack, ktorý len dekompiloval bytekód (preto ten balast), už si to presne nepamätám. Tento tvoj zápis je o dosť lepší, ale aj tak to má k Lispu celkom ďaleko. A hlavne by som chcel vidieť, ako sa to škáluje na zložitejších prípadoch ako 2 + 2 (a aj to hneď pôjdem otestovať), takže na nejaké rozširovanie syntaxe to asi extra vhodné nebude. Btw, ak som dobre pochopil tú stránku, tak je to už deprecated. Prečo?

[xkucf03]

 

museli cekat, az jim proste nekdo konstrukt ,,foreach'' do jazyka dodelal... pokud by v jave byly rozumne makra, mohli by si jej dopsat bez nutnosti cekat na novy velky release jazyka

Přiznejme si, že obě možnosti jsou dost nepříjemné. Ale já jsem rád, že jsme se nakonec dočkali a máme tu jeden způsob zápisu foreach cyklu, místo abychom tu měli desítky nebo stovky růrných konvencí a maker (protože každý by na to šel trochu jiným způsobem). Podle mého je lepší počkat až se dané řešení dostane do společného základu, který používají všichni stejně, než umožnit příliš velké rozvolnění jazyka.

 

Vycházím z předpokladu, že lidé (nebo týmy) mají stejné potřeby. Někdo si sice myslí, že jeho potřeby jsou zcela jedinečné a potřebuje nějaký svůj speciální jazyk, ale ve skutečnosti tentýž problém řeší řada dalších lidí nebo týmů. Je to jako když potřebuješ auto, které umí jezdit po bahnitých kopcích, a všude kolem jsou lidé, kteří jezdí autem jen po silnicích. Myslíš si tedy, že máš jedinečné potřeby – ale přitom na světě existují miliony dalších lidí, kteří jezdí po bahnitých kopcích – tak si prostě koupíš terénní auto, které se pro tyhle lidi vyrábí a nebudeš si montovat vlastní

(dá se to rozvést dál – když půjdu do servisu s obvyklým autem, mechanik bude hned vědět kam má sáhnout, bude mu to trvat méně času a mě to bude stát méně peněz – kdybych tam přišel s vlastním montovaným autem, buď by mě poslal k čertu, nebo by mne to přišlo draho, protože on by ztrácel čas tím, že musí pochopit tu jedinečnou konstrukci. … ale radši dál pokračovat nebudu, protože tu zase někdo řekne, že paralely s auty a počítači jsou nesmyslné )

[deda.jabko]

Přiznejme si, že obě možnosti jsou dost nepříjemné.

ja priznavam, ze jenom jedna z moznosti je neprijemna.

Ale já jsem rád, že jsme se nakonec dočkali a máme tu jeden způsob zápisu foreach cyklu, místo abychom tu měli desítky nebo stovky růrných konvencí a maker (protože každý by na to šel trochu jiným způsobem).

to je jenom hypoteticka uvaha... protoze za normalnich okolnosti by se takovy konstrukt velice rychle dostal do standardni knihovny... co si budem nalhavat standardni knihovna se meni velice snadaneji a rychleji nez samotny prekladac. a roztristenosti bych se taky nebal... CL ma taky jenom jednu smycku loop...

v tomto ohledu mne pripominas jednu zenskou se kterou jsem pracoval pred hodne a hodne lety... bylo to na projektu jeste ve foxpro... na moc mistech kodu se tam objevovalo okno... kde se zobrazila hlaska a cekalo se na ano/ne nebo nejak tak.... byla to akce na nekolik radek: vytvorit okno, vypsat text, odchytit vysledek... tak mne to prislo nesmyslne psat to porad dokolecka a dopsal jsem funkci MessageBox a zacal ji pouzivat. za to jsem byl zdrban, proc takovou funkci vubec zavadim, kdyz ji nikdo nepotrebuje, protoze misto toho tam jdou napsat ty 4 nebo 5 radek.

[xkucf03]

Z toho si nic nedělej, já zase občas narážím na lidi, kteří se diví, proč vytvářet v databázi další tabulku a snažit se o normalizaci, když to mohou nacpat jako serializované pole do jednoho atributu.

BTW: proti zavádění takových funkcí, jak píšeš, nic nemám – na rozdíl od maker nesnižují přehlednost programu a nezhoršují možnosti ladění.

[Marek Bernát]

Ty si vtipný. V živote si Lispovské makrá nepoužil (mýlim sa?) a píšeš tu o znižovaní prehľadnosti. Keby si to skúsil, zistil by si, že to funguje rovnako ako to nahradenie kódu funkciou, proti čomu nič nemáš. Je to len ďalšia úroveň abstrakcie. Samozrejme, že makrá treba používať s rozumom, rovnako ako treba s rozumom používať funkcie, ale to nie je argument proti používaniu ani jedného.

[Ondrej 'SanTiago' Zajicek]

> protoze za normalnich okolnosti by se takovy konstrukt velice rychle dostal do standardni knihovny... co si budem nalhavat standardni knihovna se meni velice snadaneji a rychleji nez samotny prekladac. a roztristenosti bych se taky nebal...

Treba v takovem C se standardni knihovna meni jednou za deset let (C98, C99) a spousta veci, ktere by tam mely byt uz desitky let, tam stale chybi.

[Ladicek]

já jsem rád, že jsme se nakonec dočkali a máme tu jeden způsob zápisu foreach cyklu

Já bych si ho milerád přepsal! Přidal bych do něj kontrolu na null.

Teď se, pravda, objeví zastánci prázdných kolekcí, ale prázdná kolekce a null jsou dvě věci s dvěma rozdílnými významy.

[xkucf03]

Já bych spíš uvítal, kdyby se při deklaraci typu uvádělo, zda může být null nebo nemůže. Většinou by se deklarovalo jako @NotNull (je jedno, jestli by to byla anotace nebo něco jiného, případně by nenulovost mohla být výchozí), takže by problém s null kolekcemi nebyl. Pokud by typ byl deklarovaný jako potenciálně nullový, je správné tuto výjimku odchytávat nebo provádět kontrolu. To by bylo fajn, ne? Výjimky by mohly být kontrolované.

BTW: co ti brání napsat si takovéto jednoduché „makro“?

Collection<T> notNull(Collection<T> kolekce) {
	if (kolekce == null) {
	    return new ArrayList<T>();
	} else {
	    return kolekce;
	}
}

Jeho použití:

Collection<String> kolekce = null;
System.out.println(notNull(kolekce).size());

for (String s : notNull(kolekce)) {
    System.out.println(s);
}

kolekce = new ArrayList<String>();
kolekce.add("ahoj");
kolekce.add("");

System.out.println(notNull(kolekce).size());

for (String s : notNull(kolekce)) {
    System.out.println(s);
}

Řekl bych, že je lepší použití takovýchto standardních (primitivních) prostředků jazyka (metody / funkce) a psaní for (String s : notNull(kolekce)) {…} – místo vymýšlení zcela nových jazykových konstrukcí typu: specialForAcceptingNull (String s : kolekce) {…}.

[Ladicek]

Anotace jako @NotNull už existují a s příchodem anotací pro typy v Javě 7 je bude možné používat k tomu, o čem píšeš. Jak bude vypadat kód… kdesi jsem viděl příklad, ale protože byl tak ošklivý, jak byl (to bude teprv anotační peklo), nebudu ho ani dohledávat.

Nullable a non-nullable typy bych bez skrupulí okopčil ze C# 2.0 (nebo v které verzi se to objevilo). String je non-nullable, String? je nullable. Pro přetypování z nullable na non-nullable nějaká speciální konstrukce, a bylo by to.

Ta pomocná metoda notNull je docela dobré řešení, to mne nenapadlo (a že jsem podobných metod už pár napsal). Pro nekritické části kódu by se to úplně v klidu dalo použít. Bohu díky za statické importy.

[podlesh]

Klon Javy podporující deklaraci nulovatelnosti jsem viděl již někdy kolem roku 2002.

[alblaho]

Jenomže pak se o tento "zbytečně" vygenerovaný kód zakopává do konce života programu. Ono napsat getter/setter ručně je úplně to nejmenší, ale proč to dělat, když v 99% případů nic užitečného nedělají?

[xkucf03]

Zakopává? Člověk prostě ty přepravky (DTO) jednou napíše a pak na ten kód nemusí šahat (takže je celkem jedno, kolik má řádek) – takovou třídu si pak otvíráš, jen když si do ní chceš nějaký atribut přidat nebo  naopak nějaký smazat. Takže jsou to řádky kódu trochu nadbytečné (neříkám, že by to nešlo udělat líp než gettery/settery), ale neškodné.

[alblaho]

Ve všech javovských programech, co jsem viděl, nebyly gettery/settery záležitostí nějaká úzké skupiny DTO tříd, ale byly všude možně.

Prostě nesnáším zbytečný balast, tak mě to víc štve. Dá se to ale přežít.

[thingie]

Přežít se dá i atomová válka. Nějak.

[Leoš Literák]

Univerzálnost. Primitivní settery a gettery sice vypadají k ničemu, jenže ti dávají možnost v budoucnu změnit jejich chování, přidat kontroly rozsahu argumentů či stavu objektu, delegovat chování někam jinam atd. Když dáš public propertu, tak v javě o tuto možnost přijdeš a ztrácíš kontrolu nad svým objektem. Jiné programovací jazyky to ale mohou řešit lépe.

[alblaho]

No právě. Kvůli 1% případů, kdy tam potřebuješ dát nějakou kontrolu, tam setter musíš dát vždycky a tedy v 99% případů zbytečně.

A to si myslím, že jsem to jedno procento nadhodnotil. Zkrátka taková nehezká vlastnost Javy.

[mirec]

A čo tak dať členské premenné ako verejné a v prípade, že treba getter / setter zmeniť typ premennej na template s pár preťaženými operátormi. Síce v Jave som nič také nevidel, ale v C++ celkom bežné.

[xkucf03]

Hmm, tak to už radši ty properties ve stylu C#.

[alblaho]

V Javě to právě udělat nejde. Ty settery se tam dávají prostě proto, aby se v případě, že je potřeba tam dát nějakou kontrolu, neměnilo rozhraní.

[Ondrej 'SanTiago' Zajicek]

A neni to jenom problem 'korporatniho' stylu programovani a rigidniho rozdeleni analyza/kodovani? Pokud mam v programu verejnou polozku struktury, a budu ji chtit zmenit na privatni a pridat nejake settery a gettery, tak tuto zmenu jde udelat pomerne snadno a spolehlive, pokud clovek muze zasahovat do veskereho kodu, ktery dane rozhrani vyuziva. IMHO je zbytecne preventivne delat settery a gettery u vseho. Staci u polozek, kde se da cekat, ze to bude vhodne.

Neco jineho je treba u knihoven (v C), kde je rozumne nepovolit primy pristup do struktur kvuli lepsimu udrzovani binarni kompatibility.

[Leoš Literák]

Pokud si prasis kod sam pro sebe a nikdo jiny s nim v zivote nebude pracovat, pak je tvuj pristup zcela efektivni Ale nebude ti fungovat nic, co pouziva javabeans specifikaci, ta podle getteru urcuje, zda je properta na cteni / zapis.

[Ondrej 'SanTiago' Zajicek]

Podobny pristup pouzivaji treba i vyvojari linuxoveho jadra, takze lze tezko ho omezovat jen na programu prasene pro sebe.

[Leoš Literák]

Kernel neni psany v Jave. Muj komentar se tykal ji. Necitim se kvalifikovan hodnotit jine jazyky.

[deda.jabko]

Akorát se tím připravíš o zapouzdření a možnost přidat např. validaci (např. číslo musí být větší než nula). Ale pokud takové věci nepotřebuješ, budiž. V čem tě Java omezuje?

jo, to je presne ta impotence javy o ktere mluim... omezuje me v tom, ze si musim vybrat mezi tim, jestli chci verejne promenne nebo gettery a settry.

proc nemuze byt v jave treba makro, ktere by se zadavalo takto... a expandovalo by se na definici getteru settru

public class MojeTrida {
   variable_with_default_getter_and_setter(String, jmeno);
   variable_with_default_getter_and_setter(int, pocet);
....
}

Jde to někde? Něco na tenhe způsob jsem viděl v Eiffelu (ale syntaxe byla dost podivná).

LISP, Scheme a jejich derivaty to umi na 100%. vsadil bych se, ze to pri trose stesti pujde i v C/C++...

[xkucf03]

A to makro si člověk musí napsat, nebo je to snadardní součást jazyka, kterou znají všichni programátoři v tom jazyce?

[deda.jabko]

:-]] to je kouzelne hloupa otazka... proc by takova vec mela byt standardni soucast jazyka nebo ji znat vsichni?

[gm]

protoze pokud je to "standard" ktery znaji vsichni, tak novy programator ktery se ma pridat k tymu/projektu se nemusi krome hromady jinych veci ucit jeste navic nejaka specificka makra ..

[Josef Kufner]

Řekl bych, že těch pár maker bude oproti zbylým 100K řádkům kódu projektu jen drobnost.

[podlesh]

On problém nebývá ani tak u nových členů vývojového týmu - ti se musí zapracovat tak jako tak. Vůbec, vývoj je v pohodě.

Problém spíš nastane, když po X letech někdo na druhém konci zeměkoule dostane za úkol opravit nějaký drobný bug.

[xkucf03]

Aby se zkrátilo rozkoukávání nových členů týmu a aby se pracovalo efektivněji. To je důležité jak při komerčním vývoji (čas jsou peníze), tak u open source projektů (nezvyklý/jedinečný styl je překážkou zapojení nových dobrovolníků).

Je to podobné jako s psaním vlastních frameworků nebo knihoven – můžeš si napsat svoji, přesně na míru, která ti sice umožní efektivní práci (ve tvém specifickém případě) – ale vyžaduje, abys tu knihovnu/framework důvěrně znal (a tu znají jen lidi z dané firmy/týmu a ještě k tomu s největší pravděpodobností neexistuje dokumentace). Když použiješ obecně použitelný framwork/knihovnu, který je rozšířený a pracuje v něm spousta lidí, snadno pak budeš shánět nové lidi do týmu. Prostě jen řekneš, že chceš člověka, který má zkušenosti s XYZ a on pak může začít pracovat téměř hned – místo aby se musel týdny až měsíce rozkoukávat.

[Ladicek]

No jejda! Ani nechci vědět, co si myslíte o oborových jazycích (DSL)!

[deda.jabko]

Aby se zkrátilo rozkoukávání nových členů týmu

a nemas deprese z toho, ze v Jave si muze kazdy definovat vlastni tridy? nekomplikuje to zivot lidem, kteri se chteji do projektu zapojit?

[Ladicek]

Ono by stačilo, kdyby anotační procesory měly povoleno změnit třídu, ve které jsou anotace použity. O automatickém generování getterů a setterů z anotací (@Get, @Set) zdaleka nesním sám.

Tedy ono to jde nahackovat už dneska, přinejmenším se suním překladačem, ale standardní API k tomu nestačí.

Po makrech v Javě zas tak netoužím – ona jsou už tak dost děsivá v homoikonických jazycích, co teprve v těch normálních. Teda přinejmenším hygienická makra jsou děsivá

[Ladicek]

Teď si uvědomuju, že si tak trochu odporuju. Jo, no, anotační procesor manipulující s AST je vlastně taky makro. Ale … explicitnější. A asi taky složitější na napsání. V Groovy něco takového mají, taky to řídí anotacemi (zatím) a vypadá to jako slušná magie.

Což teda nic nemění na tom, že přinejmenším ty @Get a @Set by mohly být součástí jazyka, jako taková velice užitečná drobnost (například pro použití s dependency injection).

[Marek Bernát]

Čo presne je na makrách desivé? Že je človek behom chvíle schopný napísať kompilátor nejakého minijazyka? To ma občas tiež desí, ale skôr v tom pozitívnom zmysle

 

[Ladicek]

No, mne teda kapitola o syntaktických makrech ve Scheme v Beautiful Code docela vyděsila Ale, pravda, tam popisují spíš implementaci, z pohledu uživatele to nebude tak hrozné

[Marek Bernát]

Hm, implementáciu som ešte nevidel, k tomu sa tiež chcem časom dostať. A makrá poznám skôr z Common Lispu -- Scheme ovládam oveľa menej a písal som v ňom zatiaľ len funkcionálne programy, žiadny makrá. Ak sa v tom trochu vyznáš, mohol by si zhrnúť, rozdiely medzi makrami v Scheme a CL?

[Ladicek]

Nevyznám a tedy ani nemohol. Ale ono jde (asi?) hlavně o to, že makra ve Scheme jsou (nebo by měla být) hygienická – totiž že když v makru použiju symbol, který se používá i někde v kódu, tak že se nepoperou. A není úplně triviální toho dosáhnout.

[Marek Bernát]

No, to už som počul tiež, ale zaujímalo by ma, načo je to vlastne dobré. Dobrý CLkár si totiž takéto veci vie ustrážiť (a dokonca sú na to postupy už priamo v CL, napríklad gensym) -- proste je to sada idiómov, ktoré sa dodržiavajú pri písaní makier a všetko bude v pohode. A zároveň som už počul zopár CLkárov nadávať na Scheme, že hygienické makrá sú oveľa slabšie ako tie v CL. Celkom ma zaujíma, že jak to teda je. Skúsim pogoogliť. Alebo prinajhoršom prečítať R5RS, snáď to odtiaľ pochopím

[Ondrej 'SanTiago' Zajicek]

Implementace makroprocesoru jako takoveho by melo byt celkem trivialni. Na (lisp-like) makrech je neprijemne napriklad to, ze kod, ktery je pouziva, se spatne debuguje (trivialni priklad je chybne pouziti makra, ktere vygeneruje compile-time chybu v expandovanem kodu) a muze zpusobit necekane chyby kvuli sve nehygienicnosti, a samotny kod maker muze byt velmi obtizny na pochopeni.

Ze Lispova makra jsou svym zpusobem desiva, ukazuje treba to, ze autori R5RS standardu scheme je radsi vyhodili a misto toho zavedli uplne jiny system zalozeny na (normal-order) pattern matching.

Osobne si nemyslim, ze to je uplne dobre reseni, ale stejne tak si nemyslim, ze je rozumne vsechno resit vsemocnymi lispovymi makry. Makra by se IMHO mely pouzivat tam, kde nejde pouzit jiny prostredek jazyka (napr. v C je asi vzdy vhodnejsi pouzit inline funkci, pokud to jde) a prostredky jazyka by mely byt natolik obecne, aby se makra mohly pouzivat minimalne (treba v C clovek musi pouzit makro tam, kde by stacilo pouzit 'typove genericke' funkce, v Scheme zase clovek musi pouzit makro tam, kde by stacilo pouzit predani reference na promennou).

 

[Marek Bernát]

Tiež si myslím, že te nebude nič zložité.

Tie argumenty proti lisp makrám sa dajú použiť aj na normálne programovanie. Holt, človek si musí dávať pozor a vedieť debugovať, atď. Uznávam, že je to ťažšie, ale to je už holt cena za tú silu, ktorú to programátorovi dáva do rúk.

Už som si tie R5RS makrá prečítal. Je to zaujímavé a v mnohých prípadoch dostatočné, ale nepáči sa mi to. Príliš to zväzuje ruky. Ale viac sa k tomu nebudem vyjadrovať, kým nebudem mať 10 rokov skúseností ako s CL, tak so Scheme makrami. Momentálne to rozhodne nie som schopný reálne porovnať.

Súhlasím, že makrá treba používať čo najmenej (a v CL sa toto skutočne dá, lebo je to mocný jazyk, na rozdiel od toho C (trochu lepší assembler) a Scheme (akademický Lisp)). Ale sú situácie, kde sú makrá (tie lispovské) skutočne potrebné a ak mi jazyk nedovoľuje rozumne situáciu vyriešiť a núti ma písať dokolečka balast, tak nie som z toho 2x nadšený.

[mirec]

Javascript

[Ivan]

>> Komu dělají problém "chytřejší" konstrukce jazyka, ten se má doučit jazyk.

S tim muze byt treba u C++ nebo u Perl dost problem. Tyhle jazyky jsou hodne neortogonalni - na jeden problem existuje milion ruznych reseni. A zrovna C++ svadi k tomu, ze si jako programator reknete "Tyhle 4 radky kodu je to nejchytrejsi, co jsem kdy napsal". Soucasti C++ standartu jsou i pretizeni operatoru  dereference a carky, tyhle veci vam umozni napsat kod, ktery na prvni pohled vypada "elegantne", ale rozmotat ho muze byt prace na dny.

[happy barney]

ak ten operátor logicky robí to, čo pôvodný, je to v pohode, nikoho by nemalo trápiť, ako to robí (to už je test niečoho iného)

[Jirka P]

To, co popisujete, není ortogonalita - ortogonalita znamená nezávislost různých vlastností jazyka na sobě, ne jediný způsob na řešení jakéhokoli problému (což je MMCH nesmysl, protože v každém rozumném Turing-complete jazyku existuje na každý problém nekonečně mnoho programů). Doporučuji přečíst tento blogpost.

[JS]

Ty dve vlastnosti spolu pomerne uzce souvisi. V Perlu (moc ho neznam) je pokud vim asi 8 ruznych funkci typu printf. Kazda dela velice podobnou vec, ale trochu jinak. Jsou navzajem tedy velmi neortogonalni. Naproti tomu v Pythonu je jen jedna takova funkce, a ruzne jeji varianty jsou reseny pomoci parametru a formatovaciho retezce. To je ortogonalni reseni.

Ortogonalni jazyky proste casto vedou na jediny elegantni zpusob, neortogonalni vedou na opak.

[Marek Bernát]

A aký je v tom rozdiel, či volám sprint(premenná) a print(premenná, parameter='s')? Len trochu iný zápis toho istého. Samozrejme, ak zadefinujem úplne rovnaké funkcie pre niečo, čo sa líši len jedným parametrom v kóde, tak to je samozrejme duplikácia kódu, akej sa treba vyvarovať. Ale ak sa tie funkcie líšia od seba podstatne, tak je rozdelenie na samostatné funkcie rozumné. V každom prípade, tých 8 funkcií z Perlu nepoznám, takže ťažko posudzovať.

[JS]

Pro zacatecnika v tom rozdil je, v citelnosti. Zatimco sprintf je nova funkce, ktera muze delat cokoli, print(.., parametr=) je uz stara znama. A tedy, i kdyz ten parametr neznate, muzete o ni predpokladat urcite vlastnosti.

To je mimochodem jedna z veci, ktera mi na Common Lispu oproti Pythonu vadi. Python ma filozofii "there should be only one way to do it". Prosazuje ji i za cenu toho, ze dost operaci musite udelat na 2 kroky, zatimco v neortogonalnim jazyce by stacil 1 (take to souvisi s filozofii "explicit is better than implicit"). Common Lisp tuto filozofii obecne neuznava (to neznamena ovsem, ze uznava opak, jako Perl), takze obcas v nem mate radu velmi podobnych funkci, coz zvysuje jeho narocnost pri uceni (klasicke jsou priklady jako eq, eql, equal, equalp nebo destruktivni/nedestruktivni prace se seznamy, o ruznych aliasech typu car/first nemluve). Ale zase, pokud tu knihovnu znate zpameti, programy jsou kratsi, a nebo mate svobodu vybrat si ktera varianta vam vyhovuje.

[Marek Bernát]

To je samozrejme pravda, ale ak sa stará známa funkcia začne s parametrom s správať úplne inak, než bez neho, tak sme tam, kde sme boli

Napríklad:

def fun(arg, **kwargs):
  fun2(arg) if **kwargs['par'] == 's' else fun1(arg)
(sorry, ak to pletiem, už som python dávno nevidel, prešiel som k iným jazykom; snáď je jasné, čo chcem povedať).


Mno, CL je veľký jazyk a 50% z neho (hrubý odhad) je len relikt minulosti, ktorý sa môže zahodiť: car => first, cdr => rest, elementy cez aref, elt, nth, char, bit, vbit, svref, ... print, princ, prin1; labels, flet; let, let*, list, list* atď, atď, ). Ale nie je to IMHO taký problém, proste nemusíte tie veci používať (hoci to chce čas naučiť sa, čo v tom jazyku je a čo nie je dobre používať). Deštruktívne funkcie majú zmysel, lebo Lisp nie je (len) funkcionálny jazyk, takže myslí na to, že človek môže chcieť mať väčšiu kontrolu nad pamäťou. Ale osobne by som asi tiež viac uvítal obecný parameter "&key :destruct nil", než spôsob, akým je to teraz (append/nconc).

Ale inak osobne neuznávam princíp TIOWTDI. Príliš to zväzuje ruky a myseľ. Ja chcem mať možnosť spraviť veci 10 spôsobmi a vybrať z nich ten najlepší, alebo ktorý ma zrovna baví. Ono, python tiež nedodržuje tento princíp ani zďaleka. Žiadny multiparadigmový jazyk nemôže. Všetko sa dá spraviť len pomocou OOP, len pomocou funkcionálneho programovania, imperatívne, alebo sa to dá skombinovať a na všetko je milión spôsobov (aj v pythone). Na spracovanie zoznamov môžem použiť map/reduce, alebo môžem iterovať, alebo sa môžem hrať, že je všetko OOP, podľa toho, čo sa mi viac hodí. Ak by mi niekto povedal, že "musíš to robiť takto a nijak inak", tak by som mu asi dal po papuli Ale sú výnimky. Napríklad Smalltalk je tak krásne OOP, že mi to neprekáža. Podobne Haskell je tak krásne funkcionálny

[JS]

Tak to pak neni dobre navrzena funkce, pokud se chova tak odlisne na zaklade jednoho parametru.

Ja chapu ze neortogonalita Lispu je casto dedictvi minulosti (i kdyz uprimne mam radeji car/cdr nez first/rest), a taky chapu, ze obcas to pomaha na vykonu. Ale me se princip TIOWTDI libi. Ja kaslu na paradigmata - chci pouzivat takove, ktere je nejpohodlnejsi a nejpraktictejsi.

To co rikate o Pythonu je sice castecne pravda, ale ja tou ortogonalitou myslim trochu nizsi uroven. Ortogonalita Pythonu (nebo jinych jazyku) spociva v tom, ze tam mate urcite mnozstvi nastroju, a ty kombinujete. Prikladem muze byt funkce reduce - ta byla nedavno odstranena z __builtin__, protoze je proste prilis specialni a da se pomerne snadno realizovat pomoci smycky.

[Marek Bernát]

To je samozrejme pravda. Ale argument mal byť, že ak tých 8 funkcií Perle je odlišných oveľa viac než len nastavením pár parametrov, tak to pokojne môže byť rozumné rozhodnutie. Ale opäť to zopakujem, nepoznám ich, takže nebudem súdiť (hoci to, čo som z Perlu doteraz videl dáva tušiť, ako to s nimi bude ).

Prečo car/cdr? Pracovali ste s tou starou mašinou, ktorá to mala ako inštrukcie? Iný dôvod si predstaviť neviem. Názov je to totiž úplne nezmyselný (mimo tú mašinu)

No práve, ja chcem tiež používať to, čo je najpohodlnejšie a najpraktickejšie. A to je práve presne proti TIOWTDI, ktoré hovorí, že musím vždy použiť jeden daný spôsob a inak sa to nedá/nesmie, ak ho dobre chápem.

To ale v tom prípade musíte špecifikovať, akú úroveň a ktoré nástroje presne myslíte, aby sme sa vôbec mohli o niečom baviť

[JS]

Pouzivam car/cdr protoze to lepe sedi memu pohledu na Lispove seznamy jako seznam consu, nez jako abstraktni seznam (a taky je to kratsi). Proste zatimco first je elementarni operace, second uz ne, a to mi vadi. U Pythonskych seznamu by mi to nevadilo - ty jsou abstraktni a jazykem neni definovana jejich implementace. I kdyz tam by to nedavalo smysl, protoze na takovato pouziti by se v Pythonu lepe pouzil tuple.

To co je nejpohodlnejsi nejde vzdycky proti TIOWTDI, pokud ta jedna cesta je ta nejpohodlnejsi. A to obvykle v Pythonu byva (a pokud ne, snazi se to opravit). To je na nem pekne. Tady ale neni o cem se bavit - oba pristupy maji sve vyhody a nevyhody, jak ten Perlovsky, tak ten Pythonsky, a me proste vyhovuje vic ten Pythonsky. Je to subjektivni zalezitost.

Jeste jiny pohled na ten rozdil je v tom, jestli si jako programatori navzajem nechame svobodu, a radeji tam dame 2 podobne funkce, abychom uspokojili vkus vsech (za cenu vetsi slozitosti jazyka, ovsem), nebo se dohodneme, dame tam jednu funkci, ktera se sice ne kazdemu bude libit, ale protoze bude 1, kazdy ji bude hned znat. Je to otazka kultury v dane programatorske komunite.

[Marek Bernát]

Ja nad Lispovskými zoznamami radšej premýšľam ako nad sekvenciami. Lisp ako taký (myslím teraz nejaký abstraktný jazyk s hlavnými vlastnosťami, ktorý robia jazyk Lispom) totiž IMHO nezávisí na jednosmerných spojovaných zoznamoch a je to proste len prežitok tej car/cdr mašiny. Jasné, že je dobré vedieť, jak to v CL funguje vovnútri, ale že by bol dôvod na to myslieť stále, to si nemyslím. S tými second/third/... súhlas. Ale rovnako tak máte cadr/caddr/...

Stále tak nejak nerozumiem, čo presne myslíte tým Pythonovským prístupom. Python sa síce tvári, že vyhovuje TIOWTDI princípu, ale podľa mňa to zďaleka nie je pravda. Dajte nejaký krátky príklad a ja Vám ho prepíšem na iný a ekvivalentný (hoci som už v Pythone dlho nerobil, tak to môže byť trochu cez ruku). Súhlasím, že Python je oveľa striktnejší a čistejší ako Perl (teda aspoň pokiaľ môžem súdiť podľa toho mála Perlu s ktorým som prišiel do kontaktu) a tiež vidím výhody/nevýhody v oboch prístupoch.

V každom prípade tú 1, proti tomu ja nič nemám. Opak väčšinou signalizuje ani nie tak chuť uspokojiť väčšinu, ale bordel z minulosti a zachovanie spätnej kompatibility, taď. Ale ak sa už jedná o dva neekvivalentné (aj keď nie nutne ortogonálne) prístupy, tak tam v princípe nemám nič proti tomu pridať oba.

[xkucf03]

• sprint(premenná)
• print(premenná, parameter='s')

Zrovna tohle by bylo dost ošklivé řešení – druhý způsob dovoluje, abych tam jako parametr podstrčil i jiné (nesmyslné) písmenko a pak se musela ošetřovat chyba – kompilátor nemůže tušit, kderá písmenka (parametry) jsou přípustná a která ne, takže se připravíme o kontrolu v době kompilace. Kdyby se k rozlišení použily třeba enumy nebo odlišný počet a typ parametrů, bylo by to o dost lepší.

[Marek Bernát]

To je úplne nepodstatný detail. V dynamických jazykoch nás takéto veci netrápia. A keby to bol statický jazyk, tak spravíme (v pseudosyntaxi) napríklad print(premenná, &keyword parameter : Print_parameter = print_default), kde Print_parameter je trieda, alebo enum, to už je fuk.

[Ladicek]

Ten článek je padlý na hlavu. To operátor pevného bodu je akademická ztřeštěnost, která je dobrá snad akorát k formální definici rekurze. Nic proti formalismům, ale tohle fakt ne.

[default]

Mě fascinuje, jak každý porovnává programovací jazyky na faktriálu. Čím míň řádek, tím lepší jazyk. Podle mě nejlepší programovací jazyk je SQL, protože v něm je to na jeden řádek:

SELECT ROUND(EXP(SUM(LN(LEVEL)))) AS factorial FROM dual CONNECT BY LEVEL <= :1
/

[Marek Bernát]

Faktoriál je v každom rozumnom jazyku na jeden riadok a to navyše tak, že to rozumne vyzerá (na rozdiel od toho SQL). Niečo ako "product 1..n" funguje skoro vo všetkom, čo podporuje aspoň trochu funkcionálneho programovania.

Pointa toho článku ale nebol vôbec faktoriál, ale zápis tej funkcionálnej myšlienky, ktorý bol proste odporný, lebo Java je primitívny jazyk. Kombinátor, ktorý je vo funkcionálnom jazyku na pár riadkov je v Jave na niekoľko desiatok, nedá sa to zapísať lepšie a pochybujem, že sa nájde niekto, kto ten kód pochopí. Faktoriál je už len jednoduchá aplikácia toho kombinátoru. Súhlasím s Ladíčkom, že je to trochu extrémny príklad a tak trochu zbytočný. Že je Java primitívny jazyk plný balastu je totiž každému nejavistovi už dávno jasné

[default]

Faktoriál je v každom rozumnom jazyku na jeden riadok a to navyše tak, že to rozumne vyzerá (na rozdiel od toho SQL).

Pro mě je to čitelný. Čitelnější, než vaše rekurze, funktory, uzávěry a specielně vaše ukvapené závěry.

[Marek Bernát]

Skutočne je to pre vás čitateľnejšie ako ten súčin "product 1..n"? Zaujímavé. Njn, čo už keď som ukvapený a považujem za lepšiu vec, ktorú som schopný vyjadriť jedným riadkom namiesto desiatich, alebo dvoma slovami namiesto dvadsiatich slov. Vy asi máte radi zbytočný bordel, čo už s Vami :-P

[default]

Skutočne je to pre vás čitateľnejšie ako ten súčin "product 1..n"? Zaujímavé.

Omlouvám se. Netušil jsem, že product 1 .. n je konstrukt skutečného programovacího jazyka.

Njn, čo už keď som ukvapený a považujem za lepšiu vec, ktorú som schopný vyjadriť jedným riadkom namiesto desiatich, alebo dvoma slovami namiesto dvadsiatich slov.

Ano. Klíčové slovo pro faktoriál. Úžasné. Napsal jsi někdy v životě alespoň jeden reálný program? Já jich napsal hned několik a zkratku na faktoriál jsem nikdy nepotřeboval. Zato jsem potřeboval úplně jiné konstrukce, o kterých ty zjevně nemáš ani páru. Jinak bys jazyky a jejich API porovnával podle skutečných možností a né podle počtu závorek a dalšího bordelu (tvůj výraz ), který je pro mě osobně méně přehlednější než binárka otevřená v hexa-editoru. To, jestli napíšu

for (int i = 0; i < :1; i++) {
    // do something
}

nebo

FOR i IN 1 .. :1 LOOP
    -- do something
END LOOP;

nebo

SELECT
    LEVEL AS val
FROM
    dual
CONNECT BY LEVEL <= :1

je pro mě bezvýznamné. Rozhodující pro mě je, zda daná platforma umí pracovat v UNICODE (nikoli s UNICODE!), zda umí XML, zda umí analytické funkce (Oracle) či rozšířené seskupování (GROUP BY). To jsou věci, které ke své práci prostě potřebuji. Nikoli, jestli při psaní cyklu zmáčknu o tři klávesy navíc či ne.

Vy asi máte radi zbytočný bordel, čo už s Vami :-P

Nemyslím si, že klíčová slova jako SELECT, FROM, CONNECT BY jsou zbytečný bordel. Specielně ten CONNECT BY je velmi užitečný konstrukt, který mnohde chybí a způsobuje, že ty databáze jsou pro mě v praxi nepoužitelné.

[thingie]

Netušil jsem, že product 1 .. n je konstrukt skutečného programovacího jazyka.

To je hodně smutný, ne na nějaký „“. A zbytek příspěvku s argumentací a tématem v podstatě vůbec nesouvisí. Teda, ano, rozdíl mezi těma třema zápisama je bezvýznamný, protože nesrozumitelný bordel jsou všechny tři…

[Marek Bernát]

Absolútne súhlasím a som rád, že si odpovedal za mňa, aspoň nemusím rozoberať tie jeho výplody...

[default]

Teda, ano, rozdíl mezi těma třema zápisama je bezvýznamný, protože nesrozumitelný bordel jsou všechny tři… 

Dobrá. A jak to tedy má být správně? Rád si to poslechnu.

[thingie]

No tak ideálně nijak. Nějakým map, filter nebo foldněco, asi… To nikdo neví, jaksi tam totiž chybí i jen nejmenší náznak toho, k čemu by ten kód měl přibližně být.

[default]

Jak typické.

[thingie]

Takže když náhodou potřebuješ z té databáze dostat záznamy odpovídající nějaké podmínce, tak napíšeš c-like for smyčku, explicitně prolezeš všechny záznamy a po jednom zkontroluješ, a kdyby ti někdo navrhnul, že v SQL je taky něco jako jakýsi záhadný SELECT, tak se mu vysměješ, asi. Nj.

[default]

Použiju bez řečí klauzuli WHERE a vysměju se tomu, komu to bude připadat jako bordel.

[thingie]

Já bych to jako docela rád interpretoval jinak, ale podle mého se jako idiot směješ něčemu, co se ani neobtěžuješ pochopit. (Možná ani přečíst.)

[xkucf03]

Já jsem to s dovolením pochopil – jsou prostě různé činnosti a hodí se k nim různé jazyky – proto s daty pracuji pomocí SQL, programy píšu v Javě, ale webové stránky v JSP, dokumenty vytvářím v XML atd. Ale nějak mi ani nechybí nějaký ultimátní jazyk, který bych si mohl přizpůsobit a přepracovat tak, aby vyhovoval pro všechny druhy činností.

Psát třeba webové stránky v Javě (generovat v ní celý dokument) by byla asi pěkná otrava – tak člověk píše web v JSP(X), které má blíže k dokumentu než k programování a aplikační logiku zase píše v Javě. I kdyby byla Java (nebo jiný jazyk) sebevíc přizpůsobitelná a ohnutelná, nedovedu si moc představit, že by se v ní psaly webové stránky lépe než v jazyce určeném přímo pro ně.

[Ladicek]

Já si dovedu představit

htmlBuilder.html {
  head {
    title("XXX")
  }
  body {
    h1("XXX")
    p("Pwned!")
    hr()
    small("(c) 666 AD by Da DeviL")
  }
}

Jako bonus můžu vyrefaktorovat společný kus kódu ne do vedlejší šablony, ale do samostatné funkce. A tak. Ale to je spíš hračka, obávám se, že webaře bych do toho nedonutil – a ještě bych se bál, že to začnou mršit, protože jsou to houby programátoři

[xkucf03]

Jenže tím jsi akorát nahradil ostré závorky složenými, ale efekt z toho žádný není*. Přijde mi to zbytečné konvertování jednoho jazyka (HTML) na jiný (nějaký programovací) a zase zpět. Přitom to jde jednoduše tak, že člověk píše celkem obyčejné HTML (se vším, na co je zvyklý a např. s atributy, BTW: ty bys v tom tvém zápise řešil jak?), akorát mu dá jinou hlavičku (JSP) a občas do něj vloží ne-HTML značky pro iterace nebo získání hodnot z nižší vrstvy programu. Použití jiných jazyků navíc programátora intuitivně vede k tomu, aby aplikaci dělil na logické vrstvy a nematlal všechno do jednoho (přinejmenším oddělení prezentační vrstvy od obchodní logiky).

Navíc JSP je schopný upravovat i člověk, který zná HTML, ale neumí Javu – kdežto v tomhle případě by se musel učit nějakou novou syntaxi, kterou v životě předtím neviděl. Např. si bude chtít k nějakému elementu přidat class nebo id atribut, aby si je mohl nastylovat v CSS. V JSP to zvládne hravě, tady to udělá jak?

*) znovupoužitelnost se řeší už odjakživa, u statického HTML pomocí rámců, jinde pomocí includů, fragmentů atd.

[Marek Bernát]

Vtip je v tom, že keď už máš tie základné objekty, tak ťa nejaké HTML nemusí vôbec zaujímať. Máš obecne komponent výstupu a ten má metódu to_HTML(). No a každý komponent je zložený z ďalších komponentov, ktoré si nejak usporia a vôbec ho nezaujíma, čo je vnútri tych objektov, proste klasické OOP s dobrým zapuzdrením. Navyše vďaka tomuto prístupu ti stačí predefinovať tie low-level metódy a získaš v prípade potreby iný výstup ako HTML, čo môže byť celkom užitočné.

Btw, rôzne vrstvy programu si musíš oddeľovať aj v rámci jedného programovacieho jazyka, na to práve slúži abstrakcia. Ak potrebuješ viac jazykov, aby si toto zvládol, tak je niečo zhnité v tvojom programovaní Navyše viac jazykov sa medzi sebou často ťažkopádne integruje (tzv. "abstraction leaking"), čo je častý kameň úrazu templatovacích enginov, ktoré buď nepodporujú skoro nič a je to len HTML, takže v reále nepoužiteľné, alebo podporujú efektívne celý nový jazyk s premenými, includmi, iteráciami, vetvením, atď. Obzvlášť odporné je to v prípade riadiacich štruktúr v XML, to by som chcel vidieť neprogramátora ako takéto templaty používa Preto je jeden jazyk efektívnejší -- tie abstraction leaky medzi jednotlivými úrovňami sú menej problematické.

[Marek Bernát]

s/usporia/usporiada/

[xkucf03]

 

Máš obecne komponent výstupu a ten má metódu to_HTML()

To mi nepřijde moc vhodné, protože každá třída musí implementovat tuto metodu a vedle toho metody pro další formáty (RTF, LaTeX, XML, PDF, cokoli…) → takže mám jednak tenhle konvertovací kód rozlezlý po všech třídách a jednak se mi míchá konvertovací kód (metody to_něco()) s vlastní logikou těch objektů. Takže považuji za lepší příslup, když jsou tyto objekty nezávislé na výstupním formátu a čisté (obsahují jen obchodní logiku, ne věci z prezentační vrstvy) a konvertování na výstupní formát dělá nějaká komponenta/vrstva pro to určená (s tímhle přístupem můžu také např. přidat další výstupní formát (konvertor), aniž bych zasahoval do tříd, která nesou data).

 

 

Ak potrebuješ viac jazykov, aby si toto zvládol, tak je niečo zhnité v tvojom programovaní

Tohle sis mohl odpustit. Ono hezky a čistě může psát člověk i v jakkoli mizerném jazyce, jen to prostě dá víc práce a je to méně příjemné, než když je ten jazyk/platforma navržen tak, jak se hodí k tvému záměru. Navíc to jak tě ten jazyk/platforma vede je důležité pro začínající programátory: podívej se na kód průměrného začínajícího PHPčkaře, najdeš tam namaštěné stránky, kde se míchá SQL, HTML, PHP, CSS, JS… dohromady, bez jakéhokoli dělení na vrstvy – a na kód průměrného začínajícího webového Javisty* – najdeš tam alespoň rozdělení na prezentační vrstvu (JSP/HTML) a ten zbytek (kód v Javě) nebo v lepším případě, prezentační vrstvu, obchodní logiku a vrstvu pro práci s databází.

 

*) i když i tady jsou odstrašující výjimky.

[Marek Bernát]

Ale ten konvertovací kód by nebol rozlezený všade, len v tej najnižšej vrstve objektov, ktorá skutočne implementuje HTML. Zvyšok by už boli proste kompozície objektov. A keď pošlem správu :toHtml objektu Auto, tak ono tú správu prepošle všetkým objektom, z ktorých sa skladá, napríklad niekoľkým objektom Koleso, atď. A keď budem chcieť zmeniť formát výstupu, tak proste pošlem správu :toPdf a zasa sa to vykoná až v tej najnižšej vrstve. Nikto nemusí nič implementovať, nikde sa nemusí nič prasiť. Na tomto je založené pravé OOP: posielanie správ medzi nezávislými samostatnými entitami. V Jave to samozrejme rozumne nejde, tam triedy slúžia len ako také lepšie structy z C doplnené o dedičnosť a o moc viac do hĺbky v OOP štýle takmer nikto neuvažuje. Takže vo výsledku Java nie je na takéto veci vhodná a musia sa hľadať rôzne obchádzania typu patterny, visitor triedy, ďalšie vrstvy a komponenty a neviem čo všetko. Free your mind Btw, netvrdím, že Smalltalk je nejaké univerzálne riešenie. Ten dynamický message dispatch prináša samozrejme problémy s výkonnosťou, ktoré sú stále predmetom výskumu ako to všetko cacheovať a optimalizovať, aby to aspoň trochu šlapalo. Ale je to rozhodne užitočné v tom, že to človeku trochu rozšíri pohľad na programovanie a to IMHO neuškodí nikomu, kto si chce hovoriť programátor.

To PHP/Java si trafil celkom dobre (podľa mojich skúseností), ale nebude to skôr jednak tým, aké sú k dispozícii tutoriály (z čoho iného sa začínajúci programátor učí?) a jednak tým, že PHP je viac používaná pre také domáce skriptenie a Java skôr korporátne, ktoré vynucuje striktný prístup k programovaniu? Alebo ešte presnejšie, že PHP je dynamický jazyk a Java statický? Možno to môže robiť začínajúcim programátorom problém (ja napríklad som začínal v Basicu, potom Pascal, potom C++, potom Java). Tak či onak, začínajúci programátor ma v tomto vlákne veľmi nezaujíma, bavíme sa o pomerne pokročilých veciach a teda predpokladám aspoň nejaké skúsenosti a nejaký talent (čím nechcem povedať, že niečo z toho nemáš, len že nerozumiem, prečo sem tých začínajúcich programátorov ťaháš).

[Ladicek]

Ony šablonovací systémy jsou leckdy pěkný ksindl. A JSP je z nich ksindl nejksindlovatější; s tvrzením, že JSP je schopný upravovat i člověk, který zná jen HTML, rozhodně nemůžu souhlasit. Ve starším kódu narazíte na hory skriptletů, v novějším na JSTL a EL (a často i na ty skriptlety, pokud nad servletovým kontejnerem nesedí nějaký rozumný framework). Asi nejlepší oddělení kódu od HTML jsem viděl ve Wicketu.

Nenavrhoval jsem tohle používat. Přinejmenším ne pro HTML. Jen jsem chtěl ukázat, že to triviálně jde. Atributy se v MarkupBuilderu mimochodem řeší pojmenovanými parametry (které byste vy, neúnavní zastánci kontrolovaných výjimek, anonymních vnitřních tříd a podobných zbytečností, rozhodně měli po Javě požadovat zvýšeným hlasem a rytmickým bušením do štítů, eh, stolů, protože narozdíl od uvedeného opravdu výrazným způsobem zvyšují čitelnost kódu).

[xkucf03]

Jako příklad jsem uváděl, že tam neprogramátor může snadno doplnit atribut elementu – protože je to vlastně normální HTML, akorát si nebude všímat těch prvků z jiných jmenných prostorů (jsp, c, fn…) – kdežto kdyby to byla nějaká jiná speciální syntaxe, tak tu vůbec nezná.

BTW: skriptlety jsou prasárna a je potřeba je použít jen opravdu výjimečně.

[xkucf03]

Ad JSP: teď jsem v tom psal program SQL Výuka – jasně, je to jednoduchá aplikace, ale dělalo se mi v tom dobře, přestože jsem použil čistá JSP bez nějaké další nadstavby.

[Marek Bernát]

Lenže uvedom si, že pre tvoj Web už všetky nástroje existujú. To ale nie je pravda v každom obore. Čo ak by si nemal to JSP? Ako by si postupoval? Zrejme by si to prasil v kóde. Pochybujem, že by si totiž JSP sám navrhol a implementoval, lebo to nestojí za to. V poriadnom jazyku, keď to človek potrebuje, tak si ho rozšíri a je to oveľa menej práce ako písať "yet another new tool".

Otrava by to v Jave samozrejme bola, lebo Java nie je dobrý jazyk Väčšinou je na takéto účely jediná dobrá možnosť DSL -- či už standalone ako JSP, alebo metaprogramované priamo v jazyku.

Nedovedeš si to představit? To ma ale vôbec neprekvapuje, lebo dokazuješ stále znova, že si nevidíš za špičku svojho Javistického nosa Odporúčam ti naštudovať si niečo o Seaside a Smalltalku, možno ti to trochu rozšíri obzory

[xkucf03]

Po Seaside jsem už trochu koukal a chystám se ho víc prozkoumat – vypadá totiž jako smysluplné a praktické využití Smalltalku (narozdíl od všech akademických a teoretických využití, které mi přišly dost na nic). Ovšem jestli to k něčemu použiji není jisté – ona jedna věc je jazyk a druhá věc platforma…

[Marek Bernát]

Pre zmenu s tebou asi vcelku súhlasím. Ale Seaside je len jedna z možných aplikácií Smalltalku a nemyslím si, že jediná zmysluplná a praktická. Tie čisté OOP myšlienky sa dajú určite použiť na mnohé ďalšie oblasti. Web je holt jediná, ktorej sa dostalo trochu pozornosti.

[thingie]

Já tedy nevím, ale když někdo třikrát napíše céčkovou for smyčku v různých jazycích, z nichž ani jeden nejspíš není céčko, tak to mi přijde docela špatný.

[default]

Já jsem to s dovolením pochopil

Tak to jseš první. A zároveň sis tím tady totálně zrušil reputaci, protože já jsem tu oblíbenej jako švábi (cucarachas) v posteli.

[Ladicek]

Kombinátory jsou speciální případy objektů

Btw jsem javista.

[Marek Bernát]

Všetko je špeciálny prípad niečoho iného, keď sa to zoberie "kolem a kolem" (na toto by v slovenčine malo byť nejaké spojenie!). Btw, pokojne mi sem napíš 5 riadkové vyjadrenie toho kombinátora v Jave, ak sa to dá, som veľmi zvedavý

Bad for you!

[Ladicek]

Ani mne nehne, to bych musel nejdřív pochopit, proč někdo programuje operátor pevného bodu, když snad každý programovací jazyk podporuje rekurzi implicitně. (Hlavně když chce dokázat, že nějaký jazyk je hrozně akademický.) No a pak bych taky musel pochopit, co je to doopravdy zač Četl jsem o tom jenom v souvislosti s překladem rekurze do lambda kalkulu a to mi úplně stačí. Takže díky, tenhle úkol s radostí vzdávám

Bad? Nemyslím. Akorát mne občas nasere, že při vhodné konstelaci hvězd a obětovaných panen zvládnu psát rychleji, než IDE zobrazovat (To k těm pár příspěvkům o všemocnosti IDE, které se tu objevily. Příslušný stroj je nějaký Core 2 Duo Intel s 4 GB paměti, Debianem testing, KDE 4, a IDE je IntelliJ IDEA 7.)

[Martin Böhm]

Na takhle pro Javu poddimenzovanem stroji bud rad, ze Ti jede Hello World :o)

[Ladicek]

No, sice jsem to nezkoumal podrobněji, ale řekl bych, že výskyt těch situací by koreloval s výskytem situací, kdy má u mne Firefox přes 2 GB VIRT a přes 1 GB RES, čímž efektivně přebíjí i tu Javu

[Martin Böhm]

Iceweasel mi v soucasne chvili docela dobre slape i na 320 MB RAM stroji. Asi se prede mnou snazi. :o)

[Ladicek]

Nevím, třeba je problém v debianím 64bitovém buildu. Nestává se to často, tak dvakrát do měsíce

[alblaho]

To je přece známá chyba. Ten build leakuje porno!-)

[Marek Bernát]

Čítal si aj tie komentáre pod blogom? Tam to ten človek totiž vysvetlil A niekto iný uviedol aj nerekurzívnu verziu v Scheme (ak som to dobre pochopil), ktorá mala 5 riadkov A vôbec, nešlo o tento konkrétny prípad. Dajú sa v Jave rozumne realizovať veci z funkcionálnych jazykov (hlavne higher-order functions; uzávery tam už prakticky sú), aby to nebol podobný bastl ako v tom článku? Zrejme by mohlo ísť nejak to nasimulovať pomocou objektov, ale neviem. Tak aspoň ľahší príklad pre teba, prepíš do Javy:

(define (compose f g)
  (lambda (x) (f (g x))))


(Btw, keď už sme pri tomto, nenájde sa tu niekto vzdelaný, kto tuší, prečo má CL oddelené menné priestory premenných a funkcií? Jednak mi to pripadá nesystémové a jednak sa ten horeuvedený kód musí písať

(define compose (f g)
  (lambda (x) (funcall f (funcall g x))))

, čo je oveľa horšie ako Scheme, nehovoriac o kvôli tomu prítomnej zbytočnej #' syntaxi a tiež zbytočnému flet, ktoré robí to isté, čo let, len pre funkcie (čo je nakoniec tiež len syntaktický cukor pre lambdy). Vždy keď prídem na chvílu do kontaktu so Scheme tak ma ohromí, aký je to čistý a pekný jazyk a mám z CL skoro depresiu. Ale nie musím s CL vydržať, kým zo mňa nebude guru a potom sa môžem presunúť ku Scheme ).

Njn, pamätám sa na svoje ostatné skúsenosti s Eclipse, alebo čo to bolo za monštrum. Najprv to nechcelo poriadne ani naštartovať a potom každý úkon trval minútu. Ale to boli ešte časy, kedy sa pamäte počítali v MB

[Ladicek]

OK, přečtu si ještě komentáře. Ale s rekurzí na mne nechoďte

Jinak myslím, že s funkcionálními věcmi to bude v Javě (samozřejmě) bledé. Stačí se podívat na Functional Javu, což je implementace různých věcí v čisté Javě. Příklady bez BGGA uzávěrů versus příklady s uzávěry dávají nahlédnout, jaký to bude opruz.

Jak už jsem říkal jinde, vyjadřovací schopnosti Javy jsou mizerné. Když Bertrand Meyer ve svém eseji Software Architecture: Object-Oriented Versus Functional (třináctá kapitola Beautiful Architecture) "dokazoval", že kombinátory jsou speciální případy objektů a vůbec že objektově orientované programování je "nadřazené" funkcionálnímu, a on to není hloupý text, požadoval jako nezbytnou součást takového objektově orientovaného jazyka agenty. Tak se v Eiffelu říká uzávěrům Proč je na tom Java tak mizerně? Protože si holt kucí mysleli, že některé nutnosti přechytračí. Naštěstí dneska už si to nemyslí tak jednoznačně.

[Marek Bernát]

Java s uzávermi vyzerá už trochu ako programovací jazyk, ktorý by som nehodil rovno na smetisko

Ja neviem, vždy som si myslel, že je to naopak, že pomocou uzáverov už nie je problém implementovať OOP. Že to nejde rozumne aj naopak ma celkom prekvapuje. Ale nič lepšie ako nejaké anonymné triedy asi človek nevymyslí (a že to teda bol výmysel za všetky drobné).

[Ladicek]

Ono jde v případě Javy v zásadě jenom o lepší syntaxi pro anonymní vnitřní třídy (ty už fakticky, z pohledu překladače, lexikální uzávěr vytváří). BGGA se mně osobně líbí nejvíc, ale ani CICE podle Joshe Blocha není tak hrozné.

Jinak lexikální uzávěry nejsou jenom věcí funkcionálního programování. Když vezmete procedury v Pascalu, tak vnořená procedura taky vytváří lexikální uzávěr Je to věc léty prověřená, a například James Gosling tvrdí, že původně se uzávěry do Javy nedostaly hlavně kvůli nedostatku času.

[Marek Bernát]

Syntax je v tomto prípade veľmi dôležitá. A nehovoril si náhodou v tom minulom flame, že anonymné triedy nie sú plnohodnotné uzávery? To CICE vyzerá ako javascript, len function je nahradené návratovou hodnotou. Je to v pohode, ale ja osobne mám ale najradšej syntax \x -> 2 * x, alebo podobnú, kde je explicitne vidieť tú matematiku

Tak samozrejme. Ono záleží, o čom presne sa bavíme v tomto vlákne a to som už ja stihol zabudnúť Uzávery a lambda funkcie sa totiž často zameňujú. Tak isto podpora higher-order functions s tým síce súvisí len nepriamo, ale jedno bez druhého je krátko povedané na ****

[Ladicek]

Úplně plnohodnotné nejsou, proměnné z lexikálního uzávěru lze jenom číst (původně mělo být možné do nich i zapisovat, ale céčkaři se báli, že nepoznají alokaci na haldě…), to řeší BGGA i CICE, a chybí nelokální návrat (ten je v BGGA možný).

Ale v zásadě funkce vyššího řádu máš – jsou to objekty tříd, které implementují nějaké jednometodové rozhraní (Runnable, Callable, Function, jak kdo chce). To platí pro objektové jazyky obecně, a holt v Javě je to kvůli syntaktickému balastu skoro nepoužitelné.

Jo taky už si nepamatuju, o co nám vlastně jde

[Marek Bernát]

No práve, takže to nie je extra použiteľné. Samozrejme, lepšie jak klincom do oka, ale tie najkrajšie vlastnosti uzáverov práve plynú z interakcií blokov medzi sebou. Hoci v praxi to človek možno až tak často nepoužije -- zvlášť v Jave, kde sú aj ďalšie možnosti, ako niektoré veci robiť.

V zásade... Ja som zasa v zásade milionár -- stačilo by, aby som vyhral v lotérii

[Pavel Křivánek]

Samotné uzávěry lze implementovat jako objekty, jako to dělá třeba Self.

www.fit.vutbr.cz/study/courses/TJD/public/0304TJD-Svec.pdf

 

[Marek Bernát]

Nie som si istý, či tomu rozumiem poriadne, ale tie bloky sú tam navyše ako špeciálna konštrukcia, nie? Nie je to niečo, čo by sa dalo postaviť z ostatných vlastností Selfu. Ale strieľam od boku, celý článok som ešte nečítal, tak budem rád, ak ma opravíte.

[Pavel Křivánek]

Ano a ne

Bloky jsou speciální konstrukce ze syntaktického hlediska. Jedná se vlastně o literály. Podobně jako literál pro řetězec vytvoří objekt řetězce, tak blok vytvoří dva objekty. Jinak v objektovém modelu Selfu se jedná víceméně o běžné objekty, kde proměnné jsou sloty, lze s nimi běžně manipulovat, přidávat rodičovské sloty apod.

Sice navíc používají výjimečné typy slotů a při invokaci metody bloku virtuální stroj klonuje některé objekty a naplňuje hodnoty několika slotů, ale stejně tak si lze představit, že se totéž může dělat i ručně. Pokud se odhlédne od konkrétní implementace v Selfu, lze na jeho objektovém modelu demonstrovat, jak se jednoduše a elegantně dají (mimo věci jako třídní dědičnost, jmenné prostory atd.) v systému založeném na prototypech a delegaci vytvořit uzávěry.

[Marek Bernát]

Aha, takže takto je to. To som z toho článku fakt nepobral, ale skôr to bude moja chyba ako chyba článku

To znie moc dobre, určite sa chcem tieto veci časom naučiť. Ale je škoda, že Self už umrel (podľa toho, čo som čítal) a Smalltalk asi na tom tiež nie je moc ružovo, ak sa nemýlim. Ľudia proste nemajú pre tie najlepšie veci pochopenie. Ale snáď sa vždy nájde pár ľudí, ktorí zachovajú myšlienky minulých generácií a uchránia ich pred záplavou Javistov

[Ladicek]

Ľudia proste nemajú pre tie najlepšie veci pochopenie.

To ale fakt nejsou ani trochu nejlepší věci. Prostě zvolili menší abstrakci. Mainstreamové jazyky volí větší abstrakci, skrývají před programátorem víc věcí, a věřte nebo ne, ono to často vůbec nevadí. A upřímně řečeno – kdo chce homoikonické jazyky? Kromě teoretiků nikdo. Ono to má sice na pohled hezké efekty, ale na druhý pohled zas tak hezké nejsou a jiné hezké efekty chybí. K čemu implementovat třídy v jazyce A, když jazyk B už je má implementované a existují pro něj nástroje, které jsou výrazně bližší uživateli?

Chci říct: dospělé kompromisy. Nekompromisní jazyky (Scheme, Self, Haskell) jsou z určitého úhlu pohledu bezcenné. Ano, ve výzkumu hrají nezastupitelnou roli. A dál? Ach, a dál. To už není naše starost. Pravděpodobně není náhoda, že Microsoft Research platí Simona Peytona Jonese za vývoj Haskellu, ale Microsoft (když už, tak) prosazuje F#. Tož asi tak.

[Marek Bernát]

Mainstreamové jazyky fungujú rovnako ako každý mainstream: chcú byť prístupné masám. Kvantita na úkor kvality. Primitívne mainstreamové jazyky sa dajú vymyslieť vždy, ale v jazykoch ako Lisp, Haskell, atď. žijú netriviálne myšlienky s veľkým potenciálom a ja dúfam, že nezmiznú kvôli záplave priemernosti, ktorú požaduje trh.

Prečo hádžeš do jedného pytla Scheme, Smalltalk a Haskell? V plne funkcionálnych jazykoch je budúcnosť (hint paralelizácia, formálne dokazovanie, unit testing) a v najkritickejších aplikáciách nájdeš práve tieto jazyky (Erlang pre telekomunikácie, rôzne Lispy vo výskumných strediskách). Jasné, že trhu, ktorý požaduje primitívnu business logiku stačí Java, ale bolo by skutočne smutné keby myšlienky Churcha, Turinga, McCarthyho, Curryho a mnohých ďalších priekopníkov nakoniec zdegenerovali do jazyka ako je Java.

V každom prípade, začína to byť príliš filozofické, radšej by som to už nechal tak. Myslím, že obaja poznáme názory toho druhého a niet tu o čom diskutovať.

[Ladicek]

Proč nepokračovat, ta paralelizace je zajímavé téma. Nevím kde jsem to četl, ale nikdo pořádně nedokázal, že funkcionální jazyky jsou pro paralelismus opravdu to pravé. Žádný stav? To naprosto odporuje veškeré lidské zkušenosti a intuici v modelování reality. Změna je přirozená skutečnost, a čistě funkcionální jazyky ji popírají. Proč? Asi to přinese nějaké zajímavé myšlenky, ale zrovna tak to asi nebude něco, co se opravdu rozšíří. Eiffel třeba razí konvenci (ačkoli ji nevynucuje), že metody, které mění stav, by měly být striktně odděleny od metod, které zjišťují stav (říkají tomu Command Query Separation), to taky může mít silně pozitivní vliv na paralelismus (stačí, aby Command metody byly linearizovatelné).

A vůbec, kdykoli mám pochyby o něčem z praktické či teoretické computer science, řídím se jedinou myšlenkou: počítače mají sloužit lidem, ne naopak. Slovo mainstream nemusí mít nutně negativní konotace

Jo a formální transformace nebo kritické aplikace? Pravděpodobně není náhoda, že nejmenovaný jazyk navržený na zakázku amerického ministerstva obrany je procedurální (s prapodivnými objekty)

[Marek Bernát]

Možno to nikto nedokázal, ale je to celkom zrejmé Keď nie je explicitný stav, nie je čo posrať. Funkcia má len vstup a výstup, je triviálne ju skontrolovať (unit-testing), a výpočty vnútri funkcie sa dajú automaticky paralelizovať a preusporiadať, lebo nemôžu meniť stav zvyšku sveta. Ako chceš toto riešiť inak ako neprítomnosťou stavu? Leda tak priamym paralelným programovaním, ale prečo to robiť, keď to za nás môže spraviť počítač?

Ale s tým stavom to preháňaš. Aj funkcionálne jazyky majú stav. Na stacku predsa! Keby žiadny stav nebol, tak to by bol skutočne problém Ničmenej, je to na prvý pohľad neintuitívne, to súhlasím, ale dá sa na tento štýl zvyknúť (to za prvé) a za druhé pohľad "všetko je funkcia" zasa nahráva matematickej prirodzenosti, ktorá je oveľa fundamentálnejšia než nejaká ľudská -- skutočne netuším prečo by ľudská prirodzenosť = sedliacky rozum mali mať niekde fundamentálny význam. Neplatí to vo fyzike už 100 rokov (hoci sa niektorí fyzici vtedy bránili zubami nechtami), prečo by mal platiť v informatike?

S tým slúžením plne súhlasím. Preto by programovanie malo byť hlavne o hraní sa s novými myšlienkami a snahou o ohýbanie počítača do krajných medzí a nie o nasycovaní trhu priemernými nástrojmi a ľuďmi.

O ktorý nemenovaný jazyk sa jedná? US ministerstvo obrany malo prsty v polovici vecí v informatike, takže ako hint mi to úplne nestačí

[Ladicek]

Ono totiž programování není matematika. To si vážně myslím Programování je v první řadě vyjadřování se programovacím jazykem. (Trochu mimo téma: proto si myslím, že multiparadigmové jazyky mají větší úspěch než ty nekompromisní. Prostě lidi se někdy vyjadřují tak a někdy onak, jak jim to zrovna vyhovuje.) Funkcionální paradigma je nesporně velmi užitečné, když se podíváte na zpracování velkých objemů dat, tak dneska je moderní používat MapReduce – ale implementované v C++ nebo v Javě (Google, Yahoo, Facebook, atd.). High performance computingu AFAIK pořád dominují Fortran a C++, a i tam se dělá s clustery o stovkách nebo tisících uzlů. Skoro bych šel tak daleko, že bych tvrdil, že funkcionální paradigma je důležitější než funkcionální jazyky

Ta fyzika mi nepřipadá jako dobrý příklad. Ano, víme, že v mikrosvětě platí zákony kvantové fyziky (ale těm podle vyjádření důvěryhodných lidí stejně nikdo doopravdy nerozumí) a v makrosvětě zase zákony relativistické fyziky (těm prý rozuměli asi tři lidi na světě ), ale v denní realitě pořád končíme u Newtona až Maxwella. A právě tak přemýšlíme. Souhlasím, že se dá (a je to výhodné) naučit myslet v některých funkcionálních pojmech, ale nemít přiřazení a vedlejší efekty?

Pokud tomu dobře rozumím, funkcionalisti jdou na věc asi tak: zbavíme se stavu a vedlejších efektů, a můžeme paralelizovat do aleluja. Ale znám i jiný postoj, který mi přijde bližší: paralelismus je nedeterministický, proto se o něm tak špatně uvažuje, a proto bychom ten nedeterminismus měli co nejvíc omezit.

Přijde mi to trochu v protiváze, ale třeba není. Když tak nad tím přemýšlím, tak se mi totiž zdá, že nejlíp se tomu nedeterminismu dá vyhnout aktérovým systémem, který mají v Erlangu. Tam si každé "vlákno" jede samo svou vlastní cestou a nemůže zasáhnout do života žádnému jinému, jen mu poslat zprávu. Ale aktérový systém je i v té Scale, a docela mi připomíná adovská (to je odpověď na tu poslední otázku) rendezvous, a není přece důvod, aby aktér nemohl mít stav a vedlejší efekty, ne?

Naopak v Haskellu honí softwarovou transakční paměť. Jim to asi skvěle funguje, právě proto, že nemají vedlejší efekty ani přiřazení, ale už v Clojure (to je takový Lisp pro JVM) upozorňují na to, že transakční proměnné musí být neměnitelné a že by se v transakcích nemělo dělat IO. A když připočtu režii, kterou STM může mít (další úroveň "nepřímosti" navíc, restartování transakcí), už mi to zdaleka nezní jako tak skvělý nápad.

Ale je možné, jak píše níže deda.jabko, že jsem příliš krátkozraký. Ostatně toho o paralelismu zase tolik nevím. Ale myslím si, že někudy skrz odstranění toho nedeterminismu vede cesta, protože lidi přirozeně přemýšlí paralelně a přitom imperativně.

[Marek Bernát]

Nie je to síce úplne matematika, ale vyjadrovanie myšlienok má k matematike veľmi blízko. Zvlášť ak si človek poriadne tie myšlienky premyslí, tak si často uvedomí, že sa dajú kompletne formalizovať (nehovím, že je to vždy nutné -- tiež sa občas s programom len tak hrám a nerozmýšľam nad tým, čo robím matematicky. Ale v prípade potreby sa to dá).

Btw, čo sa multiparadigmových jazykov týka, tak neviem. Je len veľmi málo úplne čistých jazykov a s väčšinou z nich nemá takmer nikto hlbšie skúsenosti, takže závery typu "multiparadigmové jazyky sú lepšie" mi pripadajú veľmi ukvapené a založené len na pozorovaní súčasného stavu.

Ale rozumieme, to len nevzdelanci hovoria, že nie Fyzika je o čo najlepšej aproximácii reality matematickými modelmi. Svetu ako takému možno nebudeme rozumieť nikdy, rovnako tak tomu, prečo je popísateľný matematikou, ale samotným matematickým štruktúram (Hilbertov priestor v kvantovke, difeomorfizmy v obecnej relativite) a to, akým spôsobom popisujú svet, rozumieme veľmi dobre (teda, rozumieme my fyzici -- zvyšok populácie radšej šíri sto rokov staré FUDy bez nejakej snahy aspoň trochu pochopiť svet). Samozrejme, že pri praktických aplikáciách sa to zasa redukuje na klasickú fyziku, ale bez znalosti hlbších teórií nikdy nepochopíš, prečo ti tá klasická teória z ničoho nič prestane fungovať

Jasné, že sa o tom uvažuje ťažšie, lebo to nie je blízke tomu sedliackemu rozumu. Ale ak sa chceme dostať v poznaní ďalej, tak by sme sa mali naučiť uvažovať aj v nových pojmoch. Sedliacky rozum je len o zvyku a podľa mňa nie je a priori problém naučiť sa premýšľať funkcionálne. Rovnako ako sú dobrí fyzici bez problému schopní rozmýšľať v termínoch kvantovej teórie, ktorá ľuďom ako ty pripadá nepochopiteľná. Ale samozrejme to vyžaduje dosť veľa mentálneho úsilia, kým sa človek aklimatizuje, bez toho to holt nejde.

Hm, tak zrejme bude aj viac možností ako programovať paralelne. Neviem, či to tak vyznelo, ale ja nechcem všetku informatiku nahradiť funkcionálnym programovaním Len by stálo za to sa ho poriadne naučiť a vedieť sa vyjadrovať aj v jeho jazyku. Človeku to potom určite pomôže aj v tých multiparadigmových jazykoch.

Ja toho tiež o paralelizme zas toľko neviem. Teda, viem toľko, že je pekelne ťažké zaručiť, že všetko bude fungovať. Funkcionálne programy ti toto zaručia automaticky. Len zostáva otázka, či nám vždy to funkcionálne programovanie uľahčí prácu, alebo môže byť naopak náročnejšie premýšľať funkcionálne, než navrhovať aplikáciu paralelne priamo (tj. rozmýšľať o každom vlákne, synchronizácii, kto má kedy a kam prístup a teda čo treba zamykať, atď). Osobne mám pocit, že funkcionálne programovanie (a možno aj iné paradigmy) sú o abstrakčnú úroveň vyššie od toho priameho navrhovania. Je to ako prechod strojový kód -> funkcie + výrazy + premenné a už len necháš to kompilátor skompilovať, nestaráš sa o detaily. Ale pokojne sa môžem mýliť

[Ladicek]

Neříkám, že multiparadigmové jazyky jsou lepší, říkám, že jsou úspěšnější. Takže ano, pozorování současného stavu. Btw, proč asi je neoficiálním sloganem Haskellu avoid success at all costs?

Souhlasím s hledáním nových cest, ale protože nejsem matematik (natožpak fyzik; btw že nikdo nerozumí kvantové fyzice tvrdil Feynman , ale dobře, možná dneska už je to jinak), tak v programovacích jazycích zůstávám při zemi. Programming languages researcher ze mne tedy nikdy nebude, čili tady nakrásně můžu jen blábolit, ale to snad nemusím připomínat.

Ještě k tomu paralelismu: to je právě ono, nemuset přemýšlet o sdíleném stavu, o zamykání a tak. Čistě funkcionální přístup je jen jeden z možných. A už dneska má výsledky, i javisti s oblibou používají bezestavové a neměnitelné objekty – v některých situacích je to triviálně možné a nevyžaduje to žádnou velkou změnu přemýšlení. Takže já to nezavrhuju.

Ale jsou i jiné situace. Typicky: server obsluhující každý požadavek klienta v samostatném vlákně, ta vlákna spolu nijak neinteragují, jednoduchý paralelismus, to zvládne malé děcko, imperativní přístup naprosto nemá problém. Nebo z opačného konce: sdílený seznam, strom, mapa, cokoliv, k čemuž přistupuje kdokoliv kdykoliv. To se objevuje na vědeckých konferencích, dokonce jsou na to udělovány patenty (nedávno tu byl v Jaderných novinách takový případ, lock-free kruhový buffer, jehož autor tuším za RedHat podal patentovou přihlášku; nebo byl wait-free?).

A tady se svou fantazií končím – to všechno je přirozené, ale jak to skloubit dohromady? Minimálně v současnosti ani ten čistě funkcionální přístup není řešením, už proto, že různé algoritmy (třeba grafové) pro čistě funkcionální prostředí jsou teprve předmětem výzkumu

[Marek Bernát]

Tak to áno, lenže úspech nemá u mňa žiadnu váhu. Windows je úspešný a je to shit (zveličujem, nie je to úplný shit, ale Linux ukazuje ako môže vyzerať lepší OS a dá sa ísť oveľa ďalej). Myslel som, že sa bavíme o nejakých hypotetických kvalitách a nie len o kvantite

Feynman ovládal kvantovku dokonale a samozrejme len žartoval a mal na mysli to, že nevieme, prečo sa príroda chová tak čudne (z hľadiska sedliackeho rozumu) a prečo sa správa kvantovo (tj. prečo je popísateľná zrovna týmto matematickým modelom). Ale to nebudeme vo fyzike vedieť nikdy, takže to nie je relevantné. Dnes je to úplne rovnako, plebs šíri tieto FUDy, zatiaľ čo bystrý študent jej po pár rokoch štúdia fyziky rozumie dostatočne (samozrejme, vždy sa je čo učiť).

No ale veď tie cesty nemusíš hľadať ty sám Ja som tiež nenašiel ani jednu a s výnimkou vyššie citovaných pánov takých ľudí po svete moc nechodilo/nechodí Podstatné je byť schopný aspoň tieto myšlienky a ich veľkosť rozpoznať a uplatniť (v kontraste s arogantným ignorovaním všetkého, čo nie je mainstream -- toto sa netýka teba, ale mnohých účastnikov diskusie áno).

To je pravda, klient/server architektúra je tak bežná, že ma ani nenapadlo, jak je to jednoducho paralelizovateľné

Neviem, ja nezavrhujem ostatné postupy, ale pripadá mi to, že treba premýšľať nad vecami, ktoré sú v skutočnosti pri výpočtoch z istého hľadiska nepodstatné (ako tá paralela s assemblerom, kde človek musí volať zvlášť každú inštrukciu). To funkcionálne programovanie má samozrejme ďaleko k dokonalosti čo sa teórie týka, lebo prakticky celá computer science a graph theory je vybudovaná imperatívne a je otázka, či sa s rovnakou zložitosťou dajú všetky (alebo aspoň niektoré) algoritmy preniesť do funkcionálneho prostredia. Počkáme 50 rokov a uvidíme potom

[Ladicek]

Ale kvantita je důležitá. Existují kvanta programátorů, kteří budou používat takové ty javy, a právě pro ně existuje výzkum, který je veden na těch haskellech Ale souhlasím: uvidíme za 50 let. Jejda, nevím nevím, jak se budu na stará kolena učit kvantové algoritmy

[Marek Bernát]

Asi máš pravdu, ale ja sa tak nejak snažím tomuto druhu "programátorov" vyhýbať

Pred 60 rokmi boli na tom s obyčajnými algoritmami podobne ako my dnes s kvantovými (samozrejme za podmienky, že raz budú dobré kvantové počítače) a už vtedy dobrodruhovia vymýšľali algoritmy, o ktorých nebolo jasné, či ich vôbec niekto niekedy spustí. To bola holt pravá teoretická informatika

 

[deda.jabko]

Ale kvantita je důležitá. Existují kvanta programátorů, kteří budou používat takové ty javy, a právě pro ně existuje výzkum, který je veden na těch haskellech

to je jasne... jde videt, ze vyvoj se ubira dobrym smerem... do jazyku typu java a C# se dostavaji v cim dal tim vetsi mire funkcionalni veci... co naplat, ze zname uz pres 50 let. ale neni se cemu divit... staci se podivat do mistnich flamu a objevis tu par lidi ze ,,stare skoly'' tvrdit, ze GC je zlo... ;-]

to, ze je java dobra pro kvanta vyvojaru, je asi taky tezko oddiskutovatelny fakt. ale to nezmena, ze je dobra. java/c# ma tu vyhodu, ze se ji nauci pouzivat kde kdo... a relativne casto se mezi nima nejde i nekdo kdo ji umi pouzivat dobre. nicmene, nema smysl si zastirat, ze java ma radu nedostatku... a je jenom ukazka zoufalstvi z techto nedostatku delat ctnosti. prikladem bud ta skoro nutnost pouzivat IDE... (i kdyz nedavno, kdyz jsem psal jeden projekt pouzivajici hadoop, tak jsem to delal ve ViM a kompiloval to kombinaci bash+javac ;-]) ...dalsim hezkym prikladem, ze java ma urcity problem s expresivitou, budiz snaha vymyslet pro ni system pro metaprogramovani.... :-]]

[Ladicek]

To metaprogramování pro Javu by mne zajímalo, co konkrétně máš na mysli? Mně imponuje MPS, které asi před měsícem vyšlo v první ostré verzi, ale to je takové hodně neobvyklé. Jinak je určitě dobře, že do mainstreamu se dostávají funkcionální prvky (ostatně jsou už v JavaScriptu), ale má to svá ale a o tom už jsem tady vlastně taky psal.

Nesnažil jsem se tady ani tak vyzdvihovat Javu, jako poukázat na rozdíly mezi jazyky pro výzkum a jazyky pro použití v ošklivém světě plném průměrných programátorů

[deda.jabko]

Proč nepokračovat, ta paralelizace je zajímavé téma. Nevím kde jsem to četl, ale nikdo pořádně nedokázal, že funkcionální jazyky jsou pro paralelismus opravdu to pravé.

imho jeden z hlavnich problemu je, ze lidi si od paralelizace slibuji vic nez, co je mozne. a pak jsou zklamani z toho, ze to vlastne ani moc nefunguje. muzou za to podle me dve veci... prvni je, ze hodne algoritmu je ze sve prirozenosti sekvencni (mozna taky proto, ze lidi maji tendence myslet sekvencne) a dalsi vec se jmenuje amdahluv zakon.

vidim to na tom, jak nam chodi recenze na schemik... kdyz treba dosahujeme na 8-jadrovem pocitaci zrychleni 4-6x... recenzenti jsou to schopni strhat jako ,,unsurprising''... obvykle nasleduje pripominka, ze obycejne prekladace produkuji vyrazne rychlejsi kod... coz je dalsi problem... soucasne prekladace imperativnich/objektovych jazyku jsou tak dobre, ze se nikomu moc nechce zmenit typ paradigmatu programovani a s tim spojeneho mysleni.

[deda.jabko]

A upřímně řečeno – kdo chce homoikonické jazyky? Kromě teoretiků nikdo.

tak treba ja nebo paul graham. :-]]

[Ladicek]

Tak Paula Grahama netrumfnu, tohle je K.O. Zásah, potopená

[Martin Böhm]

Microsoft Research platí Simona Peytona Jonese za vývoj Haskellu, ale Microsoft (když už, tak) prosazuje F#. Tož asi tak.

Zavidis, vid? :o) Ale vazne - Ty si opravdu myslis, ze v propagacnim oddeleni Microsoftu hraje nejakou roli kvalita jazyku? Kdyz se podivam na mnozstvi investovanych penez do .NET a uzke spojeni s ostatnimi technologiemi Microsoftu, je (aspon mne) jasne, kteremu jazyku bude MS davat prednost.

[Ladicek]

Tak nevím, MS do hlavy nevidím, zato SPJ se netají tím, že dává přednost tomu, aby se Haskell nikdy nijak výrazně nerozšířil. Ostatně F# taky původně vznikl v Microsoft Research.

Jinak v Microsoft Research se snažili Haskell na .NET naportovat (a jsou i snahy dostat ho na JVM), ale prostě to k sobě tak moc nesedlo, že ten projekt zrušili.

[Marek Bernát]

V jakom zmysle nesadlo? Problém kompatibilty funkcionálneho jazyka a bežnej virtuálnej mašiny? Alebo išlo o niečo iné? A existuje nejaká funkcionálna virtuálna mašina (Parrot asi pre toto nejakú podporu mať bude)?

[Ladicek]

Jednak kompatibilita Haskellu s CLR (jiné funkcionální jazyky se tam napasovat dají, viz třeba ten F#) a jednak kompatibilita s existujícími dodNetími API (všechno se musí honit přes monády). Kdyžtak v tomhle rozhovoru je víc podrobností.

[Marek Bernát]

No, tak je pravda, že monády asi nie sú úplne ideálne na zapuzdrenie veľkého množstva API. Síce sa ľahko používajú, ale už nie tak ľahko tvoria -- hoci ma trochu prekvapuje, že sa ich tvorba v tomto prípade nedá nejak zautomatizovať, nejakým metaprogrammingom, alebo tak. Jak rieši side effecty F#? Kontinuácie, streamy, uniqueness, alebo ich proste pripúšťa alebo ešte niečo iné? Na článok idem pozrieť, dík.

[Ladicek]

F# není čistě funkcionální, má vedlejší efekty, přiřazení, měnitelné a neměnitelné objekty, a nemá líné vyhodnocování (aspoň defaultně ne, jestli tam je volitelně nevím). Prý to vychází z OCamlu.

[Marek Bernát]

Už som naňho pozrel. Vychádza z Camlu (hoci príklady na wiki v F# a OCaml sú úplne identické), a preto niektoré pokročilé vlastnosti OCamlu nemá. Napríklad som zistil, že OCaml má Camlp4 preprocesor, ktorý dáva prístup k AST a vyzerá to, že sa s tým dajú robiť rovnaké psie kusy ako s Lispovskými makrami. Fakt som netušil, že nejaké nelispovské jazyky podporujú metaprogramovanie, cool. ML rodinu budem musieť trochu doštudovať. Doteraz sa mi do toho nechcelo, lebo všetky ML jazyky vyzerajú na prvý pohľad rovnako ako Haskell (type inference, pattern matching, atď.) a líšia sa len v drobnostiach. Ale teraz už viem, že len na prvý pohľad; v tých pokročilých technikách (ku ktorým sa človek samozrejme tak skoro nedostane) sa líšia pomerne výrazne.

[Pavel Křivánek]

Self je stejně mrtvý jako obvykle, hrob má hned vedle Lispu . Zrovna před nedávnem jsem při návštěvě stránky selflanguage.org/ s potěšením zjistil, že se mu pár dobrodruhů stále ještě věnuje

 

 

[Marek Bernát]

Spomienka na Lisp budiž večne živá v spárovaných zátvorkách

[deda.jabko]

Btw, keď už sme pri tomto, nenájde sa tu niekto vzdelaný, kto tuší, prečo má CL oddelené menné priestory premenných a funkcií?

http://www.nhplace.com/kent/Papers/Technical-Issues.html

[Marek Bernát]

Vrelá vďaka! Som nad tým premýšľal už nejaký čas, ale nie je to nič kritické, človek si proste zvykne a používa ten CLkovský zápis, tak som po tom veľmi nepatrál. Len to po tom krásnom Scheme strašne bije do očí.

[podlesh]

Čítal si aj tie komentáre pod blogom? Tam to ten človek totiž vysvetlil A niekto iný uviedol aj nerekurzívnu verziu v Scheme (ak som to dobre pochopil), ktorá mala 5 riadkov

To je docela zajímavé porovnání: ta verze ve Scheme má sice 5 řádek, ale není ani o milimetr přehlednější než ta v Javě co jich má 50.

V každém případně z toho vím jen to, že se tam nějak vytvářejí funkce co vytvářejí funkce a těm se předávají funkce... ale dokud si to nenakreslím a nestrávím nad tím někdy den, tak stejně nebudu tušit co to vlastně má dělat.

No, ještě bych si to mohl někde přečíst.

[happy barney]

no a tu narážame na definíciu "čo je to čitateľnosť/prehľadnosť zdrojového kódu a ako je ovplyvnená skúsenosťami a mentálnymi schopnosťami čitateľa ?"

[Marek Bernát]

To je samozrejme pravda. Lenže v Jave strávite týždeň len nad tým, aby ste zistili, že ten kód neobsahuje viac informácie, než tých 5 Schemovských riadkov a zvyšok je proste balast primitívneho jazyka. Až dekódujete, čo sa tou Javou chce povedať v lambda kalkule, tak až _potom_ ste tam, kde ste v Scheme hneď na začiatku. Pre poriadok, mne to tiež dá solídnu námahu pochopiť ten kombinátor. To je ostatne dôvod, prečo sa neprogramuje priamo v lambda kalkule ani v Turingových strojoch, ale máme programovacie jazyky Ničmenej, niektoré konštrukcie sú veľmi užitočné a zvlášť ak vie človek v tom funkcionálnom programovaní chodiť, tak by asi uvítal, aby mohol svoje myšlienky napísať na 5 riadkov, skôr než písať tú Javovskú onaniu

[podlesh]

Kdepak týden, asi dvě minuty. Jistě, je to praxe, ale také je to absurdní příklad: veškerý "balast syntaktického jazyka" je zde jen a pouze syntaktická "hlušina" - závorky, klíčová slova, přetypování... Sice je to dobrá ukázka jednoho z problémů Javy, ale rozhodně nevypovídá nic o funcionálních, procedurálních, primitivních, neprimitivních (atd) jayzcích. Existují jazyky koncepčně podobné Javě, ale s mnohem menším balastem.

Přitom se dají snadno najít příklady jasné, nesporné a dokonce i praktické. Stačí obyčejné iterování kolekcí.

[Marek Bernát]

Tak to Vám gratulujem, ja som tú Javu asi v polovici vzdal, svoj čas viem tráviť aj lepšie (napríklad týmito flamemami ). Ničmenej, argument, že Java nedovoľuje vyjadrovať funkcionálne programovanie rozumne stále platí. A dúfam, že mi nechcete tvrdiť, že nie je praktické (hoci súhlasím, že ten článok bol veľmi nepraktický a zbytočný. Ale tak to už s ilustratívnymi článkami občas býva).

[podlesh]

Tak to Vám gratulujem, ja som tú Javu asi v polovici vzdal, svoj čas viem tráviť aj lepšie

Před deseti lety nebyl ani zdaleka takový výběr (tedy, pokud jsem chtěl aby mi za to ještě platili). Naopak Java a její anonymní třídy jsou na tom ještě relativně dobře.

A dúfam, že mi nechcete tvrdiť, že nie je praktické

Možná jsem to napsal nejasně, takže znova: dají se najít jednoduché, jasné a praktické příklady, kdy je funkcionální přístup jednodušší, praktičtější a přehlednější. Stačí třeba taková věc jako převod prvků v seznamy z jedné formy do druhé, nebo filtrování podle nějaké podmínky. Prostě map a filter (resp. remove-if-not, to jsem si nikdy nezapamatoval že CL má takhle pojmenovanou funkci filter, který génius to vymýšlel...).

[Marek Bernát]

Samozrejme a pred 70 rokmi sa človek musel uspokojiť s tým, že programoval pre virtuálnu mašinu v hlave Inak jasné, že keď sa chce človek uplatniť na trhu, tak si veľmi nevyberie. Ale práve preto by som bol rád, aby Java podporovala niektoré rozumnejšie konštrukcie.

No, samozrejme. A tých príkladov sa dá nájsť milión a v každom jednom z nich bude tá Java dosť hrozná (aj keď väčšinou oveľa menej ako v tom článku).

CL má strašnú kopu balastu, ale zrovna toto sa riadi logickými pravidlami, lebo má funkcie find, position, atď., z ktorých všetky akceptujú predikáty pomocou variantov -if a -if-not. Ale že je filter rozumnejší názov to je asi bez debaty. Len mi nie je jasné, ako by ste potom nazvali deštruktívnu verziu remove (tj. delete).

[podlesh]

CL má strašnú kopu balastu, ale zrovna toto sa riadi logickými pravidlami, lebo má funkcie find, position, atď., z ktorých všetky akceptujú predikáty pomocou variantov -if a -if-not. Ale že je filter rozumnejší názov to je asi bez debaty. Len mi nie je jasné, ako by ste potom nazvali deštruktívnu verziu remove (tj. delete).

U destruktivní verze je to jasné, ale že "remove" je nedestruktivní není zrovna intuitivní. Druhá věc pak je, že ta podmínka remove-if je opačně - predikát určuje co se má odstranit, zatímco u nedestruktivní verze chci typicky spíše něco vybrat.

Ale je to věc zvyku, samozřejmě.

[Marek Bernát]

 

Ale je to věc zvyku, samozřejmě.

Tak.

 

[Bluebear]

Všetko je špeciálny prípad niečoho iného

ROTFL

Za tento výrok bys zasloužil vavřínový věnec filozofa

[xkucf03]

A Object (např. v Javě) je speciální případ čeho?

[Marek Bernát]

To je predsa len jedna z mnohých inštancií triedy Class, nie? Takže špeciálny prípad jak vyšitý

[xkucf03]

Myslel jsem Object jako objekt (instanci) ne jako třídu. Ale stejně: třída Class je instancí čeho?

[Marek Bernát]

Ak ako objekt, tak to bola inštancia triedy Objekt a teda jej špeciálny prípad (z definície: trieda popisuje množinu objektov podobných vlastností). Trieda Class je pokiaľ viem inštanciou Class (netuším, jak je to presne v Jave ohackované), takže zasa len špeciálny prípad A ešte obecnejšie, je to špeciálny prípad programátorskej konštrukcie

[xkucf03]

Mícháš tu dvě věci dohromady:

1. objekt (instance) je speciálním případem své třídy. Např. Objekt o je speciálním případem třídy Object.
2. Třída T je speciálním případem třídy P (potomek svého předka) – tzn. dědičnost. Např. String je speciálním případem Objectu.

Ať tak nebo tak, vždycky se dobereme k nějakému kořenovému prvku a ten je speciálním případem čeho? Sama sebe?

[thingie]

To je tak roztomile naivní.

[xkucf03]

I kdybychom přijali názor, že „třída je taky objekt“, tak to stejně neřeší otázku, speciálním případem čeho je ten poslední objekt, ke kterému dojdeme. Takhle se můžeme ptát donekonečna a hledat obecnější a obecnější pojmy…

To co píše modrý medvěd, je taky možný přístup – akorát to vede na nekonečný cyklus, dojdeme např. k tomu, že objekt je vlastně potomkem sama sebe.

[Marek Bernát]

A máš problém sa zmieriť s tým, že nie každá štruktúra je strom?

[thingie]

Nevidím žádný zásadní důvod, proč by muselo existovat nějaké nejobecnější něco…

A vlastně celá ta diskuse nic neříká, tedy, krom toho, že celá ta šaškárna s dědičnostma v Javě je jenom maličko glorifikovaný pokus o jmenné prostory bez nějakých solidnějších základů.

[Bluebear]

Ať tak nebo tak, vždycky se dobereme k nějakému kořenovému prvku a ten je speciálním případem čeho? Sama sebe?

Myslím, že původní výrok byl myšlen tak, že když si vybereš libovolný pojem, tak se vždycky dá najít nějaké hledisko, podle kterého můžeš tento pojem označit za speciální případ něčeho jiného.

Nikdo neříká, že to hledisko musí být nutně praktické nebo smysluplné ale také být může. V některých případech se takhle dají ukázat zajímavé podobnosti mezi zdánlivě nepříbuznými jevy.

[Marek Bernát]

Presne takto to bolo myslené -- teší ma, že moje zle komunikované myšlienky aspoň niekto chápe Len som si nebol istý, či to s tým filozofom nebola urážka, pretože ja osobne slová filozof a idiot používam prakticky zámenne

[Bluebear]

Len som si nebol istý, či to s tým filozofom nebola urážka, pretože ja osobne slová filozof a idiot používam prakticky zámenne

Nebyla to urážka držím se starší definice filozofa jako člověka, který se snaží nacházet široce platné souvislosti mezi věcmi.

[Marek Bernát]

Tak to potom áno, ak išlo o ten doslovný význam slova (teda slov)

[Marek Bernát]

Samozrejme, že ich miešam, lebo si sa nevyjadril dosť jasne Keď v OOP jazyku povieš Object, tak z toho ešte nie je jasné, či myslíš inštanciu, alebo triedu. Preto som uvážil obidva prípady

Tak či tak, je v tom zmätok, lebo slovo objekt sa tu používa aspoň v troch významoch Takže každý objekt (myslené abstraktne) má svoju triedu. Ako hovoríš Objekt (inštancia) má svoju triedu Objekt. Lenže aj trieda Objekt je objekt (alebo by aspoň v OOP jazyku mala byť), takže musí byť inštanciou nejakej triedy. No a to buď sám seba, alebo triedy Class. No a trieda Class je zasa inštanciou triedy Objekt. Takže nie, nedobrali sme sa koreňovému prvku, ale k rekurzii Tak či onak, vnútorne sú tieto veci vždy implementované ako special case, ale o tom som písal už na začiatku, že netuším, jak je to presne v Jave ohackované. Najbližšie bol asi Bluebear s jeho *void

Ale aj keby nie, koreňový prvok je len špeciálnym prípadov vrcholu v grafe. Túto hru môžeme hrať veľmi dlho

[Ladicek]

Například ve Squeaku je to speciální případ ProtoObjectu, pokud se dobře pamatuju

[Marek Bernát]

Lol

Pamätám sa, že som kedysi v Squeaku preliezal tieto základy v snahe pochopiť, jak to vlastne funguje. Vtedy som neuspel. Dnes som zistil, že je pre to termín raviolli kód (= milión tried, z ktorých ani jedna nič nerobí a nie je šanca zistiť, kde sa vlastne veci dejú)

[Bluebear]

A Object (např. v Javě) je speciální případ čeho?

Ukazatele na void

[Marek Bernát]

To máš samozrejme pravdu, veľkosť kódu nie je všetko. Ako hovorí Peter Norvig: Be specific, be concise, be consistent, use abstractions, use all the tools language provides, don't be obscure. To sú hlavné zásady elegantného a čitateľného kódu. Občas sa treba rozhodnúť, čo z uvedeného je dôležitejšie, ale takmer nikdy nie je dlhší kód (ak spĺňa ostatné kategórie) lepší ako kratší kód. Ony tie kategórie totiž často hrajú dokopy. Ak sa človek nesnaží používať vyložene obskurné konštrukcie jazyka, tak kód ktorý využíva abstrakcie a je špecifický, bude takmer určite aj krátky (concise = stručný, výstižný), atď.

A ďalej, je jasné, že elegancia a krása programu závisí od toho, kto sa na ten program pozerá. Rovnako je to v umení. Pochybujem, že opice ocenia Picasove obrazy. A rovnako tak pochybujem, že priemerný programátor ocení pokročilejšie jazyky a ich konštrukcie.

[deda.jabko]

alan me pripomina idiota z teto diskuze. cituji:.

Ke skutečnému programování OS – a vlastně čehokoli jiného – vůbec není zapotřebí počítač, přinejmenším ne v první fázi. Především je třeba si ujasnit cíle, oč se vlastně snažíme a proč, pak zvolit rámcově, bez velkých technických detailů realizační cesty, a pak až snad někde úplně v závěru to nějaký dobrák může převést do kódu – to už je to nejmenší.

[thingie]

Ale to je vládnoucí uvažování, žejo. Každý problém se dá zobecnit do podoby, kdy ho sice už vůbec neřešíme a nevyřešíme, ale zase to může dělat každý druhý blbec z ekonomky.

[Bluebear]

Ten člověk, kterého cituješ, mluví v extrémech a to, co říká, se rozhodně nehodí zrovna do programování OS (protože tam je každý programátorský detail kurevsky důležitý a rozhodně to nemůže "převádět do kódu" kdejaký hejhula).

Nicméně ten bod "je třeba si ujasnit cíle, oč se vlastně snažíme", ten bych podepsal. Bez toho se totiž plácáš v kruhu a k ničemu nedojdeš, protože se ti zadání (resp. to, co považuješ za zadání) mění pod rukama. Tento fakt jsem zjistil tím těžším způsobem, takže je ověřený

[podlesh]

Ehm, to přeci sedí i na Karla - akorát že zvládl obě role.

[xkucf03]

V kontextu té diskuse na Rootu to zní dost arogantně, ale když jsem četl jen tu citaci tady, musím mu dát za pravdu – to nejužitečnější vymyslí člověk a ty nejlepší rozhodnutí přijme klidně bez napsání jediného řádku kódu – prostě nejdřív myslet, potom psát.

Jasně, že i při psaní kódu si člověk leccos ujasní, ale to hlavně v případě, kdy se učí za chodu, zkouší nové technologie, postupy, nebo při prototypování, kdy kód resp. prototyp slouží jako sdělovací prostředek – aby uživatel viděl na vlastní oči, jak to bude vypadat, protože ze slovního popisu by to nemusel pochopit, nebo by si to tak nepředstavil.

[deda.jabko]

to nejužitečnější vymyslí člověk a ty nejlepší rozhodnutí přijme klidně bez napsání jediného řádku kódu – prostě nejdřív myslet, potom psát.

ja nerikam, ze analyza je k nicemu... ale striktini rozdeleni analytik-programator je podle me holy nesmysl. analytik, ktery nemusi programovat nevidi, co vymyslel za blbosti a programator bez analytickeho mysleni je taky k nicemu.

mimochodem... nemyslim si, by treba vyvojari linuxoveho kernelu podcenovali analyzu... ale schvalne by me zajimal pomer poctu radek kodu k poctu powerpointovych prezentaci a uml diagramu pouzitych behem vyvoje jadra ve srovnani treba s vyvojem bezne ,,enterprise aplikace''

[Leoš Literák]

Souhlas, kdysi jsem na nejake soutezi mel zadani konvertoru mayskeho kalendare, byla tam spousta cyklu a vyjimek. Zatimco ostatni kodovali, ja si sedl, sepsal vse na papir, chvilku si s tim hral a objevil skutecne zavislosti. Prepis do pocitace pak byla jen chvilka a muj kod byl ze vsech nejkratsi a nejrychlejsi

[Marek Bernát]

Keď sa jedná o tvorbu jednoduchých algoritmov (tj. presne špeficikovaný vstup aj výstup a treba len nájsť funkciu, ktorá to zobrazuje), tak je jasné, že toto je najlepší spôsob. Ale pri písaní väčších programov, kde nie je zo začiatku jasné, čo je vstup, ani čo je výstup, je často najlepšou možnosťou si proste sadnúť ku kódu a skúsiť jak to bude fungovať. Samozrejme, premýšľať treba tiež. Tak jak tu už niekto spomenul, dobrý programátor by mal byť zároveň analytik aj kódič, keď je len jedným z toho, tak je to na nič.

[xkucf03]

 

Ale pri písaní väčších programov … je často najlepšou možnosťou si proste sadnúť ku kódu a skúsiť jak to bude fungovať.

U větších programů začít rovnou kódovat? No to by to teda dopadlo. U menších projektů ta analýza jakoby neprobíhá (ale ve skutečnosti už proběhla, člověk to má rozmyšlené v hlavě, jen to není formalizované). Ale větší systémy se jen tak v hlavě rozmyslet nedají a bez formalit to nejde. V takovém případě by se psaním kódu začínat nemělo – jsou snad jen dvě výjimky:

 

• GUI – někdy je dobré začít s uživatelským rozhraním (i když to vypadá jako stavba domu od střechy), vytvořit si prototyp GUI, který ti pomůže ujasnit si, jaké bude mít program vstupy a jaké výstupy. Ale to je spíš klikání než kódování.
• Napsat vybrané algoritmy – aby se ušetřil čas, můžou někteří lidi začít hned pracovat na algoritmech a knihovnách, o kterých 100% víme, že je budeme potřebovat – i když nevíme, jak je do toho celku začleníme, ale víme, že tam budou. Např. víme, že budeme potřebovat funkci na spojité úročení (ale spíš něco složitějšího), tak může někdo sednout a začít ji psát, aniž by ještě existoval zbytek systému. Je to trochu risk, protože se může stát, že ten kus kódu nakonec nebudeme potřebovat, nebo ho budeme potřebovat v jiném jazyce (např. to budeme počítat na úrovni SQL databáze místo v aplikaci, pak to musíme zahodit a napsat znova), ale s dobrým odhadem to může nějaký ten čas ušetřit.

[Ladicek]

U větších programů začít rovnou kódovat?

Jasně že jo. Říká se tomu prototypování a je to užitečné v mnohem větším množství případů, než je GUI. Bohužel někteří manažeři si nevidí dál než na špičku nosu a považují to inherentně za ztrátu času (protože prototypy, jaký děs!, se zahazují). Ve skutečnosti se pak ztratí mnohem víc času jakousi formální analýzou, jejíž výsledky jsou, slušně řečeno, nepřesné.

[Leoš Literák]

Ještě větší průšvih je, když programátor dostane za úkol napsat prototyp, ten jej tedy tak napíše (jako prototyp) a pak vedení rozhodne, že se kód začlení do produktu a jen se dokončí.

[Ladicek]

Jo, no. Když vedení kafrá do způsobu vývoje, je to na zabití. Když si chcete v takovém případě zachovat poslední zbytky rozumu, jedna možnost tu je: nasadit striktní vodopád (pro otrlé i ten deformovaný, bez zpětné vazby). Pakliže vedení neví, jak funguje prototypování, pravděpodobně ani neví, jak nefunguje vodopád

[R]

Neznasam, ked vedenie pouziva slova "jenom", "pak" a "se". Jeden z najhorsich prikladov: "jenom takhle a pak se to dodela".

[xkucf03]

Ta práce se udělá, oni na to přece nemusí ani šáhnout ne? Jenom pak dostanou bomboniéru nebo flašku kořalky od spokojených uživatelů (pokud se to programátorům povede).

[alblaho]

Mi tahle bajka přijde zjednodušující až příliš

Kdyby byl Karel pako, tak by to prostě nezvládl a musel by to udělat někdo jiný, s velkým zpožděním. A upřímně, spíš bych čekal, že Karlův kód bude nedokumentovaný a bude obsahovat hacky.

Naopak když budou ti Alanovi lidi schopní, tak výsledný kód nemusí být vůbec nesrozumitelný. Naopak, ta režie se tam promítne tak, že je sepsána dokumentace a jsou na to testy.

Prostě: tým chytrých lidí je k nezaplacení. Jeden geniální programátor příliš velké riziko.

[Trained.Monkey2]

>> Prostě: tým chytrých lidí je k nezaplacení. Jeden geniální programátor příliš velké riziko.

A to je take pointa pribehu. Samotny programator nikdy nedostane odpovidajici ohodnoceni, protoze tym je tym a 4x vic lidi prece musi odvadet 4x lepsi praci.

[Ivan]

A devet zen porodi dite za mesic :)

[dad]

za meho mladi se rikalo:

'a i to je v Sovetskem Svazu mozne..'

[xkucf03]

On by spíš ten manažer měl mít odhad, jestli je to práce pro jednoho člověka na měsíc, nebo pro čtyři lidi na půl roku Lidi potřebují dostat zaplaceno tak jako tak, a to že je nějaký eman strčil do týmu, kde budou psát půl roku nějakou ptákovinu a kopat se při tom do zadku není jejich chyba.

[benzin]

Ano tenhle pribeh je uplne zcela mimo realitu. Pokud osamely vlk napise dene 5 radek kodu (jak je tam napsano), tak je to projekt extremne trivialni, coz je neco co vidi i vedeni.

 

Skutecny problem osamelych vlaku programatoru, je ten ze nad tim sedi od rana do vecera, drti, drti, drti a drti. A nakonec diky tomu ze nemeli dobrou analyzu to nesplnuje to co zakaznik ocekaval a po dvou-trech letech to zacina delat nekdo od znovu. Kdyz se produkt dostane do nasazeni stravi vlk jeste dalsi taden jeho specifickym doladenim pro daneho zakaznika a znovu pri kazdem dalsim nasazeni. Nakonec se ale nedostane k tomu nejdulezitejsimu zakaznikovi, ktery ma Sapa, protoze ho neni mozne rozumne na tuto technologii napojit, bez nutnosti to udelat cele od zacatku.

 

JJ zname jak to chodi.

[happy barney]

blbosť, to sú povery, aby si Javisti dodali presvedčenie o svojej potrebnosti

[xkucf03]

A kdo říká, že ten osamělý vlk nemůže psát v Javě?

[Marek Bernát]

To nejde moc dokopy. Java je svojho druhu COBOL (ktorý má to korporátne programovanie už v názve)

[benzin]

Ja sem zacinal jako osamely vlk a taky tak programoval deset roku. Jeste ted dodelavam nektere rozjete projekty, ale prava je takova ze je to vhodne jenom pro male projekty. Je to naprosto nemyslitelne pro software house, protoze ten musi mit jistotu ze program bude zit dal i kdyz vlak po roce odejde. Je to pouzitelne pouze tam kde vlk je vlastnikem kodu a tak je jakasi sance, ze sve detatko nenecha umrit. Bohuzel jen malo vlku pak zvladne dobry marketing a opakovany prodej, aby jeho prace nebyla pro zakaznika prilis draha.

[mirec]

3 riadky denne :D To mi pripomína test, ktorý som kedysi robil .. vyšlo z neho, že človek, ktorý vie, čo robí a vie ako to urobiť dokáže za deň napísať zhruba 2000 riadkov (extrémisti 4000).

[AraxoN]

Kto napíše 2000 riadkov kódu za deň buď veľmi nechutne zneužíva ctrl+c / ctrl+v, alebo je po pár dňoch zrelý na mesačnú dovolenku. Alebo píše kód HTML / CSS, čo by som programovaním nenazval ani omylom.

[mirec]

C++, Qt, OpenGL a rozhodne nie zlý kód.

[Josef Kufner]

Z vlastní zkušenosti můžu říct, že těch 2K řádku za den je celkem reálných, ale jsou to jen špičky. Předchází tomu spoustu času v analýze a v prozkoumávání slepých uliček. Pak také je potřeba počítat s odlaďováním a doplňováním nějakých dalších funkcí. Takže ve výsledku se to zprůměruje na maximálně pár desítek řádek denně a i to je ještě celkem dost.

[okbob]

Nevěřím - jedině za předpokladu, že 1800 řádků Vám něco vygeneruje.

[Josef Kufner]

Ale jo, věř

Záleží na tom, co je to za kód. Pokud to jsou jednoduché věci, ale jsou pestré a je jich hodně, tak to naskáče celkem rychle. Pokud v tom kódu je i tvorba UI, tak řádky také přibývají skoro samy.

Na druhou stranu pokud to je nějaký pěkný algoritmus, tak 100 řádek za den může být hodně.

Nejlepší ale jsou situace, kdy k přidání nějaké funkce stačí jen upravit konfiguraci a není potřeba psát ani řádek kódu. To pak má jeden pocit, že to navrhl opravdu dobře

[mirec]

No na pekný algoritmus je 100 riadkov občas takmer neprekonateľná hranica. Na mňa je niekedy už dosť aj tak banálna vec ako presun podstromu DFS stromu v databáze jediným sql dotazom. Tých update set case when between where min max ... je tam pekne veľa a robiť to na niekoľko query je dosť nehospodárne keď sa to dá jediným dotazom (v mojom prípade 11-riadkovým).

[default]

Tých update set case when between where min max ... je tam pekne veľa a robiť to na niekoľko query je dosť nehospodárne keď sa to dá jediným dotazom (v mojom prípade 11-riadkovým).

To mi připomíná mou rekurzi v SQL. Už jsem to tu zmiňoval, ale nevím kde. Tenkrát jsem si s tím jenom hrál, teď už mi to funguje. Příklad:

 template_id  |  template_formula
--------------+--------------------
           1  |  12
           2  |  a + <1>
           3  |  <2> * <1>
           4  |  (<3> + <2>) - <1>

A jedním dotazem lze získat:

 template_id  |  template_formula
--------------+------------------------------
           1  |  12
           2  |  a + 12
           3  |  a + 12 * 12
           4  |  (a + 12 * 12 + a + 12) - 12

Prostě rekurzivně nahradit odkazy platnými vyevalovanými formulami. Pravda — na jedenáct řádek to nejni (je to 179 včetně komentářů), ale porád je to rychlejší než PL/SQL.

[mirec]

Heh, pekné. Ja som sa hral s DFS, čo v podstate znamenalo zistiť rozsah, v ktorom sú podstromy, správne určiť rozsah tak, aby som SQL zaťažoval čo najmenej a niektoré pomocné čísla zvýšiť / znížiť podľa prvkov, ktoré sa vymieňajú. Na prvý pohľad banálna vec, ale urobil som tam asi 20 chýb, kým to fungovalo :D Áno viem, som lama. No a o takýchto veciach manipulácia s výrazmi v SQL radšej ani nesnívam ;)

[default]

Ja som sa hral s DFS, čo v podstate znamenalo zistiť rozsah, v ktorom sú podstromy, správne určiť rozsah tak, aby som SQL zaťažoval čo najmenej a niektoré pomocné čísla zvýšiť / znížiť podľa prvkov, ktoré sa vymieňajú. Na prvý pohľad banálna vec, ale urobil som tam asi 20 chýb, kým to fungovalo :D Áno viem, som lama.

Já jsem taky lama. Teď mě čeká práce s grafy, hledání cest. Tak jsem zvědavý, jak to dopadne. Už mám v hlavě nápad, jak na to, tak doufám, že to vyjde a nebude to pomalý.

[mirec]

Ja považujem u seba za reálnych 400 riadkov denne (aj s návrhom). Samozrejme najviac z toho zaberie návrh, implementácia je nič. Keď človek píše pár stoviek znakov / s nie je s tým veľký problém. Ale poznám človeka, ktorý jednoducho píše a píše dobre aj bez toho aby kreslil rôzne diagramy a nejako dlho premýšľal. Ja mu žiaľ nesiaham ani po členky.

[Messa]

Pro další pohádky doporučuju TheDailyWTF.com. Těch osamocených Karlů, co ale místo práce na projektu dělali v lepším případě něco úplně jiného, tam je dost.

Ad 5 řádků denně - jsou i dny, kdy se víc řádků smaže než napíše

[Nicky726]

Hezké.

[Richard]

Bylo by pěkné sehnat někde programátora jako je Karel. Bohužel, většina těchto lidí už je zadaných v  týmech podobných tomu Alanovu.

Mám zkušenosti s oběma variantami, "týmy" i "osamělými vlky". Reálné výsledky se ovšem nepodobají tomu co je v pohádce řečeno (možná proto je to pohádka).

V realitě většinou Karel buď zcela selže, nebo napíše něco co sice částečně funguje, ale nesplňuje to požadavky na bezpečnost a uživatelský komfort. Protože je aplikace zevnitř velmi zbastlená, musí se po dvou letech vyhodit a napsat znova. Pozor, to neznamená že Karel je blbec - takto často dopadnou i skvělí programátoři kterých si vážím, protože vývoj softwaru má mnohá skrytá úskalí.

Alanův tým většinou neselže, ale je opravdu mnohonásobně dražší než Karel. Za to ovšem vyvine aplikaci která se dosti blíží specifikaci a dokonce se dá i nadále udržovat a rozšiřovat. Nevýhodou je, že nedělá to co by zákazník potřeboval (protože analýza nebyla přesná) a že ji uživatelé nesnáší (protože na uživatele se jaksi nemyslelo). Proto se do aplikace nalije ještě několikrát více peněz aby se ty nejhorší problémy spravily.

Takže pokud máte málo peněz a nevadí vám obrovské riziko, najměte Karla, máte odhadem tak 10% že to bude jako v té pohádce a cca 40% že zcela selže a produkt nikdy nedodá.

Pokud máte hodně peněz a chcete mít kontrolu, najměte Alana - máte asi 80% že to bude jako v této pohádce a jen asi 10% že úplně selžou.

 

[dad]

my v Cechach mame oproti zbytku sveta jeste jednu optimalni moznost ....

[Yakubak]

A to?

[dad]

vy jste tady asi novej, ze jo?

[petr]

tak v tom pripade jsem tady asi taky novej... jakou optimalni moznost?

[M. Lox]

{[ŠV]ašek,Profesor} z Hradu? Je to dad, uvažuj trochu, nebo si přečti libovolný jiný příspěvek tohoto autora.

[Leoš Literák]

Ja bych si spise vzal na pohovor Karlova manazera. Nezdalo se mi, ze by jej nejak ridil, kontroloval, jen pasivne cekal na vystup. Pokud se takto chova i k ostatnim podrizenym, zrejme je zbytecny.

[mirec]

Najlepší zo všetkých je JYD :P