Pharo 6 - novinky a budoucnost

6.6.2017 17:30 | Přečteno: 2002× | | poslední úprava: 6.6.2017 17:30

Po roce vyšla nová verze vývojového prostředí Pharo, což je otevřená implementace Smalltalku. Tentokrát nese číslovku šest a přináší řadu změn, které slibují moře pod majákem v jeho logu pořádně rozbouřit.

64-bitů

Pharo konečně vychází i v 64-bitové verzi. K dosažení tohoto milníku bylo nutné udělat celou řadu dílčích mezikroků, z nichž nejvýznamnější byl přechod na model objektové paměti Spur v minulém vydání Phara a nový FFI. Z praktického hlediska je nutné vědět, že 64-bitové obrazy virtuální paměti (image) nespustíte na 32-bitovém virtuálním stroji a naopak. Starší obrazy je tak nutné konvertovat. Pharo samotné je vydáváno ve dvou verzích. Bohužel si kvůli problémům s FFI musí uživatelé Windows ještě nějaký měsíc na 64-bitovou verzi počkat.

Epicea

Ve Pharu jsou jsou všechno objekty a tedy i třídy a metody jsou objekty. Protože toto pravidlo je dodržováno opravdu důsledně, promítá se to i na odlišném přístupu k programům samotným, který se výrazně liší od nejpoužívanějších programovacích jazyků dneška. Program zkrátka není sada zdrojových textů, ale systém vzájemně komunikujících objektů, kdy integrované vývojové prostředí nesestává jen z pokročilého editoru, debuggeru a dalších nástrojů, ale je přímou součástí tohoto systému objektů a poskytuje prostředky k jeho úpravě. Ve Pharu existuje ničím nestíraný rozdíl mezi metodou a zdrojovým kódem metody.

Tento přístup má řadu výhod, ale občas může způsobit potíže. Není zde přímá vazba mezi aktuálním stavem metody a jejím uloženým zdrojovým kódem někde na disku, což znamená, že pokud si například uřežete větev pod nohama a Pharo zhavaruje, o provedené úpravy v metodách v něm přijdete, pokud jste je před tím někdy neuložili na disk.

Aby se zamezilo nepříjemným ztrátám půldenní práce, již od pradávna Smalltalk používá speciální soubor, kam ukládá průběžně všechny změny, které programátor provedl. Z něj je pak možné svoji práci zrekonstruovat. Ale protože tento mechanismus už je skutečně vousatý, zaznamenával změny jen na té nejjednodušší úrovni a člověk se tak například nedozvěděl, že daná úprava je důsledkem určitého refactoringu, nahrání balíčku apod.

Právě proto byl vytvořen manažer změn zdrojových kódů pojmenovaný Epicea. Ten poskytuje výše popsanou funkcionalitu a navíc dává možnost s těmito změnami přehledně pracovat, sledovat jejich větvení a podobně.

Záznamy, které si Epicea vytváří, jsou nezávislé na původním mechanismu ukládání změn a jejich vytváření je volitelné. Do budoucna by jej však měl zcela nahradit.

Iceberg - přímá podpora Git

Zdrojové kódy bylo možné ve Pharu spravovat pomocí Gitu již dávno, nyní ale Pharo přináší nový nástroj jménem Iceberg, který vše výrazně zjednodušuje a to především díky tomu, že přímo virtuální stroj nyní zahrnuje knihovnu libgit2 a tak je možné pracovat s Git repozitáři přímo bez externích nástrojů.

Zdrojové kódy se fyzicky ukládají do adresářové struktury, kde každé metodě přísluší vlastní soubor. To rozhodně není mezi programovacími jazyky nejobvyklejší přístup ale ve spolupráci s Gitem má takové množství výhod, že nad několika málo nevýhodami jasně převážily. Mezi nevýhody patří ztížená editace externími editory zvyklými na dlouhé nudle kódu a velké množství malých souborů, které může zatěžovat souborový systém. Ovšem zvýšení granularity sledovaných změn uloženého kódu na úroveň metod za to rozhodně stojí. Samozřejmostí je možnost kombinovat zdrojové kódy s ostatními daty.

Možnosti, které Iceberg poskytuje, jsou zatím pouze základní, takže na pokročilejší operace jako přeskládání (rebase) budete muset sáhnout přímo po Gitu, nicméně základní běžné operace zvládá dobře a problém mu nedělá například ani vytvoření pull request na GitHubu. Samotné Pharo bude od začátku vývoje sedmé verze spravováno celé Gitem a Iceberg byl vytvořen s tím, aby podporoval vše, co k tomu bude potřeba.

Bohužel se pro před vydáním Phara 6 nepodařilo dokončit přechod na vyšší verzi libgit2, kvůli čemuž zatím Iceberg nefunguje i v 64-bitové verzi. To by ovšem mělo být v následujících týdnech napraveno.

OpenSmalltalk VM

Pozitivní změny se odehrály na poli správy vývoje virtuálního stroje. Pharo vzniklo jako fork implementace Squeak Smalltalku a stále s ním sdílelo stejný virtuální stroj, který byl pouze lehce pozměněn a doplněn o některé potřebné plugginy. To se nemění. Naopak se spolupráce na vývoji společné VM ještě zintenzivnila a pod hlavičkou OpenSmalltalk se přesunula na GitHub. Stejný repozitář pro virtuální stroj tak dnes sdílí Pharo, Squeak, Cuis a Newspeak.

Virtuální stroj také doznal některá vylepšení, která by se měla především zúročit v blízké budoucnosti. Jedná se například o vylepšenou podporu uzávěrů umožňující jejich větší nezávislost a provádění agresivnějších optimalizací. Dále podporuje nezměnitelné objekty a alternativní množiny bytekódu. Vše směřuje k začlenění projektu Sista, což je adaptivní kompilátor na úrovni image.

Bootstrap

Pharo je přímý potomek Smalltalku-80 a některé základní objekty v něm byly vytvořeny pravděpodobně již v roce 1976. Od té doby již byly nesčetněkrát spolu s ostatními objekty v paměti uloženy na disk, aby z něj mohly být znovu obnoveny. Mnohokrát se změnil způsob jejich uložení, ale stále se jednalo v podstatě o ty stejné objekty.

Jediný způsob jak ve Pharu něco změnit vyžadoval provést to z něj samotného. To přirozeně vytváří nutnost vytvořit a udržovat systém s brutální reflektivitou, díky kterému má Pharo řadu unikátních vlastností. Na druhou stranu to v některých případech svazuje ruce a také ztěžuje mít nad obsahem objektové paměti plnou kontrolu.

Pharo ve verzi 6 nově podporuje možnost bootstrappingu, což je proces, při kterém je nová objektová paměť vytvořena ze statických zdrojových kódů. Nejedná se o přímočarý ani jednoduchý proces. Nedělá se to tak, že by se vytvořil soubor s objektovou pamětí a do něj se specifikovalo, jaké konkrétní objekty má obsahovat a jaké mezi nimi mají být vazby. Místo toho se k bootstrappingu využívá speciálně upravený simulátor virtuálního stroje, v jehož objektové paměti se vytvoří několik základních objektů doplněných o pár berliček. Pak se spustí kód nutný k instalací dalších objektů a zavádění tříd. Tento kód je ale na rozdíl od běžného spouštění pouze interpretován simulátorem na úrovni AST, což vlastně umožňuje využívat tříd a metod, které ještě nebyly skutečně vytvořeny. Když je vše hotovo a nezbytné berličky jsou odstraněny, simulátor vzniklou objektovou paměť standardním způsobem uloží do souboru.

Protože se jedná o relativně pomalý proces, takto se vytváří pouze základní jádro systému, které však již obsahuje plnohodnotný kompilátor a je tak schopné postupně načíst zbytek balíčků. Protože historicky se nové verze image vytvářely ukládáním starších verzí a změny v nich byly dělány často manuálně, nebylo právě jednoduché dosáhnout toho, aby výsledek bootstrappingu odpovídal originálu. Ale přesto je dnes Pharo schopno být plně znovuvytvořeno ze statických zdrojových kódů (spravovaných Gitem) a verze 7 již bude vyvíjena pouze tímto způsobem.

Možnost ukládat obraz objektové paměti zůstává ovšem stále zachován a tak může Pharo využívat výhod z obou jinak těžko slučitelných světů.

Tmavý motiv

Na první pohled nejviditelnější vpravdě kosmetickou změnou v nové verzi Phara je nastavení výchozího barevného schématu na tmavý. Ten sice byl dostupný i dříve, ale nyní je aktivní jako výchozí. Pharo tak pomáhá šetřit oči insomnií trpícím programátorům, ale hlavní důvod ke změně je spíše marketingový. Tmavší styl vypadá na obrázcích, více geekovsky a navíc pro většinu lidí platí, že pokud vidí program se světlým pozadím, očekávají od něj vzhled a chování více či méně ladící s jejich operačním systémem. V případě tmavých barev ale hned vidí, že je něco jinak, a bývají otevřenější k odlišnostem a těch Pharo nabízí víc než dost.

Další novinky

Vývojářům se také podařilo posunout projekt OSWindow, což je rozhraní umožňující pomocí SDL2 otevírat další samostatná okna pod hostitelským operačním systémem a spouštět v nich nezávislé světy v Morphicu. Cílem tohoto snažení má být odstranění kódu z virtuálního stroje, který se stará o obsluhu obrazovky, což by jej mělo výrazně zjednodušit.

Drobná avšak zpětně nekompatibilní změna se odehrála na poli syntaxe jazyka. Nyní i v komentářích jsou dvoje uvozovky (“”) ignorovány a komentář neukončí, což kopíruje přístup používaný pro řetězcové literály. Lze tak napsat komentáře typu “This code prints “”Hello World”” and quits”.

Relativně velký zásah je označení metody Object>>#name jako zastaralé. Z pochopitelných důvodů příliš kolidovala s uživatelskými datovými modely. V příští verzi bude odstraněna úplně a její volání se automaticky přepíší na zprávu #printString. Podobný osud postihne metody typu #ifNil:ifNotNilDo:, kde nyní postačí i při použití alternativního bloku s argumentem zpráva #ifNil:ifNotNil:.

Zlepšení se dočkal debugger a inspektor je nyní používá rychlejší zobrazování, které se projeví především na velkých polích či strukturách. Nautilus, což je nástroj na procházení a editaci kódu, nyní dokáže přímo pomocí ikony spouštět metody, které jsou označeny jako příklady, má lepší automatickou kategorizaci metod a obsahuje řadu dalších vylepšení a oprav.

Metalinky jsou mechanismus, který kompilátoru umožňuje obohacovat zvolené AST uzly o dodatečný kód a tak implementovat vlastnosti jako breakpointy, sledování pokrytí kódu testy, implementovat speciální druhy instančních proměnných a podobně. Jejich podpora byla spolu s dalšími reflektivními mechanismy ve Pharu 6 dále rozšířena.

