Dvě minuty nenávisti - Wordpress

21.4.2015 23:12 | Přečteno: 3758× |

V kapse se mi rozvibroval telefon a vyloudil ze sebe nenáviděný kvákavý zvuk - to nám to ten den hezky začíná. Ohlásila se Icinga; databázový server si stěžuje, že mu dochází místo. Ach jo, nějaký zákazník má zaspamovanou databázi. Při bližším pohledu zjišťuji, že dochází místo na /. WTF? Kouknu se do /var/log a vidím - slowlog od MySQL přetéká. Volám šéfovi - obligátní otázka: Ty nerotuješ logy? Grrr... představuji si, jak ho zabíjím nějakým zajímavým způsobem a velmi nasraně mu odpovídám, že logy kupodivu rotuji, ale jen jednou denně - což ale na tento nápor zjevně nestačí. Přesunuji svou frustraci opět na zákazníky a otevírám onen slowlog. Prve na něj pouštím pt-query-digest a vychází mi toto:

# Profile
# Rank Query ID           Response time     Calls R/Call   V/M   Item
# ==== ================== ================= ===== ======== ===== =========
#    1 0x737F2E8EA4D5A732 564981.9562 47.6% 36551  15.4574  6.75 SELECT wp_posts wp_postmeta
#    2 0x02E3A68936E61834 233697.7886 19.7% 11295  20.6904  2.99 SELECT diskuze
#    3 0x2970F6466BADF111  65821.0810  5.5% 22837   2.8822  0.29 DELETE ps_search_index
#    4 0xD9C9A4CDD124552A  38385.2439  3.2%  5971   6.4286  0.01 SELECT uchazeci platnost uchazeci_jazyky uchazeci_praxe users
#    5 0x33506D8C142D8597  37542.1817  3.2%  3615  10.3851  0.22 SELECT texty platnost

Hm... takže zaspamovaný Wordpress. Koukám přímo do souboru a žasnu - je plný tohoto svinstva:

# Time: RRMMDD  hh:mm:ss
# User@Host: xxx[xxx] @ xxx.xxx.cz [0.0.0.0]
# Query_time: 11.490648  Lock_time: 0.000177 Rows_sent: 12  Rows_examined: 8374547
use xxx_xx;
SET timestamp=xxxxxxxxxx;
SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts  INNER JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )  INNER JOIN wp_postmeta AS mt1 ON ( wp_posts.ID = mt1.post_id )  INNER JOIN wp_postmeta AS mt2 ON ( wp_posts.ID = mt2.post_id ) WHERE 1=1  AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') AND ( 
  wp_postmeta.meta_key = '_thumbnail_id' 
  OR 
  mt1.meta_key = 'image' 
  OR 
  mt2.meta_key = 'colabs_embed'
) GROUP BY wp_posts.ID ORDER BY RAND() LIMIT 0, 12;

Fuj. Procházím databázi onoho Wordpressu - zaspamovaná rozhodně není. Onen SELECT vypadá odpudivě, budu ho muset najít ve zdrojácích. Prohrabuji se změtí skriptů a přemýšlím, který běsný plugin má toto na svědomí. Po chvilce hledání zjišťuji, že tento dotaz je generován přímo Wordpressem samotným, konkrétně se jedná o fuknci WP_Query. Jakožto člověku neznalému architektury Wordpressu mě chvíli trvá, než se v kódu zorientuji a posléze mi dochází, že toto je zobecněné rozhraní, které poskytuje programátorům pluginů a témat možnost přistupovat standardizovaným způsobem k datům, která Wordpress spravuje. Dobrá, to je z architektonického hlediska správně, ale jak já chudák teď najdu ten shnilý plugin? Nakonec pomohlo to magické číslo 12, které jsem našel v kódu šablony Arthemia Premium. Konkrétně se jednalo o boxík, který zobrazuje náhodné příspěvky.

Co si z toho odnést? Wordpress vám dá dost provazu na to, abyste se sami oběsili, což v kombinaci s autorem šablony, který se nejspíš ani neumí nažrat příborem, vedlo ke smutnému konci. Myslím si, že to celé ukazuje na to, jak se dnešní CMS stávají velkými a složitými a doufám, že se takto postupně uvolní místo na trhu pro nějaký malý a funkčně jednodušší systém.        

Komentáře

[SAM:]

Kdo použije ORDER BY RAND() bez milosti zastřelit za úsvitu pro výstrahu do/z práce jdoucím php prgačům.

[xkucf03]

Myslím si, že to celé ukazuje na to, jak se dnešní CMS stávají velkými a složitými a doufám, že se takto postupně uvolní místo na trhu pro nějaký malý a funkčně jednodušší systém.

Asi před rokem jsem si napsal vlastní redakční resp. blogovací systém. Potíž těch „malých a funkčně jednodušších systémů“ je v tom, že poskytují jen určitou podmnožinu funkcí a každý uživatel potřebuje trochu jinou podmnožinu – takže pokud si to nepíšeš sám, téměř jistě ti tam bude něco chybět.

[Václav "Darm" Novák]

Je fakt že co jsem se začal učit Rails, myslím že pro mě bude Drupal který jsem doteď používal za pár měsíců zbytečný.

Pro člověka co potřebuje rychlý redakční systém "na klíč" je wodpress fajn, stejně tak jako Drupal na složitější věci.

Jakmile ale začnou požadavky růst, začne růst i potřebný čas pro jejich vyřešení…

[trekker.dk]

Myslím si, že to celé ukazuje na to, jak se dnešní CMS stávají velkými a složitými

Podle mě to celé ukazuje, že když si člověk nainstaluje blbě udělanej plugin, tak se nemůže divit.

[kralyk z abclinuxu]

WordPress je imho neuvěřitelná kupa hnoje. Od základů až po pluginy.

[Bedňa]

WordPress je v základe minimalistický, ja si myslím že problém je práve len v pluginoch.

