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

[...]

Zaujimavy pohlad: http://www.lessonsoffailure.com/software/google-go-good-for-nothing/

[vlastagf]

Mně se ze začátku Go vůbec nelíbilo, ale na druhou stranu jsem před pár dny nahodil kompilátor a když je čas, tak koukám na tutoriály. Co se mi moc líbí a rozčiluje mně na C++.

a) implicitní konverze, proč tohle vůbec někoho napadlo? je to úplně proti duchu C++, kde si programátor všechno hlídá sám

b) neuvěřitelně pomalá kompilace - píšu teď něco většího nad msvc, linkuju pár knihoven a je to děs

c) dynamické linkování 1) možná to šetří místo v paměti, když víc aplikací používá stejnou knihovnu, ale jedna může s novější verzí přestat fungovat 2) dá se upravit aplikace jen updatem knihovny, ale stejně jednoduše se dá rebuildnout

d) ta paralelizace vypadá dobře, člověk má uplně chuť to tak psát, v C++ jsem zkoušel TBB a Boost::Thread a nedá se to srovnat

e) líbí se mi kopírování hodnotou, to se mi zas nikdy nelíbilo na Jávě a C#

z) ale nelíbí se mi pevné formátování, to jsem nesnášel u Haskellu, nemám to rád u Pythonu a nebudu to mít rád ani tady. a ke všemu to asi udělali jen kvůli rychlejšímu parsování a jednodušší podpoře interpretování

y) a kdyby se dal občas vypnout GC a člověk by po sobě uklízel sám, to bych se taky nezlobil, nemluvě o podpoře assembleru

[jnml]

y) a kdyby se dal občas vypnout GC a člověk by po sobě uklízel sám, to bych se taky nezlobil, nemluvě o podpoře assembleru

Tělo Go funkce může být (externě) napsáno v assembleru.
Specs: Function declarations
Příklad: src/pkg/big

[Ondřej Surý]

Ad C) od toho máme v rozumných systémech SONAME a rozumní autoři knihoven jej i používají.

[Ivan]

Popripade jeste existuje verzovani symbolu vramci jedne knihovny.

[Ondřej Surý]

Pravda na to jsem úplně zapomněl a při tom to v Debianních balíčcích docela používám... Akorát ještě aby to taky používali autoři knihoven :(

[vain]

Hm.. tak v tom číst tedy neumím. Když se podívám na C++, C#, Javu, Python apod... tak chápu o co jde a co znamená co, ale tohle je humáč

[salam]

Nesnáším otevírací závorku na konci řádku, zhoršuje to výrazně přehlednost a neplní základní funkci - otevírací a zavírací závorka jsou ve stejném sloupci (to při velkém zanoření dost pomáhá). S tímto zápisem jde o python

[Solitary]

Nesouhlasim, dle meho jde o dost subjektivni nazor... pokud nejsi prase a odsazujes (nemusi jit o Python, spravne odsazovat by se melo ve vsech jazycich), tak ve stejnem sloupci jako uzaviraci zavorka bude radek kde zacina dana metoda. Oteviraci zavorka na konci radku je pak nepodstatna a usetris radek v kodu. Naopak, na novem radku, ji zase nesnasim ja, dle meho to prehlednosti neprida (pribude radek) a navic to vytvari dojem, ze dana metoda k bloku nepatri.

[Bystroushaak]

Pod tohle se můžu podepsat, mám úplně stejný názor.

[vain]

Také souhlas.

[salam]

Ano, když něco nesnáším, jde o můj subjektivní názor - to snad není třeba komentovat...

Já často spojuji velké bloky zdrojáků z různých zdrojů a časů a tam přeskok na párovou závorku a letmá kontrola čísla sloupce hodně pomáhá, používám to prakticky denně. A dále - pokud je řádek delší než zobrazený text, pak se tato závorka dostane mimo obrazovku a já pak musím při vizuální kontrole spoléhat na to, že to je dobře odsazené. Jenže pokud se ke mne dostane zdroják, kde jsou mixované tabulátory a mezery a já mám tabulátory nastavené na jinou hodnotu než autor... Prostě python

To ušetření volného řádku nějak nechápu - co přesně se tím ušetří? Možná na malém monitoru, rozlišení.. No a ten dojem, že řádky následující za začátkem bloku do něj nepatří, tak to bude nejspíš ten 'dost subjektivní názor'

[Bystroushaak]

No a ten dojem, že řádky následující za začátkem bloku do něj nepatří, tak to bude nejspíš ten 'dost subjektivní názor'

No, to jo, ale když vidím tu závorku na novém řádku, působí to nemocně.

Jinak ať žije autoformater :)

[salam]

Pro mě je nemocná ta 'schovaná' a "nepodstatná" závorka, která tak ztrácí část své funkčnosti. Ale určitě souhlasím, že čtení je věc zvyku. Problém je v tom, že ve své práci jsem ten autoformater často já sám.

