Názory k článku
František Fuka: 95 procent všeho dělám v jazyce Lua

Me by teda zajimalo, co rika FF na Ruby :)

Fuxoft minimálně v jedné své životní fázi Ruby evidentně používal, takže asi nelze hovořit o vyložené antipatii. ;-)

pouzival aj PHP a je mu z neho na zvracanie… ako vlastne zo vsetkeho okrem lui

Vývoj mého „primárně používaného“ programovacího jazyka byl: Python → Smalltalk → Ruby → Lua

Já mám zase zafixováno, že Fuxoft dělá ve Smalltalku…asi proto, že ho sám používám :)

Mohl byste se mi prosím ve věci ST ozvat na bordel007(na)cen­trum(tečka)cz?

Proč ta oklika přes SmallTalk? Pochopil bych, kdybyste přešel z Pythonu ke ST nebo naopak, ale od P přes ST k R, to fakt nechápu – ale důvody by mě moc zajímaly! :)

Ja si pana Fuky velmi vazim za muziku v Galactic Gunners. Skoda ze o tom nebyla rec. To jsem si vzdycky u jidla poslechl, utrel si ruce a hubu, a bez ztraty zivota vsechny levely zmydlil. To byly casy!

Co vam konkretne na Jave a C++ vadi ?

V tom nehezkém C je totiž napsaný ten hezký Lua :)

Za 5 let udelejte rozhovor s nekym kdo tyhle programy bude muset udrzovat :-))

To je sice pravda, ale ne celá pravda. Každý program existuje v nějakém svém ekosystému – v nějaké své nice. A podle toho je také tvořen (v lepším případě).

Věci jako hry, redakční systémy pro blogování a různé agregátory googlových služeb, to není věc, která by vůbec měla předpokládanou dobu života pět let.

A naopak, věci jako enterprise systémy, bankovní systémy, databázové servery a tak, ty se nepíšou ani v Pythonu ani v lua ani v ničem podobném; resp. jejich základy se v nich nepíšou – je možné samozřejmě do nich lua integrovat a konkrétní business procesy už v lua skriptovat. Předpokládaná životnost toho konkrétního scénáře (toho lua skriptu) je typicky několik málo let, zatímco předpokládaná životnost toho systému jsou desítky let.

Lua potřebuje v podstatě jediný ekosystém: podmnožinu ANSI C. Je záměrně napsaná tak, aby šla zkompilovat i kompilátorem C++, a neznám moc implementací programovacích jazyků (psaných v C), které by šly zkompilovat nejen „hosted“ implementacemi jazyka C, ale i „freestanding“ implementacemi céčka. Lua to umí.

Její autoři jsou navíc docela silně konzervativní, a i když je Lua (jako současná implementace) záměrně napsaná tak, aby byla co nejvíc hackovatelná a tweakovatelná (a existuje spousta zajímavých patchů), tak sami provádějí pouze ty změny, které projdou docela náročným sítem. Docela pěkné je shlédnout přednášku Evolution of Lua, kde se k tomu Roberto vyjadřuje docela podrobně.

Myslím, že dnes napsaný program v jazyku Lua bude možné za čtyřicet let spustit s mnohem menší námahou než program v Pythonu nebo v Ruby.

Takhle dopředu věštit si u počítačů může dovolit jen Sibyla.

„I don't know which programming language I will use [in the year 2000], but I know its name will be Fortran.“

 – Anonymní citát z 60. let. No v čempak že se to počítají dnes ty černé díry? :-)))

Myslíte, že udržovat desetikilobajtový program je složitější, než udržovat desetimegabajtový? Skutečně?

desetikilobajtový program znamená, že veškerá logika je schována uvnitř samotného runtimu programu. takže kromě vlastního zdrojáku ještě budete muset debugovat tenhle.

Netuším, čemu přesně říkáte „samotný runtime programu“ a čím se to liší od „programu“ a co s tím má společného fakt, jak daný jazyk zachází se zdrojáky, ale že logika těžko může být mimo program, to je mi celkem jasné.

Spis mi jde o to ze tenhle ‚super duper programmer‘ si vsechno bastli sam. Persistenci, webserver, xml parser. Dokonce se chlubi ze si dela vlastni dedicnost apod… Pritom i Lua ma dobre knihovny.

Ted delam na projektu kde vetsina kodu je z 1999/2000 + udrzba a nove featury, nastesti dobre zdokumentovana Ja­va.