[#Tom]

PHP samo o sobě kupa hnoje, a je hrozné, že nízkonákladové hostingy nic jiného neumějí.

[Bedňa]

Je to free software a má prehľadný kód like C. Python je fajn, ale tiež má kopec múch, na ideme hejtovať o C++? Toto nikam nevedie.

Taký HACK vychytáva chyby PHP a je to stále easy.

[Bystroushaak]

Je to free software a má prehľadný kód like C.

Je to kopa hoven, která nikdy neměla spatřit světlo světa. Speciálně pak interně je to největší hnus, který jsem měl kdy smůlu vidět a způsob jak na sebe vrství jeden špatný nápad za druhým je přímo legendární. Přehlednost kódu je taky úplně v prdeli, horšíuž je fakt jen to C++, které se ani nedá normálně parsovat. Když už pak něco dává smysl syntakticky, tak zprasenost parseru je často tak epická, že ti to stejně nedovolí.

Taký HACK vychytáva chyby PHP a je to stále easy.

HACK toho o PHP vypovídá víc, než veškerý lidský hate - říká, že PHP je na tom tak hrozně, že jedinou alternativou potom co jim to začalo padat na hlavu bylo ho napsat odznova.

[Bedňa]

Je to idea jedného človeka ktorá riešením aktuálnych problémov prerástla možnosti udržania kódu v konzistentnosti. PHP sa stalo najrýchlejšie rastúcim projektom na serverových aplikáciach, určite tam chýbala osobnosť Linusa ktorá by toto stabilizovala. Si mladší, ale spýtam sa ťa akú alternatívu sme vtedy mali? Žiadnu, pokiaľ si sa nechcel uviazať k MikroSoftu.

[#Tom]

Co? Třeba (Fast)CGI, cgicc. Nebo Javu…

[Bedňa]

A fakt si skúšal spraviť web s CGI? Heh Java, no šlo by to, ale nebolo tam ešte nejaké divné licencovanie a kto vlastne o nej počul.

[#Tom]

Ku podivu ano. Pomocí C++ a knihoven boost, cgicc & libfcgi++, cppdb(mysql), libxml2+libxslt, mhash, cryptopp. Na straně klienta je samozřejmě nějaký ten javascript (místy i ajax).

Javu jsem si též nikdy neoblíbil, ale asi by byla lepší (tj. pohodlnější volbou) než C++, protože je pro ni všechno hotové a připravené k použití, jen si vybrat z široké nabídky knihoven. Na velké projekty je používána celkem často, jistě častěji než fastcgi a C/C++.

[Aleš Kapica]

Úchyle

[Bedňa]

Dobre a teraz sa vráť pred rok 2000 a skús to na nejakom hostingu spustiť Mal som s tým problémy, inak môj prvý web bol v Perly.

[deda.jabko]

Jeste se slusi dodat, at si zkusi vytvorit web bez tech knihoven, jelikoz koncem devaddesatych let, temer nic z toho nebylo. A C++ bylo v takovem stavu, ze jednotlive projekty mely stanovene jake featury z jazyka se muzou pouzivat, protoze prekladace vzdy podporovaly jen urcitou podmnozinu jazyka.

[#Tom]

Otázka je, co přesně je konec devadesátých let. U internetu jsem seděl poprvé někdy v sedmadevadesátém a první stránky jsem zkoušel dělat asi o rok později. Stránky byly čistě v HTML a pokročilé možnosti stránkám dodávaly snad tak Java-applety.

Co bylo na straně serverů, nevím, protože jsem k tomu v oné době neměl možnosti. Dynamické stránky byly asi povětšinou v CGI, až už jako binárky, nebo nějaké unixové skripty, třeba v Perlu. Freehosty nabízely dynamické stránky snad až po roce 2000. Mimochodem, ve škole jsem měli tehdy webový server od Novellu, a tam se snad s dynamickými stránkami ani nepočítalo. :)

C++ na tom bylo všelijak, no já dodnes programuju v C++98, ale pamatuju si i ty doby, kdy STL ještě nebylo, a taky to šlo. :)

PHP jsem objevil až po roce 2000 ve verzi 3.0, a co se týče jeho vývoje, tak můžu říct jen to, že látání nedostatků v návrhu všechny mé někdejší projekty rozbilo a uvrhlo v zapomnění.

P.S.: Cgicc a libfcgi jsou poměrně letité knihovny a konec 90. let také pamatují. Že mi to bylo až donedávna k ničemu, pramení zejména z této skutečnosti.

[xxx]

Pokrocile moznosti v te dobe dodavaly strankam animovane gify a JavaScript. Take v te dobe bylo webu mnohem min. PHP proste prislo v dobe, kdy lidi objevovali web, chteli mit jednoduche stranky a neumeli programovat. Umet programovat byla v podstate podminka nutna pro pouziti C/C++ pres CGI. PHP jim dalo presne to co potrebovali, kdyz uz jim nestacila jednoducha staticka webova stranka. V podstate je to jazyk navrzeny tak, aby se v nem dal napsat jednoduchy guestbook a jednoducha sprava clanku na webu (tedy aby je tam uz nikdo nemusel cpat skrz FTP). To bylo to co tehdy uzivatele chteli, protoze to byl predstavitelny krok od statickych stranek. Vyvoj PHP jako jazyka pak imho kopiruje vyvoj toho co lidi chteji aby jejich stranky umely.

[xxx]

Teda abych to zkratil. Slo o co nejsnazsi prechod od ciste statickych stranek k jednoduchym dynamickym. A PHP byl jazyk, ktery byl navrzen imho na zaklade teto potreby, nebo ji nejvice vyhovoval.

[#Tom]

S tím v zásadě souhlasím. PHP je poměrně jednoduché a pro začátek opravdu stačí kopírovat příklady z učebnice. Přestože to vypadá jako zpotvořené Céčko, je jednodušší a nehrozí potíže např. s ukazateli. Na prostinké dynamické stránky pro soukromé účely postačuje. Hrozné je, že jsou v tom tvořeny velké projekty, redakčními systémy a diskusními fóry počínaje, elektronickými obchody konče.

Potíž je ale v tom, že pokud někdo programovat umí, může si vybrat lépe, a pokud programovat neumí, měl by si vybrat jazyk, který nesvádí ke zlozvykům. :)

[Josef Kufner]

Pokud někdo programovat umí, udělá i v PHP velký projekt slušně a rychle. Pokud neumí, neměl by se do velkých projektů pouštět v libovolném jazyce, neboť to dopadne tragicky tak jako tak.

[pavlix]

A fakt si skúšal spraviť web s CGI?

Ano. Bylo to velmi jednoduché a přehledné. Jediný problém byla režie celé aplikace nanovo, ale tu řeší FastCGI nebo jakýkoli jiný konektor založený na kontinuálním běhu obslužného procesu. Klasické PHP tak jak se používalo a často ještě používá je hodně blízko právě tomu CGI s trochou hodně špatně řešené persistence napříč projekty. Vývoj PHP vnímám jako pokusy o postupné odstraňování starších špatných rozhodnutí.

Si mladší, ale spýtam sa ťa akú alternatívu sme vtedy mali? Žiadnu, pokiaľ si sa nechcel uviazať k MikroSoftu.

Jaký rok myslíš tím „vtedy“. Já si osobně nepamatuju rok, kdy by PHP bylo už rozšířené a přitom ještě nebyla lepší alternativa. Na většinu věcí, na které se PHP kdysi používalo, bylo snad i to CGI lepší. Pokud se bavíme o větších aplikacích pro větší množství souběžných uživatelů, tak jsem přesvědčený, že v době, kdy se takové v PHP dělaly, už byly k dispozici nástroje na to při troše snahy vhodnější.

Moje teorie je, že se PHP prosadilo náhodou. Omylem. A díky tomu bylo ve správný čas použitelné s masivním virtualhostingem v Apache a tudíž mohl php skripty splácat kde kdo a nahodit je na nějaký ten freehosting. Já osobně jsem PHP začal používat jen pro to, že za mnou chodili lidi, abych jim s ním poradil. Delší dobu jsem u něj zůstal nejprve z neznalosti a posléze z důvodu, že jsem měl poptávky na jeho opravy, bylo to tehdy něco jako Windows (když odhlédnu od open sourcovatosti).

[deda.jabko]

Jaký rok myslíš tím „vtedy“. Já si osobně nepamatuju rok, kdy by PHP bylo už rozšířené a přitom ještě nebyla lepší alternativa. Na většinu věcí, na které se PHP kdysi používalo, bylo snad i to CGI lepší. Pokud se bavíme o větších aplikacích pro větší množství souběžných uživatelů, tak jsem přesvědčený, že v době, kdy se takové v PHP dělaly, už byly k dispozici nástroje na to při troše snahy vhodnější.

Ja za "vtedy" urcite povazuju obdobi roku '96-97 a tu dobu si moc dobre pamatuju.

(1) CGI v te dobe bylo synonymem pro bezpecnostni diru. Aplikace tehdy bezne trpely na buffer overflow a podobne problemy, pokud byly psane v C/C++, nebo byly zoufale pomale, kdyz se nekdo pokusil programovat web v shellu. (2) Jediny ,,rozumny'' jazyk pro tvorbu webu byl Perl, coz hodne vypovida o zoufale situaci tehdejsi doby. (3) Ale u Microsoftu na tom bylu jeste hur, protoze se stranky delaly ve VBScriptu.

[pavlix]

Ja za "vtedy" urcite povazuju obdobi roku '96-97 a tu dobu si moc dobre pamatuju.

Tak k tomu se nemůžu vyjadřovat, PHP jsem používal ve třetí až čtvrté verzi, tedy v době, kdy se každý považoval za hustého programátora, když napsal pár řádků právě v tomto jazyce.

(1) CGI v te dobe bylo synonymem pro bezpecnostni diru.

Tak to za mě už bylo synonymem pro bezpečnostní díru PHP mimojiné kvůli tomu, že si nechalo nakecat po HTTP prakticky cokoliv.

[deda.jabko]

Tak k tomu se nemůžu vyjadřovat, PHP jsem používal ve třetí až čtvrté verzi,

Takze si nedokazes predstavit jaka v te dobe byla PHP spasa...

Tak to za mě už bylo synonymem pro bezpečnostní díru PHP mimojiné kvůli tomu, že si nechalo nakecat po HTTP prakticky cokoliv.

A myslis, ze s CGI to bylo jine? S tim to bylo jeste vychytanejsi. V pripade C spousta krasnych buffer overflow pro spusteni libovolneho kodu. V pripade psani CGI v shellu jedny zapomenute uvozovky a uz jsi mel bezpecnosti diru, ktera ti umoznila spustit libovolny kod pres HTTP request. To s PHP do znacne miry odpadlo.

[pavlix]

Takze si nedokazes predstavit jaka v te dobe byla PHP spasa...

Zkušenosti jsou nepředatelné a osobně jsem docela rád, že jsem s PHP strávil jen nějaký čas a pak šel o dům dál.

A myslis, ze s CGI to bylo jine?

Dnešní specifikace CGI mi přijde bezproblémová, ona tehdy byla nějaká jiná?

V pripade C spousta krasnych buffer overflow pro spusteni libovolneho kodu. V pripade psani CGI v shellu jedny zapomenute uvozovky a uz jsi mel bezpecnosti diru, ktera ti umoznila spustit libovolny kod pres HTTP request.

Nic z toho ovšem nejsou vlastnosti CGI, ale jsou to vlastnosti programů, potažmo jazyků, ve kterých jsou vytvořené.

To s PHP do znacne miry odpadlo.

Pokud to správně chápu, tak s PHP neodpadl jediný bezpečnostní problém CGI.

[deda.jabko]

Na většinu věcí, na které se PHP kdysi používalo, bylo snad i to CGI lepší

Zeptsam se tedy: A PHP pres CGI je v necem lepsi?

Dnešní specifikace CGI mi přijde bezproblémová, ona tehdy byla nějaká jiná?

Nic z toho ovšem nejsou vlastnosti CGI, ale jsou to vlastnosti programů, potažmo jazyků, ve kterých jsou vytvořené.

FYI, CGI je jen rozhrani a se samotnym CGI toho opravdu prilis nenaprogramujes. Nemuzes rict, CGI je bez problemu, kdyz k tomu neberes veci okolo.

Pokud to správně chápu, tak s PHP neodpadl jediný bezpečnostní problém CGI.

PHP umoznilo eliminovat radu beznych chyb, ktere se tehdy dely kvuli tomu, jak fungovala kombinace CGI/C nebo CGI/shell.

Btw. jeden z duvodu proc se PHP rozsirilo na levne/free hostingy bylo i to, ze to narozdil od CGI slo relativne bezpecne nakonfigurovat.

[pavlix]

Nemuzes rict, CGI je bez problemu, kdyz k tomu neberes veci okolo.

Jenže ono není bez problémů, má výkonnostní problém spojení se spouštěním aplikace pro každý jednotlivý request. Ale rozhodně bych netvrdil, že nelze CGI hodnotit samostatně. Není vázané na žádný programovací jazyk, tudíž není nutné ho hodnotit v kontextu C/C++ ani shellu.

PHP umoznilo eliminovat radu beznych chyb, ktere se tehdy dely kvuli tomu, jak fungovala kombinace CGI/C nebo CGI/shell.

S tím nemám problém. Tak jak se běžně píše v céčku se nedá o bezpečném programování mluvit a o shellu bych radši pomlčel. Ale jak už jsem psal, nic z toho není problém CGI, klidně se mohl použít jakýkoli programovací jazyk včetně PHP nad CGI nebo vyjít z konceptu CGI a přidat obsluhu více requestů, což se stalo (FastCGI, mod_PHP, ...). Přisuzování bezpečnostních problémů CGI považuju za chybnou analýzu, jestliže ty problémy vycházejí z výběru jazyka a nikoli protokolu.

[deda.jabko]

Sorry, ale ohybas si vyznam slov dle vlastni potreby. Napsals:

Já si osobně nepamatuju rok, kdy by PHP bylo už rozšířené a přitom ještě nebyla lepší alternativa. Na většinu věcí, na které se PHP kdysi používalo, bylo snad i to CGI lepší.

Vyvodil jsem si, ze myslis programovani s CGI v sirsim slova smyslu, tj. tak jak se bezne pouzivalo. Samotne CGI evidentne nemuze byt alternativou k PHP, jinak predchozi tvrzeni nedava smysl, jelikoz prvni verze PHP bezely prave pres CGI, coz je evidetne spor.

Ale rozhodně bych netvrdil, že nelze CGI hodnotit samostatně.

Pokud chces srovnavat PHP a CGI musis to brat jako celek. Jinak srovnavas auto s pneumatikou.

Přisuzování bezpečnostních problémů CGI považuju za chybnou analýzu, jestliže ty problémy vycházejí z výběru jazyka a nikoli protokolu

Ja ty problemy prisuzuju celemu ekosystemu (CGI v sirsim slova smyslu) a ukazuju na to, ze PHP v te dobe ty problemy opravdu resilo, coz ty si evidentne nemyslis. Viz citace vyse.

Kdyz jsme u toho, predstav si, ze se pise rok '97/'98, co bylo tou lepsi alternativou?

[pavlix]

Asi nemůžu věnovat diskuzi tolik času a energie, abych se vyjádřil dostatečně jasně pro tento účel. Tohle by bylo spíš asi na hospodskou diskuzi.

[Aleš Kapica]

Pokud si já pamatuji, tak se PHP rozšířilo především kvůli tomu, že to byl jediný skriptovací jazyk, který nabízela většina free hostingových serverů. Špatně napsané CGI skripty tyto hostingy představovaly bezpečnostní riziko, proto bylo obvykle jejich použití zakázáno. Nepamatuji si, že by někdo nabízel k využití něco jiného.

Já své první dynamické weby psal v ASP (VBScript) (2000-2003), především proto, že byly určeny pro servery, které jely na Mrkvosoftu. Pak už jsem programoval webové aplikace výlučně v PHP, protože to byla proti tomu naprostá selanka. S aplikacemi v javě jsem měl tak špatné zkušenosti, že jsem o jejím použití ani neuvažoval.

Na PHP jsou postaveny prakticky všechny webové aplikace, se kterými nějakým způsobem pracuji - MediaWiki, Moodle, Mantis, aj. Kamarád, co dělá weby komerčně, je staví na ruby. Ale to nejsou žádné velké věci. Se skutečně funkčním webem v pythonu jsem se prakticky nesetkal. Tedy pokud nepočítám ojedinělý pokus o aplikaci webu na Plone, který ztroskotal na tom, že dotyčný nesehnal nikoho, kdu by mu ten web vůbec udělal. Prakticky jediný web o kterém vím, že jede na javě je abclinuxu.

[pavlix]

Pokud si já pamatuji, tak se PHP rozšířilo především kvůli tomu, že to byl jediný skriptovací jazyk, který nabízela většina free hostingových serverů.

Jestliže tvrdíš, že se rozšířil až následkem nabídky freehostingových serverů, jak vysvětlíš vznik té nabídky tehdy obskurního jazyka? To ho nabízeli omylem?

[Aleš Kapica]

Instalaci kombinace apache + php + mysql na domácím kompu zvládnul každý kdo měl do prdele díru. Logicky proto pak hledal hosting, nabízející stejnou kombinaci, kde by své podomácku usmolené stránky upíchnul. A nejlevnější byly hostingy na linuxových serverech, kde byla instalace této kombinace obdobně jednoduchá.

[pavlix]

Instalaci kombinace apache + php + mysql na domácím kompu zvládnul každý kdo měl do prdele díru.

Ostatně jako jakoukoli kombinaci software, ke které existoval návod.

[Bystroushaak]

Se skutečně funkčním webem v pythonu jsem se prakticky nesetkal. Tedy pokud nepočítám ojedinělý pokus o aplikaci webu na Plone, který ztroskotal na tom, že dotyčný nesehnal nikoho, kdu by mu ten web vůbec udělal.

Na plone jedou prakticky všechny veřejně přístupné aplikace Národní knihovny. Interně se pak používá místy i PHP* a docela dost .net, protože to nějaký manažer to vybral jako „stabilní platformu“.

*PHP se tu začalo hroutit lidem na hlavu až tak, že se teď několik projektů přepisuje do pythonu, jelikož byly naprosto neudržovatelné.

[Aleš Kapica]

Je úplně fuk co se použije. Pokud je programátor prase, tak to sebelepší skriptovací jazyk nespasí.

[Bystroushaak]

To nerozporuji. Jde mi spíš o to, že PHP působí na prasata jako magnet a ještě jejich prasáckost amplifikuje, protože je samo prasácké.

[Aleš Kapica]

No jó. Jenže to je dané jeho lácí (viz výše). Použít cokoliv jiného již vyžaduje vyšší dívčí, což znamená jistý filtr. Na druhou stranu větší popularita PHP také znamená větší šanci, že se vyskytnou kromě čuníků i schopní prgači co nečuňačí.

[pavlix]

Na druhou stranu větší popularita PHP také znamená větší šanci, že se vyskytnou kromě čuníků i schopní prgači co nečuňačí.

Na druhou stranu, pokud se někdo chce vydávat za programátora, tak by pro něj změna programovacího jazyka neměla být zásadní překážkou, zvláště pokud se to ukazuje jako změna k lepšímu.

[Aleš Kapica]

Na počátku většiny dnes profláknutých PHP aplikací byli nadšenci, co si chtěli udělat aplikaci pro svou potřebu a ne profi programátoři. Tudíž je na místě spíš položit si otázku: Proč nejsou k dispozici srovnatelné aplikace v oněch "lepších" jazycích?

A rovnou ti odpovím - profi prgači totiž na takové blbosti nemají čas. Je to obdobná situace jako u opensource překladů. Většinou je dělají nadšenci, co se překlady neživí.

[Bedňa]

Ako píšeš hlavne to chodilo všade s CGI skriptami boli problémy, hlavne v rozdielnom nastavení serverov. Informácií bolo málo a okolo sa začala šíriť PHP3 niekedy pred rokom 2000 čo dobre chodilo na každom hostingu.

Internet bol veľmi drahý a keď som tam chcel byť online aspoň hodinu, tak som radšej išiel do NetCafe, tam ma to aj s Pivom vyšlo lacnejšie o viac ako polovicu. Toš dnes sú všetci chytrí, ale vtedy neexistoval ani Google, teda minimálne o ňom nepočul nikto koho som poznal.

Proste to bola úplne iná doba.

[pavlix]

Ako píšeš hlavne to chodilo všade

To není tak úplně pravda. Formálně vzato chodilo PHP všude, ale aplikace napsané pro PHP už nikoliv, z tím jsem udělal taky nějakou tu zkušenost.

[Bedňa]

Problémy boli len keď si prešiel na vyššiu verziu PHP, preto si spravidla na hostingoch môžeš vybrať verziu PHP. Ja už keď som na niečo šiahol, tak som to hneď prepísal na najnovšiu verziu. Väčšinou išlo o triviálne veci riešiteľné skriptom, medzi najhorší porod pokladám prechod z ereg na preg_match riešil som to hneď ako bola ereg za výbehovú (≅ 2002), teda vždy som nasadzoval najnovšie funkcie aby som mal potom na dlhšie pokoj.

[pavlix]

Problémy boli len keď si prešiel na vyššiu verziu PHP

Nikoliv. Problémy nastávaly i při přesunu na jiný hosting se stejnou verzí nebo při přesunu domácí testovací verze na hosting. A ty problémy mimochodem přetrvávají dodnes, není to tak dlouho, co mi někdo platil za jejich řešení jak na straně vývojářské firmy, tak na straně hostingu.

[Aleš Kapica]

Tak to musela být echt humusácky napsaná aplikace.

[pavlix]

Tak určitě.

[kralyk z abclinuxu]

Tak to musela být echt humusácky napsaná aplikace.

Ani ne, úplně stačilo, když měl hosting trochu jinak nakonfigurované PHP, PHP moduly a/nebo Apače, a aplikace šla do kýblu.

[Bedňa]

Stále chyba programátora ktorý používal neštandardné veci, toto je úplne rovnaké v hocijakom jazyku.

[pavlix]

toto je úplne rovnaké v hocijakom jazyku.

Právě naopak, PHP je v tomto unikátní.

[Bedňa]

Aha jasne, zrejme narážaš na veľké rozdiely v konfigurákoch, ja som ale písal a prepisoval skripty tak aby to šlo aj na hostingoch s najprísnejšou bezpečnostnou politikou. Pokiaľ to bolo nevyhnutné požiadal som helpdesk o povolenie určitej voľby na inú hodnotu. Sa čudujem že vôbec niekto s tým má problém, pretože sa mi nestalo aby na mňa vyskočila chybová ktorá by ma nenavigovala správnym smerom.

Nikto na hostingu samozrejme nepoužíva defaultný konfig a samozrejme medzi tvojim a ich konfigom rozdiel bude. Námatkovo fopen na HTTP je na hostingoch na 99% zakázaný atď.

[pavlix]

Víceméně. Jen se to nesnažím za každou cenu prezentovat jako super věc.

[Josef Kufner]

PHP se prosadilo hlavně neskutečně nízké vstupní bariéře. Udělat jednoduchou dynamickou stránku je velmi, velmi snadné. Není potřeba nic, než napsat pár řádek kódu a nahrát to na server. Tomu jen málo který jazyk/framework dokáže konkurovat. Pro velké projekty a pokročilé programátory to nepředstavuje moc velký přínos, neboť ti už musí deploy řešit pořádně, ale pro ty malé a začínající to je obrovská výhoda. Ze stejného důvodu se chytlo Arduino a podobné věci.

[pavlix]

Pro velké projekty a pokročilé programátory to nepředstavuje moc velký přínos, neboť ti už musí deploy řešit pořádně, ale pro ty malé a začínající to je obrovská výhoda.

Myslím si, že se jedná pouze o domnělou výhodu s výjimkou skutečně malých „projektů“ typu deset řádků PHP kódu v rámci HTML stránky, programování pomocí copy&paste, případně člověka, který ještě nenapsal svých prvních pár desítek řádků vlastního kódu. Sám jsem se zasekl hned za touhle bariérou ve chvíli, kdy jsem měl mít více stránek s nějakými společnými prvky. To jsem zjistil, jaká je to neskutečná prasárna a od té doby jsem jenom hledal cestu jak z toho ven. Ta hranice byla přesně mezi vepisováním skriptíků do jednotlivých HTML stránek a tvorbou programového celku i kdyby jen na úrovni pár článků se společným layoutem a nabídkou a nedej bože, aby ještě člověk chtěl, aby to mělo rozumná URL.

[Josef Kufner]

Jenže tyhle skutečně malé projekty jsou to, kde uživatel a budoucí programátor začne, kde se naučí cykly a funkce. To je to podstatné. Další krok je poskytnout vhodný framework, který ho přenese přes ty další překážky, aby mohl začít tvořit něco většího.

[deda.jabko]

Jenže tyhle skutečně malé projekty jsou to, kde uživatel a budoucí programátor začne, kde se naučí cykly a funkce. To je to podstatné.

To je dobry postreh. PHP je do jiste miry ekvivalentem Basicu. Neni to zadna elegance, ale diky nizkym vstupnim barieram v tom muze i zacatecnik jednoduse udelat neco, co hned funguje a ma tak zpetnou vazbu, cf. Java, C#, C, kde si clovek musi nejdriv nastudovat relativne pokrocile vlastnosti, aby vubec udelal "Hello World".

[q]

tehdy? co treba lisp? Machri v tom napsali treba viaweb (dneska se to menuje yahoo store). Doporucuju poctenicko

[Bystroushaak]

Jako počteníčko doporučuji celou tu knihu, například i kapitola o školách stojí za pozornost.

[kralyk z abclinuxu]

Doporucuju poctenicko

Sorry, ale články tohohle typu mi přijdou jako naprostý bullshit. A to celkem bez ohledu na to, jaká technologie se tam glorifikuje... Jestli se jim dařilo, tak to bylo proto, že byli prostě dobří v tom, co dělali, a to jak po obchodní stránce, tak po programátorské. A že k tomu zrovna použili technologii XY (v tomto případě LISP) nedokládá, že tato technologie nejmocnější na světě a všichni ostatní jsou Blub necháopající pokročilé myšlenkové paradigma a kdesicosi, ale prostě to, že ji dobře zvládli a dokázali ji dobře obchodně využít, to je celý. Zbytek textu je jen mentální onanie nad makry v LISPu...

P.S. Nemám nic proti LISPu. Podobný moudra by se daly napsat o víceméně jakýkoli technologii...

[Bystroushaak]

Proto jsem odkazoval tu knihu, protože článek je lehce vytržený z kontextu. Konkrétně lisp mu v té době (95/98? už nevím) umožnil hodně rychle vytvářet prototypy, čemuž ostatní jazyky (C/C++, možná Java) moc konkurovat nemohly. Uvádí tam různé příběhy, jak konkurence uvedla s velkou slávou nějakou novou feature, kterou vytvářeli půl roku a on tu funkčnost přes noc nahackoval v lispu.

Osobně docela chápu, co tím myslel, protože v pythonu taky člověk dosahuje podstatně větší produktivity, když se snaží a „hackuje“. Kdysi jsme na IRC dělali pár různých soutěží, kde bylo cílem co nejrychleji něco implementovat (spam bota na web, IRC bota pro TODO listy a tak) a většinou jsem to vyhrával, právě díky pythonu. Samozřejmě že kód nebyl nijak super čistý a nenazval bych ho „produkčním“, ale to se v jeho případě dalo řešit týdny po tom co tu funkčnost přidal.

[xkucf03]

Kdysi jsme na IRC dělali pár různých soutěží, kde bylo cílem co nejrychleji něco implementovat (spam bota na web, IRC bota pro TODO listy a tak) a většinou jsem to vyhrával, právě díky pythonu.

A proč myslíš, že je to jazykem? IHMO to souvisí spíš s existencí potřebných knihoven a hlavně se schopnostmi programátora (jak dobře ty knihovny a jazyk zná). Kdybys uměl na stejné úrovni Javu, tak věřím, že by ti to šlo stejně rychle nebo i rychleji – knihovny bys postahoval přes Maven a poslepoval to dohromady. Totéž v C++, pokud by ty knihovny existovaly a byl bys schopný je rychle postahovat a nainstalovat (u těch, co jsou v distribuci by to nebyl problém). Perlař by to napsal rychle v Perlu, Rubysta v Ruby a PHPčkář stejně tak v PHP (jakkoli si můžeš říkat, že PHP je špatný jazyk).

V takových sólových sprintech se rozdíly mezi jazyky moc neprojeví (za předpokladu, že existují potřebné knihovny a není potřeba program stavět na zelené louce včetně implementace protokolů a formátů). Rozdíly se projeví až při běhu na dlouhou trať a při týmové práci.

[Bystroushaak]

A proč myslíš, že je to jazykem?

Protože se té soutěže účastnili lidi, kteří uměli programovat líp jak já a prohrávali. Podle mého právě díky volbě jazyka. Speciálně pak v Javě a C++, kde s trochou nadsázky v prvním jmenovaném začali implementovat továrnu továren a zabili spoustu času na okrajových věcech. Nehledě tedy na to, že nižší ukecanost pythonu a REPL ti imho obecně vývoj prototypu dost usnadňují.

[xkucf03]

začali implementovat továrnu továren a zabili spoustu času na okrajových věcech.

To opět není věc jazyka. To je dané stylem vývoje. Za C++ nechci mluvit, ale v té Javě je zvykem dodržovat nějakou štábní kulturu, používat víc abstrakce a dělat robustnější návrh, který ti usnadňuje měnit věci v budoucnu. (taky by mi to bylo proti srsti a vím, že bych s tím bojoval, jestli program naprasit a vyhrát soutěž nebo napsat program tak, abych s ním byl spokojený a mohl ho později rozvíjet)

Např. tam podstrčíš (injektuješ) jinou továrnu, a tím změníš chování programu nebo mu přidáš novou funkcionalitu, aniž bys musel měnit ten zbytek. Dokonce nemusíš měnit vůbec žádný kód a stačí přidat nějaké JARko do cesty a upravit konfigurační soubor. A díky typové bezpečnosti to drží pohromadě a ani při takových změnách se ti to nerozsype pod rukama.

Ono to není úplně intuitivní a přiznám se, že jsem zpočátku taky nechápal, proč musím vytvářet nějakou továrnu a psát tři řádky kódu, když by na to stačila jedna funkce. Na tohle člověk přijde až časem, když potřebuje psát větší programy nebo mít flexibilnější návrh aplikace.

Ale na druhou stranu to není nic povinného – i v té Javě se to dá naprasit a napsat to rychle, jednoúčelově, mít kód na jedno použití. Existuje spousta knihoven, které to standardní pružné API obaluje jednoúčelovými funkcemi a jednodušším (v krátkodobém horizontu) rozhraním.

a zabili spoustu času na okrajových věcech

Jedna z důležitých věcí, co jsem se v průběhu programování naučil, je: dělat robustní návrh, ale ne víc, než je nutné a zohledňovat při tom důležitou otázku: kolik kódu budu muset při přepisu zahodit? Dejme tomu, že program bude tvořit pár modulů o celkově X řádcích (v nich je ta důležitý byznys logika). A pak můžu napsat nějaký úžasný framework, který ty moduly zapojí dohromady a bude flexibilní, konfigurovatelný a připravený na všechno a bude mít třeba 1/3 X řádků. Ale v první verzi programu tahle flexibilita není potřeba. Tak udělám pořádně ty moduly, navrhnu jim dobré rozhraní, ale ten framework teď psát nebudu a místo něj napíšu kód na pár desítek řádků, který to jen natvrdo poslepuje dohromady. A až v příští verzi dopíšu ten konfigurovatelný framework, zahodím jen třeba 50 řádků toho původního lepidla, což není žádná tragédie. Zároveň těch modulů už bude víc, takže 1/3 původního X už není tolik.

Na druhou stranu, kdybych měl zahazovat větší stovky nebo tisíce řádků, tak by se asi vyplatilo to napsat už od začátku pořádně. Tohle je celkem dobré kritérium pro rozhodování.

REPL

Malé programy v Javě jsou zkompilované a spuštěné okamžitě (doslova), stačí v IDE zmáčknout tlačítko a hned vidíš výsledek. A i když ten program má třeba tři sta tisíc řádek, tak je zkompilovaný za půl minuty, takže ani to není nějaká tragédie. Taky se používají jednotkové testy, které ti umožňují odladit část programu, ať už je ten celek sebevětší. Můžeš si to spouštět a ladit znova a znova v řádu milisekund. To mi přijde lepší, než nějaký REPL, protože jednotkový test máš uložený v souboru a je to reprodukovatelné – můžeš na to navázat za měsíc, za rok, předat to kolegovi. Ale co jsi psal do REPL včera, to už dneska nenajdeš, nebo to stěží vydoluješ z historie.

Navíc je tu výborný debugger, ve kterém můžeš měnit program za chodu – takže když zjistíš, že jsi někde zapomněl podmínku nebo prohodil dva řádky, aktualizuješ kód v běžícím programu a hned ti to funguje. Nemusíš kvůli tomu kompilovat a restartovat celou aplikaci.

A REPLy pro Javu taky existují. Taky existuje BeanShell nebo různé skriptovací jazyky, které můžeš začlenit do programu v Javě. A nakonec i jiné jazyky než Java běžící nad JVM, které se s tou Javou dají používat souběžně.

BTW: jak dlouho taková soutěž trvá? Jaký čas měl nejlepší a nejhorší soutěžící + nějaký průměr?

[Bystroushaak]

Přijde mi, jako bys předpokládal, že jsem nikdy nedělal v Javě. Já tím strávil 3 roky na VŠ. Programovat bych v ní sice asi už nemohl, protože už je to 5 let a půlku jsem zapomněl (nebyl by problém si připomenout), ale tyhle věci kolem si dobře pamatuji.

Ale co jsi psal do REPL včera, to už dneska nenajdeš, nebo to stěží vydoluješ z historie.

Úplně normálně se mi to ukládá, stejně jako třeba historie bashe:

try:
    import readline
except ImportError:
    print("Module readline not available.")
else:
    import rlcompleter
    if 'libedit' in readline.__doc__:
        readline.parse_and_bind("bind ^I rl_complete")
    else:
        readline.parse_and_bind("tab: complete")

# command history
import os
import atexit

# file pyhistory must be created first, e.g. with `touch`
historyPath = os.path.expanduser("~/.pyhistory")
def save_history(historyPath=historyPath):
    readline.write_history_file(historyPath)

if os.path.exists(historyPath):
    readline.read_history_file(historyPath)

atexit.register(save_history)

del os, atexit, readline, rlcompleter, save_history, historyPath

(Snippet odněkud z netu do ~/.pythonrc, který přidává historii (~/.pyhistory) a zároveň doplňování kódu TABem.)

BTW: jak dlouho taková soutěž trvá? Jaký čas měl nejlepší a nejhorší soutěžící + nějaký průměr?

Přibližně 2 hodiny. Většinou nás to napadne někdy večer, třeba kolem deváté, desáté a táhne se to do půlnoci. Dneska je asi moderní tomu říkat „hackathon“, ale tohle je taková spontánní akce, vzniklá z nějaké hádky většinou. Nejkratší řešení je obvykle na čas, tedy do půlnoci (2 - 3 hodiny), nejdelší trvá dodnes :D

[xkucf03]

Přijde mi, jako bys předpokládal, že jsem nikdy nedělal v Javě. Já tím strávil 3 roky na VŠ. Programovat bych v ní sice asi už nemohl, protože už je to 5 let a půlku jsem zapomněl (nebyl by problém si připomenout), ale tyhle věci kolem si dobře pamatuji.

Tím spíš bys měl vědět, že tohle je otázka stylu daného programátora a dalších knihoven a ne otázka jazyka jako takového a jeho standardní knihovny. BTW: když píšeš programy v Pythonu, jak často si vystačíš se standardní knihovnou a jak často musíš sáhnout po externích knihovnách?

Jestli ten programátor začal psát vlastní továrny… tak byl pomalejší kvůli tomu stylu, ne kvůli jazyku – zřejmě psal stylem, jakým se píší aplikace, které plánuješ udržovat a rozvíjet roky, což se na jednorázový bastl nehodí a zákonitě mu to tímhle stylem muselo trvat déle.

Úplně normálně se mi to ukládá, stejně jako třeba historie bashe:

Vždyť píšu, že se to dá vydolovat z historie. Ale mít to v souboru, který můžeš spravovat verzovacím systémem a sdílet s kolegy (nebo sám se sebou po týdnech, měsících, letech…), je kvalitativně někde jinde. Přijde mi, že se význam REPL přeceňuje. Já to používám tak leda když potřebuji něco triviálního spočítat v Octave. Jinak píšu buď ty jednotkové testy nebo ten jednorázový spustitelný kód uložím do souboru a spouštím – když to odladím, tak se to pak snáz zkopíruje do skutečného programu, než kdybych to měl dolovat z historie.

Přibližně 2 hodiny.

A o čem má tahle soutěž vypovídat?

Úlohy na dvě hodiny se nedají srovnávat s projekty, které trvají měsíce a jejichž produkt se má používat a rozvíjet další roky. Je to asi jako když máš něco spočítat: jeden vezme tužku, papír, kalkulačku a má to hotové dřív, než ten druhý zapne počítač a spustí program (Calc, Octave, PostgreSQL…). Ale když je to opakovaný a dlouhodobější úkol, tak se vyplatí investovat víc času v začátku a pak už jen třeba sypat data do tabulky a spouštět nad nimi proceduru.

[Bystroushaak]

Tím spíš bys měl vědět, že tohle je otázka stylu daného programátora a dalších knihoven a ne otázka jazyka jako takového a jeho standardní knihovny.

S tím právě nesouhlasím. Jak zde bylo ukázáno v minulé diskuzi, python člověku spoustu věcí usnadňuje, i díky zabudovaným featurám jako list comprehension, dynamickým a asociativním polím atd.. Ne že by to v javě nebylo, ale taková trivialita jako hození objektu do asociativního pole zabere v pythou asi tak jeden řádek, zatímco v javě (a jinde) jsou to desítky. To tě zpomaluje.

Vždyť píšu, že se to dá vydolovat z historie. Ale mít to v souboru, který můžeš spravovat verzovacím systémem a sdílet s kolegy (nebo sám se sebou po týdnech, měsících, letech…), je kvalitativně někde jinde.

Tady se asi nechápeme - REPL používám na debug, či ověřování některých vlastností. V podstatě se to dá srovnat s napsáním miniaturního testu, který spustím ručně. K tomu mám historii, abych se do ní mohl podívat, ale není to nic co bych chtěl udržovat věčně a sdílet s kolegy, to je samotný ten zdroják, který je také verzovaný.

BTW: když píšeš programy v Pythonu, jak často si vystačíš se standardní knihovnou a jak často musíš sáhnout po externích knihovnách?

Záleží na tom co zrovna dělám. Třeba u toho IRC bota si člověk vystačí se socketem. U práce s webem to chce htmlparser a něco co bude podporovat https a cookies (requests třeba).

Přijde mi, že se význam REPL přeceňuje.

Mně zas že se podceňuje. Když já programuji, tak to doslova vypadá tak, že uprostřed obrazovky je Sublime a okolo 2-4 okna terminálu, některé s bashem a jiné s pythonem, kde z těch bashových často skáču přes pdb/code přímo do kódu toho běžícího programu.

A o čem má tahle soutěž vypovídat?

O tom že (cituji sám sebe):

Proto jsem odkazoval tu knihu, protože článek je lehce vytržený z kontextu. Konkrétně lisp mu v té době (95/98? už nevím) umožnil hodně rychle vytvářet prototypy, čemuž ostatní jazyky (C/C++, možná Java) moc konkurovat nemohly. Uvádí tam různé příběhy, jak konkurence uvedla s velkou slávou nějakou novou feature, kterou vytvářeli půl roku a on tu funkčnost přes noc nahackoval v lispu.

Osobně docela chápu, co tím myslel, protože v pythonu taky člověk dosahuje podstatně větší produktivity, když se snaží a „hackuje“.

Vypovídá to tedy o tom, že chápu jak to v té knize myslel, protože v pythonu jsem taky zažil velmi rychlé vytváření poměrně komplexních prototypů.

[xkucf03]

taková trivialita jako hození objektu do asociativního pole

K čemu je to dobré?

Za správné a bezpečné považuji definovat si strukturu na jednom místě (napsat třídu, rozhraní) a pak ji na mnoha místech používat. Vtip je v tom, že to drží pohromadě a nerozsype se to, nemusíš ručně udržovat v souladu jednotlivé části programu – to za tebe hlídá kompilátor. Když k tomu budeš přistupovat jako k prvkům mapy schovaným pod nějakým textovým klíčem, tak si musíš ručně hlídat, aby na sebe ty klíče pasovaly, aby ses vždy trefil do správných – stačí jeden překlep a vede to k těžko odhalitelným chybám a nevyzpytatelnému chování.

Kdežto když použiješ třídy/rozhraní a přistupuješ k metodám, kontrolu za tebe provede kompilátor.

A když už máš natolik volné struktury, můžeš rovnou používat mapy a žádné objekty do toho ani tahat nemusíš.

Jsem toho názoru že reflexe a introspekce objektů náleží spíš frameworkům/knihovnám, ne aplikacím. Např. můžeš mít vizuální editor vlastností libovolného objektu.

Když už to chceš řešit v aplikaci, tak viz níže.

zabere v pythou asi tak jeden řádek, zatímco v javě (a jinde) jsou to desítky.

V Javě je to taky jeden řádek:

Map<String, Object> mapa = převeďNaMapu(o);

Zbytek je otázka knihoven. Když si to budeš chtít napsat sám, je to na pár řádků:

public static Map<String, Object> převeďNaMapu(Object o) throws IntrospectionException {
    Map<String, Object> mapa = new HashMap<>();

    Stream.of(Introspector.getBeanInfo(o.getClass()).getPropertyDescriptors())
            .filter(pd -> pd.getWriteMethod() != null)
            .forEach((PropertyDescriptor pd) -> přidejDoMapy(mapa, pd, o));

    return mapa;
}

private static Object přidejDoMapy(Map<String, Object> mapa, PropertyDescriptor pd, Object o) {
    try {
        return mapa.put(pd.getName(), pd.getReadMethod().invoke(o));
    } catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException e) {
        throw new RuntimeException(e);
    }
}

Příklad použití:

PolníTřída o = new PolníTřída();

o.setA("Ahoj");
o.setB(true);
o.setC(123);
o.setNázev("Polní třída");

Map<String, Object> mapa = převeďNaMapu(o);
mapa.entrySet().stream().map(e -> e.getKey() + " → " + e.getValue()).forEach(System.out::println);

vypíše:

a → Ahoj
b → true
c → 123
název → Polní třída

To tě zpomaluje

Mě spíš zpomalovalo bojovat se záhadným chováním aplikace psané v Pythonu. A i když jsem se ptal jejích „architektů“, tak nebyli schopní chybu odhalit, resp. rozluštění té záhady jim trvalo na můj vkus až moc dlouho (šlo o to zjistit, co je potřeba kde upravit, když jsem na nějaké místo dopsal pár řádků – zhruba ve smyslu: přidal jsem nové vlastnosti nějakému objektu). Právě ta dynamičnost a práce s různými asociativními poli je příčina, proč se to špatně ladí a špatně hledá, kde je potřeba provést další změny.

V Javě bych dal Alt+F7 a zjistil, kde se daná věc používá a provedl tam potřebné úpravy. Když ale používáš asociativní pole a textové klíče, tak nic nenajdeš (nebo zase najdeš spoustu nesouvisejících věcí – grepem).

REPL používám na debug, či ověřování některých vlastností

K tomu používám public static void main(String[] args) { … }, když už jsem tedy líný psát jednotkový test nebo to nedává smysl (jedná se skutečně o jednorázové odladění a kód se pak zahodí nebo přesune jinam). Neříkám, že REPL je špatná věc, ale nechybí mi (resp. nemám důvod ho používat).

skáču přes pdb/code přímo do kódu toho běžícího programu.

K tomu používám debugger v IDE. Resp. on tam ten REPL vlastně je – zastavíš si program na určitém řádku a v tu chvíli můžeš v daném kontextu spustit libovolný kód, který napíšeš do okna v IDE. A historii to má taky. Výsledek vyhodnoceného výrazu vidíš v okně s lokálními proměnnými a navíc to není textový výstup na konzoli, ale stromový pohled na objekty, který si můžeš rozklikávat.

Nicméně správně by IMHO měl vývoj vypadat tak, že si vystačíš s IDE a dokumentací a měl bys to trefit napoprvé správně (resp. to, že to netrefíš, je dané tvými lidskými chybami, ne tím, že by to nešlo). Tzn. návrh aplikace a okolních API by měl být tak dobrý a tak dobře zdokumentovaný, aby sis přečetl JavaDoc (nebo jeho obdobu v jiných jazycích) a věděl, co máš napsat. Ladění v debuggeru by měla být spíš výjimečná záležitost.

Vypovídá to tedy o tom, že chápu jak to v té knize myslel, protože v pythonu jsem taky zažil velmi rychlé vytváření poměrně komplexních prototypů.

Jenže život nejsou jen prototypy nebo weby s jepičím životem (které se namastí, pak pár měsíců běží a zvyšují prodej a pak se zahodí a jede se znova).

Minulý projekt jsem dělal na produktu v Javě, jehož základy byly deset let staré. Teď dělám na produktu, jehož SQL části se začaly psát před víc než patnácti lety. A jsem rád, že to tehdy autoři nenamastili jako rychlý prototyp. Ona ta pracnost slušného řešení není o tolik vyšší a brzo se vrátí (to se samozřejmě netýká dvouhodinových soutěží nebo malých jednorázových webů předurčených k zahození).

jak konkurence uvedla s velkou slávou nějakou novou feature, kterou vytvářeli půl roku a on tu funkčnost přes noc nahackoval v lispu.

Co se týče rychlého uvádění na trh: dost věcí můžeš odložit do další verze (viz prostřední část mého předchozího komentáře), ale nemám rád kompromisy v kvalitě – už mnohokrát se mi potvrdilo, že přístup „teď to uděláme narychlo a pak to přepíšeme pořádně“ prostě nefunguje. Prasit se nevyplácí a když to uděláš, vrátí se to to jako bumerang. Jediný způsob, jak tomu utéct, je ten produkt zahodit nebo jít pracovat jinam. Je tedy potřeba mít přehled, co je dobře napsané a splňuje tvoje nároky na kvalitu, a co je dočasný bastl – např. jsi napsat kvalitní vstupně-výstupní moduly, víš že je to dobrý kód, na který se můžeš spolehnout a znovupoužívat ho. A pak máš jádro, které bys v první verzi nestíhal pořádně napsat, tak je místo něj dočasné lepidlo, které následně zahodíš. Takhle se pracovat dá a zrychlit vývoj, ale musíš přesně vědět, která část kódu patří do které kategorie a kterou je potřeba v příští verzi přepsat. Když se ty hranice setřou a zahnojené je tak trochu všechno, tak se s tím už špatně něco dělá.

[Bystroushaak]

Myslím, že se nechápeme na nějaké základní úrovni, ale jsem moc líný to řešit.

[kralyk z abclinuxu]

Za správné a bezpečné považuji definovat si strukturu na jednom místě (napsat třídu, rozhraní) a pak ji na mnoha místech používat.

Všiml sis, že vlákno je o rychlém prototypování? Trochu mi přijde, že ses tak zabral do chvalozpěvu na Javu, žes úplně zapmněl, o čem je vlákno

[deda.jabko]

A proč myslíš, že je to jazykem? IHMO to souvisí spíš s existencí potřebných knihoven a hlavně se schopnostmi programátora (jak dobře ty knihovny a jazyk zná).

Z vlastni zkusenosti nemuzu souhlasit. Mezi me uchylne zaliby patri psani prekladacu, coz je uloha, kde te opravdu nejake knihovny moc nezachrani. Jeden problem jsem mel schvalne napsany ve vice jazycich. Takze programy se stejnou funkcionalitou mely velikosti cca 2000 LoC (Java), 500 LoC (C), 50 LoC (Scheme). Rozdil v produktivite byl markantni a neda se rict, ze bych nektery jazyk umel vyrazne lip nez druhy.

Kdybys uměl na stejné úrovni Javu, tak věřím, že by ti to šlo stejně rychle nebo i rychleji – knihovny bys postahoval přes Maven a poslepoval to dohromady.

A kdyz nebudou knihovny, tak jsi v pasti...

[xkucf03]

ezi me uchylne zaliby patri psani prekladacu, coz je uloha, kde te opravdu nejake knihovny moc nezachrani. Jeden problem jsem mel schvalne napsany ve vice jazycich.

Nemáš někde schované zadání nebo ty kódy?

A kdyz nebudou knihovny, tak jsi v pasti...

Tak jsi na tom zhruba stejně jako v jiných jazycích, pro které neexistuje knihovna. Musíš si nastudovat příslušné RFC nebo jiný standard definující ten protokol/formát. Musíš si rozmyslet návrh, alespoň základní stavební kameny, ať už třídy, funkce, procedury, struktury…

Samotná implementace je jen zlomek času. A většinu té analýzy můžeš dělat nezávisle na zvoleném jazyce.

[deda.jabko]

Nemáš někde schované zadání nebo ty kódy?

Ne a i kdybych mel, tak by to samo o sobe k nicemu nebylo.

Musíš si nastudovat příslušné RFC nebo jiný standard definující ten protokol/formát.

Ufff, ... jeste, ze se muzu venovat i nejakemu kreativnejsimu programovani...

Musíš si rozmyslet návrh, alespoň základní stavební kameny, ať už třídy, funkce, procedury, struktury…

Samotná implementace je jen zlomek času.

Jak u koho... kdyz mas problem vyreseny, tak te psani kodu jenom zbytecne zdrzuje. Napr. v tom C je to kod pro spravu pameti, v Jave zase zbytecne POJO, Factory, atd. A do ceho si myslis, ze je lepsi delat zasahy, kdyz prijde zmena? Do programu, ktery ma (a) 50, (b) 500 nebo (c) 2000 radku?

[xkucf03]

v Jave zase zbytecne POJO, Factory, atd.

POJO můžeš vyřešit přes Lombok.

Továrny mají svůj smysl – jednak kvůli flexibilitě (možnost injektovat jinou továrnu a tím změnit chování nebo přidat funkčnost) a jednak kvůli výkonu – inicializace něco stojí, tak se může udělat jednou v továrně, která se sdílí, a pak z ní vypadávají objekty, jejichž výroba už byla levná a zabírají méně paměti.

Ale když na tom nesejde, můžeš to zabalit do funkce (resp. použít knihovnu, která to obaluje) a pak místo několika řádků mít jen:

X x = xxx(y);

[deda.jabko]

POJO můžeš vyřešit přes Lombok.

A nebo muzu pouzit jiny programovaci jazyk... treba Groovy...

Továrny mají svůj smysl – jednak kvůli flexibilitě (možnost injektovat jinou továrnu a tím změnit chování nebo přidat funkčnost) a jednak kvůli výkonu – inicializace něco stojí, tak se může udělat jednou v továrně, která se sdílí, a pak z ní vypadávají objekty, jejichž výroba už byla levná a zabírají méně paměti.

Opravdu mi nemusis vysvetlovat, co je to tovarna... V LISPu/Schemu ti na to staci jedno let+lambda, tj. dva radky kodu.

Ale když na tom nesejde, můžeš to zabalit do funkce (resp. použít knihovnu, která to obaluje) a pak místo několika řádků mít jen:

Takze dalsi kod navic.

[xkucf03]

A nebo muzu pouzit jiny programovaci jazyk... treba Groovy...

Groovy jsem jednu dobu chtěl používat právě pro POJO třídy, ale bylo to pomalé (první použití třídy psané v Groovy), tak jsem od toho upustil. Ale jinak souhlas, tohle je výhoda JVM, že je tu víc jazyků a dají se různě kombinovat.

V LISPu/Schemu ti na to staci jedno let+lambda, tj. dva radky kodu.

V Javě 8 jsou taky lambdy. Továrna je v zásadě funkce, takže teď se dá i tak zapisovat.

Takze dalsi kod navic.

Máš to jen na jednom místě nebo lépe v nějaké knihovně.

Jinak musím říct, že ten LISP/Scheme mě celkem láká, jen zatím nebyl dostatečně silný impulz, abych do toho pronikl. Stejně tak mi přijde zajímavý Erlag, ale prostě nemám, co bych v tom psal, aby to nebyla jen intelektuální onanie. To už mi přijde praktičtější C++.

[Bystroushaak]

Jinak musím říct, že ten LISP/Scheme mě celkem láká, jen zatím nebyl dostatečně silný impulz, abych do toho pronikl. Stejně tak mi přijde zajímavý Erlag, ale prostě nemám, co bych v tom psal, aby to nebyla jen intelektuální onanie. To už mi přijde praktičtější C++.

Je to dobré už jen kvůli tomu, že to člověku změní styl uvažování.

[kralyk z abclinuxu]

Je to dobré už jen kvůli tomu, že to člověku změní styl uvažování.

Asi už se fakt budu muset podívat, v čem tkví ta úžasnost Lispu.

Zatím jsem jako hlavní prktický výsledek Lispu zaznamenal množství pasivně-agresivních esejí na téma Většina lidí jsou moc blbí na to, aby chápali Lisp, svět si radši volí něco horšího. Někteří autoři byli dokonce tak vyšinutí, že si napsali pod jinou identitou reakce na své eseje stylem Faun-Jik. O reálném sosftwaru napsaném v tomto jazyce nevím, ačkoli nejspíš nějaký existuje...

[xkucf03]

Co třeba Emacs?

Případně někteří píší v Clojure – příklady.

Ale taky si nejsem jistý, jestli je v tom nějaký zásadní přínos.

[kralyk z abclinuxu]

Afaik GNU Emcas je napsán v C a Lisp používá jako skriptovadlo... Ale je pravda, že na to jsem zapomněl a za reálné nasazení se to považovat dá...

[xkucf03]

Jenže to „skriptovadlo“ přináší většinu funkcionality.

Viz struktura zdrojáků – v Lispu je tam přes 1 250 000 řádků kódu, kdežto C jen asi 250 000.

$ cloc emacs-24.5/
    3320 text files.
    3206 unique files.                                          
    1134 files ignored.

http://cloc.sourceforge.net v 1.60  T=22.68 s (96.4 files/s, 93704.8 lines/s)
-------------------------------------------------------------------------------------
Language                           files          blank        comment           code
-------------------------------------------------------------------------------------
Lisp                                1602         158978         199386        1266735
C                                    248          52261          63695         247403
C/C++ Header                         171           7255          11130          33683
Bourne Shell                          19           6328           3846          29184
Objective C                            7           3130           2064          14251
m4                                   102           1287            783          13729
HTML                                   4             38              1           1671
Perl                                   4            423             98           1268
XML                                    6             74             42           1107
DOS Batch                              9            205            300           1036
Verilog-SystemVerilog                  1            283              0            861
C#                                     1            267              0            770
awk                                    8             89            148            477
make                                   3            131            118            424
Bourne Again Shell                     1            135             53            203
Patran Command Language                1             35              0            188
-------------------------------------------------------------------------------------
SUM:                                2187         230919         281664        1612990
-------------------------------------------------------------------------------------

[Bystroushaak]

Asi už se fakt budu muset podívat, v čem tkví ta úžasnost Lispu.

Já bych to nenazval úžasnost, ale geniální jednoduchost. Několikrát jsem viděl přirovnání ke geniální rovnici, ze které vykvétá všechno ostatní*. To je hrozný rozdíl oproti ostatním jazykům, které jsou prostě nějak náhodně nablity a zality dávkou bukkake, jak zrovna autory napadlo.

Když jsem to tenkrát všechno pochopil, tak jsem měl pocit silného osvícení, a změnil jsem se. Není to úžasná komplikovanost, ale úžasná jednoduchost, ze které se vše odvodí.

Zatím jsem jako hlavní prktický výsledek Lispu zaznamenal množství pasivně-agresivních esejí na téma

Já mám pocit, že to tvoří hlavně lidi, kteří měli příležitost pracovat s lisp-machines v osmdesátých letech. Popravdě se jim ani moc nedivím, protože sledovat co přišlo po nich a jak upadly do zapomnění, nahrazeny jazyky jako C++ a Java, to muselo být hodně drsné, duši drtící.

*Mám rád ten příběh z Lisp as the Maxwell’s equations of software:

On my first day of physics graduate school, the professor in my class on electromagnetism began by stepping to the board, and wordlessly writing four equations.

He stepped back, turned around, and said something like: “These are Maxwell’s equations. Just four compact equations. With a little work it’s easy to understand the basic elements of the equations – what all the symbols mean, how we can compute all the relevant quantities, and so on. But while it’s easy to understand the elements of the equations, understanding all their consequences is another matter. Inside these equations is all of electromagnetism – everything from antennas to motors to circuits. If you think you understand the consequences of these four equations, then you may leave the room now, and you can come back and ace the exam at the end of semester.”

[Josef Kufner]

Je to tak. Prakticky je dnes samotný Lisp nepoužitelný, ale jde o to osvícení, ke kterému dojde při jeho studiu. Ty jednoduché principy pak lze přenést do řešení komplikovaných problémů, ať už jako DSL (domain specific language) nebo se jím inspirovat při vymýšlení reprezentace dat. Vůbec to, že člověk ví, jak i velmi jednoduché nástroje mohou být mocné, ho motivuje k hledání elegantních a přirozeně jednoduchých řešení, neboť ta jsou obvykle ta správná.

[kralyk z abclinuxu]

Podobná přirování Lispu k podstatě vesmíru jsem už četl víckrát a přijde mi to neuvěřitelně nabubřelé. Ten, kdo to napsal, si o sobě a/nebo Lispu imho musel myslet strašně moc.

Nesedí mi to ze dvou důvodů:

1. Maxwellovy rovnice popisují realitu. Naprosti tomu Lisp měl s kontaktem s realitou vždy problémy. Maxwellovy rovnice jsou low-level záležitost, zatímco Lisp je relativně vysokoúrovňová abstrakce.

2. Lisp používá GC. Dokonce koncept GC obecně AFAIK vzešel ze světa Lispu.

Odbočka: Poslední dobou se dost zabývám Rustem (resp. snažim, co volný čas dovolí), ve kterém se hodně řeší správa paměti, je tam velký důraz na koncepty jako vlastnictví, doba života, (im)mutabilita, sdílení, apod. Kompilátor je schopen odhalit velmi brzo problémy např. se sdílenou mutabilitou apod. a programátora dokopat k lepšímu promyšlení návrhu z hlediska vlastniství objektů a resources. Jazyk obsahuje aktuálně asi 5 různých typů pointerů od holých C-like pointerů použitelných pouze v usafe kódu přes víceméně klasické reference až po smart pointery. GC aktuálně Rust nemá, ale dobudoucna je plán GC přidat (zpřístupněn by byl nejspíše formou dalšího typu pointeru).

Mohl by podobný systém existovat v Lispu? Vzhledem k tomu, že v Lispu se dá udělat všechno možný včetně OOP, tak počítám, že asi nějak jo, ovšem a) otázka je, jak by to šlo dokupy s existujícími konvencemi, knihovnami, atd. a b) něco takového v Lispu určitě není standard, standardně se prostě počítá s GC, což je konkrétní způsob správy paměti. S tou proklamovanou "Maxwellovostí" jazyka tohle imho těžce nejde dohromady, protože se tím zcela ignoruje celá jedna zajímavá oblast problémů (a jejich řešení).