To je samozřejmě jen špička ledovce, přidána byla celá řada drobných potěšujících vylepšení, jako je detektor rekurzí, děditelné proměnné procesů, jednodušší tvoření anonymních tříd apod. Opraveno bylo i několik úniků paměti, což jen dokazuje, že ani jazyk s garbage collectorem jich není ušetřen, i když způsob jejich vzniku a odhalování je samozřejmě jiný než například v Céčku.

Proces vývoje Phara je víceméně řízen časově. Nová verze se vydává po roce a její obsah není příliš řízen vlastnostmi. Na její vypuštění do světa se nečeká, až vše bude naprosto dokonalé. Stačí, aby výsledek byl dobrý natolik, aby podpořil další iteraci vývoje, což Marcus Denker výborně popsal v prezentaci Perfection and Feedback loops.

V případě Phara 6 to znamená, že ani u nejdůležitějších změn, jako je podpora 64-bitů a Gitu, není vše dotaženo na 100%. 64-bitová verze zatím není vydána pro Windows a Iceberg není podporován v 64-bitové verzi. Vše by se však mělo během pár měsíců doladit.

Budoucnost

V přípravě jsou již změny pro další verzi. Tou hlavní pro Pharo 7 je kompletní přechod vývoje na bootstrap ze zdrojových kódů spravovaných Gitem. Jedná se o velký skok, který pozmění prakticky všechny dosavadní postupy vývoje a dá se očekávat, že alespoň ze začátku bude rozjezd pomalejší a nikoliv zcela hladký. I tak se později očekává několik zásadních změn.

Jedná se především o postupné opuštění browseru Nautilus a jeho nahrazení lépe navrženou alternativou jménem Calypso. Její hlavní předností je možnost připojit se přes síť k jiným instancím Phara a spolu s upraveným debuggerem tak poskytnout možnost kompletně interaktivně vyvíjet a ladit programy vzdáleně třeba přímo na NanoPi.

Calypso zvládá také editovat nezávislé modely smalltalkovských prostředí, což v praxi znamená, že s ním bude možné pracovat například s nenahraným balíčkem nebo editovat celé vlastní malé smalltalkovské prostředí jen s vybraným obsahem a z něj pak pomocí bootstrappingu vygenerovat specializovanou image a tu pak nasadit například na nějaké IoT zařízení či použít v samostatném vlákně.

S tím souvisí vyvíjený minimalistický nahrávač kódu v binární formě pojmenovaný Hermes, který dovolí dovolí bootstrap provádět pro ještě menší obrazy neobsahující ani kompilátor a přesto schopných nahrát celý zbytek Phara.

Pracuje se rovněž na možnosti používat vlastní metatřídu. To v praxi znamená, že si uživatel bude moci vybrat, jestli se ve své image spokojí s použitím pouhých tříd nebo využije Traits či sáhne po jiné alternativě (stateful Traits, Talents).

Vzdálenějším cílem je náhrada Morphicu prostředím Bloc, které je schopné využívat akcelerovanou vektorovou grafiku a tak výkon a možnosti celého prostředí posunou o značný kus dále. Ve verzi sedm se ho pravděpodobně ještě nedočkáme, i když se na tomto úkolu stále pracuje.

Pharo má oddanou rozšiřující se komunitu, která ho doslova každým dnem vylepšuje a přibližuje svým praktickým potřebám, čehož je nově vydaná verze jasným dokladem.

Pozdnámka pod čarou

Čas od času si někdo všimne, že na oficiálním webu Pharo.org nějaké zmínky o programovacím jazyce Smalltalk člověk aby pohledal, a rozpoutá diskusi proč tomu tak je a jestli není kontraproduktivní se ke Smalltalku nehlásit. Pravdou je, že Pharo je přímým pokračováním linie, kterou započal Smalltalk-80.

O Pharu lze říct, že je Smalltalkem asi jako Scheme je Lisp. Tedy implementací určitého konceptu. Vazba mezi Pharem a Smalltalkem je v současnosti jasně zřetelná, ale nikdo jí nechce být do budoucna příliš omezován a lpět na zastarávajícím standardu.

       

Obrázky

Komentáře

[pf]

Děkuji za české shrnutí, je toho dost. Ten bootstrap ze zdrojáků a nelpění na zastaralých principech, neznamená to, že bude postupně opouštěn koncept ukládané objektové image?

[Pavel Křivánek]

Toho, že se od konceptu ukládání obrazu objektové paměti ustoupí, bych se nebál, ale samozřejmě tu existuje riziko, že některé problémy spojené s tímto procesem nebudou řešeny prioritně, což doposud byla nezbytnost. Na druhou stranu se do teď prioritně neřešily problémy spojené s modularizací, takže snad v tom nastane nějaký uspokojivý rovnovážný stav.

[tom]

Object storage mi vzdycky prislo jako zasadni prekazka pouziti smalltalk(-like) jazyku na nejake vetsi projekty, kde je vyzadovana hiarchicka struktura organizace vyvoje, kdy par lidi integruje zmeny od nekolika desitek vyvojaru. Je dobre, ze si toho zacinaji vsimat taky.

[Bystroushaak]

Velmi husté. Bylo by teď možné, aby Self běžel (s úpravami samozřejmě) na té VM? Vím, že předtím to nebylo možné, ale z toho jak jsi to popsal mi přijde, že teď by se to asi dalo.

[Pavel Křivánek]

Jazyky, které podporuje OpenSmalltalk VM, jsou všechny třídní, takže v první řadě by to vyžadovalo doplnit delegaci jako alternativní message lookup. Pak také mechanismy kolem clone families atd. Alternativní bytekód by něco zjednodušíl, ale VM je dnes celkově mnohem komplikovanější než byla dřív, takže by se určitě nejednalo o snadný úkol.

Přechod Selfu na OpenSmalltalk VM je asi jediné, co by ho dnes mohlo trochu pošťouchnout. Ovšem čím později se tak stane, tím obtížnější to bude.

[kralyk z abclinuxu]

Dík za ten odkaz na tu prezentaci, to je pěkný.

Jinak, já ti nevim, mně tyhlety systémy/jazyky jako Pharo, Squeak, Self a i některé méně prakticky zaměřené lispy jako třeba Scheme připadají jako takové samy na sebe zaměřené sandboxy... Je určitě zajímavé a zábavné si s tím hrát, ale nějak se nemůžu zbavit dojmu, že to není moc využitelné na nic praktického... Možná to je jen dojem, ale přijde mi to jako redstone v Minecraftu

[Honza]

Kde se takový dojem bere? Pharo/Smalltalk se používá k vážnému vývoji jak na frontendu tak na backendu! A nebo je ten dojem správný, ale žádnou překážkou to není.

[kralyk z abclinuxu]

Ono to umí kompilovat do JS?

[Honza]

Kromě toho, že to umí taky, tak to není vždycky ani potřeba: (Seaside web framework to řeší takhle)

	html textInput 
			class: 'my-email';
			onChange: (html jQuery ajax serializeThis); "Ajax update server-side model"
			on: #email of: self model;
			with: self model defaultEmail.

	html anchor
			class: 'btn btn-mini btn-link';
			onClick: ((html jQuery: '.ajax-target') load 
							html: [ :h | self renderDataOn: h ]); "Ajax component render"
			onClick: (html jQuery: '.dialog') show; "client-side javascript"
			with: 'show me'.

Žádné HTML, žádný Javascript vůbec nepíšu

[kralyk z abclinuxu]

Žádné HTML, žádný Javascript vůbec nepíšu

To bych v dnešní době ani nečekal.

Připomíná mi to dost způsob, jak se dělá DOM v Elmu (nicméně Elm má tu výhodu, že na to nepotřebuje jQuery, a tudíž netrpí špagetovým kódem, který nad jQuery celkem nevyhnutelně vzniká).

[Honza]

To zní,

1) jako by použití jQuery měla být nevýhoda - není
2) a jako by bylo jQuery potřeba - není potřeba

ale to je spíš záležitost použitého frameworku, než programovacího jazyka...

Čili argument, že

není moc využitelné na nic praktického

bychom měli z krku

[kralyk z abclinuxu]

jQuery nechme bejt, to je jedno, jde spíš o to, že to je renderování html na serveru, ie. to beru jako backend záležitost, ne frontend.

Ale že je Pharo použitelné na backend, to beru, nevěděl jsem, že v tom mají ten web.

[alfonz]

Máto nějaké praktické výhody oproti běžným jazykům? A jaké to má nevýhody? Viz, rychlost, efektivnost vývoje, perfektní stabilita, případně co?

Jde mi o to, že co jsem viděl ty ukázky, tak mi nepřišlo, že by vlastně bylo něco co by to vlastně řešilo, krom toho, že to vypadá zajímavě. Např. v C mám low level věci a rychlost programu/optimalizace na kompileru. Java řeší multiplatformní vývoj a že tam vše vypadá dlouhé. V JS mám vcelku dobrou rychlost a nějaké blbosti. Python je pomalý a má dobrý návrh jazyka (pokud nebereme verzi 3, kde se již motá každá další blbost).

Tzn co má Pharo za ty důležité vlastnosti?

[Bystroushaak]

Killer feature je to prostředí. Tohle se velmi těžko vysvětluje a samotnému mi trvalo dlouho, než mi to skutečně došlo. Pomohlo tohle video: Getting started with Pharo 3.0.

Poslední dobou mi taky čím dál víc přijde jako výhoda, že nemusíš zacházet s vrstvami nestrukturované kompatibility a demence, která se nahromadila ve všech operačních systémech. Jsou to prostě objekty až úplně dolu a nemusíš řešit žádné formáty dat a serializaci a parsování a kokotiny. Prostě objekt sem, objekt tam.

[alfonz]

Ok, když se programuje přímo pro to prostředí, tak to je fakt pěkný (to gui pro ty obrázky bylo hodně rychlé). Když se tam pak programuje ten server, tak to už tak dobrý není.

Ovšem je tam jeden problém a to je to, že jsem v jednu chvíli ztrácel orientaci v tom co vlastně bylo napsáno za kód, jak je to vše oddělené.

[Bystroushaak]

Když se tam pak programuje ten server, tak to už tak dobrý není.

Já jsem teď Pharo asi rok nesledoval, ale podle toho co píše Pavel v blogu by mělo být už plně možné takhle upravovat i server.

Ovšem je tam jeden problém a to je to, že jsem v jednu chvíli ztrácel orientaci v tom co vlastně bylo napsáno za kód, jak je to vše oddělené.

Ono to právě moc není oddělené. Jen ten kód vytváří z různých míst, někdy třeba přímo v debuggeru změní zdroják a tak. Je to zmatené pro neznalé, ale když to jednou člověk pochopí, tak brutálně silné.

[kkk]

ja nevim. mne prijde, ze neodpovidas na otazka: k cemu je to uzitecne.

pouzivam emacs a python shell. elegantni programovaci jazyk stranou, je to nejake prostredi. ale to prostredi je uzitecne diky tomu, co v nem uz muzu delat diky praci jinych. v emacsu mam spoustu vlastne aplikaci (dokonce ho muzu mit jako spravce oken). v pythonu mam "baterky" a bazilion knihoven z moji domeny (zpracovani dat).