No tak vzhledem k tomu, že se svět ještě neshodl na tom, jaký objektový model že je vlastně nejlepší (či „nejlepší“? :-)) – na rozdíl třeba od scopingu, kde statický lexikální nakonec vyhrál na celé čáře – mi přijde, že přístup „udělám si objektový model na míru“ není až tak úplně mimo mísu. Ono to není až tak těžké a neliší se to od programování v jazycích, které mají sice objektový model, ale k němu také MOP. Pokud jde o perzistenci, je kupa projektů, které ji buď prostě musí mít vlastní (postavil byste Google search engine nad MySQL?), nebo je to jednodušší než to roubovat nad něco jiného. Taky by asi byla chyba si myslet, že František neustále všechno zbůhdarma přepisuje. Tomu nevěřím.

Me prijde ze „udělám si objektový model na míru“ je uplne mimo misu. Nejde o to si jen neco nabastlit, ale otestovat a zdokumentovat. Pro Lua existuje nekolik objektovych systemu, proc psat vlastni a nevzit uz existujici? Protoze muj program bude o 0.05% rychlejsi?

BTW a vite na cem google search engine bezi? Schvalne si zjistete proc google do mySQL dopsal clustering :-)))))

Hlavne si zjistete, proc vubec vytvoril BigTable, a k cemu je technika MapReduce. Opravdu naivni clovek si muze myslet, ze Google bezi na MySQL.

Nejde o existenci knihoven, ale o to, ze neexistuji knihovny, ktere by se nejak vyrazne kryly s tim, co pri svem programovani potrebuju. A za druhe, pri kazdem projektu ty veci vetsinou potrebuju trochu jinak. A ty projekty delam treba dva za mesic. Napsani potrebnych knihoven a jejich upravu provadim v prubehu programovani celeho toho projektu. Nestalo se vam nikdy, ze zjistite, ze nejaka knihovna neco dela jinak, nez byste chtel? Mne jo. Takze si ji v takovem pripade upravim. A velmi snadno, protoze ma maximalne par kilo (nebot dela presne to co potrebuju) a napsal jsem ji ja pred par dny…

Napriklad misto XML parseru mi vetsinou staci napsat nejake 2–3 regulerni vyrazy (respektive to co misto nich ma Lua). Vyhoda je, ze vetsinou delam na vecech, u kterych se nemusim starat o validaci vstupu.

Základní pravidlo pro klasické OOP a knihovny zní – knihovny jsou uzavřené pro změny, ovšem otevřené pro rozšiřování. Pokud není knihovna přesně ušitá na míru mým potřebám, tak ji neupravuju, ale udělám odvozenou třídu, která modifikuje chování knihovní třídy. Díky tomu vývojáři prohlubují své znalosti jednotlivých knihoven, aniž by se báli, že se ty knihovny budou měnit… knihovny tvoří hierarchickou strukturu, no a u těch méně používaných se holt musí kouknout do dokumentace. Obávám se, že lepší systém na vývoj velkých systémů zatím nebyl vynalezen.

Nějak si nejsem jistý, jestli „klasické OOP“ vůbec mělo třebas i podobná pravidla, natožpak tahle. Podívejte se do Smalltalku 80 a jeho potomků (Cincom Smalltalk, Squeak…). Zjistíte, že byl vyvinut způsobem nikoli nepodobným tomu, jaký František popisuje. :-) A to je, prosím pěkně, to „nejklasičtější“ OOP, jaké snad může být. To, co popisujete, sedí spíš na Modulu (nebo další podobné Wirthovy vynálezy) a modulární programování.

Tak možná jsem špatně použil pojem „klasické OOP“. Prostě tou zásadou, co píšu, dnes začíná každá učebnice objektového programování a design patternů. Byla to reakce na Františkův dotaz, co děláme, když zjistíme, že nějaká knihovna nedělá přesně to, co potřebujeme. Alfou a omegou dnešního programování je dělat takové knihovny, které se snadno rozšiřují a kombinují. Nikoliv modifikují.

Co to je „dnešní programování“? Máte na mysli dnešní lepení kódu? Kdo si nemůže dovolit zaplatit programátora, ten se holt musí spokojit s lepičem. Ale jejich metody bych neztotožňoval s metodami programování. Hlavním cílem programování nikdy nebylo, aby i imbecil zvládnul nějak něco vyřešit, ale danou věc vyřešit co nejefektivněji a nejelegantněji. A jestli to vyžaduje modifikaci existujícího kódu… Účel světí prostředky.