Proti GC jako takovému určitě nic nemám, je to bezesporu užitečný nástroj. Nepřijde mi ale dobré prosazovat GC jako Jediné Správné™ řešení správy paměti, zejména u jazyků, které mají ambice být něčím víc než jen skriptovadlem - tj. třeba Java, Go a ten Lisp.

[Bystroushaak]

Nesedí mi to ze dvou důvodů:

Je to analogie - samozřejmě, že nebude sedět na všechno, co si vymyslíš.

Naprosti tomu Lisp měl s kontaktem s realitou vždy problémy.

To mi ani nepřijde, to že běžně není moc vidět neznamená, že se nepoužívá. Naopak je docela sranda sledovat, jak všechny jazyky konvergují k lispu a možná za padesát až sto let k němu konečně dorazí (ne syntakticky, ale co do funkce).

Podobná přirování Lispu k podstatě vesmíru jsem už četl víckrát a přijde mi to neuvěřitelně nabubřelé.

To chápeš špatně, ale asi ani nemá smysl to vysvětlovat, protože to vysvětlení by zahrnovalo vysvětlení lispu jako takového.

Proti GC jako takovému určitě nic nemám, je to bezesporu užitečný nástroj. Nepřijde mi ale dobré prosazovat GC jako Jediné Správné™ řešení správy paměti, zejména u jazyků, které mají ambice být něčím víc než jen skriptovadlem - tj. třeba Java, Go a ten Lisp.