to odkazovane video je hloupe. sorry jako. zobrazit si lokalne obrazky z nejake sluzby je banalita. kdyz se na to podivam z hlediska moji domeny, zajimave to bude ve chvili, kdy budu moct selektovat obrazky podle algoritmu, ktery uz nekdo efektivne napsal, nebo je dal zpracovavat.

rozumim snaze divat se na data jinak nez na "soubory", ale to je spis vec navrhu "souboroveho systemu" a prace s metadaty

[Pavel Křivánek]

Příloha:

• PharoScreenshot.png (72393 bytů)

Ve spojení s Roassal2 se dobře hodí na analýzu a vizualizaci dat: (https://www.youtube.com/watch?v=iXUZiFtnxK8).

Velice snadno se v tom také dělají vlasntí nástroje. Například následující kód vezme kolekci přeživších mutací kódu (proměnná alive), které prošly testy, a zobrazí porovnání původního a zmutovaného kódu.

browser := GLMTabulator new.
browser 
	row: #results;
	row: #diff.
browser transmit to: #results.
browser transmit to: #diff; from: #results; andShow: [ :a | 
	a diff display: [ :mutant | {mutant mutant originalSource . mutant mutant modifiedSource}] ].
browser openOn: alive.

[kkk]

ok, takze jedna firma to tak dela a ma k tomu nejake nastroje. fajn, ale to neni uplne co jsem chtel slyset.

algoritmy se (efektivne) implementuji nad jvm nebo v c + wrapper do pythonu pro prototypovani. muzu si cokoliv stahnout z githubu a v shellu, kde shell muze byt emacs) pustit. jestli rozumim tomu, jak je to ve pharo, musim vzit zdrojak knihovny, upravit ho pro ffi, prelozit a pak pouzivat. na to me napada jedine, padnouci

ffuuuuuuuuuuu-

[kkk]

nebo jinak: python nebo lisp se mi jevi na ffi lip pripraveny

[Pavel Křivánek]

Proč upravovat pro FFI a překládat, pokud je to knihovna s C-like rozhraním? Metoda pro FFI call v Pharu vypadá nějak takhle:

privShmat: shmid shmaddr: shmaddr shmflg: shmflg

	^ self ffiCall: #(void * shmat(int shmid, ulong shmaddr, int shmflg))

[kkk]

protoze jsem na to prisel guglenim, ktere mi vyplivlo asi tri divne tutorialy a jednu neexistujici knihu. jestli jde rozumne volat knihovny v c, aspon neco. kdyz tedy hledani "pharo ffi" vraci nesmysly

[Bystroushaak]

ja nevim. mne prijde, ze neodpovidas na otazka: k cemu je to uzitecne.

Je to programovací jazyk a programovací prostředí. K čemu to asi tak může být užitečné? K čemu je užitečný python? Ke všemu, co v něm dokážeš naprogramovat a přináší ti to užitek.

pouzivam emacs a python shell. elegantni programovaci jazyk stranou, je to nejake prostredi. ale to prostredi je uzitecne diky tomu, co v nem uz muzu delat diky praci jinych. v emacsu mam spoustu vlastne aplikaci (dokonce ho muzu mit jako spravce oken). v pythonu mam "baterky" a bazilion knihoven z moji domeny (zpracovani dat).

Taky dělám jako python programátor.

to odkazovane video je hloupe. sorry jako. zobrazit si lokalne obrazky z nejake sluzby je banalita.

To odkazované video ukazuje úplně jiný způsob práce napříč celým systémem, který jsem neviděl nikde jinde, kromě Selfu. Pointa není ukázat jak udělat výslednou aplikaci, ale jak se přitom používá to prostředí (Pharo 3, hodně stará verze).

kdyz se na to podivam z hlediska moji domeny, zajimave to bude ve chvili, kdy budu moct selektovat obrazky podle algoritmu, ktery uz nekdo efektivne napsal, nebo je dal zpracovavat.

Ehm. Proč bys jako nemohl? Myslím, že jsi to video nepochopil.

rozumim snaze divat se na data jinak nez na "soubory", ale to je spis vec navrhu "souboroveho systemu" a prace s metadaty

Ne, to není. Souvisí s tím například perzistence, kterou jinde řešíš neustálou serializací a deserializací. Zkoušel jsem jeden čas používat v pythonu ZODB, ale nakonec jsem celý ten projekt musel vyhodit, protože se to rozbilo a i tak to bylo skoro nepoužitelné, protože se v tom špatně dělalo a navíc byl velký problém se dívat na data tak jako můžeš ve smalltalku.

Hele. Já nechci tvrdit, že Pharo / Smalltalk je nejlepší věc pod sluncem a nahradí všechny systémy a programovací jazyky. To jsou černobílé pohledy pro děti. Je to prostě zajímavý způsob práce s počítačem, který funguje hodně jinak, než na to co jsme zvyklí. Je dobré si to zkusit, když už k ničemu jinému, tak aspoň k rozšíření rozhledu. Rozhodně tě nebudu přesvědčovat, abys ho začal používat - mě je to fakt jedno.

[kkk]

nedelam jako "python programator" a vlastne ani "programator".

v mem oboru se bezne sdileji ipython notebooky. nemam z toho radost. mel jsem tu rozepsanou stat o tom, jak bych si to predstavoval a co mame rozdelane (pulka tymu jsou lispari nebo javisti). nakonec jsem to smazal, ze to nema cenu. proste me zajimalo, jestli to jde delat v tom uzasnem prostredi, nebo je to technicka masturbace.

[kkk]

sakra. pulka mi vypadla. nic, cas jit spat

[Bystroushaak]

v mem oboru se bezne sdileji ipython notebooky. nemam z toho radost. mel jsem tu rozepsanou stat o tom, jak bych si to predstavoval a co mame rozdelane (pulka tymu jsou lispari nebo javisti). nakonec jsem to smazal, ze to nema cenu. proste me zajimalo, jestli to jde delat v tom uzasnem prostredi, nebo je to technicka masturbace.

Hele, přijde mi, že máš pocit jako že se ti tu máme snažit Pharo prodat a teď jsi zklamaný, že se o to nikdo nesnaží. Lidem je docela jedno, jaký z toho máš pocit. I kdyby to byla masturbace, tak je to pořád pro některé zajímavá masturbace. To že ti přijde, že neřeší všechny tvoje problémy, je chyba tvých očekávání, ne chyba Phara.

proste me zajimalo, jestli to jde delat v tom uzasnem prostredi, nebo je to technicka masturbace.

Pokud tě zajímá nějaká konkrétní feature, tak se zeptej přímo na ní, ne na obecné filosofické otázky jako „k čemu to je užitečné“.

[kralyk z abclinuxu]

Killer feature je to prostředí. Tohle se velmi těžko vysvětluje a samotnému mi trvalo dlouho, než mi to skutečně došlo.

LISP-style bait? Na to už podruhé neskočim

Poslední dobou mi taky čím dál víc přijde jako výhoda, že nemusíš zacházet s vrstvami nestrukturované kompatibility a demence, která se nahromadila ve všech operačních systémech.

Tohle je ten sandbox / Minecraft redstone, co mám na mysli. Sice nemusíš řešit "demence nahromaděné v OS", ale zároveň tím pádem zůstáváš stále v tom sandboxu a nedostaneš se nikam jinam, vyjma případů, kdy už se o ty dementní OS a další API postaral někdo jinej a zabalil je pomocí FFI...

[Honza]

Tohle je ten sandbox / Minecraft redstone, co mám na mysli. Sice nemusíš řešit "demence nahromaděné v OS", ale zároveň tím pádem zůstáváš stále v tom sandboxu a nedostaneš se nikam jinam, vyjma případů, kdy už se o ty dementní OS a další API postaral někdo jinej a zabalil je pomocí FFI...

Tohle jsem moc nepochopil, to je jedna z věcí, která ve Pharo Smalltalku už dlouho neplatí.

Platit by to mohlo pro jazyky Swift, Rust, Golang. Nejsou tady tak dlouho.

[kralyk z abclinuxu]

U Swiftu nevím. Golang a Rust mají snadno použitelné FFI (V Rustu jde např. bez problému napsat knihovna pro C, kde z té céčkové strany nepoznáš, že ta knihovna není v C.) ...

[Honza]

Pokud jde o tohle, tak Smalltalk (Pharo) samozřejmě FFI má, v tom problém také nebude. A jeden projekt, který udělá i nativní x86/x64 binárku také existuje (ale blíže jsem ho nezkoumal).

[Bedňa]

A presne v tomto kontexte mi príde C++ ako zbytočný jazyk, je to proste len paródia na objekty a ich správu. Toto čiastočne riešilo U++ nad C++, ale dnes už na to všetko pozerám len z diaľky.

[Bystroushaak]

Tak porovnávat C++ z hlediska objektů vážně nemá cenu. To je něco úplně jiného, co nemá ani moc společné principy. Ve smalltalku například hrají velkou roli bloky, což je něco jako lambda funkce, které se používají fakt všude. Například if podmínka je metoda bool objektu, které se předává blok (lambda) s kódem, který se vykoná v případě true a (volitelně) další v případě false. Už to ti mění styl programování k nepoznání.

[deda.jabko]

Killer feature je to prostředí.

A pro me je to zase hodne neprijemna vlastnost. Protoze nemas jen samostatny jazyk k nemu prekladace/interpret a behove prostredi, ale i cele vyvojove prostredi. Vymenit jednu cast retezce je problem, protoze je vsechno se vsim tesne svazane. Takovy hodne nemodularni navrh.

Poslední dobou mi taky čím dál víc přijde jako výhoda, že nemusíš zacházet s vrstvami nestrukturované kompatibility a demence, která se nahromadila ve všech operačních systémech. Jsou to prostě objekty až úplně dolu a nemusíš řešit žádné formáty dat a serializaci a parsování a kokotiny.

V podstate ocenujes, ze se muzes nechat zavrit ve zlate kleci.

Vezmi si treba tu integraci GITu. U jinych jazyku kazdy programator mohl zacit pouzivat GIT hned, jak se s nim seznamil, nemusel cekat, az bude za integrovana podpora do vyvojoveho prostredi.

[Honza]

Vezmi si treba tu integraci GITu. U jinych jazyku kazdy programator mohl zacit pouzivat GIT hned, jak se s nim seznamil, nemusel cekat, az bude za integrovana podpora do vyvojoveho prostredi.

Smalltalk měl své vlastní verzování kódu ještě dávno předtím, než vůbec GIT vzniknul.. to jen aby nedošlo k nedorozumění. To ti ostatní čekali na ten GIT, než vůbec vzniknul.

Killer feature je to prostředí.