Ano, dnešní programování je z největší části o tom, mít přehled, co existuje za knihovny, frameworky, design patterny, zkrátka, co už někdo řešil přede mnou a co se stává v nějaké oblasti průmyslovým standardem. A samozřejmě také o tom, že když chci přispět vlastní knihovnou, tak jak ji tvořit (pravidlo uzavřenosti k modifikacím, otevřenosti k rozšiřování). Zásadně protestuju, abyste špičkového vývojáře, který má tyto znalosti, o kterých píšu, i když vlastního kódu za pracovní den napíše jen pár řádků, označoval za „lepiče“. Ani on se nevysmívá tomu druhému (generačně staršímu) druhu programátora, který je spíše geniálním algoritmizátorem a v jeho kódu není jediná zbytečná řádka. Oba představují vysoce náročný typ práce a oba jsou potřební, aby šel vývoj dopředu. Těch prvních je dnes ale prostě víc a je to v pořádku.

To není vysmívání se. To je konstatování faktu. Programování JE v první řadě algoritmizace, NE lepení knihoven dohromady. Ale i kdyby to mělo být bráno jako výsměch – on se totiž ten „dnešní špičkový vývojář“ nemá komu vysmívat. Kvalita toho, co on plodí, velmi silně zaostává za tím, co vzešlo od toho „generačně staršího“ druhu programátorů. Už jsem narazil na tvrzení, že „co nenajdu googlem, to jako by nebylo“. Na dnešní vývojáře se to dá parafrázovat slovy „nač není knihovna, to nejde udělat“. Takovým lidem bych se měl co vysmívat (jak jedněm, tak druhým), protože jde o evidentní atrofii jejich intelektu.

Dobrý programátor v tom pojetí, jak ho chápu já, ví, že neplatí „nač není knihovna, to nejde udělat“, ale „nač není knihovna, to bude dražší“. Mě se zkrátka líbí myšlenka, že programátoři chápou svou práci tak, že produkují především knihovny a ty pak sdílí s ostatními, ideálně s celým světem. Jednotlivé projekty jsou pak průsečíky těch knihoven, klidně za cenu částečné ztráty jejich efektivnosti. Musíte se na „efektivnost“ dívat globálně. Tvořit software dnes může „každý blbec“, jak si asi myslíte, ovšem díky tomuto kvantitativnímu skoku zase vzrostla konkurence a koncový uživatel z toho nakonec profituje. Jak je nejlépe vidět na internetových aplikacích. Uživatele nezajímá, jak efektivně pracuje programový kód, který mu něco poskytuje. Ale v této debatě nemá smysl pokračovat, začíná připomínat debatu s ševcem z 19. století o dnešní globální ekonomice. Samozřejmě, že ten švec dělal poctivé bytelné boty, které vydrží dvacet let, o tom žádná. :) Ale to je jen naprosto dílčí fakt.

A já mám kamaráda, který má tak velkou nohu, že si ty boty prostě musí nechat šít od ševce na míru. Ale možná by se měl podvolit dnešní globální ekonomice a začít chodit bos. :)

Jo, dobrý příměr. A František Fuka je prostě ten švec, co šije ty atypické programy. Našel si mezírku na trhu, která je dnes už hodně malá, a ostatní ševci, co se učili šít na osmibitech, mu můžou jen závidět. Buď mrzoutsky mumlat něco o starých zlatých časech nebo si najít prostor pro kreativitu i v tom novém systému…

Teď je otázka, jestli zadavatel potřebuje OPIMÁLNĚ VYŘEŠIT svůj problém (klasicky vyjádřeno funkcí 3 nebo 4 proměnných – čas, cena, kvalita, resp. funkcionalita), nebo zda má zájem brousit léta nějaký kód jako vzácný drahokam, což bylo možná představitelné v době, kdy se psaly programy daleko menšího rozsahu, než jsou některé dnešní.

Zaplatit si geniálního solitéra sice může být lákavé, ale jenom do té doby, než nastane potřeba projekt rozšířit nebo daného člověka z jakéhokoliv důvodu nahradit. A nejhorší situace z hlediska firmy nastává v okamžiku, kdy se takovému géniovi nechají zcela volné ruce. Sice možná zná nazpaměť každý svůj napsaný řádek, ale pokud nemá dostatek sebedisciplíny, nebude s velkou pravděpodobností existovat časem jiné řešení, než celý systém nahradit něčím jiným nebo ho kompletně přepsat. V takovém případě si géniův nadřízený zcela přirozeně položí otázku, zda neměl raději zaměstnat nějakého „lepiče“.