Obecně se dá říct, že tam jde všechno (přes makra jde asi fakt úplně všechno). Ovšem bez garbage collectoru si to nějak neumím představit, aniž bys zároveň nepřišel o většinu výhod. Já v něm ale nedělám, takže se třeba pletu.

[kralyk z abclinuxu]

Naopak je docela sranda sledovat, jak všechny jazyky konvergují k lispu a možná za padesát až sto let k němu konečně dorazí (ne syntakticky, ale co do funkce).

Proč máš pocit, že jazyky konvergují k Lispu? Byl by příklad, jak se to projevuje?

To chápeš špatně, ale asi ani nemá smysl to vysvětlovat, protože to vysvětlení by zahrnovalo vysvětlení lispu jako takového.

Jaký by byl vhodný úvod a na jakej dialekt se mám podívat? Znám základní prvky (S-expressions, cons) a nerad bych se probíral nějakými základy jako Co je to (+ 1 2)...

[Bystroushaak]

Proč máš pocit, že jazyky konvergují k Lispu? Byl by příklad, jak se to projevuje?

Adopce lambd, ústup od imperativního stylu, snaha o čím dál větší abstrakci a zaměřování se na manipulaci s daty, spíš než na lowlevel popisy co přesně dělat. Reflexe.

Jaký by byl vhodný úvod a na jakej dialekt se mám podívat? Znám základní prvky (S-expressions, cons) a nerad bych se probíral nějakými základy jako Co je to (+ 1 2)...