A pro me je to zase hodne neprijemna vlastnost. Protoze nemas jen samostatny jazyk k nemu prekladace/interpret a behove prostredi, ale i cele vyvojove prostredi. Vymenit jednu cast retezce je problem, protoze je vsechno se vsim tesne svazane. Takovy hodne nemodularni navrh.

Není problém vyměnit žádnou část, překladač lze odebrat, stejně tak jako vytvořit celý runtime bez něj. Ta výhoda muset dělat všechno na x-samostatných kroků navíc místo jednoho mně tedy uniká.

[kralyk z abclinuxu]

Ta výhoda muset dělat všechno na x-samostatných kroků navíc místo jednoho mně tedy uniká.

Tak typicky to člověk má automatizované. Výhody jsou hlavně komposabilita a reprodukovatelnost.

[Honza]

Tak to rozhodně souhlas. I ve Smalltalku mám automatizované testy, CI, build výsledné aplikace... Ale myslel jsem něco trochu jiného...

[Bystroushaak]

Já bych rád znovu připomněl, že všechno ve Smalltalku jsou objekty. I celé aplikace jsou objekty. Komposabilita a „scriptovatelnost“ je tam někde úplně jinde, než v ostatních prostředích, které typicky spoléhají na volání programů a předávání stringů (parametry příkazové řádky). Reprodukovatelnost z toho plyne tak nějak sama.

[kralyk z abclinuxu]

Ano, ale to platí pouze vevnitř ve Smalltalku, pouze v tom sandboxu nebo zlaté kleci (jak tomu říká děda.jabko). Tj. aby si člověk těch výhod skutečně užíval, nesmí pro projekt používat nic jinýho...

[Bystroushaak]

Pokud bude používat něco jiného, bude na tom přinejhorším stejně, jako všichni ostatní.

[pavlix]

Tohle linuxákům nevysvětlíš. My máme rádi skládání z komponent, dlouhodobě udržované lego, kde se běžně některé části zavrhnou a nahradí jinými. Většina z nás má tenhle mindset v sobě a molochovité projekty máme spíš neradi, i ten kernel nám dělá problémy.

[Bedňa]

My máme rádi skládání z komponent

Hoci v tomto s tebou súhlasím, tak práve myšlienka objektového skladanie kódu vyzuálne, alebo písanou formou pokladám v dnešnej dobe za dobrý krok vpred.

Veľa krát máš myšlienku ako by sa niečo dalo jednoducho spraviť, ale vo finále zistíš že framework je buď zbytočne zložitý, alebo ťa naštve spracovanie a celé si to nakoniec prepíšeš sám a toto je taký klasický jav v C++ a spústy frameworkov a každý je najlepší.

Takže buď to človek napíše v Céčku a keď už chce programovať objektovo, tak nech je to skutočný ojekt ktorý sa dá uchopiť, naklikať, napísať, inak OOP stráca úplne zmysel.

[pavlix]

Mě štve v poslední době všechno a mám chuť si všechno přepsat po svém. :D

[Komentář jsem nečetl, protože neumím číst.]

Java řeší multiplatformní vývoj a že tam vše vypadá dlouhé.

Multiplatformní vývoj řeší každý high-level jazyk. Java je především o jednotném způsobu uvažování, řešení a zápisu. Lze toho docílit i v jiných jazycích, ale pak to klade větší nároky na celý tým, protože všichni musí dodržovat totožná pravidla. To se spoustě lidí nebude líbit, protože kód vnímají jako nástroj, jak prezentovat svoji domnělou genialitu, a snaží se toho docílit psaním co nejkratších a nejúdernějších konstrukcí. To je v profesionálním vývoji katastrofa.

Odtud ta nepopularita Javy u mnoha lidí pramení, protože to je jazyk, ve kterém když dáte stejnou úlohu vyřešit nezkušenému a zkušenému programátorovi, tak za předpokladu, že ji ten nezkušený bude schopen vyřešit, pravděpodobně mezi odevzdanými kódy neuvidíte fundamentální rozdíl v jiných než architektonických záležitostech (přičemž ty architektonické záležitosti se snadno vyřeší tak, že součástí zadání úlohy je stritkně daný interface, který je potřeba naimplementovat). Není tam tolik prostoru ukázat svojí znalost jazyka a zamachrovat si na zbytečně složitých konstrukcích, protože k tomu jazyk jednoduše nemá prostředky. To je vzácně nevýhoda, častěji výhoda.

[kralyk z abclinuxu]

Není tam tolik prostoru ukázat svojí znalost jazyka a zamachrovat si na zbytečně složitých konstrukcích, protože k tomu jazyk jednoduše nemá prostředky.

LOL, tak to teda Javu/javatiky těžce podceňuješ.

Java sice neumožňuje ukázat programátorskou genialitu pomocí něčitelného zhuštěného one-lineru á la Perl, zato umožňuje ukázat oddanost GoF cargo-cultu (návrhovým vzorům). Každý čerstvě vyškolený javista rád předvede svému okolí znalosti nasazením 8 návrhových vzorů tam, kde by stačil jeden nebo žádný. Viz třeba skvosty jako toto a toto.

Takže zbytečně složité konstrukce jsou v Javě nejen možné, ale i často podporované jako best practices.

[Komentář jsem nečetl, protože neumím číst.]

Každý čerstvě vyškolený javista rád předvede svému okolí znalosti nasazením 8 návrhových vzorů tam, kde by stačil jeden nebo žádný. Viz třeba skvosty jako toto a toto.

To se týká každého programovacího jazyka a ostatně jsem architekturu/patterny explictině uvedl. S chybně zvolenou architekturou/návrhovými vzory (do čehož spadá i over-engineering) jsem se setkal v mnoha různých jazycích.

Takže zbytečně složité konstrukce jsou v Javě nejen možné, ale i často podporované jako best practices.

V první řadě to vůbec nesouvisí s jazykem, jestliže to není skrz na skrz celým standardním API.

Uvádět jako příklad zdrojový kód, který je záměrně napsaný příliš složitě, poukazuje pouze na nedostatek argumentů, nebo neschopnost posoudit rozdíl mezi nečitelnými elementárními konstrukcemi (což lze na úrovni syntaxe jazyka jakž takž omezit) a kódem, který na první pohled vypadá užitečně, ale nijak nevede ke splnění zadání.

Obdobný kód bych mohl přenést do C#, PHP nebo C++ relativně s minimem (designových) změn, ale boiler-plate lze napsat úplně v čemkoliv. Přesto se podobné argumenty vztahují takřka výhradně na Javu.

[kralyk z abclinuxu]

To se týká každého programovacího jazyka a ostatně jsem architekturu/patterny explictině uvedl. S chybně zvolenou architekturou/návrhovými vzory (do čehož spadá i over-engineering) jsem se setkal v mnoha různých jazycích.

Jj, souhlasím.

Uvádět jako příklad zdrojový kód, který je záměrně napsaný příliš složitě, poukazuje pouze na nedostatek argumentů, nebo neschopnost posoudit rozdíl mezi nečitelnými elementárními konstrukcemi (což lze na úrovni syntaxe jazyka jakž takž omezit) a kódem, který na první pohled vypadá užitečně, ale nijak nevede ke splnění zadání.

Ty to asi bereš hodně vážně... Trochu klidu, vždyť tohle jen klasický Language Pissing Match.

Obdobný kód bych mohl přenést do C#, PHP nebo C++ relativně s minimem (designových) změn, ale boiler-plate lze napsat úplně v čemkoliv. Přesto se podobné argumenty vztahují takřka výhradně na Javu.

Protože v Javě je ten problém nejvýraznější. Java je u design pattern kultistů z nějakého důvodu extra oblíbená. Krom toho nenabízí moc abstrakcí, což ještě zvyšuje "poptávku" po patternech.

[Komentář jsem nečetl, protože neumím číst.]

Ty to asi bereš hodně vážně... Trochu klidu, vždyť tohle jen klasický Language Pissing Match.

Pak bych mohl tvrdit naprosto cokoliv a v případě nesouhlasné reakce poukázat na nesmyslnost diskuze jako takové (přesto, že jsem se do ní již zapojil a na nesmyslnost poukazuji až poté, co své výroky nejsem schopen zdůvodnit).

Protože v Javě je ten problém nejvýraznější. Java je u design pattern kultistů z nějakého důvodu extra oblíbená.

Dříve PHP a nyní JavaScript jsou statisticky populární nejvíce u lidí, co neumí programovat, a přesto jejich výtvory nelze předkládat jako ukázku chybného návrhu jazyka, pokud k tomu jazyk vysloveně nevybízí (tj. ve srovnání s jinými jazyky je to natolik složité a neintuitivní, že v tom skoro nikdo neumí pořádně; takové neintuitivní věci lze v Javě nalézt např. ohledně kódování, ale opět to nebývá hlavním terčem kritiky v podobných diskuzích – snad proto, že jinde situace nebývá o mnoho lepší).

Kupříkladu zmiňovaný Spring je často kritizován i mezi samotnými javisty (zejména historicky, kdy nepodporoval anotace a wiring bylo nutné dělat v XML souborech).

Krom toho nenabízí moc abstrakcí, což ještě zvyšuje "poptávku" po patternech.

Co si pod těmi abstrakcemi mám představit? Jiné rozšířené jazyky z C syntaktické rodiny je podporují? Protože ze své profesní praxe si kromě builderu asi nevybavuji jiný pattern, jehož výskyt v kódu by byl opodstatněn omezeností jazyka (a i u toho builderu je to sporné).

Nejvíc mě na těchto diskuzích fascinuje, jak odpůrci Javy zpravidla nejsou schopni předložit konkrétní argumenty, patrně proto, že aby toho byli schopní, museli by Javu výrazně lépe umět (tj. skutečně v ní nějakou dobu programovat). Jejich postoj a hodnocení je tedy převážně estetického rázu, což opět souvisí s mým komentářem o kousek výše.

Javě toho lze vytknout dost – ostatně, je to takřka čtvrt století starý jazyk. Jestli existuje rozumná (čti: lepší) náhrada, to je druhá otázka. V něčem Javu překonává C#, ale své návrhové nedostatky má také (a především bude ještě chvilku trvat než více vyspěje ekosystém okolo něj). Pointa však je, že to, co lze Javě doopravdy a oprávněně vytknout, jí zpravidla vytýkají ti, co v ní programují a mají ji alespoň trochu v oblibě, nikoliv ti, co v ni neprogramují, a hodnotí ji podle dokumentace třídy frameworku třetí strany, satirického Hello Worldu a podobně.

Poznám to podle toho, že tu nepadla jediná zmínka o autoboxingu a neintuitivním bordelu okolo něj (pooly), celkových problémech okolo primitivních typů (zejména v souvislosti s poli), type-erasure u generik, některých problémech při inicializaci final fieldů apod. To jsou reálné a pro Javu specifické problémy, se kterými se programátoři potýkají, ale zároveň to asi není dost cool jako střelivo do diskuze, protože to zpravidla lze snadno řešit a není to dostatečná protiváha proti objektivním a prokazatelným výhodám.

[kralyk z abclinuxu]