Myslíš LPeg? Jako „to, co místo nich má Lua“? Mně to přijde o něco (nebo o hodně?) udržovatelnější než „perlí regexpy“ přes půl řádku, a přitom člověk nemusí čekat na Perl 6 Grammars (ano, i autoři Perlu uznali, že současná syntaxe regulárních výrazů v Perlu nebyl až tak dobrý nápad :-)).

Desetimegabajtový program taky může znamenat, že je samodokumentující, protože je ukecanější. Proto ano, jeho přečtením pochopím jeho architekturu a algoritmy rychleji než louskáním desetikilového programu od matematického ge­nia.

Samodokumentující programy jsou samozřejmě fajn, ale napsáním dokumentace k desetikilobaj­tovému programu z něj těžko udělám desetimegabajtový. To by ke každé řádce kódu muselo ve zdrojovém kódu existovat tisíc řádků dokumentace! To by už možná bylo až nepřehledné. :-) TeX má, pokud se nepletu, poměr dokumentace ke kódu asi tak čtyři ku jedné (zjištěno z jeho jediného zdrojového souboru), a to je přitom docela obsáhlá.

A jaká část kódu toho desetimegabajtového programu je z klávesnice jeho vývojáře? Řekl bych, že optimistický odhad je asi tak promile. Zbytek je automaticky generovaný kód a kód knihoven. Troufám si tvrdit, že jakýkoliv autonomní problém se dá popsat strojovým kódem desítky, v krajním případě stovky kilobajtů dlouhém.

„Troufám si tvrdit, že jakýkoliv autonomní problém se dá popsat strojovým kódem desítky, v krajním případě stovky kilobajtů dlouhém.“

V tom máte nepochybně pravdu. Proto také věřím Chucku Moorovi, který říká, že dáte-li mu libovolný megabajtový program řešící nějaký problém, napíše obdobný program desetikilobajtový, který bude dělat přesně to, co potřebujete. Pokud jde o automatické generování kódu, nezapomeňte, že forthisté, lispeři a další podobná verbež (zřejmě včetně luistů) ho sice používají taky, a to v mohem dokonalejší formě (koneckonců ji vynalezli), ale nemají tu drzost započítávat generovaný kód do „zdrojového“, neboť očividně zdrojový není (a jelikož se u nich generování kódu odehrává při kompilaci, tak leckdy není ani vidět, takže není moc co měřit a započítávat).

A co tedy máte na mysli vy, když řeknete „desetimegabajtový program“ a porovnáváte ho s tím „desetikilovým“? Porovnáváme snad výsledný kód, ne? Zdrojáky se obvykle měří na řádky (my forthisté ho měříme na „skriny“ ;-).

Já? Já měl na mysli právě 10 MB ručně napsaných. To až Vy jste mě upozornil na možnost, že by někdo počítal henerovaný kód. Zdrojáky se měří na řádky, ale u projektů, které kód generují, osobně za zdroják počítám pouze velikost zdrojáků generátoru + velikost jeho vstupních dat. Generované Cčko ignoruji úplně stejně, jako meziprodukty Scheme-to-C kompilátorů a GAS assembleru uvnitř GCC.

Na mainframech existuji programy napsane v CLISTu a REXXu, ktere funguji stejne od 80.let (pokud nevite, oba jsou dynamicke skriptovaci jazyky). I kdyz je pravda, ze IBM uzkostlive dodrzuje zpetnou kompatibilitu, coz u OSS zdaleka tak dobre neplati.

Kazdopadne, pokud pointou vaseho prispevku melo byt, ze programy napsane ve skriptovacich jazycich jsou neudrzovatelne (nebo hure udrzovatelne nez C++), tak to neni pravda. Muj osobni nazor je, ze udrzovatelnost jazyka je dana v podstate jen a jen zpetnou kompatibilitou jeho implementace, to ostatni na to nema zasadni vliv.

„Na mainframech existuji programy napsane v CLISTu a REXXu, ktere funguji stejne od 80.let (pokud nevite, oba jsou dynamicke skriptovaci jazyky) I kdyz je pravda, ze IBM uzkostlive dodrzuje zpetnou kompatibilitu, coz u OSS zdaleka tak dobre neplati.“

