Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: . 30. 04. 2017, 18:53:33
-
Díval jsem se na testy výkonosti jazyka Go a oproti C je dost pomalý. Samozřejmě je i pomalejší než Java nebo C#.
Co na tom moc nechápu je, proč to tak je. Včem je výhodnější, aby měl Go svůj vlastní kompilátor? Syntaxe toho jazyka je dost podobná jazyku C. Proč prostě Go nefunguje tak, že se kód transformuje do jazyka C a potom se prostě zkompiluje pomocí gcc? Mělo by to přece samé výhody:
1. Výstupní kód by byl kompatibilní s C, toho se dá dost využít.
2. Nemuseli by řešit svůj vlastní překladač, použil by se prostě ten, který už si prošel někollika dekádami vývoje.
3. Bylo by to celé podstatně rychlejší.
Neznám Go nějak extra moc, ale co jsem tak viděl, jedná se o jazyk který je prostě takový syntax sugar nad C. Vždyť co je tak špatného na samotném C? Dá se v tom napsat úplně všechno, akorát je ten jazyk poněkud ukecaný.
No a když už jsme teda u toho, proč není Go transofrmovatelný do C, tak neexistuje nad Céčkem nějaká jazyková OOP nadstavba, která by přío generovala Céčkový kód a až ten by se pak kompiloval?
-
Pokud jsou tady takoví, co neví, jak transformaci z jazyka A do B myslím, tak se podívejte, jak to umí Kotlin: (dole si můžete vybrat, jestli výstupní kód má být javaScript)
http://try.kotlinlang.org/#/Examples/Basic%20syntax%20walk-through/Use%20when/Use%20when.kt
-
Jak jsi přišel na to, že je Go pomalé? Mám podezření, že jsi do něj přepsal kus programu z jazyka C a teď se divíš. Takhle to nefunguje, s tímto přístupem by C bylo nejrychlejším jazykem při každém porovnávání s jiným jazykem.
-
Jak jsi přišel na to, že je Go pomalé? Mám podezření, že jsi do něj přepsal kus programu z jazyka C a teď se divíš. Takhle to nefunguje, s tímto přístupem by C bylo nejrychlejším jazykem při každém porovnávání s jiným jazykem.
A jak ty na to, že je rychlé?
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc
-
A jak ty na to, že je rychlé?
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc
To jsou typy úloh, ve kterých je už předem znám vítěz. Zkus si třeba tohle přepsat do C a pak porovnávej:
package main
import (
"fmt"
"net/http"
"log"
)
func sayHello(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello Kit!")
}
func main() {
http.HandleFunc("/", sayHello) // set router
err := http.ListenAndServe(":9090", nil)
if err != nil {
log.Fatal("ListenAndServe: ", err)
}
}
Je to jen primitivní webserver, nic složitého.
-
neexistuje nad Céčkem nějaká jazyková OOP nadstavba, která by přío generovala Céčkový kód a až ten by se pak kompiloval?
Nestačilo by prostě vzít C++ a použít z něho jen to, co je potřeba (tzn. třídy, virtuální metody, ale třeba ne šablony)?
Před lety jsem takový projekt implementující OOP do C viděl, bohužel si již nevzpomenu na jméno. Nezkoušel jsem, takže o něm nemohu nic moc říci. Tehdy byl v experimentálním stavu a přišlo mi zbytečné použít jej místo použití malé podmnožiny C++.
-
Jaký máte vůbec názor na Golang? Teď na něj budu v práci přecházet a na netu neslyším zrovna chválu.
-
A jak ty na to, že je rychlé?
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc
To jsou typy úloh, ve kterých je už předem znám vítěz. Zkus si třeba tohle přepsat do C a pak porovnávej:
package main
import (
"fmt"
"net/http"
"log"
)
func sayHello(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello Kit!")
}
func main() {
http.HandleFunc("/", sayHello) // set router
err := http.ListenAndServe(":9090", nil)
if err != nil {
log.Fatal("ListenAndServe: ", err)
}
}
Je to jen primitivní webserver, nic složitého.
Tady není řeč o rychlosti vývoje, ale úplně o něčem jiném, jestli sis nevšiml. Tak si to laskavě nech a vyjadřuj se k tématu. Mezi performance testy je i binární strom a to mi opravdu nepřijde jako nějaké nefér srovnání výkonu.
-
Jaký máte vůbec názor na Golang? Teď na něj budu v práci přecházet a na netu neslyším zrovna chválu.
Že aktuálně neznám ekvivalent. C je moc low level, v C++ je překomplikovaný relikt, Python je pomalý a nic jiného, co by se kompilovalo přímo do strojového kódy, mělo to GC a bylo to populární, tu není, jen Go.
-
Jaký máte vůbec názor na Golang? Teď na něj budu v práci přecházet a na netu neslyším zrovna chválu.
Každý jazyk má svůj use case, je potřeba uvědomit si, z jakého důvodu golang vznikl a proč ho vyvíjí a tlačí zrovna google. Historicky má google spoustu kódu v pythonu (i v produkci), což není zrovna ideální stav, python je pomalý a na velké projekty se moc nehodí. Google chce nahradit python něčím lepším a na to si vyvinul golang.
Když potřebuješ nějakou service, která paralelně zpracovává requesty, je golang výborná volba. Je kosmicky rychlejší než python, mnohem bezpečnější (kompilovaný, staticky typovaný...) a stejně jako v pythonu v něm může během pár dní začít programovat každý průměrný programátor.
S C nebo C++ dosáhneš lepších výsledků, ale je otázka, jestli ti to za to stojí. Potřebuješ lepší programátory, protože v C(++) je mnohem jednodušší střelit se do nohy a křivka učení je u golangu mnohem strmější než u C(++).
-
Díval jsem se na testy výkonosti jazyka Go a oproti C je dost pomalý. Samozřejmě je i pomalejší než Java nebo C#.
Co na tom moc nechápu je, proč to tak je. Včem je výhodnější, aby měl Go svůj vlastní kompilátor? Syntaxe toho jazyka je dost podobná jazyku C. Proč prostě Go nefunguje tak, že se kód transformuje do jazyka C a potom se prostě zkompiluje pomocí gcc? Mělo by to přece samé výhody:
1. Výstupní kód by byl kompatibilní s C, toho se dá dost využít.
2. Nemuseli by řešit svůj vlastní překladač, použil by se prostě ten, který už si prošel někollika dekádami vývoje.
3. Bylo by to celé podstatně rychlejší.
Neznám Go nějak extra moc, ale co jsem tak viděl, jedná se o jazyk který je prostě takový syntax sugar nad C. Vždyť co je tak špatného na samotném C? Dá se v tom napsat úplně všechno, akorát je ten jazyk poněkud ukecaný.
No a když už jsme teda u toho, proč není Go transofrmovatelný do C, tak neexistuje nad Céčkem nějaká jazyková OOP nadstavba, která by přío generovala Céčkový kód a až ten by se pak kompiloval?
Rychlejší by to nejspíš nebylo. I ten C kód by musel dělat automatickou správu paměti, scheduling a pracovat s interface v čase běhu.
-
a nic jiného, co by se kompilovalo přímo do strojového kódy, mělo to GC a bylo to populární, tu není
Jasne ze je, JavaScript, az na tu kompilaci, to je minule tisicileti, interpretovane jazyky jsou just fine.
-
Moje představa ideálního jazyka by bylo něco na způsob C++:
1. Bez GC
2. OOP bez podpory pro procedurální programování - tzn. žádné multiparadigmatické kraviny
3. Nedalo by se přímo pracovat s pointry, jen s jistými highlevel pointry, které by v sobě zároveň obsahovaly délku alokované paměti (to by mělo dalekosáhlé následky ve prospěch komfortu při programování)
4. Polymorfismus by se dal realizovat pomocí statické alokce, tzn. nebyly by tam takov pitominy, jako je v C++ Object slicing
5. Zabudovaná podpora pro správu verzí, něco jako je Maven
Ještě existuje jakýsik Rust, prý C++ gona right, ale ten jsem nezkoušel.
-
Díval jsem se na testy výkonosti jazyka Go a oproti C je dost pomalý. Samozřejmě je i pomalejší než Java nebo C#.
Co na tom moc nechápu je, proč to tak je. Včem je výhodnější, aby měl Go svůj vlastní kompilátor? Syntaxe toho jazyka je dost podobná jazyku C. Proč prostě Go nefunguje tak, že se kód transformuje do jazyka C a potom se prostě zkompiluje pomocí gcc? Mělo by to přece samé výhody:
1. Výstupní kód by byl kompatibilní s C, toho se dá dost využít.
2. Nemuseli by řešit svůj vlastní překladač, použil by se prostě ten, který už si prošel někollika dekádami vývoje.
3. Bylo by to celé podstatně rychlejší.
Neznám Go nějak extra moc, ale co jsem tak viděl, jedná se o jazyk který je prostě takový syntax sugar nad C. Vždyť co je tak špatného na samotném C? Dá se v tom napsat úplně všechno, akorát je ten jazyk poněkud ukecaný.
No a když už jsme teda u toho, proč není Go transofrmovatelný do C, tak neexistuje nad Céčkem nějaká jazyková OOP nadstavba, která by přío generovala Céčkový kód a až ten by se pak kompiloval?
CPython :-)
-
Moje představa ideálního jazyka by bylo něco na způsob C++:
1. Bez GC
2. OOP bez podpory pro procedurální programování - tzn. žádné multiparadigmatické kraviny
3. Nedalo by se přímo pracovat s pointry, jen s jistými highlevel pointry, které by v sobě zároveň obsahovaly délku alokované paměti (to by mělo dalekosáhlé následky ve prospěch komfortu při programování)
4. Polymorfismus by se dal realizovat pomocí statické alokce, tzn. nebyly by tam takov pitominy, jako je v C++ Object slicing
5. Zabudovaná podpora pro správu verzí, něco jako je Maven
Ještě existuje jakýsik Rust, prý C++ gona right, ale ten jsem nezkoušel.
Na to je už 50 let Smalltalk, zkuste Pharo :-)))
-
Tady není řeč o rychlosti vývoje, ale úplně o něčem jiném, jestli sis nevšiml. Tak si to laskavě nech a vyjadřuj se k tématu. Mezi performance testy je i binární strom a to mi opravdu nepřijde jako nějaké nefér srovnání výkonu.
Zrovna ten binární strom je v Go chybně implementován a to je fakt vůči Go nefér.
-
Kódy na benchmarksgame.alioth.debian.org nejsou vždy to nejlepší co se dá udělat. Cčko mělo hodně pozornosti a má tam fakt optimalizovaný kódy, nemusí to být případ dalších jazyků. Skoro půlrok mi tam visel k-nucleotide v Rustu co byl cca 3x pomalejší než C než si toho všiml někdo zkušenější a poslal tam něco co překonalo Cčko.
Go tam má asi polovinu příkladů srovnatelných s C. Kde je pomalejší jsou:
binary-tree: alokace a dealokace. Go má GC a nevidím tu nic co by ho optimalizovalo. Asi není super-optimalizované
n-body: hodně operací s floatama
fannkuch-redux: (tady nemám tucha co to benchmarkuje)
k-nucleotide: hashmapy, v zadání je že se nemá implementovat vlastní a vyžaduje použití buď build-in nebo polulární knihovny. To v C je trochu podivné, asi bych to nechtěl použít ve skutečném programu. Go opravdu používá build-in.
regex-redux: regex
Go se mi docela líbí. Je jednoduché, kompakní syntax, základ se dá naučit přes víkend, není OOP. Asi bych se nestyděl doporučit to jako první jazyk.
-
RPython to je překlad do C.
-
Jaký máte vůbec názor na Golang? Teď na něj budu v práci přecházet a na netu neslyším zrovna chválu.
Na Golang názor nemám, ale členové komunity zde na rootu nepůsobí moc přátelským dojmem.
-
RPython to je překlad do C.
Cython je v praxi používaný.
-
Jaký máte vůbec názor na Golang? Teď na něj budu v práci přecházet a na netu neslyším zrovna chválu.
Na Golang názor nemám, ale členové komunity zde na rootu nepůsobí moc přátelským dojmem.
Golang jsem dodnes neviděl, ale díky tomuto dotazu jsem si ho vyzkoušel. Docela se mi ten jazyk zalíbil, určitě si v něm ještě nějaký prográmek napíši - nejspíš to bude nějaký malý server nebo třeba vlastní implementace Lispu.
-
Že aktuálně neznám ekvivalent. C je moc low level, v C++ je překomplikovaný relikt, Python je pomalý a nic jiného, co by se kompilovalo přímo do strojového kódy, mělo to GC a bylo to populární, tu není, jen Go.
A co tak skusit D (http://"https://dlang.org/") ?
-
Že aktuálně neznám ekvivalent. C je moc low level, v C++ je překomplikovaný relikt, Python je pomalý a nic jiného, co by se kompilovalo přímo do strojového kódy, mělo to GC a bylo to populární, tu není, jen Go.
Okrem go je tu este D, Rust, Swift a Vala...
-
Že aktuálně neznám ekvivalent. C je moc low level, v C++ je překomplikovaný relikt, Python je pomalý a nic jiného, co by se kompilovalo přímo do strojového kódy, mělo to GC a bylo to populární, tu není, jen Go.
Okrem go je tu este D, Rust, Swift a Vala...
Rust vypadá poměrně zajímavě, ale nemám s ním bližší zkušenosti. D dtto. Swift je hodně slibný, ale je prozatím zabugovaný (překladač i standardní knihovna). Go je oproti Swiftu zralejší a podstatně jednodušší (KISS), i když čím více v něm člověk dělá, tím víc objevuje různé záludnosti. Rozhodně však není pomalé, oproti Javě je znatelně efektivnější (na optimalizovaný kód v C se pochopitelně nechytá nic). A taky o něm evidentně existuje hodně mýtů (nejlepší je učit se jej z prací Pika a spol.), jak dosvědčují příspěvky místního ksindlu.
-
No a když už jsme teda u toho, proč není Go transofrmovatelný do C, tak neexistuje nad Céčkem nějaká jazyková OOP nadstavba, která by přío generovala Céčkový kód a až ten by se pak kompiloval?
To je naivní a (obecně) chybný předpoklad, že kdyby se z X generovalo "něco" v "tom rychlém" C, tak by z toho plynulo, že by bylo rychlé X.
Před lety jsem takový projekt implementující OOP do C viděl, bohužel si již nevzpomenu na jméno. Nezkoušel jsem, takže o něm nemohu nic moc říci. Tehdy byl v experimentálním stavu a přišlo mi zbytečné použít jej místo použití malé podmnožiny C++.
Myslíš https://wiki.gnome.org/Projects/Vala ? Ten je afaik už docela dlouho (polo)mrtvý.
Jaký máte vůbec názor na Golang?
Jazyk s jasnu agendou/myšlenkou, kterou velmi slušně naplňuje. Na můj vkus trochu moc jednoduchý. Tak mi přijde z pročítání materiálů, osobně jsem v něm nic nedělal.
Mezi performance testy je i binární strom a to mi opravdu nepřijde jako nějaké nefér srovnání výkonu.
Je to srovnání hrubého výkonu - jde o spíš jednodušší number crunching. O vhodnosti pro konkrétní praxi to nemusí vypovídat vůbec nic (např. pokud jazyk umožňuje snadno paralelizovat i složitější programy - tj. líp vytížit víc jader CPU, vhodněji cachovat atd. atd., může to být v praxi větší výhoda než samotný hrubý výkon).
bez podpory pro procedurální programování
To si teď nějak neumím představit - co konkrétně by v tom jazyce nebylo a jak a čemu by to pomohlo? :)
Ještě existuje jakýsik Rust, prý C++ gona right, ale ten jsem nezkoušel.
Rust jsem viděl z rychlíku tady na Root.cz a na prezentaci Pavla Tišnovského a vypadá fakt dobře. Ve finále ale stejně bude záležet na velikosti komunity. Bez ní bude těžko použitelný i kdyby to byl svatý grál designu programovacích jazyků... a z toho bych měl obavu, bohužel.
-
nejlepší je učit se jej z prací Pika
https://en.wikipedia.org/wiki/Pika bych určitě nedoporučoval, to není ani hlodavec! Jedině z prací https://cs.wikipedia.org/wiki/Pytlono%C5%A1ovit%C3%AD !
-
Jedná se o microbenchmarky a tak je k tomu potřeba přistupovat. Vezměme třeba ten pro Go nejhorší, binary-tree.
Ve své podstatě se jedná o benchmark testující průchodnost GC. Tady je výtah z podmínek testu:
Use default GC, use per node allocation or use a library memory pool.
As a practical matter, the myriad ways to tune GC will not be accepted.
As a practical matter, the myriad ways to custom allocate memory will not be accepted.
Please don't implement your own custom "arena" or "memory pool" or "free list" - they will not be accepted.To ve své podstatě značně diskvalifikuje jakýkoliv jazyk s GC. Jednoduchým nastavením GC zrychlíte tento test pro Go zhruba 2,3x. Ale toto není akceptováno. Co se potom poměřuje mi ale není jasné.
Díval jsem se na testy výkonosti jazyka Go a oproti C je dost pomalý. Samozřejmě je i pomalejší než Java nebo C#.
Možná se díváme na jiné testy, ale pokud myslíte benchmarksgame, nevidím, že by bylo Go samozřejmě pomalejší než Java nebo C#. Je srovnatelné a dokonce bych podle srovnání řekl v průměru i krapánek rychlejší.
http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest-firstlast.svgz (http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest-firstlast.svgz)
A to nemluvíme o tom, že GC v Go je optimalizován pro latenci, což se v žádném benchmarku neprojeví a minimalizuje alokace na haldě, což se v těchto microbenchmarcích taky moc neprojeví.
A v neposlední řadě by stálo za to se podívat i na sloupeček mem. Java tam má 2,5-30x větší čísla než Go. (Nepsal tu někdo před nedávnem, že Java je stejně paměťově náročná, jako každý jiný jazyk?) No a C# je na tom v této kategorii ještě hůře než Java.
-
nejlepší je učit se jej z prací Pika
https://en.wikipedia.org/wiki/Pika bych určitě nedoporučoval, to není ani hlodavec! Jedině z prací https://cs.wikipedia.org/wiki/Pytlono%C5%A1ovit%C3%AD !
A o genitivu jsi už slyšel? :P
-
A o genitivu jsi už slyšel? :P
Ano, ale správně se to píše genitÁL, pane suvenýr!
-
We want easy answers, but easy answers are often incomplete or wrong. You and I know, there's more we need to understand.
-
Kdyz jsem se na Go naposledy dival, tak jeho typovy system byl slabsi nez ten Javy - neumelo to ani generika, muselo se to nejak hackovat. I tvurce sam rika, ze hlavnim cilem je, aby se podprumerny programator (clovek bez zkusenosti - student po skole) byl to rychle schopen naucit. Podle me je to uplne zcestny cil jazyka. Kolikrat se ucim novy jazyk do zamestnani? Ja osobne jeden za par (mozna i vic) let, navic casto velmi podobny nejakemu jinemu, takze problem nebyva. IMO je lepsi se dobre naucit jeden jazyk + ekosystem, nez "umet" 5x mini-jazyk trpici vaznymi nedostatky typu Go.
Na uceni programovani mozna dobre, ale pracovat bych v tom nechtel. Boileplatu jako v Jave, mene moznosti (napr. podradny typovy system) nez v Jave, horsi ekosystem nez v Jave. Mozna na nejake specificke pripady je vhodny, ale jako univerzalni jazyk me prijde dost nepovedeny.
-
Kdyz jsem se na Go naposledy dival, tak jeho typovy system byl slabsi nez ten Javy.
Java ten typový systém také nemá zrovna dokonalý. I Pascal ho má lepší. Tato nedokonalost se však dá obejít používáním tříd, i když je to trochu pracnější, než definice typu.
-
I tvurce sam rika, ze hlavnim cilem je, aby se podprumerny programator (clovek bez zkusenosti - student po skole) byl to rychle schopen naucit.
Nevím, jestli's to trochu neposunul.
The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/#fn-601-1
Chtít, aby byl jazyk tak jednoduchý, aby v něm byl "normální" programátor schopný rychle psát kvalitní kód, je imho docela dobrá myšlenka. Je to lepší než když vymyslím skvělý jazyk, který ale lidi nepochopí a tak radějí píší (třeba) v tom Pythonu. Mimo to, jednodušší jazyk znamená taky např. rychlejší kompilaci, snadnější vytvoření nástrojů, snadnější refaktoring, snadnější typovou inferenci (vím s jistotou, že bude fungovat dobře vždycky) apod.
Myslím, že to není tak blbý, jak jsi to vykreslil.
5x mini-jazyk trpici vaznymi nedostatky typu Go.
Žádný "vážný nedostatek" jsi ale nezmínil. Absenci uživatelských* generik tak můžu chápat. Anebo ne. Co dál?
Existují poměrně rozumné argumenty (já s nima nesouhlasím, ale jsou respektuhodné), že uživatelská generika zas tak nutná nejsou. Koneckonců třeba C taky generika nemá - je to tímpádem podřadný jazyk pro blbečky?
* afaik Go generika má ve standardní knihovně - akorát si nemůžu vytvořit svoje
Boileplatu jako v Jave
Míň minimálně díky typové inferenci.
-
Kdyz jsem se na Go naposledy dival, tak jeho typovy system byl slabsi nez ten Javy - neumelo to ani generika, muselo se to nejak hackovat. I tvurce sam rika, ze hlavnim cilem je, aby se podprumerny programator (clovek bez zkusenosti - student po skole) byl to rychle schopen naucit. Podle me je to uplne zcestny cil jazyka. Kolikrat se ucim novy jazyk do zamestnani? Ja osobne jeden za par (mozna i vic) let, navic casto velmi podobny nejakemu jinemu, takze problem nebyva. IMO je lepsi se dobre naucit jeden jazyk + ekosystem, nez "umet" 5x mini-jazyk trpici vaznymi nedostatky typu Go.
Na uceni programovani mozna dobre, ale pracovat bych v tom nechtel. Boileplatu jako v Jave, mene moznosti (napr. podradny typovy system) nez v Jave, horsi ekosystem nez v Jave. Mozna na nejake specificke pripady je vhodny, ale jako univerzalni jazyk me prijde dost nepovedeny.
Na typovém systému se prozatím nic nezměnilo, generické jsou jen kolekce. Nicméně trefná je právě ta poznámka, že Go není (nemá být) univerzální jazyk, jeho doména je poměrně omezená (z toho možná vznikají různá nedorozumění a následně flamy).
-
I tvurce sam rika, ze hlavnim cilem je, aby se podprumerny programator (clovek bez zkusenosti - student po skole) byl to rychle schopen naucit.
Nevím, jestli's to trochu neposunul.
The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/#fn-601-1
Chtít, aby byl jazyk tak jednoduchý, aby v něm byl "normální" programátor schopný rychle psát kvalitní kód, je imho docela dobrá myšlenka. Je to lepší než když vymyslím skvělý jazyk, který ale lidi nepochopí a tak radějí píší (třeba) v tom Pythonu. Mimo to, jednodušší jazyk znamená taky např. rychlejší kompilaci, snadnější vytvoření nástrojů, snadnější refaktoring, snadnější typovou inferenci (vím s jistotou, že bude fungovat dobře vždycky) apod.
Myslím, že to není tak blbý, jak jsi to vykreslil.
Jiste, proti slozitosti nastroju nemuzu nic namitnout, ale neberu to jako duvod, proc udelat "hloupy" jazyk. Prace stroje je o nekolik (desitek?) radu levnejsi, nez prace programatora. Pokud mam jazyk s nizkou mirou abstrakce, jako Go, tak je programator odsouzen k opakovani psani a cteni boilerplatu.
Mimochodem, co se stane, az se z podprumerneho programatora bez zkusenosti stane programator prumerny, ktery by tu Javu daval s prehledem? Odpovim si - bude muset zacit prasit, protoze to jinak nejde (rozepsano dale).
5x mini-jazyk trpici vaznymi nedostatky typu Go.
Žádný "vážný nedostatek" jsi ale nezmínil. Absenci uživatelských* generik tak můžu chápat. Anebo ne. Co dál?
Existují poměrně rozumné argumenty (já s nima nesouhlasím, ale jsou respektuhodné), že uživatelská generika zas tak nutná nejsou. Koneckonců třeba C taky generika nemá - je to tímpádem podřadný jazyk pro blbečky?
C neni jaksi zamyslen jako univerzalni jazyk, nic co by melo nahradit Javu, Python ci JavaScript. Nebo snad Go aspiruje nahradit C? Rozhodne nesouhlasim s tim, ze uzivatelska generika nejsou nutna. Minimalne pro knihovny se dost hodi a obcas je pouziji i ve svem kodu (a to se tim nezivim, lidi kolem Javy to urcite budou pouzivat vic, nez ja se Scalou [kde jsou navic alternativy], ktery si s tim hraje par hodin tydne).
* afaik Go generika má ve standardní knihovně - akorát si nemůžu vytvořit svoje
Boileplatu jako v Jave
Míň minimálně díky typové inferenci.
Videl jsem, jak se "resi" generika. Copy/paste, potlacenim typove kotroly ci generatory kodu. Nic jineho nez fuj na to rict nemuzu. Kdyby byla rozumna nahrada, nejake typeclassy nebo neco podobneho, tak nic nereknu, ale (nejen) z meho pohledu je ten jazyk zamerne oklesteny, kvuli tomu v realnych projektech casto pokulhava a slaby type system se resi generatory kodu, ktere nejsou rozhodne jednoduche a urcite slozitejsi, nez kdyby pridali napr. generika ala Java, prestoze jednoduchost je jeden z hlavni duvodu proc pouzivat ten jazyk.
-
...
Na typovém systému se prozatím nic nezměnilo, generické jsou jen kolekce. Nicméně trefná je právě ta poznámka, že Go není (nemá být) univerzální jazyk, jeho doména je poměrně omezená (z toho možná vznikají různá nedorozumění a následně flamy).
Bohuzel casto vidim lidi, jak Go srovnavaji s Javou, JS nebo ho vyobrazuji jako zabijaka Pythonu. Ostatne neni nahrada Pythonu snad duvod, proc Go vznikl? Mozna proto ta vsudypritomna nedorouzmneni a click-bait prispevky na blozich provokujici flame...
-
Jiste, proti slozitosti nastroju nemuzu nic namitnout, ale neberu to jako duvod, proc udelat "hloupy" jazyk. Prace stroje je o nekolik (desitek?) radu levnejsi, nez prace programatora. Pokud mam jazyk s nizkou mirou abstrakce, jako Go, tak je programator odsouzen k opakovani psani a cteni boilerplatu.
Souhlasím. Ale nevidím to tak příkře jako ty. Kdybych chtěl propagovat opak: přílišná volnost v úrovni abstrakce a přílišný důraz na DRY vede k sice kratšímu, ale o to nečitelnějšímu kódu. Navíc otrocká implementace DRY může taky způsobit, že všechno centralizuješ/abstrahuješ a pak máš velké problémy jednu část přizpůsobit/poupravit. Mám s tímhle konkrétní špatnou zkušenost z jednoho projektu - všechno bylo vyřešeno tak abstraktně/jednotně/DRY, že se kdokoli pak bál na cokoli šáhnout, aby nerozbil něco úplně jinde...
Osobně mám třeba docela špatné zkušenosti s tím, co produkují Rubyisti. To jsou takové kejkle s metaprogramováním, monkeypatchingem a jánevímčím (because we can!), že pak říct, co a přesně jak doopravdy ten kód dělá, je nadlidský úkol. Ideální řešení všeho je samozřejmě DSL (because we can!)
Podobný, ale o několik řádů lepší je to s haskellisty - taky si libují v abstrakcích, kde prokousat se z abstraktní roviny až dolů není žádný med, ale aspoň haskellisti bývají nadprůměrně chytří, tak to aspoň dělají dobře.
C neni jaksi zamyslen jako univerzalni jazyk, nic co by melo nahradit Javu, Python ci JavaScript.
Tak to potom asi moc nechápu. V C je napsaná snad největší množina všeho možného softu. Od GUI po matematické knihovny...
Rozhodne nesouhlasim s tim, ze uzivatelska generika nejsou nutna.
Všechno je jenom otázka ceny. Když je nemám, platím nějakou cenu, kterou mi může vyvážit něco jiného... Ale jinak v tomhle taky souhlas: osobně by mi bylo sympatičtější, kdyby generika měl.
Videl jsem, jak se "resi" generika. Copy/paste, potlacenim typove kotroly ci generatory kodu.
Souhlas, je to zoufalost.
-
nejlepší je učit se jej z prací Pika
https://en.wikipedia.org/wiki/Pika bych určitě nedoporučoval, to není ani hlodavec! Jedině z prací https://cs.wikipedia.org/wiki/Pytlono%C5%A1ovit%C3%AD !
A o genitivu jsi už slyšel? :P
to neeeeeeee
-
...
Na typovém systému se prozatím nic nezměnilo, generické jsou jen kolekce. Nicméně trefná je právě ta poznámka, že Go není (nemá být) univerzální jazyk, jeho doména je poměrně omezená (z toho možná vznikají různá nedorozumění a následně flamy).
Bohuzel casto vidim lidi, jak Go srovnavaji s Javou, JS nebo ho vyobrazuji jako zabijaka Pythonu. Ostatne neni nahrada Pythonu snad duvod, proc Go vznikl? Mozna proto ta vsudypritomna nedorouzmneni a click-bait prispevky na blozich provokujici flame...
Tvůrci tvrdí, že chtěli nahradit C++. Co si myslí jiní, je bezpředmětné.
Možná už je čas vyrůst z kritizování pouze syntaxe (ať už Go nebo třeba ObjC). Na Go je pěkná rychlost, obsáhlá a efektivní standardní knihovna a neuvěřitelně výkonný GC. Zrovna syntax je dle mého čistě *subjektivního* pohledu celkem hnusná, ale objektivní výhody to dostatečně vyvažují. Třeba boilerplatu se dá úspěšně vyhnout používáním rozhraní.
-
... v kazdym pripade je zajimavy si poslechnout par nazoru od samotnych lidi z googlu co ho musi pouzivat ... a ted nemyslim marketing
-
nejlepší je učit se jej z prací Pika
https://en.wikipedia.org/wiki/Pika bych určitě nedoporučoval, to není ani hlodavec! Jedině z prací https://cs.wikipedia.org/wiki/Pytlono%C5%A1ovit%C3%AD !
česky je to pišťucha.
-
... v kazdym pripade je zajimavy si poslechnout par nazoru od samotnych lidi z googlu co ho musi pouzivat ... a ted nemyslim marketing
Měl bys tip na nějaký link, co stojí za přečtení?
-
Jiste, proti slozitosti nastroju nemuzu nic namitnout, ale neberu to jako duvod, proc udelat "hloupy" jazyk. Prace stroje je o nekolik (desitek?) radu levnejsi, nez prace programatora. Pokud mam jazyk s nizkou mirou abstrakce, jako Go, tak je programator odsouzen k opakovani psani a cteni boilerplatu.
Souhlasím. Ale nevidím to tak příkře jako ty. Kdybych chtěl propagovat opak: přílišná volnost v úrovni abstrakce a přílišný důraz na DRY vede k sice kratšímu, ale o to nečitelnějšímu kódu. Navíc otrocká implementace DRY může taky způsobit, že všechno centralizuješ/abstrahuješ a pak máš velké problémy jednu část přizpůsobit/poupravit. Mám s tímhle konkrétní špatnou zkušenost z jednoho projektu - všechno bylo vyřešeno tak abstraktně/jednotně/DRY, že se kdokoli pak bál na cokoli šáhnout, aby nerozbil něco úplně jinde...
Osobně mám třeba docela špatné zkušenosti s tím, co produkují Rubyisti. To jsou takové kejkle s metaprogramováním, monkeypatchingem a jánevímčím (because we can!), že pak říct, co a přesně jak doopravdy ten kód dělá, je nadlidský úkol. Ideální řešení všeho je samozřejmě DSL (because we can!)
Podobný, ale o několik řádů lepší je to s haskellisty - taky si libují v abstrakcích, kde prokousat se z abstraktní roviny až dolů není žádný med, ale aspoň haskellisti bývají nadprůměrně chytří, tak to aspoň dělají dobře.
Naopak, bez DRY musíš měnit jednu věc na více místech, snadno něco přehlédneš.
Na této sránce https://appliedgo.net/generics/ doporučují copy pastovat nebo generovat kód nějakými externími nástroji. Takový projekt bych nechtěl udržovat.
Ruby není pro lidi co neumí psát testy. Je v tom napsaný třeba github.
-
... v kazdym pripade je zajimavy si poslechnout par nazoru od samotnych lidi z googlu co ho musi pouzivat ... a ted nemyslim marketing
Měl bys tip na nějaký link, co stojí za přečtení?
ani ne :) napriklad kdyz Rob prechazel do gluglu tak k tomu mel sve duvody a tak jak jinak - ono vsechno v gluglu trosku smrdi zenao
-
Mezi performance testy je i binární strom a to mi opravdu nepřijde jako nějaké nefér srovnání výkonu.
Je to srovnání hrubého výkonu - jde o spíš jednodušší number crunching. O vhodnosti pro konkrétní praxi to nemusí vypovídat vůbec nic (např. pokud jazyk umožňuje snadno paralelizovat i složitější programy - tj. líp vytížit víc jader CPU, vhodněji cachovat atd. atd., může to být v praxi větší výhoda než samotný hrubý výkon).
Nevím čemu říkáš number crunching, já si pod tím představuji něco jiného. Máš nějaký příklad lepší úlohy? Souhlasím, že ty výsledky nejsou moc objektivní. Nepoužívají dostupné knihovny.
-
https://en.wikipedia.org/wiki/Limbo :))
-
Souhlasím. Ale nevidím to tak příkře jako ty. Kdybych chtěl propagovat opak: přílišná volnost v úrovni abstrakce a přílišný důraz na DRY vede k sice kratšímu, ale o to nečitelnějšímu kódu. Navíc otrocká implementace DRY může taky způsobit, že všechno centralizuješ/abstrahuješ a pak máš velké problémy jednu část přizpůsobit/poupravit. Mám s tímhle konkrétní špatnou zkušenost z jednoho projektu - všechno bylo vyřešeno tak abstraktně/jednotně/DRY, že se kdokoli pak bál na cokoli šáhnout, aby nerozbil něco úplně jinde...
Naopak, bez DRY musíš měnit jednu věc na více místech, snadno něco přehlédneš.
Při aplikaci DRY musí vývojář přemýšlet, zda při požadavku na změnu ji skutečně bude moct uplatnit jednotně ve všech užitích. Jedna implementace pro různé typy dat může vypadat výhodně, ale pokud se budoucí požadavek na změnu týká pouze jednoho typu dat, na průšvih je zaděláno.
-
Naopak, bez DRY musíš měnit jednu věc na více místech, snadno něco přehlédneš.
Mám komponenty A a B. Jsou dvě možnosti, co se v budoucnu může stát: buď chci něco změnit v obou komponentách, nebo chci naopak něčím jednu od druhé odlišit. V prvním případě je lepší, když je ten dotčený kód v nějakém společném "rodiči" (ať už to znamená cokoli, ne nutně dědičnost), ve druhém případě je lepší, když je v obou ten stejný kód zkopírovaný.
Navíc otrocké používání DRY spojené s OOP megalomanií vede k vytváření superobecných komponent, které jsou zbytečně komplikované a stejně nejsou nikdy znovupoužité, takže vůbec nic nepřináší, jenom komplikují a znepřehledňují kód, tj. zdražují budoucí úpravy (viz https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition )
Protože člověk nemá křišťálovou kouli, neví, jestli pro něj do budoucna bude lepší složitější abstraktnější nebo naopak konkrétnější přímočařejší kód. Neexistuje pro to žádné obecné pravidlo. Proto nemám rád, když někdo DRY principem příliš šermuje.
Na této sránce https://appliedgo.net/generics/ doporučují copy pastovat nebo generovat kód nějakými externími nástroji. Takový projekt bych nechtěl udržovat.
Ano, to je dobrá stránka, mám ji v Pocketu ;) A taky je to tam dobře vysvětleno, proč to není taková blbost, jak si spousta lidí myslí:
Every time you think that you need to create a generic object, do a quick Litmus test: Ask yourself, “How many times would I ever have to instantiate this generic object in my application or library?” In other words, is it worth to construct a generic object when there may only be one or two actual implementations of it? In this case, creating a generic object would just be an over-abstraction.
Máš nějaký příklad lepší úlohy? Souhlasím, že ty výsledky nejsou moc objektivní. Nepoužívají dostupné knihovny.
Nemám žádný příklad úlohy. Každé zadání je jiné. Z principu nemůže existovat žádný benchmark, který by určoval, který jazyk je obecně nejlepší.
-
Naopak, bez DRY musíš měnit jednu věc na více místech, snadno něco přehlédneš.
Mám komponenty A a B. Jsou dvě možnosti, co se v budoucnu může stát: buď chci něco změnit v obou komponentách, nebo chci naopak něčím jednu od druhé odlišit. V prvním případě je lepší, když je ten dotčený kód v nějakém společném "rodiči" (ať už to znamená cokoli, ne nutně dědičnost), ve druhém případě je lepší, když je v obou ten stejný kód zkopírovaný.
Navíc otrocké používání DRY spojené s OOP megalomanií vede k vytváření superobecných komponent, které jsou zbytečně komplikované a stejně nejsou nikdy znovupoužité, takže vůbec nic nepřináší, jenom komplikují a znepřehledňují kód, tj. zdražují budoucí úpravy (viz https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition )
Protože člověk nemá křišťálovou kouli, neví, jestli pro něj do budoucna bude lepší složitější abstraktnější nebo naopak konkrétnější přímočařejší kód. Neexistuje pro to žádné obecné pravidlo. Proto nemám rád, když někdo DRY principem příliš šermuje.
DRY a OOP megalomanie jsou dvě různé věci. Používání OOP návrhových vzorů jde často proti DRY a naopak prodlužuje kód.
-
DRY a OOP megalomanie jsou dvě různé věci. Používání OOP návrhových vzorů jde často proti DRY a naopak prodlužuje kód.
Chybné používání návrhových vzorů opravdu jde často proti DRY a prodlužuje kód.
Většinou však vadí, že se návrhové vzory nepoužívají v dostatečné míře a místo nich se jen lepí špagety.
-
Někdy může být copy&paste lepší než DRY, ale až příliš často se děje to, že z původních dvou kopií kódu jsou tři, pak pět a nakonec patnáct. A pak se to musí měnit všude. Jsem pro DRY, pokud to jenom trochu dává smysl.
-
Zatím zde napadla pro tazatele krutá pravda: go je pomalý, protože je genderově vyvážený.
Prolítněte jak go prezentovali v ranné fázi a co bylo cílem, já si to pamatuji dost dobře.
-
Zatím zde nepadlo odpověď, proč si tazatel myslí, že je Go pomalejší než Java nebo C#, ačkoliv i z těch benchmarků jednoznačně vyplývá, že to není pravda.
-
Zatím zde nepadlo odpověď, proč si tazatel myslí, že je Go pomalejší než Java nebo C#, ačkoliv i z těch benchmarků jednoznačně vyplývá, že to není pravda.
Pokud se ve VM nikdy nespustí GC, tak u některých typů úloh bude Go "pomalejší", protože má nedeterministický alokátor. To je ovšem značně nerealistická situace, v praxi je Go výrazně rychlejší (minimálně v porovnání s Javou, .NET má komplikovanější VM). Takový "benchmark" se dá napsat levou zadní (jen nebude o ničem vypovídat).
-
Zatím zde napadla pro tazatele krutá pravda: go je pomalý, protože je genderově vyvážený.
Prolítněte jak go prezentovali v ranné fázi a co bylo cílem, já si to pamatuji dost dobře.
Původně to vycházelo z Plan-9, tedy měl to být jazyk pro multiprocesorový distribuovaný systém.
-
Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.
Chybné používání návrhových vzorů opravdu jde často proti DRY a prodlužuje kód. Většinou však vadí, že se návrhové vzory nepoužívají v dostatečné míře a místo nich se jen lepí špagety.
Kdyby všichni programovali dokonale, žádných paradigmat ani návrhových vzorů by nebylo třeba. Bezmyšlenkovité používání návrhových vzorů jen proto, že to "bylo v tej brožuře", je ale snad ještě větší zlo, než kdyby to dotyčný nějak spatlal, jak mu to přišlo na mysli. Protože to vede jen k tomu, že se jeden problém vynásobí problémem druhým: nešikovné řešení krát nesprávně aplikovaný vzor.
-
Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.
Běžný Pepa (nebo Míra) programátor nečte akademické články, a možná to je dobře, rozvoj a inovace by se měly přenechat těm kreativnějším (ne nutně akademikům).
-
Chybné používání návrhových vzorů opravdu jde často proti DRY a prodlužuje kód. Většinou však vadí, že se návrhové vzory nepoužívají v dostatečné míře a místo nich se jen lepí špagety.
Kdyby všichni programovali dokonale, žádných paradigmat ani návrhových vzorů by nebylo třeba. Bezmyšlenkovité používání návrhových vzorů jen proto, že to "bylo v tej brožuře", je ale snad ještě větší zlo, než kdyby to dotyčný nějak spatlal, jak mu to přišlo na mysli. Protože to vede jen k tomu, že se jeden problém vynásobí problémem druhým: nešikovné řešení krát nesprávně aplikovaný vzor.
Ano, tomu se říká "cargo cult programming" a obávám se, že mnozí, ne-li většina, takto programují a ještě si na tom zakládají.
-
Chybné používání návrhových vzorů opravdu jde často proti DRY a prodlužuje kód. Většinou však vadí, že se návrhové vzory nepoužívají v dostatečné míře a místo nich se jen lepí špagety.
Kdyby všichni programovali dokonale, žádných paradigmat ani návrhových vzorů by nebylo třeba. Bezmyšlenkovité používání návrhových vzorů jen proto, že to "bylo v tej brožuře", je ale snad ještě větší zlo, než kdyby to dotyčný nějak spatlal, jak mu to přišlo na mysli. Protože to vede jen k tomu, že se jeden problém vynásobí problémem druhým: nešikovné řešení krát nesprávně aplikovaný vzor.
Často potkávám nesprávně použitý vzor Flyweight nebo Singleton. Těmi se opravdu musí šetřit, protože dokáží zaneřádit aplikaci. Ovšem logování přes Observer je podle mne docela sympatické a vzor Factory má také časté uplatnění.
-
Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.
Co konkrétně máš namysli tady u toho, o čem jsme se bavili? To je spíš o zkušenosti než o nějaké teorii imho.
Běžný Pepa (nebo Míra)
Já ti dám Míru, ty darebáku! ;)
-
Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.
Co konkrétně máš namysli tady u toho, o čem jsme se bavili? To je spíš o zkušenosti než o nějaké teorii imho.
Běžný Pepa (nebo Míra)
Já ti dám Míru, ty darebáku! ;)
:P
-
Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.
Běžný Pepa (nebo Míra) programátor nečte akademické články, a možná to je dobře, rozvoj a inovace by se měly přenechat těm kreativnějším (ne nutně akademikům).
Vůbec nejde o akademické články. Akademickým článkům té doby by běžný Pepa kodér vůbec nerozuměl. Jde o texty praktiků, kteří popisovali své zkušenosti a často i řešení problémů, s nimiž se setkali.
Např. zmiňovaný postřeh o nepředvídatelnosti budoucího vývoje SW produktu. Tak na to naráželi už v 70. letech. A řekl bych, že většina z nás se už někdy setkala s poznámkami "reserved for future extensions". A taky tenkrát doporučili, jak se s tím vypořádávat:
1. Řešte jen problém, který máte skutečně řešit dle zadání. Dejte si pozor na dodatečné podmínky, které ve skutečnosti ze zadání neplynou, ale vy jste si je podvědomě dotvořili ve snaze předvídat budoucí vývoj nebo řešení nějak vylepšit, a přitom vedou k potřebě větší abstrakce a komplexity.
2. Pokud obecnější řešení v daném případě nevede k nárůstu komplexity nebo náročnosti na zdroje, není důvodu omezovat se na specifikaci.
Zdůvodnění je jednoduché. V naprosté většině případů o ta vylepšení nikdo nestojí a vývoj se bude ubírat jiným směrem než si myslíte, ale jejich přítomnost velmi zkomplikuje budoucí modifikace směrem, s nímž se nepočítalo. Jednoduchá věc se dá překopat snadněji než komplikovaná.
Vyčleníte-li někde 4 bajty pro budoucí rozšíření vlastnosti X, 4 bajty pro vlastnost Y a 4 bajty pro vlastnost Z, vemte jed na to, že jich nakonec bude zapotřebí nejméně 5 pro vlastnost X a vyvstane potřeba přidat vlastnost W, co potřebuje 2 bajty, a vlastnost Y už nikdo nepotřebuje, protože děrné pásky odnesl čas. Přestože prostor k obojímu je, technicky to bude hlavolam, protože někdo před lety "myslel" víc, než bylo zdrávo. Je to jen ilustrační příklad, ale na podobné situace jsem ve svém profesionálním životě narážel neustále - komplikované hierarchie tříd, zabránění opakování stejného kódu i za cenu, že se to celé znepřehlední zbytečnými abstraktními mezičlánky a lepidly mezi nimi, jež vydají za 5x tolik kódu, než kdyby se to prostě duplikovalo apod., načež se potom ukáže, že přeci jen ten kód nebude úplně stejný, takže struktury, jež měly zamezit duplikaci kódu, se musejí obcházet a nastavovat jak kaše, protože tím okamžikem ztrácejí smysl, ale zato vydatně překážejí.
Přestože formulace je jednoduchá, realizace je náročná, protože ne každý si umí ty klapky z očí sundat a má cit pro to, co ještě ano a co už ne. Ale rozhodně by přemýšlení o takovýchto věcech měl být dáván větší prostor, než jak nejčistěji aplikovat návrhový vzor XYZ, protože jsem podlehl pocitu, že jde o zázračný všelék, který za mě vyřeší problémy. V knížce to sice vypadá elegantně, možná se to i v konkrétním případě podaří implementovat elegantně, ale jakmile bude třeba do toho trošku hrábnout, stane se z toho podobný zážitek, jako oprava traktoru typu LKT.
-
Lidi! Co to proboha hulíte? :D :D :D
-
Je prča sledovat, jak lidi vítězoslavně přicházejí na dávno známé věci. Ale proč číst počítačovou literaturu ze 70. a 80. let, že... To je přece doba kamenná.
Běžný Pepa (nebo Míra) programátor nečte akademické články, a možná to je dobře, rozvoj a inovace by se měly přenechat těm kreativnějším (ne nutně akademikům).
Vůbec nejde o akademické články. Akademickým článkům té doby by běžný Pepa kodér vůbec nerozuměl. Jde o texty praktiků, kteří popisovali své zkušenosti a často i řešení problémů, s nimiž se setkali.
Např. zmiňovaný postřeh o nepředvídatelnosti budoucího vývoje SW produktu. Tak na to naráželi už v 70. letech. A řekl bych, že většina z nás se už někdy setkala s poznámkami "reserved for future extensions". A taky tenkrát doporučili, jak se s tím vypořádávat:
1. Řešte jen problém, který máte skutečně řešit dle zadání. Dejte si pozor na dodatečné podmínky, které ve skutečnosti ze zadání neplynou, ale vy jste si je podvědomě dotvořili ve snaze předvídat budoucí vývoj nebo řešení nějak vylepšit, a přitom vedou k potřebě větší abstrakce a komplexity.
2. Pokud obecnější řešení v daném případě nevede k nárůstu komplexity nebo náročnosti na zdroje, není důvodu omezovat se na specifikaci.
Zdůvodnění je jednoduché. V naprosté většině případů o ta vylepšení nikdo nestojí a vývoj se bude ubírat jiným směrem než si myslíte, ale jejich přítomnost velmi zkomplikuje budoucí modifikace směrem, s nímž se nepočítalo. Jednoduchá věc se dá překopat snadněji než komplikovaná.
Vyčleníte-li někde 4 bajty pro budoucí rozšíření vlastnosti X, 4 bajty pro vlastnost Y a 4 bajty pro vlastnost Z, vemte jed na to, že jich nakonec bude zapotřebí nejméně 5 pro vlastnost X a vyvstane potřeba přidat vlastnost W, co potřebuje 2 bajty, a vlastnost Y už nikdo nepotřebuje, protože děrné pásky odnesl čas. Přestože prostor k obojímu je, technicky to bude hlavolam, protože někdo před lety "myslel" víc, než bylo zdrávo. Je to jen ilustrační příklad, ale na podobné situace jsem ve svém profesionálním životě narážel neustále - komplikované hierarchie tříd, zabránění opakování stejného kódu i za cenu, že se to celé znepřehlední zbytečnými abstraktními mezičlánky a lepidly mezi nimi, jež vydají za 5x tolik kódu, než kdyby se to prostě duplikovalo apod., načež se potom ukáže, že přeci jen ten kód nebude úplně stejný, takže struktury, jež měly zamezit duplikaci kódu, se musejí obcházet a nastavovat jak kaše, protože tím okamžikem ztrácejí smysl, ale zato vydatně překážejí.
Přestože formulace je jednoduchá, realizace je náročná, protože ne každý si umí ty klapky z očí sundat a má cit pro to, co ještě ano a co už ne. Ale rozhodně by přemýšlení o takovýchto věcech měl být dáván větší prostor, než jak nejčistěji aplikovat návrhový vzor XYZ, protože jsem podlehl pocitu, že jde o zázračný všelék, který za mě vyřeší problémy. V knížce to sice vypadá elegantně, možná se to i v konkrétním případě podaří implementovat elegantně, ale jakmile bude třeba do toho trošku hrábnout, stane se z toho podobný zážitek, jako oprava traktoru typu LKT.
Nemohu než (opět) souhlasit, že návrhové vzory nejdou všelék a mnohdy nadělají víc škody než užitku. Jako i jinde mimo IT obecně platí "tonoucí (nekompetentní programátor) se stébla chytá" (a navíc se pak do krve hádá o něčem, čemu ani trošku nerozumí). Jenže s tím nic nenaděláme...
-
Lidi! Co to proboha hulíte? :D :D :D
Fluid karma - Look, green you dream. Blue, in an hour you feel new. And you can forget all about mellow yellow and ancient orange, cause hey, I'm giving you blood red. Do you bleed? I said, do you bleed? Well, then you take the Blood train. You talk to God without seeing Him. You hear His voice and you see His disciples. They appear like... like angels under a sea of black umbrellas. Angels who can see through time.
-
Zatím zde napadla pro tazatele krutá pravda: go je pomalý, protože je genderově vyvážený.
Prolítněte jak go prezentovali v ranné fázi a co bylo cílem, já si to pamatuji dost dobře.
Původně to vycházelo z Plan-9, tedy měl to být jazyk pro multiprocesorový distribuovaný systém.
A je to tady zase! Plan-9? Uz je cas? https://forum.root.cz/index.php?topic=12377.0
-
Zatím zde napadla pro tazatele krutá pravda: go je pomalý, protože je genderově vyvážený.
Prolítněte jak go prezentovali v ranné fázi a co bylo cílem, já si to pamatuji dost dobře.
Původně to vycházelo z Plan-9, tedy měl to být jazyk pro multiprocesorový distribuovaný systém.
Ano, a doteď tím trpíme - překladače se chovají divně (mají svou verzi C), asembler je taky proprietární, vše má své ABI (volání mezi Go a C musí přesypávat zásobník do registrů a vice versa), zarovnávat a přehazovat zásobník, halda není halda atd. Jinak ale naprostá pohoda...
-
Zatím zde napadla pro tazatele krutá pravda: go je pomalý, protože je genderově vyvážený.
Prolítněte jak go prezentovali v ranné fázi a co bylo cílem, já si to pamatuji dost dobře.
Původně to vycházelo z Plan-9, tedy měl to být jazyk pro multiprocesorový distribuovaný systém.
Ano, a doteď tím trpíme - překladače se chovají divně (mají svou verzi C), asembler je taky proprietární, vše má své ABI (volání mezi Go a C musí přesypávat zásobník do registrů a vice versa), zarovnávat a přehazovat zásobník, halda není halda atd. Jinak ale naprostá pohoda...
Ale to je v poradku, ne? Vsak Java byla take vymyslena a designovana do mixeru a pracek a dnes ji sotva utahne nadupany server. ;)
-
...
Ale to je v poradku, ne? Vsak Java byla take vymyslena a designovana do mixeru a pracek a dnes ji sotva utahne nadupany server. ;)
To zijete asi v jinem svete, protoze ja ctu, ze se to pouziva i ve vecech jako RaspberryPi nebo IoT a ty maji k nadupanym servrum hoodne daleko.
-
...
Ale to je v poradku, ne? Vsak Java byla take vymyslena a designovana do mixeru a pracek a dnes ji sotva utahne nadupany server. ;)
To zijete asi v jinem svete, protoze ja ctu, ze se to pouziva i ve vecech jako RaspberryPi nebo IoT a ty maji k nadupanym servrum hoodne daleko.
To byla ironie. Timto podivnym prispevkem jsem se opet vratil k puvodni otazce, proc je Go pomale. Omlouvam se, ze to nebylo pochopitelne i bez zapnuti hlavy. ;) Kdyby ne: Protoze se Go pouziva i na nenadupanych serverech, resime tady, proc je pomale. Takovy forek. A zaroven snaha o navrat k puvodni otazce.
Tak snad uz to pochopili vsichni.
-
To se omlouvam. Jsem uz zvykly na to, ze do Javy (JVM) si vsichni kopou, jak je hrozne pomala, takze na mou obranu - rozlisit ironii a trolovani ohledne Javy neni lehke. (Na rootu spis cekam trolovani :D :'(.)
-
To se omlouvam. Jsem uz zvykly na to, ze do Javy (JVM) si vsichni kopou, jak je hrozne pomala, takze na mou obranu - rozlisit ironii a trolovani ohledne Javy neni lehke. (Na rootu spis cekam trolovani :D :'(.)
... tak java jako je obecne dost pomala navic ten jazyk je hroznej ...
:}
-
Zatím zde napadla pro tazatele krutá pravda: go je pomalý, protože je genderově vyvážený.
Prolítněte jak go prezentovali v ranné fázi a co bylo cílem, já si to pamatuji dost dobře.
Původně to vycházelo z Plan-9, tedy měl to být jazyk pro multiprocesorový distribuovaný systém.
Ano, a doteď tím trpíme - překladače se chovají divně (mají svou verzi C), asembler je taky proprietární, vše má své ABI (volání mezi Go a C musí přesypávat zásobník do registrů a vice versa), zarovnávat a přehazovat zásobník, halda není halda atd. Jinak ale naprostá pohoda...
Ale to je v poradku, ne? Vsak Java byla take vymyslena a designovana do mixeru a pracek a dnes ji sotva utahne nadupany server. ;)
Až bude Java použitelná i na Arduinu, tak se stane skutečným jazykem ;)
-
To se omlouvam. Jsem uz zvykly na to, ze do Javy (JVM) si vsichni kopou, jak je hrozne pomala, takze na mou obranu - rozlisit ironii a trolovani ohledne Javy neni lehke. (Na rootu spis cekam trolovani :D :'(.)
... tak java jako je obecne dost pomala navic ten jazyk je hroznej ...
:}
Java má být jako pomalá na co? Mám zkušenost, že když jsem reimplementoval jednu funkcionalitu z IntelliJ IDE pro Javu, tak jsem dosáhl cca 1000x většího výkonu. Java není pomalá, jen se v ní píšou někdy pomalé aplikace - a možná i záměrně, prostě se to naprototypuje a pak se to nechá být, protože to výkonově stačí. Další věc jazyk samotný. Java je prostě jednoduchý jazyk, neobsahuje nějaké složité konstrukce. Podívej se někdy na bytecode. Dělal jsem nad ním jednu knihovnu a byla to jedna radost. Navíc Java má něco, co C++ nebo Go nikdy mít nebudou, jako např. Hot Swap - za běhu aplikace v debug režimu aktualizuješ zdrojový kód jejich části v JVM, tzn. nemusíš restartovat. Je to výhodné pro vývoj. Bohužel některé frameworky (Spring) tuto funkcionalitu nectí a dělají masivní inicializace bez možnosti aktualizace za běhu aplikace.
-
To se omlouvam. Jsem uz zvykly na to, ze do Javy (JVM) si vsichni kopou, jak je hrozne pomala, takze na mou obranu - rozlisit ironii a trolovani ohledne Javy neni lehke. (Na rootu spis cekam trolovani :D :'(.)
... tak java jako je obecne dost pomala navic ten jazyk je hroznej ...
:}
Java má být jako pomalá na co? Mám zkušenost, že když jsem reimplementoval jednu funkcionalitu z IntelliJ IDE pro Javu, tak jsem dosáhl cca 1000x většího výkonu. Java není pomalá, jen se v ní píšou někdy pomalé aplikace - a možná i záměrně, prostě se to naprototypuje a pak se to nechá být, protože to výkonově stačí. Další věc jazyk samotný. Java je prostě jednoduchý jazyk, neobsahuje nějaké složité konstrukce. Podívej se někdy na bytecode. Dělal jsem nad ním jednu knihovnu a byla to jedna radost. Navíc Java má něco, co C++ nebo Go nikdy mít nebudou, jako např. Hot Swap - za běhu aplikace v debug režimu aktualizuješ zdrojový kód jejich části v JVM, tzn. nemusíš restartovat. Je to výhodné pro vývoj. Bohužel některé frameworky (Spring) tuto funkcionalitu nectí a dělají masivní inicializace bez možnosti aktualizace za běhu aplikace.
V Go jde taky aktualizovat bez restartu (tuším od verze 1.7).
-
Myslim ze nie. To co myslis su asi pluginy. Existuje udelatko od facebooku, ktore dokaze restartovat server bez straty spojeni, ale to nie je to iste. HotSwap v jave vymeni classu ale zachova data (nieco ako v smalltalku). Go to nemoze urobit, lebo je kompilovane a nevie spravit deoptimalizaciu. Predstav si, ze by si chcel hotswapnut inlinovane funkcie. (teda ono sa to ciastocne da v debug rezime - visual c++ to vedelo uz v dobach win95)
-
Myslim ze nie. To co myslis su asi pluginy. Existuje udelatko od facebooku, ktore dokaze restartovat server bez straty spojeni [...]
Ano, pluginy. Go nanejvýš zvládne to, že "gracefully" ukončí server (obslouží všechna spojení) a pak ho znova spustí, ani by skončil proces, což vyjde v praxi nastejno. Jak se to "udělátko" jmenuje?
-
https://github.com/facebookgo/grace
-
https://github.com/facebookgo/grace
Merci. Koukám, že to je zhruba to, co bylo přidáno do Go 1.8 (náhoda?).
-
Jaký máte vůbec názor na Golang? Teď na něj budu v práci přecházet a na netu neslyším zrovna chválu.
Že aktuálně neznám ekvivalent. C je moc low level, v C++ je překomplikovaný relikt, Python je pomalý a nic jiného, co by se kompilovalo přímo do strojového kódy, mělo to GC a bylo to populární, tu není, jen Go.
Python spusteny nad PyPy """by se kompilovalo přímo do strojového kódy, mělo to GC a bylo to populární""".
-
...jo a Java :-) taky treba.