Pak bych mohl tvrdit naprosto cokoliv a v případě nesouhlasné reakce poukázat na nesmyslnost diskuze jako takové (přesto, že jsem se do ní již zapojil a na nesmyslnost poukazuji až poté, co své výroky nejsem schopen zdůvodnit).

Je mi velice líto, že tě ten Enterprise FizzBuzz tak rozrušil a urazil, důvod toho, že to někdo napsal, je parodie na jiné existující projekty a styl práce. Já jsem se takovým stylem práce skutečně setkal (ne, jmenovat konkrétně nebudu), pokud ty ne, tak jsi šťastný člověk.

Dříve PHP a nyní JavaScript jsou statisticky populární nejvíce u lidí, co neumí programovat, a přesto jejich výtvory nelze předkládat jako ukázku chybného návrhu jazyka, pokud k tomu jazyk vysloveně nevybízí

U PHP je celkem jednoznačně velmi špatně navržená standardní knihovna a práce se stringy. Dále oba tyhle jazyky trpí quirky okolo dynamického typování.

(Když už jsem u těch stringů, mají své problémy i v JS a Javě - k UTF-16 se chovají jako k UCS-2)

Nejvíc mě na těchto diskuzích fascinuje, jak odpůrci Javy zpravidla nejsou schopni předložit konkrétní argumenty, patrně proto, že aby toho byli schopní, museli by Javu výrazně lépe umět (tj. skutečně v ní nějakou dobu programovat). Jejich postoj a hodnocení je tedy převážně estetického rázu, což opět souvisí s mým komentářem o kousek výše.

To je celkem dost pokrytecké, vzhledem k tomu, jakým stylem jsi toto vlákno otevřel - tam ses vysmál ostatním jazykům a následně vyzdvihl Javu, technické důvody tam nebyly absolutně žádné. Byl to naprosto jasný Language Pissing Match a nevnímal jsem to jako seriózní diskusi. Odpověděl jsem úplně stejným stylem proti Javě a ty najednou chceš seriózně diskutovat a chceš abych předkládal technické důvody.

Pokud bychom od začátku diskutovali seriózně a ty by ses neopřel takhle nesmyslně do ostatních jazyků, neopřel bych se já takhle nesmyslně do Javy, to je jednoduché Já jinak ani tak nejsem nijak zapřísáhlým odpůrcem Javy, spíš jsem odpůrcem protežování Javy v míře větší něž malé. Celkově se snažim nemít k jazykům emocionální vztah. Z toho pravidla mam aktuálně pouze dvé výjimky: Nesnáším PHP a mám jistou náklonnost k Rustu (čemuž se kdokoli může pochechtávat a nebudu se tomu divit - viz třeba celkem oprávěnné označení Rust Evangelism Strikeforce )

Máme-li mluvit technicky o Javě, autoboxing a pooly samozřejmě vnímám jako nepříjemné, jednak kvůli porovnáváním (viz klasický pohovorový chyták s Integer 127 a 128), ale hlavně spíš proto, že generika nepodporují primitivní typy, takže člověk nemůže třeba mít kontejner intů nebo něco takového. Kromě těch problémů, které jsi zmiňoval, mě ještě vysírá absence samostatných funkcní, absence přetěžování operátorů, absence skutečné immutability a další věci. V Javě programuju v rámci zaměstnání (není hlavní jazyk, ale je nedílnou součástí projektu). Krom toho mam ještě nějaké hobby projekty (2 appky pro android), které byly dřív v Javě, ale konvertoval jsem je do Kotlinu, což považuju za velmi pěknou tenkou nadstavbu nad Javou (v mnoha ohledech v podstatě jen syntactic sugar, ačkoli má i standardní knihovnu). Killer features jsou IMHO zejména to, že součástí typu reference je (ne)nullovatelnost, dále type inference, podpora sum types (ač trochu divná), et al., ale třeba tu immutabilitu bohužel neposkytuje a taky má nějaký svoje mouchy...

[kralyk z abclinuxu]

(Když už jsem u těch stringů, mají své problémy i v JS a Javě - k UTF-16 se chovají jako k UCS-2)

Viz následující příklad:

"\u1D11E".length()    // Java
"\u1D11E".length      // JS

Chtěl jsem původně vložit ten znak přímo, ale abclinuxu (napsané v Javě) mi nechtělo komentář uložit, dokud jsem příslušný problematický znak nenahradil tím číselným kódem. (Je pravda, že to ale asi může být způsobeno i DB.)

[Komentář jsem nečetl, protože neumím číst.]

To je celkem dost pokrytecké, vzhledem k tomu, jakým stylem jsi toto vlákno otevřel - tam ses vysmál ostatním jazykům a následně vyzdvihl Javu, technické důvody tam nebyly absolutně žádné.

Skutečně? Můžeš nějak konkrétně uvést, jak jsem se v komentáři #13 vysmál jiným jazykům?

[kralyk z abclinuxu]

Tvrdil jsi, že v Javě je, narozdíl od jiných jazyků, méně prostoru pro zamachrování si na zbytečně složitých konstrukcích. Naznačil jsi, že ostatní jazyky tímto problémem trpí, zatímco Java ne.

Což je samozřejmě naprostý nesmysl, Java tím trpí minimálně stejně jako ostatní jazyky, akorát to vypadá trochu jinak a machruje se specifickým způsobem, efekt je ale v zásadě úplně stejný.

(Koneckonců, v každém jiném jazyce se taky machruje specifickým způsobem.)

[Komentář jsem nečetl, protože neumím číst.]

Přečti si to ještě jednou. Abych ti to usnadnil, tak to tady máš ocitované (se zachováním formátování, tj. třeba tučného písma):

Odtud ta nepopularita Javy u mnoha lidí pramení, protože to je jazyk, ve kterém když dáte stejnou úlohu vyřešit nezkušenému a zkušenému programátorovi, tak za předpokladu, že ji ten nezkušený bude schopen vyřešit, pravděpodobně mezi odevzdanými kódy neuvidíte fundamentální rozdíl v jiných než architektonických záležitostech (přičemž ty architektonické záležitosti se snadno vyřeší tak, že součástí zadání úlohy je stritkně daný interface, který je potřeba naimplementovat).

V následující větě ti tu podstatnou část budu muset zvýraznit teď, když máš tendenci ignorovat slova, která se ti nehodí:

Není tam tolik prostoru ukázat svojí znalost jazyka a zamachrovat si na zbytečně složitých konstrukcích, protože k tomu jazyk jednoduše nemá prostředky. To je vzácně nevýhoda, častěji výhoda.

Ty to zcela chybně interpretuješ tak, že Java tím problémem vůbec netrpí. Komentář však zcela jasně mluví o tom, že ten problém je menší, nikoliv, že neexistuje. Pro jistotu je to patrné z obou těch vět a v každé je to vysvětlené jinými slovy, aby bylo snažší to pochopit.

Jediné, čím se tu pořád oháníš, jsou ty šílené design patterny. První věc tedy je, že jsem v té první citované větě doslova napsal:

rozdíl v jiných než architektonických záležitostech

Druhá věc je, že když jsem se zeptal, ke kterým ohavným a zbytečným patternům Java tak moc vybízí (a řekl jsem, že mě napadá možná tak builder a to si ani u něj nejsem jistý, že to do té kategorie spadá), odpovědi jsem se nedočkal.

Jinak ano, vím, že s Javou trochu pracuješ v práci. Ve starší diskuzi jsi tvrdil, že se jedná o relativně minoritní část většího projektu a převážně pracuješ v jiném jazyce. Také vím, že nepoužíváš IDE a plácáš to jen v editoru. To nepovažuji za podstatnou zkušenost.

Víc mě asi nebaví to vysvětlovat. To by ses musel snažit pochopit, co říkám, a pak to teprve hodnotit, ne naopak.

[pavlix]

Nevím přesně, jakými problémy trpí Java, ale už jsem narazil na problémy, kterými trpí hodně jejích uživatelů, a v chvástání se a sebechvále tíhnou tak nějak víc než ostatní. :D

[podlesh]

Tak zrovna v tomhle jsou myslím lepší kandidáti. I když, pravda, tam to nevypadá tak trapně.

[Komentář jsem nečetl, protože jeho autor nemá dostatečný intelekt.]

Nevím přesně, jakou duševní poruchou trpíš, ale už jsi narazil na problémy, kterými trpíš hodně často, a ve schopnosti interpretovat psaný text selháváš nějak víc než ostatní.

[pavlix]

Děkuji.

[kralyk z abclinuxu]

Ty to zcela chybně interpretuješ tak, že Java tím problémem vůbec netrpí. Komentář však zcela jasně mluví o tom, že ten problém je menší, nikoliv, že neexistuje.

To je celkem jedno, stále je to nesmysl. Java tím problémem rozhodně netrpí méně, trpí jím +/- stejně.

Ono to nedává smysl ani z teoretického hlediksa - Java je turing complete stejně jako statní jazyky a umožňuje psát komplexní programy stejně jako ostatní jazyky, tudíž se v ní dá bez problémů psát překomplikovaný kód stejně jako v ostatních jazycích.

Každý jazyk má nějakou kulturní zátěž (v Javě to jsou patterny, v jiných jazycích zas jiné věci) a nějaké zvyklosti toho, co se považuje idiomatické v daném jazyce. Překomplikovaný kód typicky plyne z toho, že někdo špatně pochopil, co je / není idiomatické, a/nebo to aplikuje příliš drasticky. Je pak zálěžitostí codereview, aby tohle odfiltrovalo.

Tím to končí, tvá Máňa.

První věc tedy je, že jsem v té první citované větě doslova napsal:

rozdíl v jiných než architektonických záležitostech

Zaprvé nevim úplně co tím myslíš (nejsem povinen přesně 100% správně interpretovat, co píšeš), zadruhé architetura je podstatná, zatřetí, pokud by součástí zadání byl interface, znemenalo by to bias k určitému jazyku/jazykům, protože i interface je zatížen zvyklostmi daného jazyka.

Druhá věc je, že když jsem se zeptal, ke kterým ohavným a zbytečným patternům Java tak moc vybízí (a řekl jsem, že mě napadá možná tak builder a to si ani u něj nejsem jistý, že to do té kategorie spadá), odpovědi jsem se nedočkal.

Jeden konkrétní příklad už jsi dostal. Necítím se absolutně povinen psát něco více obsažného a serióznějšího vzhledem k tomu, že ty jsi v první řadě žádné konkrétní příklady přílišné komplexity v ostatních jazycích nenapsal, požaduješ zdůvodnění a důkazy zkušeností pouze od ostatních.

Jinak ano, vím, že s Javou trochu pracuješ v práci. Ve starší diskuzi jsi tvrdil, že se jedná o relativně minoritní část většího projektu a převážně pracuješ v jiném jazyce. Také vím, že nepoužíváš IDE a plácáš to jen v editoru. To nepovažuji za podstatnou zkušenost.

Tohle si běž napsat do r/gatekeeping.