Zase takový ignorant historie nejsem, dokonce znám i SNOBOL. :-p ;-) A pánové kolem Lua si na takovýchhle věcech dávají docela záležet, linkoval jsem už i video.

„Kazdopadne, pokud pointou vaseho prispevku melo byt, ze programy napsane ve skriptovacich jazycich jsou neudrzovatelne (nebo hure udrzovatelne nez C++), tak to neni pravda. I kdyz je pravda, ze IBM uzkostlive dodrzuje zpetnou kompatibilitu, coz u OSS zdaleka tak dobre neplati.“

Já jsem napsal pouze to, že deset kilobajtů se udržuje lépe, než deset megabajtů. Pokud tam vidíte cokoli o jazycích, tak si to tam dosazujete sám. :-) S poslední větou bezvýhradně souhlasím.

Šmarjá, ta poslední věta, se kterou souhlasím, měla být „Muj osobni nazor je, ze udrzovatelnost jazyka je dana v podstate jen a jen zpetnou kompatibilitou jeho implementace, to ostatni na to nema zasadni vliv.“ Vlepil jsem tam něco, co nedává v kontextu smysl. :D

Reagoval jsem na Bubaka, ne na vas. :-) Myslim, ze se shodneme.

Kdyby tohle vyslo v Zene a zivot, tak nereknu ani slovo, ale proc to je na webu pro programatory? To je, jako by na webu AVU byl rozhovor s Karlem Gottem o malirstvi. Chteli jste ho zesmesnit? Kazdej je preci trochu naivni a detinskej, tak mu to snad neni potreba davat takhle sezrat.

Myslím, že tu je spousta lidí, kteří mají vůči FF respekt a které tohle zajímá. Narážku na Karla Gotta nechápu.

(Mimochodem, přijde mi docela zajímavé, že je to už druhá zdejší osobnost (po Pavlu Tišnovském), která si po dlouhých zkušenostech s programováním oblíbila právě jazyky Forth, Smalltalk a Lua. Genius minds think alike? :-))

Sezrat? Me ten rozhovor naopak primel k tomu se na Lua podivat a je docela dobre mozne, ze se ho za mesic ci dva zacnu ucit (az dodelam ten projekt, ktery ted koncim). Novych jazyku je celkem dost, ale Fuka je pojem a kdyz neco doporucuje, tak predpokladam vi proc. A dokaze vypichnout par dost zajimavych a podstatnych vlastnosti, proc se na to aspon podivat a zhodnotit to :)

No, je fakt, že to, co se píše v článku, je legrační (prezentovaný přístup k programování je přístup studenta 1. ročníku SŠ a zdůvodnění, proč Lua je oproti PHP tak bezvadná, je fór měsíce :-). Klasika pak je názor, že vysoká škola je k ničemu, od člověka, kteý ji nevystudoval. Neboli neví, o čem mluví. Kdyby ji vystudoval, možná by neříkal takový hlouposti, měl by trochu nadhled a přehled. (Nechci bejt prudič kterej se musí do každýho nutně strefovat, ale když je to psaný stylem „já jsem velkej machr“, tak to k nezjemnělé reaci svádí. Jinak nic proti F.F., v jinejch oblastech si jistě vede dobře).

„prezentovaný přístup k programování je přístup studenta 1. ročníku SŠ“, „zdůvodnění, proč Lua je oproti PHP tak bezvadná, je fór měsíce“ – nechcete to nějak okomentovat? Už vidím studenty prvního ročníku SŠ, jak si cení minimalismu a ortogonality před cargo cult designem (PHP) a jak dávají přednost Haskellu před Majkrosoft Vižuəl D-moll. Nevšiml jsem si ani, že by FF psal stylem Radka Hulána. Opravdu jsme četli stejný článek?

Opravdu snese Lua srovnání s Haskellem? O tom bych docela pochyboval. ;)

No ve velikosti generovaného kódu určitě. ;-) A ten minimalismus a ortogonalita se týkaly spíš Luy, ono v Core Haskellu asi moc lidí neprogramuje.

fuka je v prvom rade bastlic,
ja bych takehoto cloveka nezamestnal ani omylom,
vo vacsom time na vacsom projekte su takito
vymyselnici najvacsim postrachom (a to mam par
vacsich projektov aj par vymyselnikov za sebou)