Tak v tomhle ti moc neporadím. Já jsem se před nějakou dobou rozhodl pro Scheme, ale nepovažuji se v tomhle za vhodnou autoritu. Možná Clojure, pokud ti nevadí, že je to nad JVM.

[xkucf03]

Adopce lambd, ústup od imperativního stylu,

Otázka je, jak moc je to užitečné – když se podíváš třeba na JavaScript, tak tam je prakticky všechno callback funkce, ale prase aby se v tom vyznalo. Kód není tak přímočarý a čitelný, přínosy jsou sporné.

Ty funkce mají svůj smysl a dokáží ledasco zjednodušit, třeba filtrování a transformace objektových proudů. Ale nemá cenu to hnát do extrému, to je pak kontraproduktivní a ten imperativní zápis je čitelnější.

[kralyk z abclinuxu]

Otázka je, jak moc je to užitečné – když se podíváš třeba na JavaScript, tak tam je prakticky všechno callback funkce, ale prase aby se v tom vyznalo.

To je ale způsobený spíš JavaScriptem jako takovým a knihovnama, jako např. jQuery, ve kterým neprasit je dost náročný Je ale možný v JS psát i tak, aby to nebyla změť callbacků.

[xkucf03]

nahrazeny jazyky jako C++ a Java, to muselo být hodně drsné, duši drtící.