Tonocí ve zdrojáku se i závorky chytá...

[Solitary]

Nekomentoval jsem tvuj nazor, ze je subjektivni (ten samozrejme je), ale to, ze nahled na danou problematiku je vzdy subjektivni a kazdy se k tomu stavi jinak. Kdyz mas kod tak dlouhy, ze presahuje sirku obrazovky, tak by mozna bylo na miste ho rozlozit na vic radku... ono kdyz neni videt kus kodu, tak se to cte blbe tak ci onak. Hlavni duvod, proc si myslim, ze je lepsi davat zavorku hned za danou metodu je ten, ze je jasne, ze ten blok kodu k tomu patri a nejde o nejaky samostatny blok.
if(true) do();
{
//blok kodu
}
A presne v tuhle chvili by dle meho bylo velmi snadne treba prehlidnout nenapadnou metodu do() a myslet si, ze ten blok patri k podmince (zrovna treba ten pripad, kdy by vyraz v podmince byl delsi nez je sirka monitoru). Je to extrem, ale je to vec, ktera me vadi :) navic ta rozlezlost - ten radek navic me proste irituje :) je takovy chudak opusteny a vypada to, ze se k nicemu nevaze... (v tomto pripade se opravdu nevaze, a pokud bys prehledl do() tak si toho tak lehce nevsimnes)

[Roger]

Tohle resi

if (true)
  do();

prip. rovnou

if (true)
{
  do();
}

coz dost pomaha, pokud nechcete hledat nahodnou chybu ve ctyri rano pred odevzdanim...

[Solitary]

Tak samozrejme... osobne pouzivam novy radek a i zavorky u techto jednoduchych vyrazu (az na vyjimky, kdy jsem rozmarny ale nikdy na ukor prehlednosti), byl to jen pripad, ktery by mohl nastat a pri tomto zapisu byt problematicky. Ono totiz ne vzdy musime cist kod, ktery jsme sami napsali, a pokud nekdo pise takto a udela neco podobneho, tak muze byt problem na svete. V pripade zapisu s oteviraci zavorkou na konci vyrazu to prakticky nehrozi.

[Roger]

Jo, s tim blokem u ifu to byla vlastni (horka) zkusenost - kolega napsal

if (neco) { blok; } else prikaz;

a pak chtel pred prikaz doplnit ladici vypis, ale zapomnel puvodni prikaz u else dat do bloku, takze vypadl mimo if/else :( Od te doby jsem opatrny, a - kdyz nejsem rozmarny :) - radeji zavorkuju kde co.

Taky, pokud treba odnekud kopiruju jen kus kodu a neupravuju cizi projekt, pouzivam formatovani v editoru - pak mam jakz-takz jistotu, ze se v tom da vyznat.

Na druhou stranu - treba v jave pisu zavorky na konec, tam je to standard (a NB to tak automaticky formatuji :) ). Naopak MSVS formatuje tak, jak popisuju nahore.

Zatim jsem se z toho jeste nezblaznil. Aspon myslim :)

[vlk]

takze v praci asi budes plateny od poctu riadkov, ze?

[__dark__]

Každý normální programátor by před tu složenou dal mezeru. Ten váš výpis mi připadá spíš jako nějaký výstup z autoformateru, který nepřemýšlí (mimochodem normální programátor snad autoformát ani nepotřebuje). Já osobně mám rád složené závorky na samostatný řádek - nikdy mi nepřekážel větší kód, který je čitelný.

[salam]

Pokud někdo formátuje zdroják takto, pak je jen na místě, aby si problémy s tím spojené pěkně odladil. Nepamatuji si ale, že bych při práci někdy viděl něco podobného v takové pozici, že by to znamenalo programátorovu chybu. Samozřejmě, že tam pro lepší čitelnost patří odřádkování a klidně bych uvítal komentář, proč je tam ten extra blok.

Já, když už při své práci více zasahuju do cizího kódu (oprava chyby), tak ho většinou poměrně dost lokálně asimiluju a tuhle (pozor nasleduje subjektivní názor ) chybu formátování okamžitě opravuju, stejně jako závorky na konci řádků, velmi dlouhé řádky (to si okamžitě zvětším okno, případně zmenším písmo), chybějící odřádkování, někdy dokonce absence formátování...

Dělám v týmu, ve kterém převážně vždy dodržujeme několik jednoduchých pravidel. Jedno z nich je primitivní: za if, for, while... se nemá schovávat NIC.

Mini anketa: já mám běžně nastavenou velikost okna tak, že vidím ze zdrojáku 50 řádků po 150 znacích. Kolik máte vy?

[Ondřej Surý]

Koukám, že se svět stále nezbořil a komentáře pod článkem o Go stále ve většině případů nejsou ani trochu blízko obsahu článku.

Ale je pravda, že zatím mi tady chybí 'D'.