[Komentář jsem nečetl, protože jeho autor nemá dostatečný intelekt.]

Že nevidíš rozdíl oproti jazykům, které jsou méně striktní (nejčastěji absencí statického typování), nebo silněji multiparadigmatické, nebo s širší podporou různých syntactic sugars, a tedy celkově složitostí jazyka (mj., nikoliv však výhradně, jeho specifikace a náročnosti naučení se), na což ten komentář jasně referoval, když mluvil o jednotném způsobu uvažování, řešení a zápisu, je pouze a jen tvůj problém a já to nemíním dál reagovat.

[kralyk z abclinuxu]

Ten rozdíl samozřejmě vidím a nerozporoval jsem ho, rozporuju pouze ty údajné důsledky toho rozdílu, zejména toto:

Není tam tolik prostoru ukázat svojí znalost jazyka a zamachrovat si na zbytečně složitých konstrukcích, protože k tomu jazyk jednoduše nemá prostředky.

To prostě není pravda, to se na mě nezlob. Pro zbytečně složité konstrukce má Java prostředků habaděj a kulturní zátěž k tomu vedoucí také...

Mimochodem, něco podobného dnes tvrdí někteří zapálenější fanoušci Golangu, dokonce se vymezují i oproti Javě jako příliš složité.

[Komentář jsem nečetl, protože se mi nechtělo.]

Není tam tolik prostoru ukázat svojí znalost jazyka a zamachrovat si na zbytečně složitých konstrukcích, protože k tomu jazyk jednoduše nemá prostředky.

To prostě není pravda, to se na mě nezlob. Pro zbytečně složité konstrukce má Java prostředků habaděj a kulturní zátěž k tomu vedoucí také...

Ale já nepopírám, že tam nějaký prostor je, jako spíš to, že ho není tolik. O subjektivním vnímání velikosti té míry v různých jazycích můžeme diskutovat do nekonečna.

Mimochodem, něco podobného dnes tvrdí někteří zapálenější fanoušci Golangu, dokonce se vymezují i oproti Javě jako příliš složité.

Nikde jsem nenapsal, že Java to řeší nejlíp. Javou se kromě již zmiňovaného C# inspirovali třeba i tvůrci jazyka D (ačkoliv D je určené k něčemu trochu jinému).

Abych se zeptal ještě jinak: Vážně si myslíš, že kdybys chtěl nějakou algoritmickou úlohu vyřešit co nejkratším a nejelegantnějším kódem, tak Java bude jedna z nejlepších voleb? A nebo bys to raději napsal třeba v Pythonu, kde nejsi nucen kód balit do třídy a všude deklarovat typy, máš k dispozici syntaktické cukříky jako jsou generátory (yield), array slicing, neexistují tam checked výjimky, nejsi nucen v podmínkách proměnné porovnávat s null (resp. None), protože konverze na boolean je implicitní, bez nutnosti cokoliv importovat máš všude k dispozici funkce jako range, map, filter a další?

Pokud dál trváš na tom, že v Javě to bude zrovna tak hackersky elegantní a esteticky půvabné, tak se prostě není o čem bavit. Pokud uznáváš, že v Pythonu ten kód může být podstatně kratší a hezčí, tak se dostáváme k jádru věci, což je to, co jsem tedy napsal hned v tom prvním příspěvku:

to je jazyk, ve kterém když dáte stejnou úlohu vyřešit nezkušenému a zkušenému programátorovi, tak za předpokladu, že ji ten nezkušený bude schopen vyřešit, pravděpodobně mezi odevzdanými kódy neuvidíte fundamentální rozdíl v jiných než architektonických záležitostech

Programátoři prostě mívají tendence tyhle syntaktické cukříky zneužívat. A jakkoliv souhlasím s tím, že můžou být (a mnohdy jsou) nesmírně užitečné, tak zkušeného programátora poznáš především právě podle toho, že je pouze využívá tam, kde je to na místě, nikoliv zneužívá. A protože Java takovými věcmi nedisponuje, mezi odevzdanými kódy ten fundamentální rozdíl, který by byl patrný na první pohled, nejspíš nebude, zatímco v tom Pythonu situace s větší pravděpodobností bude jiná.

A opět se tedy vracím ke svému prvotnímu tvrzení:

Java je především o jednotném způsobu uvažování, řešení a zápisu.

Těch způsobů, jak ten kód napsat jinak, tam prostě není tolik. Znovu opakuji, že jsem nikde nenapsal, že tam vůbec nejsou. Je ale podstatně složitější je hledat. Pokud někdo nemá absolutně žádný úsudek, samozřejmě, že je najde. Nic ti nebrání vymyslet si vlastní jazyk, úlohu vyřešit v něm, zabalit to do stringu a pak to přeložit do bajtkódu a ten teprve spustit.

Design patterny a architektura s tím nesouvisí a říkám to od počátku. Psaní úplně zbytečného kódu také ne. Mluvím o konstrukcích, které plní zadání a k cíli vedou – v mezích daného jazyka – vcelku přímočaře. Není tam tolik nuancí, kdy se zdravě uvažující člověk rozhoduje mezi více způsoby, jak tutéž konstrukci zapsat.

A ano, trvám na tom, že tohle je jedna z hlavních příčín popularity i nepopularity Javy současně. A ne, pro větší high-level projekty (zejména pracuje-li na nich víc lidí) neznám jiné řešení než:

• použít restriktivní jazyk (jehož restrikce mi z dlouhodobého hlediska spíš pomáhají nez přidělávají práci; kdy/kde se Java hodí/nehodí jsem zde ale rozebírat nezačal já, pouze jsem vyzdvihl tu restriktivní vlastnost)
• stanovení přiměřeně přísného coding style (vymezujícího, které konstrukce použít a kdy)
• rozbít velký projekt na velmi malé samostatné moduly a zaobírat se pouze interfacem mezi nimi, nikoliv coding-stylem, který si jednotlivci/malé týmy spravující konkrétní moduly zvolí – za tu cenu, že cestování programátorů mezi podprojekty bude složitější

A opět: Netvrdím, že Java to nutně řeší v plném rozsahu, nebo že není možné (ba dokonce žádoucí) použít kombinaci výše uvedeného.

Už si konečně rozumíme?

[Bystroushaak]

bez nutnosti cokoliv importovat máš všude k dispozici funkce jako range, map, filter a další?

Nezapomínej na comprehensions (nejen pro list, ale taky pro dicty a sety!) a generátor expressions, to taky šetří brutálně moc kódu. Od té doby co jsem se je pořádně naučil používat už map a filter vůbec nevyužívám a kód je navíc ve výsledku efektivnější.

[Komentář jsem četl, protože byl konečně k věci.]

Jo no, to taky. Dobrá připomínka.

[kralyk z abclinuxu]

Abych se zeptal ještě jinak: Vážně si myslíš, že kdybys chtěl nějakou algoritmickou úlohu vyřešit co nejkratším a nejelegantnějším kódem, tak Java bude jedna z nejlepších voleb? (...) Pokud dál trváš na tom, že v Javě to bude zrovna tak hackersky elegantní a esteticky půvabné, tak se prostě není o čem bavit.

Netrvám. V tomhle nejsme ve sporu, to už jsem se snažil vysvětlit. Samozřejmě, že Java nenabízí všelijaké hackerské konstrukce, které jsou možné v některých ostatních jazycích.

V čem jsem ve sporu s tebou je to, že tento fakt stačí k tomu, aby kód byl jednodušší, snadno pochopitelnější nebo čitelnější. To prostě z toho absolutně neplyne.

Programátoři prostě mívají tendence tyhle syntaktické cukříky zneužívat. A jakkoliv souhlasím s tím, že můžou být (a mnohdy jsou) nesmírně užitečné, tak zkušeného programátora poznáš především právě podle toho, že je pouze využívá tam, kde je to na místě, nikoliv zneužívá.

Souhlasím. Celková komplexita a čitelnost kódu ale zdaleka není pouze o syntaktických cukrech.

Těch způsobů, jak ten kód napsat jinak, tam prostě není tolik.

Ano, ale to nijak nutně nevede k jednoduchosti nebo větší čitelnosti. To je asi jako kdybys tvrdil, že myšlenky zapsané v binárních číslech je snažší číst než v desítkových, protože obsahují pouze dvě číslice. Ano, binární číslo je snažší na parsování, ale to nijak nesouvisí s tím, jestli ta myšlenka je zapsaná do toho čísla jednoduše nebo složitě.

Stejnětak je pravda, že Java je (pravděpodobně) snažší na parsování než většina jazyků, a tím nemyslím pouze strojové parsování, ale i 'parsování' hlavou když čtu kód. To je ale o úroveň níže, než co mě jako programátora nebo případně code-reviewera zajímá. Mě zajímá, jak moc složitě někdo danou myšlenku vyjádřil a to vůbec nesouvisí s tím, jak velkou měl k dispozici abecedu.

Těch způsobů, jak ten kód napsat jinak, tam prostě není tolik.

Vzhledem k tomu, že délka zdrojáků není omezena, pak v podstatě porovnáváš dvě nekonečna. Javovské zdrojáky jsou typicky delší - to je kompenzace té měnší abecedy, tj. celkový prostor možností jak něco psát zůstává +/- stejný.

Design patterny a architektura s tím nesouvisí a říkám to od počátku. (...) Už si konečně rozumíme?

Já vím, co chceš říct a souhlasím s tím, rozporuju pozue ty důsledky. Design patterny a architektura s tím nejenže souvisí, ale jsou ve výsledku mnohem důležitější pro celkovou přehlednost a čitelnost kódu než nějaký syntaktický cukřík.

Zcela souhlasim s nutností rigorózního code review. To nasazení restriktivního jazyka mi smysluplné až tak nepřipadá - to je totiž omezení velikosti vícerozměrného objektu pouze v jednom prostoru, takže se ti sice v tom daném prostoru změnší, ale na to konto zvětší v jiném. To bys musel leda omezit jak prostředky jazyka, tak ale i zároveň třeba celkovou bajtovou velikost zdrojáků nebo počet tříd/funkcí/entit nebo něco takového.

[Už nevím, jaké nicky vymýšlet.]

Tomu porovnávání nekonečen (a souvisejícím argumentům) moc nerozumím, bavíme-li se o implementaci nějakého konkrétního algoritmu a vymezili jsme si následující podmínku:

Mluvím o konstrukcích, které plní zadání a k cíli vedou – v mezích daného jazyka – vcelku přímočaře. Není tam tolik nuancí, kdy se zdravě uvažující člověk rozhoduje mezi více způsoby, jak tutéž konstrukci zapsat.

Zkusím to demonstrovat ještě jinak. Od chvíle, kdy jsem začal v Javě programovat, se moje programátorské uvažování v ní podstatně nezměnilo. V Pythonu to bylo jinak. Počáteční ryze imperativní přístup se postupně rozvíjel a začal jsem se víc seznamovat s tím, jak psát v Pythonu víc idiomaticky.