Přijde mi, že mám celkem štěstí na technologie – s Javou jsem začínal, když přicházela verze 5, a tudíž měla generika (dneska je používám k různým věcem, ale už jen ty generické kolekce jsou obrovský přínos). S EJB jsem začínal ve verzi 3, kdy už to bylo dost dobré. A s C++ ve verzi 11 a vůbec to není špatné. Ale chápu, že někdo, kdo k tomu přišel dřív, si tyhle technologie mohl docela znechutit a pak se k nim už třeba nechtěl vracet.

[deda.jabko]

A nebo muzu pouzit jiny programovaci jazyk... treba Groovy...

FYI

V Javě 8 jsou taky lambdy.

S tim slovem "taky" bych byl hodne opatrny...

Máš to jen na jednom místě nebo lépe v nějaké knihovně.

Proste je to dalsi vec, kterou musis udrzovat.

Divej se, nema smysl obhajovat Javu z tohoto pohledu. Je to jazyk navrzeny pro softwarove inzenyry a ma schvalne omezene vyjadrovaci schopnosti, aby ten kod byl co nejsrozumitelnejsi i na ukor toho, ze bude delsi a jeho priprava zabere vic casu. A je to dobra vlastnost, pro nektere pouziti. Ale pokud chces vyjadrit neco rychle, jsou na to lepsi opravdu jine jazyky.