F. Fuka holt sedne, a co potrebuje, to si napise. Napriklad ja sednu, a co potrebuju, napisu jen zcasti, a podivam se, jestli neni nekde nejaka zajimava knihovna, protoze vim, ze nejsem matematicky genius, a napisu to treba blbe. Knihovny pouzivam spis pro inspiraci (mluvim o PHP) a pak si to napisu sam. Kdo umi, ten umi, kdo umi mene, ten se inspiruje od tech, kdo umi, a ten, kdo neumi, ten lepi :) IMHO „lepeni“ je dnes k videni i u lidi, co umi, protoze holt se dnes dela vse honem, honem a na vymysleni sveho reseni neni cas. Nerikam, ze je to dobre, ale je to tak…

Programoval jsem v životě opravdu hodně a nesnáším, když musím při různých projektech psát znovu dokola stejné kusy kódu.

Stačí před samotným psaním trochu zauvažovat a předem počítat se znovupoužitelností. Pak k ničemu takovému, jako je neustálé psání stejných kusů kódu, nemůže dojít. Pokud je někdo (a to platí snad v jakémkoli jazyce!) nucen neustále přepisovat stejné kusy kódu, asi něco dělá špatně a měl by se nad svým programátorským „uměním“ hluboce zamyslet.

Františka Fuku uznávám už od svých asi deseti let, jeho hry jsem zbožňoval, takže proti němu opravdu nic nemám. Nicméně některé odpovědi mi přijdou jako obyčejné a ubohé plácání taky-programátorů.

Nejvíce mě dostalo toto

v C nelze psát hezké / elegantní / zajímavé programy

to jsem se opravdu málem svezl pod stůl. Byl bych to schopen pochopit, kdyby daná věta zněla „v C neumím psát hezké / elegantní / zajímavé programy“, jinak to snad muselo být myšleno jako vtip. V Céčku je napsán třeba interpreter Luy (a co jsem si tak prohlížel její zdrojáky, tak i poměrně pěkně), v C byl před spoustou let napsán Unix (jehož architektura je konkrétně pro mě ztělesněním elegance návrhu, který dodnes snad nebyl překonán – možná tak Plan9, napsaný opět v C znovu stejnými lidmi, mu co se týče zajímavosti myšlenek šlape na paty)… Musím přiznat, že jsem trochu zklamán.

Každopádně díky za rozhovor s jednou z legend mého dětství. :) A díky hlavně za informace o Lue, hned jsem si o ní našel nějaké informace a docela se mi zamlouvá. Na první pohled mi některými svými vlastnostmi připomíná procedurální a trochu více konvenčnější Scheme. Jestli je tomu opravdu tak, jak to z letmého nahlédnutí do manuálu a dokumentace vypadá, tak se na ní zkusím podívat detailněji, protože takový jazyk mi vcelku chybí. Ne, že by mi Scheme nestačilo, jsem fanda funkcionálních jazyků obecně, ale určitě bych využil i jazyk, který se jimi inspiroval, ale je procedurální.

„Stačí před samotným psaním trochu zauvažovat a předem počítat se znovupoužitelností. Pak k ničemu takovému, jako je neustálé psání stejných kusů kódu, nemůže dojít. Pokud je někdo (a to platí snad v jakémkoli jazyce!) nucen neustále přepisovat stejné kusy kódu, asi něco dělá špatně a měl by se nad svým programátorským „uměním“ hluboce zamyslet.“

Barbie říká „Software reuse in practice is hard“. Možná se na to FF dívá právě tímhle prizmatem – ne vždycky se to povede, i když se člověk snaží, a nedá se to dost dobře algoritmizovat. (Tady asi hraje roli i chuckoidní návrh, který FF zjevně vyznává, a který v situacích, kdy ho lze aplikovat, k přepisování vyloženě svádí. :-))

Samozřejmě, ne vždy se všechno povede a občas se vyskytne případ, kdy je třeba nějakou knihovničku (i když byla navržena pečlivě a bylo při její tvorbě počítáno se znovupoužitelností) potřeba rozpárat a trochu předělat. Ale rozhodně by nemělo být nutné to činit „znovu dokola“ pro „stejné kusy kódu“. :) Některé menší věci je určitě snazší naprasit, ale v případě, že často řeším podobné úlohy, už se ta trocha snahy vyplatí.

Znovupoužitelný kód je krásná teoretická představa, ale v praxi je buď neuplatnitelná vůbec, nebo trvání na jejím uplatňování vede k neoptimálním řešením. Málokdy nastane ta idealistická třetí možnost. Se znovupoužitelností se prakticky nedá téměř vůbec počítat dopředu. To by dokázala leda Sibyla.