To jsou ty nuance, o kterých mluvím. Psát v Pythonu ryze imperativně lze, ale ne vždy je to nejlepší nápad. Někdy je lepší myšlenku zhmotnit jinak.

Před příchodem Javy 8 prakticky nepřipadalo v úvahu snažit se v Javě psát za každou cenu funkcionálně – na první pohled by bylo patrné, že to prostě vypadá divně (viz ten zdravý úsudek zmiňovaný výše). V Javě 8 se tahle možnost (resp. možná zneužitelnost) otevřela víc, ale pořád to dává smysl jen někde a Java nadále zůstává především silně imperativním, objektovým, staticky typovaným jazykem.

Použité patterny a celkový návrh kódu samozřejmě ovlivňují výsledek víc (resp. jsou rozhodující pro technický stav projektu), ale tam mezi jednotlivými jazyky (třeba tou Javou a Pythonem) tak zásadní rozdíl nevidím a do porovnání to proto záměrně nezahrnuji.

Připomínám, že mluvím především o situaci, kdy skupině programátorů v jednom jazyce s úplně odlišnou úrovní zkušeností dáš zadání ve smyslu naimplementování metody/funkce s daným prototypem a kontraktem a pak porovnáš výsledné kódy z hlediska rozdílů v uvažování a způsobu zápisu. Sázím na to, že v té Javě bude ta deviace menší než v Pythonu. Exaktně dokázat to nejsem schopen, ale mé zkušenosti (mj., nikoliv však pouze, ze čtení StackOverflow) to odpovídá. Pokud s tím nesouhlasíš – v pořádku.

[kralyk z abclinuxu]

Připomínám, že mluvím především o situaci, kdy skupině programátorů v jednom jazyce s úplně odlišnou úrovní zkušeností dáš zadání ve smyslu naimplementování metody/funkce s daným prototypem a kontraktem a pak porovnáš výsledné kódy z hlediska rozdílů v uvažování a způsobu zápisu.

Hmm... Například před časem jsem byl jedním z reviewerů na kusu javovského kódu, který psal junior-začátečník. Byla to metoda, která někam serializovala nějaké objekty. Běhěm code review se ukázalo, že tam je několik zbytečných hashmap, protože onen programátor nevěděl, že může pro objekty jednoduše naimplementovat určitý interface a potom je použít přímo v serializačním API, místo toho z nich ručně kopíroval nějaká data do hashmap a ty pak serializoval. Eliminací těhle věcí se ten kód smrskl asi 2~3×.

Ale tohle asi není to, co máš na mysli (úplně tomu tvému zadání popravdě nerozumím). Pokud jde vyloženě jenom a pouze o syntaxi tak ta je určitě v Javě dost homogenní.

Že máš s tímhle zkušenosti, to beru, ty jsou obvykle dost nepřenositelné / nesdělitelné. Moje negativní zkušenosti s přístupem lidí k Javě začaly už někdy koncem školy, kdy jsme ve skupině dělali na nějaké ročníkovce nebo něčem takovým a byl tam jeden mladší kolega, který měl plnou hlavu UML diagramů a kdovíčeho. V jeho části projektu měla úplně každá třída nejméně jeden svůj vlastní interface (který byl navíc ve struktuře projektu uložen někde úplně jinde), přestože naprostou většinu těch interfaců by design implementovala jen jedna třída (a nebylo to externě exponované API). Dále tam byla fůra nějakých Factories a Adapterů a kdovíčeho, i na místech, kde to vůbec k ničemu nebylo dobré. Nebylo to tak špatné jako ten FizzBuzz výše, ale byl to krok tím směrem. Když jsem pak měl dotazy, kolega odvětil, že byl na brigádě v nějaké bance (už si nevzpomínám) a že "se to tam takhle dělalo".

Po tomhle a pár dalších podobných incidentech jsem, obávám se, definitivně ztratil víru v blahodárné účinky té restriktivity Javy...

[Už nevím, jaké nicky vymýšlet.]

Ale tohle asi není to, co máš na mysli (úplně tomu tvému zadání popravdě nerozumím).

Takhle z hlavy se nějaké příklady vymýšlí docela blbě, ale tak alespoň trochu pro ukázku (není to nejlepší příklad, ale trochu to z toho patrné snad je):

#!/usr/bin/env python3
def odd_numbers1(n):
    for i in range(n * 2):
        if i % 2:
            yield i

def odd_numbers2(n):
    return filter(lambda i: i % 2, range(n * 2))

def odd_numbers3(n):
    return (i for i in range(n * 2) if i % 2)

Z hlediska přístupu (ve smyslu paradigmat) ty řešení považuji za různá. Současně ale žádné z nich nedělá zbytečné kroky, ani není do očí bijícím způsobem chybné.

K tomu prvnímu řešení zřejmě bude tíhnout člověk přecházející z imperativního jazyka (třeba zrovna té Javy). Ke druhému člověk přecházející třeba z LISPu. A konečně třetí řešení je asi nejvíce idiomatické a většina pythonistů ho asi bude považovat za nejčistější.

Pro prdel si dáme i tu Javu, se zachováním stejného rozhraní:

public static Iterator<Integer> oddNumbers1(int n) {
    return new Iterator<Integer>() {
        private int generatedNumbers = 0;

        @Override
        public boolean hasNext() {
            return generatedNumbers < n;
        }

        @Override
        public Integer next() {
            return 2 * ++generatedNumbers + 1;
        }
    };
}

public static PrimitiveIterator.OfInt oddNumbers2(int n) {
    return IntStream.range(0, 2 * n).filter(i -> i % 2 != 0).iterator();
}

V podstatě asi nevím, jak bych to bez použití 3rd party knihoven udělal jinak, aniž bych přidával zbytečné kroky a podobně (což – připomínám – jsem v tom Pythonu neudělal).

Po tomhle a pár dalších podobných incidentech jsem, obávám se, definitivně ztratil víru v blahodárné účinky té restriktivity Javy...

V předchozím komentáři jsem znovu (už ani nevím po kolikáté) zopakoval, že design patterny do toho neřadím. Někde o kus výš jsem dokonce i vysvětloval proč.

Domněnka, že mluvím o nějakých blahodárných účincích, je opět jen výplod tvé fantazie. Už (a opět ani nevím po kolikáté) opakuji, že jsem především poukázal na tu vlastnost jako takovou, aniž bych Javu nějak hodnotil. Hodnotil jsem častý přístup některých programátorů, na kterém si trvám. Nikde jsem ovšem nenapsal nic v tom smyslu, že Java is da best, protože je restriktivní, a kdo s tím nesouhlasí, je amatér, který si chce honit triko na složitých konstrukcích. Neustále je mi to tu podsouváno, ale prostě jsem to nenapsal. A nenapsal jsem to především proto, že si to nemyslím.

Chce mi tu někdo oponovat, že není nežádoucí, když se v kódu mísí naprosto odlišné přístupy k řešení stejných problémů? Asi ne. Celou dobu poukazuji jen na to, že Java v tomto ohledu může pomoci. V předchozím komentáři jsem se zmínil o dvou dalších způsobech, jak to lze řešit (přičemž jeden z nich jsem uvedl ve svém úplně prvním komentáři).

tl;dr téhle diskuze je, že někdo řekl, že Java řeší multiplatformnost. Já upřesnil, že Java je spíš o jednotnosti uvažování/zápisu, zmínil, proč by se to mělo řešit, a rovnou se zmínil o jiném možném řešení. Ve druhém odstavci jsem pak dal najevo, že ta vlastnost je podle mě hlavním zdrojem nepopularity Javy.

Místo toho se tu řeší záměrně překomplikovaný FizzBuzz, debilní třída ve Springu, zbytečné interfacy, „pár dalších incidentů“ a nevím co ještě. Celou dobu jsem stavěn do role nějakého obhájce Javy přesto, že mluvím o jednom konkrétním žádoucím výsledku a Javu zmiňuji jen jako jednu z možných alternativ (případně použitých v kombinaci). O čem je řeč jsi pochopil už před delší dobou, když jsi začal mluvit o abecedě (což je solidní abstrakce), ale ať to opakuju kolikrát chci, tak se stejně neustále znovu vracíme ke stejným věcem.

I kdybych tisíckrát a jednou napsal, že si nemyslím, že Java, nebo nějaký jiný mainstream jazyk zabraňuje lidem aplikovat všechny patterny z právě dočtené knížky o OOP (nebo jaké jiné paradigma to zrovna používají) bez ohledu na to, jestli to dává smysl, tak to stejně za chvíli někdo zase zmíní a bude očekávat odpověď, nebo, ba o to hůr, se bude domnívat, že to s tou diskuzí souvisí.

Když se proti tomu ohradím, přijde reakce ve stylu „chill bro, to neber tak vážně“.

Validní argumenty jsou třeba:

• Takováto definice restriktivity je nesmyslná, protože ...
• Java není restriktivní jazyk, protože ...
• Restriktivita není žádoucí, protože ...
• Java to neřeší dostatečně, protože ...
• Je lepší to řešit zaměstnáním lepších programátorů a nezaobírat se restriktivitou, protože ...
• Zpochybňuji tvoje nedoložené tvrzení, že ...

I kdyby se usekla ta část se zdůvodněním, tak je to aspoň nějaký názor rozporující konkrétní tvrzení, a to pokud možno co nejníž v myšlenkové pyramidě (např. zpochybním-li/vyvrátím-li předpoklad, že nejaký problém existuje, nemá smysl nadále diskutovat jeho řešení).

Pak se dá vést stručná a obsahově smysluplná diskuze. Takto se tu propsalo nevím kolik komentářů, ale dosud jsme se vlastně neshodli na elementárních bodech a plácá se furt páťák přes deváťačku.

[kralyk z abclinuxu]

Nikde jsem ovšem nenapsal nic v tom smyslu, že Java is da best, protože je restriktivní, a kdo s tím nesouhlasí, je amatér, který si chce honit triko na složitých konstrukcích. Neustále je mi to tu podsouváno, ale prostě jsem to nenapsal. A nenapsal jsem to především proto, že si to nemyslím.

No mně ten první komentář ve vlákně zněl přesně takhle a tak jsem ho interpretoval (a myslimže jsem nebyl sám). Ale beru, že to tak myšleno nebylo.

Validní argumenty jsou třeba:

Ok, pokusim se to nějak zformulovat:

Takováto definice restriktivity je nesmyslná, protože ...

Nemyslim si, že je nesmyslná, spíš mi přijde nepodstatná pro praxi. To jsem se snažil říct tím porováváním nekonečen: Je to jako zadat dvoum lidem, aby vyjádřili nějakou myšlenku/informaci a jednomu k tomu dát abecedu o 30 znacích a druhému o 15 znacích. Pointa je v tom, že IMHO nejde obecně bez nějakých dalších informací nebo omezení (třeba max délkou řešení) předpokládat, že jedno nebo druhé řešení bude jednodušší / elegantnější / snáze čitelné. Přestože jeden z nich má k dispozici menší abecedu, vyjadřovací prostor mají oba neomezený (nekonečný) a odtud to porovnávání nekonečen.