ale prostě nemám, co bych v tom psal, aby to nebyla jen intelektuální onanie

Schvalne, co si predstavuje pod pojmem intelektualni onanie? Mimochodem, zminil jsi tu psani podle RFC a specifikace, pridavani knihoven, atp. to mi prijde jako ubijejici nuda, kterou rad prenecham nekomu jinemu.

[xkucf03]

Schvalne, co si predstavuje pod pojmem intelektualni onanie?

Aby to mělo nějaký praktický význam – aby byl výsledkem produkt, který půjde používat a bude užitečný – ne že to bude kód, který si jen vystavím do vitríny nebo si odškrtnu fajfku u „naučit se letos další programovací jazyk“.

Z těch věcí co chci/potřebuji napsat:

• přepsat pár GUI aplikací, protože jejich současný stav je tragický a při jejich používání trpím
• různé utility pro příkazovou řádku
• démoni a různé mikroslužby
• moduly do programů jako Apache, OpenLDAP, PostgreSQL, Dovecot, Postfix
• síťové aplikace nad TCP, UDP, SCTP
• klasické podnikové aplikace (tady asi zůstanu u Javy)
• programy do jednočipů (většinou Arduino)
• e-mailový klient
• www prohlížeč
• IM klient

Nejsou to úplně akutní věci, které bych potřeboval řešit hned – prostě seznam nápadů na různé projekty, které bych rád někdy realizoval. U počítače už tak trávím dost času a nemám tudíž potřebu u něj sedět ještě proto, abych se naučil nový jazyk, jen proto, abych ho uměl. Když už nad tím budu trávit čas, tak ať z toho je i nějaký použitelný produkt.