Diky za rozhovor. FF je proste samorost a je treba to brat s rezervou. Sam jsem zacinal s vypisy ROMky C64, okomentoval si GEOS na hromadu traktoroveho papiru a pak presel na Amigu a vrtal se v ni taky docela dost ale i tak se s nekterymi vecmi v clanku nejak nemuzu ztotoznit:-) V Ccku jde psat elegantni programy jako v cemkoliv jinem na nizsi urovni (Ccku se nekdy rika ze je to lepsi assembler). Java jako takova mi prijde urcite jako pokrok oproti silenostem typu objekty v c++. A docela se divim ze nekdo kdo ma rad luu nema rad javascript. I kdyz je syntaxe jave trochu podobna ma taky javascript v zakladu asociovane pole kterymi jdou udelat objekty, a funkce jako promenne a regularni vyrazy, cili krome psani ve stylu Ccka v nem jde psat i ve stylu lispu/luy/…, co umi lua navic? Je fakt ze samostatny interpret javascriptu se nejak neprosadil jako python/ruby/lua/… ale jazyk na scriptovani je to hezky stejne jako lua.

Když tak čtu diskusi (ne článek) :) tak nechápu Vás pány programátory co si pochvalují fortran, lisp, smalltalk nebo ještě něco víc low.

Představa že budu po někom pracovat s 9 let starým java kódem je pro mě nemyslitelná stejně tak jako představa, že si budu psát vlastní knihovny na parsování xml apod. no prostě já patřím ke generaci co raději sáhne po sí šárp, ruby (ror) apod. než abych se patlal v C(++). To mi dovoluje naprogramovat aplikaci rychle a efektivně s daleko menším usilím :)

No teď k otázce. Nechápu proč když je někdo tak skilled se patlá v těch low jazycích místo toho aby dal výpověď a šel dělat v nějakém frameworku a vydělal mooc $$$. :) Místo toho si bastlí operační systémy na míru a dělá věci ohledně programování složitěji (samo že jsou úkoly kde má třeba fortran opodstatnění, ale bavme se o většině aplikací co jsou vidět na úřadech, nemocnicích apod.) než je nutné a btw na desktopu mu běží ubuntu místo gentoo (=něco dělá složitě a někde dává přednost pohodlí) ← z toho mně vyhází, že je to nějaká úchylka ;)
Ale hlavně mě zajímá proč teda pracuje v nadnárodní fi. místo toho aby šel svou cestou. Snad to není kvůli tomu, že by ho bavilo prolézat kód a prostě celkově ho baví programovat.

Podotýkám, že nikde nemluvím o fukovi..a když něco nedává smysl tak je to z vyčerpání a ne že bych byl retard..du spát. :-)

„lisp, smalltalk nebo ještě něco víc low“

Cožeto? Lisp a Smalltalk jsou low levelové jazyky? :D Radši choď opravdu dřív spát, jinak by to blábolení lidi mohli opravdu považovat za projev retardace. ;)

Víš vůbec něco o jazycích, o kterých píšeš? Kolik jsi toho v nich napsal?

Je pravda, že C# a podobné jazyky možná umožňují naprogramovat aplikace rychle, efektivně a snadno. To bohužel znamená, že se k programování dostane každý jouda… no a podle toho taky ta úroveň programů vypadá. :)

Ani vlastně nevím, proč na tuhle snůšku nesmyslů C#-taky-programátora odpovídám. Jakmile člověk, který programuje v Ruby on Rails a jeho ambice evidentně nemíří výše, než k psaní vskutku intelektuálně náročných aplikací pro úřady, začne hodnotit Fortran, Lisp, Smalltalk a další, hovoří to samo za sebe.

Plácáte nesmysly.

