Google Go v příkladech 2. (diskuse)

[pht]

Hm, tenhle přístup k polymorfizmu je zjevně odvozený z ady ;) Zajímalo by mě jestli můžu v Go odvodit nový typ např. z int? A jestli Go umí double dispatch?

Jinak ty příklady nejsou moc výchovné protože ukazují dědění implementace, což je většinou nežádoucí.

[mich]

Typ z int odvodit lze (a pak k němu lze i přidávat metody). Go neumí přetížení funkcí.

[Ladicek]

Mně to z těch příkladů připadá spíš jako kompozice než jako dědičnost. Ale nečetl jsem specifikaci.

[alblaho]

Na první pohled se mi to nějak přestává líbit. Mám pocit, že vazby jsou příliš volné a nedrží to po hromadě.

Nějak jsem si oblíbil tu neskutečnou primitivnost Javy. Programování třeba v Pythonu je větší zábava, ale když má člověk udržovat kód, kde si původní autor hrál s metaprogramováním/dekorátory jiným způsobem, než je ten můj oblíbený, tak je to spíš detektivka.

Zas ale pošilhávám po Scale...

[dopisovatel]

Jedině Ruby

[Foo Bar]

To je ten jazyk, který programátoři používají tak, že mění API v knihovnách i mezi minor releases a nepřipadá jim to divné? :)

[dopisovatel]

Chceš snad tvrdit, že Ruby nemá výborný sraz příznivců v Brně?

http://www.abclinuxu.cz/zpravicky/sraz-priznivcu-ruby-v-brne

[Foo Bar]

Chci tvrdit, že medvídek kaola jede na dovolenou k mývalovi. (Toto tvrzení je relevantní asi tak stejně to první k tomu Vašemu :).

[Foo Bar]

Ale trochu na vážnou notu... přebral jsem balíkování rails pro Debian a z ruby-rchardet embedované v ruby-tmail embedované v ruby-actionpack mi fakt jde hlava kolem...

[----]

článek hezký, ale Go se mi vůbec nelíbí..

[dopisovatel]

Moje řeč... Výborná věc je Ruby.

[alblaho]

Jenže Ruby je úplně jiný typ nástroje. Dynamické typování, interpretovaný kód... Go je statické a bude výkonově někde jinde, hlavně se snaží cílit na paralelní zpracování dat.

Já mám Ruby rád, ale není to nástroj na všechno.

[Luboš Doležel (Doli)]

Ruby jsem hlavně strašně pomalé.

[Ladicek]

Což pod komentářem Ruby je úplně jiný typ nástroje … Go je statické a bude výkonově někde jinde dává obrovský smysl.

[Luboš Doležel (Doli)]

Ale ono je strašně pomalé na cokoliv. Nedovedu si představit, k čemu bych to kdy použil.

[Ladicek]

Na normální skriptování je rychlé až až (u každého shellového skriptu, který má nad deset řádek, přemýšlím, že ho přepíšu do Ruby). A zdá se, že ta spousta webů v RoR taky nějak funguje, nebo ne? (Ha, už vidím argumentaci Twitterem! )

Mimochodem, mezi Ruby 1.8 a 1.9 je obrovský výkonnostní rozdíl.

[dopisovatel]

A taky právě v Ruby byla napsána některá skvělá vylepšení pro některé distribuce. Pokud existuje Ruby, může jít všechno ostatní do háje.

[Luboš Doležel (Doli)]

(Uznávám, že jsem ten komentář nade mnou špatně přečetl)

[x.]

Zlatej Python. Tam mrknu na kod a rychle vim, co dela, k cemu slouzi. I u toho C/C++ to clovek vetsinou odhali, ale Go?? Typicka ukazka jazyka, jak nema vypadat. To neni jazyk pro lidi, ale roboty. Nebo je to programatorem-autorem, protoze zvolil nevhodne priklady?

[Sten]

Go používá hodně odlišný způsob myšlení. Taky se mi nelíbí, ale nezavrhoval bych jej, určitě si svoje příznivce najde (když to zvládlo Ruby ). Na druhou stranu to, co mi opravdu mezi jazyky chybí, je staticky typovaný jazyk (kvůli rychlosti běhu a compile-time kontrole chyb v práci s objekty) stylem podobný Pythonu (velmi jednoduchá syntaxe), ale schopnostmi blízký C++ (třeba generické programování — šablony, možnost low-level programování, logičtější přetěžování operátorů nebo vícenásobná dědičnost — Python nepotřebuje, když má duck-typing). Ano, vím, že existuje Boo, ale to je jenom pro .NET a navíc má hodně omezené schopnosti. Až budu mít čas, zkusím napsat nějaký překladač takového jazyka do C.

[alblaho]

Scala? Má dost z toho, co chceš, ale zase to asi není z nejjednodušších jazyků.

[Sten]

Hmm, to vypadá hodně dobře

[________________]