Asi na ty démony a mikroslužby by tyhle jazyky byly použitelné. Ale ty ostatní oblasti?

Jelikož se nechystám psát vlastní OS, tak mi z toho vychází, že si nejspíš vystačím s Javou a C++ jako hlavními jazyky (plus další jazyky jako SQL, XSLT, XPath, XQuery, regulární výrazy a nějaké to skriptování – Perl, Bash).

[kralyk z abclinuxu]

Kdybys uměl na stejné úrovni Javu, tak věřím, že by ti to šlo stejně rychle nebo i rychleji – knihovny bys postahoval přes Maven a poslepoval to dohromady.

Taková je teorie. Praxe je taky třeba taková, že potřebuješ pracovat například s datem a časem. Zjistíš, že standardní funkce pro datum a čas jsou dost přiblblé. Tak postahuješ přes Maven, resp. v mém případě to byl Gradle, knihovnou pro rozumnější práci s datem, která funguje mnohem lépe. Nicméně později zjistíš, že v jednom určitém případě použití je v té knihovně bug, díky kterému je to nepoužitlné. Doje ti, žes zabil odpoledne, nasraně to celý vyhodíš a jdeš radši dělat něco úplně jinýho...

[xkucf03]

Zrovna včera jsem na svůj blog přidával podporu RSS a musel jsem implementovat ten jejich debilní formát data (RFC822). Žádnou nestandardní knihovnu jsem na to nepotřeboval, stačilo si najít ten formátovací vzor (E, d MMM yyyy HH:mm:ss Z) a napsat dva řádky v Javě (mohlo to být na jeden, ale přehlednější jsou dva).

Zjistíš, že standardní funkce pro datum a čas jsou dost přiblblé.

Které?

[Bystroushaak]

Zrovna včera jsem na svůj blog přidával podporu RSS a musel jsem implementovat ten jejich debilní formát data (RFC822).

Osobně se mi osvědčilo nepoužívat RSS, ale Atom, který je imho podstatně čistější.

[xkucf03]

To je. Atom tam mám už dlouho a původně jsem chtěl podporovat jen Atom. Ale pak mi pár lidí psalo, že jim ho neumí načíst čtečka (přesto že je validní), tak jsem dodělal ještě šablonu pro RSS a už jim to funguje

[kralyk z abclinuxu]

Které?

Celý ten návrh, viz komentář na stránce date4j - to se v podstatě shoduje s mým dojmem. Bohužel Date4j je taky zabugovaný - když se tomu předhodí čas v ISO formátu, nefungují některé operace.

[kralyk z abclinuxu]

a většinou jsem to vyhrával, právě díky pythonu

To zní spíš jako argument pro můj komentář - nepotřeboval jsi LISP a jeho über-fíčury (code = data, makra, etc.). Stačilo jazyk který 1) dobře znáš a 2) dobře se v něm dělaj rychlý prototypy.

[Bystroushaak]

No, a to byl tenkrát lisp :) Neexistovalo ruby, python byl v dětském stádiu (ale zmiňuje ho tam taky) a perl byl .. perl. Ta knížka je už docela stará.

[kralyk z abclinuxu]

No jo, ale Python je jiný než LISP, Python je IMHO z uživatelského hlediska, narozdíl od LISPu, celkem snadno zvládnutelný, jednoduchý, nevyžaduje žádnou vyšší úroveň vědomí ani 456. zasvěcení do LISPovské lóže.

Čili otázka je, kteréže vlastnosti to jsou, které pomohli Viawebu a tobě v té soutěži. Oni tvrdí, že síla LISPu, potažmo jeho makra, ty tvrdíš, že nižší ukecanost Pythonu a REPL. Shodujete se jenom v tom REPLu, protože LISP je ukecaný a Python nemá LISPí makra. A REPL má kdejaký jazyk, že...

[deda.jabko]

protože LISP je ukecaný

Na to jsi prisel jak? Prave diky makrum programy v Lispu nemusi byt tolik ukecane.

[Bystroushaak]

Čili otázka je, kteréže vlastnosti to jsou, které pomohli Viawebu a tobě v té soutěži.

Já tvrdím hlavně to co jsem si přečetl - že za to mohlo hlavně rychlé prototypování.

BTW: Fakt si tu knihu přečti. Není zas tak dlouhá, ani zas tak debilní a na netu se povalují ebooky.

[kralyk z abclinuxu]

Já tvrdím hlavně to co jsem si přečetl - že za to mohlo hlavně rychlé prototypování.

Ok, otázka je, co umožňuje rychlý prototypování. To neříkám proto, že bych ti nevěřil, spíš by mě zajímalo, jaký fíčury v tomhle ohledu pomůžou.

BTW: Fakt si tu knihu přečti. Není zas tak dlouhá, ani zas tak debilní a na netu se povalují ebooky.

Ok, mrknu...

[R]

PHP sice nie je cisty a elegantny jazyk, ale na mnohe veci velmi dobre pouzitelny.

[kralyk z abclinuxu]

PHP je trochu jako lopata na přehazování žumpy. Je to hnus a člověk musí dávat hodně velký pozor, aby se neumazal, ale když si pozor dá, může s tím vykonat spoustu užitečné práce.

[pavlix]

Chtěl jsem tě podpořit, ale jako obvykle přirovnávání pokulhává v tom, že při přehazování žumpy není původcem hnusu ta lopata, ale ta žumpa. Užitečnost žumpy v místě bez kanalizace je zjevná. Potřeba přehazování žumpy ovšem vychází z provozu té žumpy, nikoli z držení lopaty. Nehledě na to, že by šoufek mohl posloužit o něco lépe.

[R]

U nas ta lopata prehadzuje dost velke peniaze uz par rokov.

[kralyk z abclinuxu]

Věřím tomu a věřím, že to funguje dobře. Koneckonců, taky jsem před časem napsal aplikaci v PHP a taky to funguje (je to ale jen malá appka). Ale to neznamená, že při psaní neskřípu zuby nad vlastnostmi jazyka a standardní knihovny...

[#Tom]

Používání nedefinovaných proměnných a chybějící typová kontrola patří mezi největší nedostatky PHP. Největší prasárnou pak je míchání kódu s HTML. Oddělení kódu od formátování výstupu sice u menších projektů přidělává práci, ale u větších je k nezaplacení.

O Hacku tam píšou, že má aspoň typovou kontrolu, což je krok správným směrem.

Na větší věci se mi víc než PHP líbí C++ a Java.

[Bedňa]

Heh, prasárny napíšeš všade, to moc dôkaz nieje. Správa premenných je vec iná.

[#Tom]

Heh, prasárny napíšeš všade, to moc dôkaz nieje.

Pravda. Ale PHP dnes vypadá, jako by to byl jeho hlavní smysl.

[Bedňa]

[petr_p]

Ne v každém interpretu se každý druhý týden řeší nová bezpečnostní chyba (137 chyb za 5 let).

[ewew]

Môžeš urobiť svoj vlastný programovaci jazyk. Iná možnosť je urobiť fork PHP a urobiť to posvojom.

[kralyk z abclinuxu]

+1

[Bedňa]

Zato C++ nemá chybu, choďte s tým niekde chlapi

[kralyk z abclinuxu]

Tak to jsem rozhodně neřekl. Nicméně ostatní jazyky mají oproti PHP alespoň nějaký víceméně ucelený návrh. Zato vývoj PHP probíhal a probíhá tak, že se prostě kupily fíčury jedna na druhou halabala jak to zrovna přišlo autorům pod ruku. Funkce mají často podivné výchozí chování, spousta caveats a gotchas... Je to prostě šílený kočkopes.

[Bedňa]

Ani ti to nijak vyvracať nebudem, PHP ponúklo riešenie v časoch keď všetci zaspali dobu a na web si si mohol písať skripty v Perly, aj môj prvý web bol napísaná v Perly. Keď začalo PHP tak písať inovácie v Perli kontra PHP bolo kontraprodiktívne a alternatívy od MS proste nikto nechcel, tak PHP vyhralo. Jako C++ tiež nemuselo vyzerať tak prasácky keby malo alternatívu. Toš ja viem po vojne sú všetci generáli.