Ty příklady s tím Python kódem jsou pěkné a hezky ukazují různé způsoby zápisu generátorů, ale není to něco, co bych považoval za nějak důležité z hlediska týmové práce nebo z nějakého takového praktického hlediska. V podstatě řešit rozdíly mezi těmihle třemi funkcemi už bych řadil do kategorie bikeshedding. Pokud je pointa v tom, že tahle 'bohatost' některých jazyků může vést k bikesheddingu, tak to souhlasím.

Já myslimže chápu, jaký rozdíl v restriktivitě máš od začátku na mysli, jen jaksi nevidim ten důsledek / závěr z toho plynoucí / význam, který ty taknějak automaticky předpokládáš.

Java není restriktivní jazyk, protože ...

Záleží, co se myslí tou restriktivitou. Java je restriktivní tou "abecedou" a efekt téhle restriktivity (a v důsledku té uniformity zápisu) je IMHO hlavně ten, že Java je snadná na zvládnutí pro začátečníky. Podobně je na tom třeba JavaScript, Go, PHP(víceméně) a další. Ale nepřipadá mi restriktivní způsobem, který by měl nějaký efekt na kvalitu kódu / čitelnost kódu / snadnost code review / kvalitu výsledného programu. Vymyslet jazyk tak, aby skutečně obecně snižoval prasení, to mi přijde hodně hodně těžké, spíš nemožné.

Jeden typ restriktivity, který mi přijde užitečný pro výslednou kvalitu programů, je restrikce přístupu k paměti a control flow, tj. třeba absence goto a eliminace problémů se správnou paměti (jako např. use-after-free, buffer overflow apod.). Tady je dobré si všimnout, že tyhle restrikce nesouvisí s komplexností jazyka - třeba jazyky jako Haskell, Rust nebo D jsou komplexní, zatímco jazyky jako Java, JavaScript nebo Go jsou jednoduché, ale všechny tyhle jmenované zrabraňují use-after-free a nemají goto (mimo unsafe kód v případě Rustu a D, samozřejmě).

Další restrikce, která mi přijde velmi užitečná, je static typing, ale to ani ne tak kvůli nějakým týmovým aspektům, jako spíš hlavně kvůli tomu, že IMHO dost eliminují boilerplate (Python: if not type(foobar) is str: raise SomeError ...) a/nebo snižuje množství testů, které je potřeba psát.

[kralyk z abclinuxu]

Sorry, D má goto, ale tak snad je myšlenka té věty jasná i tak...

[Bystroushaak]

Další restrikce, která mi přijde velmi užitečná, je static typing, ale to ani ne tak kvůli nějakým týmovým aspektům, jako spíš hlavně kvůli tomu, že IMHO dost eliminují boilerplate (Python: if not type(foobar) is str: raise SomeError ...) a/nebo snižuje množství testů, které je potřeba psát.

Jen taková vedlejší poznámka:

Tohle není boilerplate, to je totální hovnokód. Jednak je naprostá prasárna pro to používat type() (isinstance() když už něco!), ale taky to úplně ukazuje, že autor nepochopil ducktyping a tedy celý python a pak se lze těžko divit, že piše javu v pythonu. V takovém případě ovšem nepotřebuje statické typování, ale Ježíše. To úplně vynechávám, že libovolný linter by na něj řval za Yoda condition v podobě not před podmínkou, místo za is (když už by to fakt musel napsat, tak by to mělo vypadat jako if not isinstance(foobar, str): .., nebo alespoň if type(foobar) is not str: ..).

Jinak smysl celého toho kódu, kdy vyhodíš výjimku, aby nedošlo k výjimce někde o tři řádky později mi přijde přinejmenším rozporuplný. Když už něco, tak by mělo smysl kontrolovat, jestli třeba foobar má metodu __str__(), tedy ověřovat interface a ne trvat na tom, že to bude zrovna a jedině nesubclassovatelná instance stringu. Ve všech případech by ale bylo lepší na foobar volat str(), místo snahy určovat její typ.

[kralyk z abclinuxu]

Ono to ve skutečnosti bylo trochu složitější - ta metoda brala buď string nebo list stringů a byla součástí API. Akceptovat nějaké subclassy nebo širší typy v tomhle případě moc nedávalo smysl. Vyhození výjimky tam bylo z toho důvodu, že data byla následně předávána 3rd party API, které pokud nedostalo data správného typu, tiše bez jakékoli chyby prostě nefungovalo.

Ale ono i když třeba ten kód výhodí následně někde výjimku kvůli špatnému typu, často se stává, že tyhle výjimky vylezou někde hluboko ze střev dané knihovny/programu a může být zbytečně složitý pak dohledávat, kudy tam přišel špatný typ a co to kde způsobilo.

[Už nevím, jaké nicky vymýšlet.]

Ono to není ani tolik o srovnání dvou zápisů v různě velkých abecedách, ale o počtu možných rozumných zápisů v té jedné abecedě. V praxi jde o to, jak moc pohodlně budeš schopen číst/upravovat kód kolegů. A nejde mi tolik o čistou syntaxi, ale o to uvažování.

Třeba v tom příkladu s Pythonem čtu každou funkci trochu jinak. Nějak jako:

1. pro každé i € <0; 2n), kde i není dělitelné 2, generuj i
2. vyfiltruj i nedělitelná dvěma z rozsahu <0; 2n)
3. generuj i pro každé i € <0; 2n) nedělitelné 2

Na takto jednoduchém příkladu to nejde vidět tak dobře a ty „lidské“ popisy jsou si dost podobné (v prvním a třetím případu se liší vlastně jen slovosled), ale trochu ten rozdíl cítit je.

No, a ta hlavní myšlenka, kterou celou dobu mám, je vlastně ta, že při vývoji nějakého projektu by si měl ten tým dát záležet na tom, aby psal +/- podobně. Odchylky tam budou vždy, samozřejmě, tomu se úplně zabránit nedá (a ani to nemá smysl; s tímto extrémem jsem se taky setkal a byla to katastrofa), ale není dobré, aby se třeba ty tři uvedené zápisy míchaly úplně náhodně podle toho, co se zrovna kterému vývojáři líbí víc.

Čili je ideální se nějak dohodnout a případně to někde sepsat. Java IMO část těch praviděl implementuje okamžitě, ale samozřejmě to neřeší v plném rozsahu a za cenu, že někdy ti různé zkratky a syntaktické cukříky můžou chybět...

[podlesh]

Ty to asi bereš hodně vážně... Trochu klidu, vždyť tohle jen klasický Language Pissing Match.

Pak bych mohl tvrdit naprosto cokoliv a v případě nesouhlasné reakce poukázat na nesmyslnost diskuze jako takové (přesto, že jsem se do ní již zapojil a na nesmyslnost poukazuji až poté, co své výroky nejsem schopen zdůvodnit).

No, musím upozornit že tu diskusi jsi začal ty a už od začátku bylo jasné že z toho nic nebude, jen nějaká forma flame.

Krom toho nenabízí moc abstrakcí, což ještě zvyšuje "poptávku" po patternech.

Co si pod těmi abstrakcemi mám představit? Jiné rozšířené jazyky z C syntaktické rodiny je podporují?

No, to je dobrá otázka. Bohužel odpovědět je velmi náročné, protože opravdu v rodině jazyků s C-like syntaxí je to obecně bída. Nejlepší odpověď je opravdu: zkusit něco jiného. Koneckonců, od toho jsou VŠ - a pokud programátor nezískal na škole zkušenost s vyššími programovacími jazyky, tak škola selhala. A tím "vyššími" myslím opravdu "vyšší" z hlediska dostupných abstrakcí - Java je v podstatě někde skoro na úrovni C, překládá se přímo do JVM asembleru!

Nejhorší je, že ono to zas tak úplně strašné není - OOP v podstatě umožňuje (zvlášť když jsou k dispozici anonymní třídy nebo lambdy) docela slušnou úroveň abstrakce (byť poněkud ukecaně), ale nesmí být člověk pokřiven tradiční koncepcí OOP (tedy že objekt modeluje nějakou reálnou entitu a všechno je NOUN). Já osobně jsem vždy razil názor, že pro objektové programování musí člověk alespoň trochu přičichnout k funkcionálnímu - jinak je to jen nalakované procedurální (a to se v Javě vyskytuje opravdu hodně, hodně často).

Poznám to podle toho, že tu nepadla jediná zmínka o autoboxingu a neintuitivním bordelu okolo něj (pooly), celkových problémech okolo primitivních typů (zejména v souvislosti s poli), type-erasure u generik, některých problémech při inicializaci final fieldů apod. To jsou reálné a pro Javu specifické problémy, se kterými se programátoři potýkají, ale zároveň to asi není dost cool jako střelivo do diskuze, protože to zpravidla lze snadno řešit a není to dostatečná protiváha proti objektivním a prokazatelným výhodám.

Určitě, tohle jsou velmi důležité vady. Možná kromě toho final, to je fakt detail. Na druhou stranu jeden problém chybí: všechno je uloženo na heapu a neexistuje možnost optimalizace kompilátorem, takže s GC zazvičí každá blbá smyčka kde se něco intenzivního dělá (ačkoliv by se všechny pracovní objekty daly teoreticky jen alokovat třeba na stacku a pak rovnou zahodit).

[Komentář jsem nečetl, protože neumím číst.]

No, musím upozornit že tu diskusi jsi začal ty a už od začátku bylo jasné že z toho nic nebude, jen nějaká forma flame.

Ano? Já mám za to, že jsem se především vyjádřil k výroku, že Java řeší přenositelnost mezi platformami s tím, že Java řeší především něco úplně jiného. Výslovně jsem zmínil, že to lze řešit i jinak, a cena za to řešení je taková a taková (ne nutně neakceptovatelná – záleží na projektu).

A tím "vyššími" myslím opravdu "vyšší" z hlediska dostupných abstrakcí - Java je v podstatě někde skoro na úrovni C, překládá se přímo do JVM asembleru!

Přínos pro vývoj v Javě to má nepochybně ohromný (s ohledem na to, o čem jsem mluvil v tom prvním komentáři). Jinak umím a používám Python a rozumím LISPu a trochu Haskellu (tj. pochopil jsem, jak v nich uvažovat, a zkusil si v nich vyřešit nějaké úlohy). A pak samozřejmě něco vím o asi všech rozšířenějších jazycích nad JVM (z nichž některé se od Javy fundamentálně liší).

[David80]

Diky Pavle za pekny clanek se souhrnem! Deni kolem Smalltalku jsem nejaky cas nesledoval (po roztristenosti o smerovani Squeaku) a s prijemnym zjistenim ted sleduju, kam se posunulo Pharo! Videl jsem zaznamy z PharoDays2017 a musim rict, ze to mnozstvi prace vykonane komunitou je ohromujici a je dobre, ze pusobis jako jeden z tuzemskych pionyru!