1. Fortran, Lisp ani Smalltalk rozhodně nejsou žádné nízkoúrovňové jazyky. Očividně jste je neviděl ani z rychlíku. Třeba takový C# vypadá vedle Smalltalku jako hodně chudý příbuzný. A to po všech stránkách.
2. Jedna věc je splácat nějakou okýnkovou aplikaci s formuláři či webové rozhraní a něco jiného je třeba napsat expertní program, firmware k embedded zařízení nebo fyzikální simulaci. Na to první se C# hodí výborně (a taky pro tyto účely bylo vytvořeno), u toho druhého byste s C# těžce zaplakal.
3. Mooc $$$ vydělá právě člověk, který nedělá v C#, v němž dělá každý blbec. Resp. který nemůže použít C# vzhledem k povaze řešeného problému a musí jít do složitějších věcí, které průměrný vývojář mentálně nezvládá.
4. Na spoustu (neřku-li většinu) aplikací, co jsou vidět na úřadech a nemocnicích, jejich uživatelé nadávají, a právem. Spoustě vývojářů nastanou těžké problémy, až se zavede hmotná zodpovědnost za škody způsobené jejich softwarem. To, co si dovolí někteří dnes prodávat, s tím by si před dvaceti lety nedovolil předstoupit ani student střední školy před učitele.

Dnes se za programátora považuje kdejaký blbec. Jejich výsledky tomu také odpovídají – tragédie, naprostá tragédie. Namátkou si vyberte v podstatě libovolnou instituci a informujte se o tom, jak jsou tam spokojeni s novým softwarem. Uslyšíte o nekonečných tahanicích o to, že software vlastně nedělá to, co se po něm požadovalo, je nestabilní, poruchový, náprava je v nedohlednu, při pokusu o ostrý provoz kolabuje, uživatelé raději setrvávají u starších variant (z 90. let!), protože nový software nepřináší žádné, a to podtrhuji, žádné výhody (za nejvíce zdůrazňovanou výhodu je dnes prezentováno to, že běží pod Windows, kliká se v něm myší, má to ikonky a podobné nesmysly, které jsou pro člověka, který se softwarem (jakýmkoli) pracuje rutinně, naprosto nepodstatné). Kdyby nebylo státních institucí a velkých firem, jejichž management funguje v podstatě ekvivalentně, 90% dnešních vývojářů by muselo vzít za vděk asi nějakou manuální prací, protože to, co produkují, by od nich nikdo nekupoval.

Kolegové to už řekli za mě, já jen doplním, že Lisp jako metajazyk je all-levels jazyk (stejně jako Forth), nikoli low-level (to jste měl na mysli tím „low“?), sahá tedy od assembleru (LAP) až po hodně vysoká (E)DSLka.

Keď si spomínam tak cca 25 rokov dozadu, tak najhoršie boli jazyky, ktoré mali príkaz GOTO. Príkaz GOTO, horší ako triedny nepriateľ, mal jediný cieľ, a to zneprehľadniť program a spôsobovať nekonečné slučky. Preto istý profesor navrhol programovací jazyk Pascal, kde mal programátor na nekonečné slučky elegantnejšie príkazy ako DO WHILE a DO UNTIL. :-)

Ja som mal tiež obdobie, keď mi nevyhovoval žiadny programovací jazyk, a preto som sa pokúšal navrhnúť vlastný, v prvej fáze taký, ktorý by skĺboval nevýhody všetkých ostatných jazykov. Možno sa to zdá nelogické, ale práve takýto jazyk by ostatným tvorcom jazykov ukázal, čoho sa majú pri návrhu programovacieho jazyka vyvarovať, akési cimrmanovské „tudy ne, přátelé!“. :-)

Potom som ale skúsil vytvoriť čosi optimalizované, čo by mi uľahčovalo prácu. Začal som ako to býva na programovací jazyk zvykom, jednoduchým programom vypisujúcim „Hallo, world!“. Prijal som jednoduchú zásadu, že čokoľvek, čo programátor napíše do príkazového riadku od jedného CR+LF do druhého CR+LF, čo nebude následnou syntakticko-semantickou analýzou vyhodnotené ako platný výraz nového (ešte vtedy bližšie nezadefinovaného) jazyka, bude považované za string, ktorý sa má jednoducho vypísať na konzolu. Program vyzerá potom nasledovne:

Hello, world!

Toto je najoptimálnejšia verzia tohoto programu zo všetkých jazykov, nevyskytujú sa tam nijaké zložené zátvorky, alebo výrazy ako void, println a pod. proste iba to, čo človek potrebuje. Na ďalšie uľahčenie programátorskej práce som frázu „Hello, world!“ zabudoval priamo do syntaxe jazyka ako pseudopríkaz @H. Za pomoci tohoto superkrátkeho príkazu môže každý programátor kedykoľvek vypísať na konzolu string „Hello, world!“ bez vypisovania Hello, world! :-)

Zdravím FUXOFT a spol. Jano

supergeek ;-)
ale verim tomu, ze s FF by ste si rozumeli ;-)