abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 11:33 | Pozvánky

Konference LinuxDays 2017 proběhne o víkendu 7. a 8. října v Praze v Dejvicích v prostorách FIT ČVUT. Konference OpenAlt 2017 proběhne o víkendu 4. a 5. listopadu na FIT VUT v Brně. Organizátoři konferencí vyhlásili CFP (LinuxDays, OpenAlt). Přihlaste svou přednášku nebo doporučte konference známým.

Ladislav Hagara | Komentářů: 0
dnes 06:00 | Nová verze

Byla vydána verze 1.3.0 odlehčeného desktopového prostředí Lumina (Wikipedie, GitHub) postaveného nad toolkitem Qt. Z novinek lze zmínit nový motiv ikon nahrazující Oxygen (material-design-[light/dark]) nebo vlastní multimediální přehrávač (lumina-mediaplayer).

Ladislav Hagara | Komentářů: 2
včera 17:33 | Bezpečnostní upozornění

Před šesti týdny byly publikovány výsledky bezpečnostního auditu zdrojových kódů OpenVPN a nalezené bezpečnostní chyby byly opraveny ve verzi OpenVPN 2.4.2. Guido Vranken minulý týden oznámil, že v OpenVPN nalezl další čtyři bezpečnostní chyby (CVE-2017-7520, CVE-2017-7521, CVE-2017-7522 a CVE-2017-7508). Nejzávažnější z nich se týká způsobu, jakým aplikace zachází s SSL certifikáty. Vzdálený útočník může pomocí speciálně

… více »
Ladislav Hagara | Komentářů: 1
včera 06:55 | Zajímavý projekt

V Edici CZ.NIC vyšla kniha Průvodce labyrintem algoritmů. Kniha je ke stažení zcela zdarma (pdf) nebo lze objednat tištěnou verzi za 339 Kč (připojení přes IPv4) nebo 289 Kč (připojení přes IPv6).

Ladislav Hagara | Komentářů: 6
včera 06:33 | Zajímavý software

Byla vydána verze 2.2.0 svobodného správce hesel KeePassXC (Wikipedie). Jedná se o komunitní fork správce hesel KeePassX s řadou vylepšení.

Ladislav Hagara | Komentářů: 0
včera 06:11 | IT novinky

Vývojář Debianu Henrique de Moraes Holschuh upozorňuje v diskusním listu debian-devel na chybu v Hyper-Threadingu v procesorech Skylake a Kaby Lake od Intelu. Za určitých okolností může chyba způsobit nepředvídatelné chování systému. Doporučuje se aktualizace mikrokódu CPU nebo vypnutí Hyper-Threadingu v BIOSu nebo UEFI [reddit].

Ladislav Hagara | Komentářů: 0
24.6. 01:23 | Komunita

Phoronix spustil 2017 Linux Laptop Survey. Tento dotazník s otázkami zaměřenými na parametry ideálního notebooku s Linuxem lze vyplnit do 6. července.

Ladislav Hagara | Komentářů: 3
23.6. 22:44 | Nová verze

Po třech měsících vývoje od vydání verze 5.5.0 byla vydána verze 5.6.0 správce digitálních fotografií digiKam (digiKam Software Collection). Do digiKamu se mimo jiné vrátila HTML galerie a nástroj pro vytváření videa z fotografií. V Bugzille bylo uzavřeno více než 81 záznamů.

Ladislav Hagara | Komentářů: 1
23.6. 17:44 | Nová verze

Byla vydána verze 9.3 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab. Představení nových vlastností v příspěvku na blogu a na YouTube.

Ladislav Hagara | Komentářů: 3
23.6. 13:53 | Nová verze

Simon Long představil na blogu Raspberry Pi novou verzi 2017-06-21 linuxové distribuce Raspbian určené především pro jednodeskové miniaturní počítače Raspberry Pi. Společně s Raspbianem byl aktualizován také instalační nástroj NOOBS (New Out Of the Box Software). Z novinek lze zdůraznit IDE Thonny pro vývoj v programovacím jazyce Python a především offline verzi Scratche 2.0. Ten bylo dosud možné používat pouze online. Offline bylo možné používat pouze Scratch ve verzi 1.4. Z nového Scratchu lze ovládat také GPIO piny. Scratch 2.0 vyžaduje Flash.

Ladislav Hagara | Komentářů: 1
Chystáte se pořídit CPU AMD Ryzen?
 (6%)
 (31%)
 (1%)
 (9%)
 (44%)
 (9%)