Scala teda rozhodne neni minimalistický jazayk (oproti ostatným ML jazykom je najukecanejšia).

[alblaho]

Přijde mi, že jazyk se statickým typováním vždycky bude ukecaný. Protože programátor ty typy musí nějak specifikovat. Typová inference pomůže, ale až po té specifikaci. Naproti tomu v Pythonu, Ruby je vlastně jen jeden "typ" a běhová pravidla.

[________________]

aj staticky typovaný jazyk môže byt úsporný pre porovnanie:

statická scala:

def add(a:Int, b:Int) = a + b

dynamický python:

def add(a, b): return a + b

dynamický scheme:

(define (add a b) (+ a b))

statický F#:

let add a b = a + b

na scale mi vadí hlavne ten balast zbytočné zátvorky a aj zložené zátvorky označujúce začiatok a koniec bloku, ktoré len zneprehľadňujú kód, tektiež type inference v scale nefunguje najoptimálnejšie pretože u argumentov funkcií musím tak či tak zadávať názvy typov, pritom by si ich mohol prekladač automaticky odvodiť.

[ava]

Ty závorky mi ve scale přijdou docela užitečné, nechtěl bych místo

(1 to 100).map{i => i * i}.filter{i => (i % 2) == 0} psát třeba
(1 to 100)
  .map
    i => i * i
  .filter
    i => (i % 2) == 0

nebo jak si to vlastně představuješ?

U argumentů funkcí typy dovodit nejdou, protože při překladu dané funkce nevíš, ze kterých všech modulů bude zavolaná. Nebrání to ovšem dělat generické funkce

scala> def joinStrings[T](x: T, y: T) = {x.toString + y.toString}
joinStrings: [T](x: T, y: T)java.lang.String

a tady už inference typů argumentů funguje, místo

scala> joinStrings[Int](1, 2)

klidně stačí napsat

scala> joinStrings(1, 2)
res0: java.lang.String = 12

Jinak jo, staticky typovaný jazyk může působit úsporně :)

[Ladicek]

Scala používá lokální typovou inferenci, proto je potřeba deklarovat typy argumentů. Osobně bych šel ještě dál a vynutil deklaraci i návratového typu, ale ten už Scala odvozuje. Jazyky, které používají plnohodnotnou typovou inferenci (Hindley-Milner a spol.) umí odvodit i typy argumentů.

[ava]

Asi beru tento svůj příspěvek zpět, co se týče typových systémů, jsem začátečník a tady spíše matu než osvětluji. Jak píše ládíček, je možné provádět i inferenci typů argumentů (s tím, že co je vlastně "plnohodnotná" typová inference je podle mě subjektivní, dle wikipedie např. "As of 2008, GHC, a Haskell compiler, goes beyond HM, and now uses System F extended with non-syntactic type equality, for example." - ale to už bych slovíčkařil).

Příklad s generickou funkcí joinStrings, který jsem uvedl, neukazuje na inferenci typů argumentů (lepší by bylo říci parametrů) podle těla funkce.

Pokud jsem někomu zamotal hlavu, omlouvám se :)

[________________]

>>Jak píše ládíček, je možné provádět i inferenci typů argumentů

ja to aj v praxi používam takže viem že to funguje, aj v mojom predchádzajúcom poste bola ukážka:

let add a b = a + b

ak funkcii add priradím 2 parametre rovnakého typu tak si z nich prekladač automaticky odvodí typy argumentov...

ak ale jednému argumentu priradím trebárs string a druhému trebárs integer tak prekladač vyhodí chybu. rovnako prekladač vyhodí chybu aj ked 2x zavolám funkciu v vždy s iným typom argumentov.

[alblaho]

To jsem nemyslel. Jasně že Scala umí být úsporná, vždyť se tím chvástají. Ale stejně tam musí být kód, který ty typy specifikuje. Díky typové inferenci to sice nemusíš opisovat všude, ale někde tam ten kód je.

[Ondra]

jazyk se statickým typováním vždycky bude ukecaný

rekl clovek, ktery v zivote neslysel o Haskellu...

[alblaho]

Náhodou, o Haskellu jsem přečetl celou knihu.

Haskell i Scala mohou být velmi úsporné, protože ta syntaxe je mocná a navíc je tam typová inference.

Ale zároveň to bude i "ukecané", protože nezanedbatelnou část programu bude tvořit specifikace typů. Srovnej třeba s Pythonem, kde je typ vlastně jen jeden ("slovník") a člověk to prostě jen používá.

To je můj dojem z typického používání, i v tom Pythonu je možné mít "typové" vifikundace řešící třeba AOP, DbC atd.

[Bystroushaak]

D, ale syntax je podobná C/Javě, z pythonu si to bere jen schopnosti.

[Sten]

D znám, ale mám k němu docela dost výhrad:

• chybí alespoň virtuální vícenásobná dědičnost, docela běžně to používám u výjimek, hlavně u těch vyhazovaných mixiny: ENetworkFileRead (chyba sítě při čtení souboru) dědí z EFileRead (obsahuje např. URL souboru) i ENetwork (obsahuje např. IP adresu)
• přetěžování operátorů má dost divnou syntaxi a nedovoluje použití ternární (SQL) aritmetriky, třeba a != b je automaticky !(a == b) a nelze to změnit (a přitom třeba i pro podporovaný double tohle u NaN neplatí)
• chybí podpora pro dynamicky načítané knihovny (alespoň aby fungovalo RTTI, když už nefunguje garbage collector)
• nepochopil jsem, jak jde udělat částečná inicializace šablon (jestli to jde; ve features je napsané, že to umí, v dokumentaci to ale vůbec není)
• zápis šablon mi přišel poněkud zmatený, protože se velmi podobný zápis používá pro imperativní i generické programování (ale pro někoho to může být výhoda)

[vladaf]

Vícenásobná dědičnost je právě vlastnost, které se v moderních jazycích snaží vyhýbat po otřesné zkušenosti z C++. Třeba autoři Fortranu 2003 to říkají zcela explicitně a u D to nejspíš nebude jiné, protože je to takové C++ done right.

[pht]

protože je to takové C++ done right.

To mi připomíná Linusovu hlášku o tom, že SVN je "CVS done right" ...

[----]

ale však ono je :) A D opravdu je "C++ done right"

[alblaho]

Btw, "CVS dnone right" není Linusova hláška, ale přímo moto Subversion. A je to dost přesné, SVN je oproti CVS poklad, ale v porovnání s Gitem neobstojí. Proto se tomu Linus posmíval.

Vícenásobná dědičnost v C++ je fakt zlo .

[----]

jojo, Git je prostě nejlepší

[pht]

Btw, "CVS dnone right" není Linusova hláška, ale přímo moto Subversion. A je to dost přesné, SVN je oproti CVS poklad, ale v porovnání s Gitem neobstojí. Proto se tomu Linus posmíval.

"Posmíval" není asi to pravé. Ta citace zní: if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right. Což je přesně jak já to vidím s C++, není jak ho "udělat dobře", špatné jsou už ty koncepty za tím. Nejlepší je se na to kompletně vykašlat a udělat to celé jinak, nejlépe přesně naopak. (Analogicky k Take CVS as an example of what not to do; if in doubt, make the exact opposite decision.)

[----]

No, zrovna to D je perfektní jazyk, koncepčně dost dobře vymyšlený, bere určitý koncepce z Javy, určitý z Cčka a C++ a přidává své vlastní a výsledek je dobrý; zato C++ je občas designovaný dost hrozně a jediný způsob, jakým ho využívám je "Cčko s objekty"

[pht]

zrovna to D je perfektní jazyk

Za prvé nic takového neexistuje - existují jen jazyky které jsou nepoužitelné, a méně nepoužitelné... a za druhé, který případ nastal z těchto dvou se uvidí až tak za 10 let, jak u Go, tak u D. (U C++ už se vidí :P )

[----]

pojmem "perfektní jazyk" myslím dobře navržený jazyk s dobrou použitelností

[:::]

Což je přesně jak já to vidím s C++, není jak ho "udělat dobře", špatné jsou už ty koncepty za tím.

to ze necemu nerozumis neznamena ze je to spatne

[----]

Ale ono to špatně je.

[:::]

nerad bych se opakoval :)

[----]

jojo, C++ fanboys to nikdy neuznají

[:::]

nene, ale C++ haters to nikdy neuznaji

[----]

já nejsem hater, C++ používám Jen nepoužívám stdlib, exceptions, multiple inheritance

[pht]

to ze necemu nerozumis neznamena ze je to spatne

To samozřejmě ne, ale oba jevy najednou nastat můžou. A to je právě případ C++.

[Sten]

Zajímavý, že třeba v té Scale vícenásobná dědičnost je a bez těch problémů (pomocí mixinů), co má C++. Takže D to má spíše stylem „nevíme, jak to rozumně udělat, tak to prohlásíme za vlastnost, která není potřeba/je špatná/se nedá implementovat/...“

[Jablíčko]

Přijde mi, že asi hledáš právě Go (až na ty generiky). Dokonce bych řekl, že Go duck-typing povyšuje na další úroveň (je to teda ještě pořád o trochu nižší level než mají některý funkcionální jazyky, viz například typový třídy v Haskellu).

[Freeman]

Já se také přikláním k Pythonu, nicméně mě na Goo těší, že tam nejsou středníky a dolary

[________________]

mám jednu otázku na autora článku:

panic("<img alt="" class="emo" src="/images/smile/smutek.gif" />")

ako prekladač jazyka zistí kde končí reťazec keď aj vo vnúti reťazca sa používa znak ukončenia reťazca bez escapovania?

[Luboš Doležel (Doli)]

Dal jsem do kódu jiného smajlíka. Je zjevné, že engine Ábíčka nahrazuje sekvenci "" obrázkem...