Celkem 845 hlasů
 Komentářů: 65, poslední 1.6. 19:16
    Rozcestník

    Pharo 6 - novinky a budoucnost

    6.6. 17:30 | Přečteno: 1278× | Výběrový blog | poslední úprava: 6.6. 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.

    Pharo 6

    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.

           

    Hodnocení: 89 %

            špatnédobré        

    Obrázky

    Pharo 6 - novinky a budoucnost, obrázek 1

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    6.6. 20:24 pf
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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?
    6.6. 20:50 Pavel Křivánek | skóre: 24 | blog: Kvičet nezávaznou konverzaci
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    Mír je, když se střílí jinde.
    6.6. 21:40 tom
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 avatar 6.6. 21:48 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    7.6. 09:38 Pavel Křivánek | skóre: 24 | blog: Kvičet nezávaznou konverzaci
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.

    Mír je, když se střílí jinde.
    oryctolagus avatar 7.6. 15:16 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 :-D
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    7.6. 15:41 Honza
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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í.
    oryctolagus avatar 7.6. 17:08 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    Ono to umí kompilovat do JS?
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    7.6. 17:28 Honza
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost

    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
    oryctolagus avatar 7.6. 19:10 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    Žá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á).
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    7.6. 20:19 Honza
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost

    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

    oryctolagus avatar 7.6. 20:45 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    7.6. 17:41 alfonz
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 avatar 7.6. 18:03 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    7.6. 18:38 alfonz
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 avatar 7.6. 18:47 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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é.
    7.6. 18:57 kkk
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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
    7.6. 22:10 Pavel Křivánek | skóre: 24 | blog: Kvičet nezávaznou konverzaci
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    Příloha:

    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.
    
    Mír je, když se střílí jinde.
    7.6. 22:47 kkk
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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-
    7.6. 22:51 kkk
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    nebo jinak: python nebo lisp se mi jevi na ffi lip pripraveny
    7.6. 23:11 Pavel Křivánek | skóre: 24 | blog: Kvičet nezávaznou konverzaci
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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))
    
    Mír je, když se střílí jinde.
    7.6. 23:55 kkk
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 avatar 7.6. 23:14 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    7.6. 23:52 kkk
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    7.6. 23:59 kkk
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    sakra. pulka mi vypadla. nic, cas jit spat
    Bystroushaak avatar 8.6. 00:18 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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é“.
    oryctolagus avatar 7.6. 19:25 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 :-D
    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...
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    7.6. 20:28 Honza
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.

    oryctolagus avatar 7.6. 22:24 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.) ...
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    7.6. 23:08 Honza
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 avatar 7.6. 23:12 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    Bystroushaak avatar 7.6. 23:18 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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í.
    8.6. 00:48 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    8.6. 01:12 Honza
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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á.
    oryctolagus avatar 8.6. 12:18 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    8.6. 13:07 Honza
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 avatar 8.6. 13:11 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    oryctolagus avatar 8.6. 15:11 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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...
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    Bystroushaak avatar 8.6. 16:14 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    Pokud bude používat něco jiného, bude na tom přinejhorším stejně, jako všichni ostatní.
    pavlix avatar 8.6. 12:41 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 avatar 8.6. 22:08 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.

    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    pavlix avatar 8.6. 23:45 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    Mě štve v poslední době všechno a mám chuť si všechno přepsat po svém. :D
    7.6. 18:41 Komentář jsem nečetl, protože neumím číst.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    oryctolagus avatar 7.6. 19:46 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    7.6. 20:57 Komentář jsem nečetl, protože neumím číst.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    oryctolagus avatar 7.6. 22:03 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    7.6. 23:30 Komentář jsem nečetl, protože neumím číst.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    oryctolagus avatar 8.6. 09:53 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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...
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    oryctolagus avatar 8.6. 10:02 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    (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.)
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    8.6. 20:42 Komentář jsem nečetl, protože neumím číst.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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?
    oryctolagus avatar 8.6. 23:08 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.)
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    9.6. 01:37 Komentář jsem nečetl, protože neumím číst.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 avatar 9.6. 01:50 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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
    9.6. 10:29 podlesh | skóre: 38 | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    Tak zrovna v tomhle jsou myslím lepší kandidáti. I když, pravda, tam to nevypadá tak trapně.
    9.6. 22:18 Komentář jsem nečetl, protože jeho autor nemá dostatečný intelekt.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 avatar 10.6. 00:39 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    oryctolagus avatar 9.6. 09:41 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    9.6. 22:13 Komentář jsem nečetl, protože jeho autor nemá dostatečný intelekt.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    Ž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.
    oryctolagus avatar 9.6. 23:49 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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é.
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    10.6. 02:38 Komentář jsem nečetl, protože se mi nechtělo.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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 avatar 10.6. 03:21 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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ší.
    10.6. 03:26 Komentář jsem četl, protože byl konečně k věci.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    Jo no, to taky. Dobrá připomínka.
    oryctolagus avatar 10.6. 10:42 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    10.6. 22:03 Už nevím, jaké nicky vymýšlet.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    oryctolagus avatar 10.6. 23:43 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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...
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    11.6. 07:53 Už nevím, jaké nicky vymýšlet.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    oryctolagus avatar 11.6. 13:36 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    oryctolagus avatar 11.6. 13:38 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    Sorry, D má goto, ale tak snad je myšlenka té věty jasná i tak...
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    Bystroushaak avatar 11.6. 15:42 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    oryctolagus avatar 11.6. 17:22 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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.
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    11.6. 21:09 Už nevím, jaké nicky vymýšlet.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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...
    8.6. 10:03 podlesh | skóre: 38 | Praha
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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).
    8.6. 20:53 Komentář jsem nečetl, protože neumím číst.
    Rozbalit Rozbalit vše Re: Pharo 6 - novinky a budoucnost
    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ší).

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.