Byla vydána verze 0.81 telnet a ssh klienta PuTTY. Opravena je kritická bezpečnostní chyba CVE-2024-31497 obsažena ve verzích 0.68 až 0.80. Používáte-li klíč ECDSA NIST P521 a použili jste jej v PuTTY nebo Pageantu, považujte jej za kompromitovaný.
Hra MineClone2 postavena nad voxelovým herním enginem Minetest byla přejmenována na VoxeLibre.
Společnosti Avast Software s.r.o. byla pravomocně uložena pokuta ve výši 351 milionů Kč. Tu uložil Úřad pro ochranu osobních údajů za neoprávněné zpracování osobních údajů uživatelů jejího antivirového programu Avast a jeho rozšíření internetových prohlížečů (Browser Extensions), k čemuž docházelo prokazatelně po část roku 2019.
… více »Bylo vydáno do češtiny přeložené číslo 714 týdeníku WeeklyOSM přinášející zprávy ze světa OpenStreetMap.
V sobotu 20. dubna lze navštívit Maker Faire Jihlava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Knihovna pro potlačení šumu RNNoise byla vydána ve verzi 0.2. Kvalitu potlačení lze vyzkoušet na webovém demu.
FRRouting (FRR) (Wikipedie), tj. softwarová sada pro směrování síťové komunikace, fork Quagga, byl vydán ve verzi 10.0.
Julian Andres Klode vydal APT (Advanced Packaging Tool) ve verzích 2.9.0 a 2.9.1. Jedná se o vývojové verze nové větve APT 3.0. Vylepšuje se uživatelské rozhraní. Přidány byly barvičky. Aktuální náhledy a vývoj lze sledovat na Mastodonu.
Miguel de Icaza se na svém blogu rozepsal o vložitelných herních enginech. Kdysi slibné projekty UrhoSharp a Urho3D jsou již mrtvé. Zůstává Godot. Aktuálně vývojáři řeší Pull request #90510 s návrhem knihovny LibGodot.
Byla vydána nová verze 5.0 linuxové distribuce Lakka, jež umožňuje transformovat podporované počítače v herní konzole. Nejnovější Lakka přichází s RetroArchem 1.17.0.
Společnost Google představila veřejně svůj jazyk Go o trochu víc než před rokem, v listopadu 2009. Mezi autory jazyka patří např. Rob Pike nebo „otec zakladatel“ Unixu Ken Thompson. Na oficiální domovské stránce jazyka Go je k nalezení mnoho užitečných informací jako třeba několik různě pokročilých tutoriálů, odkazy na prezentace a blog, kompletní formální specifikace jazyka, apod.
U oné specifikace je snad zajímavé poznamenat, že se vejde na sice trochu delší, ale přece jen jednu webovou stránku. Nejde ani tolik o rozsah, ale spíše o to, že specifikace Go, což není úplně obvyklé, je určena pro čtení a studium programátora a nahrazuje tak i něco ve stylu „referenční příručky jazyka“, která u jiných programovacích jazyků typicky nemá, či obvykle nemívá, úplnost specifikace. Z uvedeného plyne téměř nutně, že definice syntaxe i sémantiky jazyka Go je poměrně pravidelná, obsahuje jen málo základních konceptů, které jsou ale navrženy tak, aby při kompozici složitějších, leč často se vyskytujících konstrukcí, pokud možno žádný podstatný nechyběl.
Pokud navštívíte výše zmiňovanou domovskou stránku Go, tak v tom momentě ve skutečnosti využíváte aplikaci godoc, která je určena pro práci s dokumentací zdrojových kódů Go z příkazové řádky, ale umí se chovat i jako i webový server. Přestože jeden z autorů jazyka loni potvrdil, že Go se v rámci společnosti Google používá pro opravdové nasazení, je webový server Go domovské stránky jedinou takovou konkrétně potvrzenou a známou aplikací.
Následující text, dnes jen jeho první část, je míněn jako letmé shrnutí pro programátory a částečně jako snad užitečný rozcestník. Podrobnější informace, ukázky kódu atd. viz odkazy na domovské stránce Go.
Go je imperativní (neboli též procedurální) programovací jazyk, podobně jako třeba C, Java, Pascal, Basic, ... Program v Go je sadou příkazů, které mění stav procesu/aplikace. Na opačné straně pomyslné hranice tohoto rozdělení stojí více či méně čistě funkční programovací jazyky z nichž mezi ty dobře známé patří např. LISP.
Logika rozhodování, která se používá třeba u příkazů if, for, je standardní booleovská, tedy dvouhodnotová a Go se zde opět drží v tradičních mezích výše uvedené rodiny typických procedurálních jazyků.
Hodnoty s typem funkce (ukazatel na funkci) jsou v Go objekty první kategorie:
Do Go by díky tomu nemělo být zas až tak těžké přepsat implementaci některých algoritmů, které jsou ve funkčních programovacích jazycích někdy mnohem kratší a/nebo elegantnější v zápisu.
Gramatika jazyka Go je navržena s cílem minimalizovat kód a maximalizovat jeho čitelnost (to druhé je samozřejmě z definice čistě subjektivní kategorie, přesto vděčný zdroj četných flame wars). Součástí distribuce je nástroj pro standardní formátování kódu: http://golang.org/cmd/gofmt/ a http://research.swtch.com/2009/12/gofmt.html.
Bloková struktura, tj. příkaz sestávající z libovolného počtu jiných příkazů, je stejná jako v C nebo Javě, tedy je uzavřena ve složených závorkách. Příkazy se ukončují středníkem (opět jako v C). Určitě příjemné pro programátora je, že v naprosté většině míst lze ukončovací středník ze zápisu vypustit. Jistou daní za takové pohodlí je nutnost dodržení některých konvencí. Odměnou za jejich respektování je pak to, že kompilátor automaticky vloží středníky na správná místa.
Deklarace typů nejsou ve stylu C. Používají se sice C ukazatelové konvence (*) avšak s pořadím převážně jako v Pascalu a dalších jazyků z dílny profesora N. Wirtha. Důvodem je i v tomto případě zlepšení čitelnosti. Ano, jistě je to opět subjektivní záležitost, ale tentokráte podpořená i trochou teorie. Byla by jistě škoda na konci právě odkazovaného článku přehlédnout jeho úplně poslední odkaz. Tam se totiž dozvíte, proč se programátorovi při čtení deklarací typů v Go hlava nezatočí. Doufám, že mi laskaví příznivci jazyka C prominou.
Vývojářský tým Go uvolňuje nová vydání obvykle každý týden nebo jednou za dva týdny a vydané verze lze označit za docela stabilní. Množství nacházených chyb je myslím přiměřené rozsahu projektu, jejich odstraňování bývá docela rychlé. Zázemí velké společnosti se na vlastnostech vývoje tohoto open source projektu projevuje nesporně příznivě.
Přesto Go ještě není určeno pro produkční nasazení. Důvodem je jiná nestabilita a to jazyka jako takového. Při svém výslovně uváděném a zdůrazňovaném experimentálním statusu si autoři Go zatím mohou dovolit zasahovat do definice jazyka i způsoby, které nejsou zpětně kompatibilní s existujícím kódem třetích stran. V silně aktivní diskuzní skupině Go se návrhy na některé úpravy probírají prakticky denně a autoři jazyka občas výslovně uvádějí úmysl a/nebo ochotu měnit jej k lepšímu i za cenu „rozbití“ staršího kódu, pokud nabudou přesvědčení o účelnosti takové změny. K odhadem asi minimálně tuctu takových změn již za krátkou historii jazyka i skutečně došlo.
Asi nejvýznamnější zpětně nekompatibilní změnou jazyka Go bylo opuštění původní zcela volné podoby (free form) zápisu kódu. Bylo to ovšem výměnou za novou možnost nepsat téměř žádné středníky ukončující příkazy (viz předchozí kapitola „Syntaxe“). Free form zápis, tak jak je znám u jazyků C, Java nebo třeba Pascal, dovoluje libovolně formátovat kód pomocí oddělujících „bílých“ znaků. Typicky to jsou mezery, tabulátory, konce řádků, ale také komentáře, pokud nemají hodnotu z pohledu sémantiky programu.
Změna směrem k omezení úplně volné formy byla velká a úměrné tomu byly zpočátku i vášně většiny lidí o ní diskutujících. Z „historického“ pohledu je docela zajímavý první příspěvek Roba Pikea ve vláknu, ve kterém ohlašuje úmysl vývojářů změnu uskutečnit a přidává podrobný pohled na to, co všechno se tím změní. Jazyk kupříkladu přišel o možnost automatického spojování sousedících řetězců (tak jako v C). To dle debat nevadilo skoro nikomu. Nadále už také nebylo dle návrhu možné rozdělovat (dlouhé) výrazy s binárními operátory kdekoli, ale pouze tak, že operátor v takovém případě musí „viset“ na konci řádku. Pokud by jím, jak bylo dříve možné, začínal až řádek následující, opět by došlo k automatickému vložení ukončovacího středníku a původní kód by nešel dále kompilovat. Nejhorší možný případ by ovšem byl, pokud by stávající kód i nadále kompilovat šel, jen s tichou změnou sémantiky programu. I tuto katastrofickou variantu Rob ve svém návrhu bere do úvahy. Ale ani „nesvobodné“ umísťování operátorů, čárek oddělujících položky seznamu apod. nedokázaly dohromady vyvolat a dodnes občas vyvolávat bouře. Přitom jde ve skutečnosti opravdu jen o pouhý zvyk. Kdo tuší, že řeč je o „brace style“, tak to odhadl naprosto správně.
V dnešní podobě Go (už) nemáte možnost, napsat otevírací složenou závorku bloku, kterou začíná tělo funkce nebo např. složený příkaz po if kdekoli jinde než na stejném řádku jako je hlavička funkce nebo příkaz. A řekněme, že odhadem polovina z desítky (nebo snad desítek?) běžně se vyskytujících stylů psaní složených závorek je má přitom až na řádce následující. Výsledkem třaskavého mixu těchto dvou skutečností bylo, že někteří členové diskuzní skupiny golang-nuts protestně páchali virtuální, závorkově rituální sebevraždy. Považovali mj. totiž za nezbytně nutné oznámit všem ostatním několika tisícům odběratelům této e‑mailové konference, že s Go kvůli této změně navždy, neodvolatelně a do smrti končí. R.I.P.
Pro otrlé zvědavce ukázka mezní (ze strany odpůrce nových omezujících pravidel) vyhrocenosti debaty na vývojářské konferenci mezi autory jazyka a autorem implementace navrhované změny, která měla opětně dovolit psát alespoň částečně free form Go.
Pro překlad jazyka Go jsou k dispozici různé kompilátory, pojmenované dle konvencí Plan9, tj. podle cílové instrukční sady procesoru – 5g (ARM), 6g(AMD64) a 8g(386), souhrnně se jim říká také „gc“. K nim příslušejí další nástroje (linkovací programy 5l, 6l, 8l, assemblery, 5a, 6a, 8a atd.). Kromě požadovaného procesoru samozřejmě kompilátor ještě musí vědět na kterém operačním systému má být vytvořená binární aplikace spouštěna. Oficiální distribuce Go podporuje zatím tyto kombinace OS a procesoru:
Používání knihoven vytvořených jinými kompilátory v C ABI umožňuje nástroj cgo. Je možné z Go volat funkce C knihoven a možná jsou i zpětná volání Go funkcí z C knihovny (callbacks). Tato obousměrná interakce je trochu ztížena přepínáním zásobníků a vláken na hranici Go a C světů, takže se hodí nejlépe tam, kde C kód vykonává relativně hodně činnosti v porovnání s ne zcela zanedbatelnou režií přepnutí. Vhodný příklad je třeba využití libgtk, nevhodným je pak jakákoli často volaná lineárně prováděná C funkce v rozsahu pár desítek řádků.
Postup pro získání celého Go zdrojového stromu, sestavení a provoz uvedených kompilátorů, resp. celého řetězce „gc“ nástrojů je na webu golang.org.
Další implementací kompilátoru jazyka Go je gccgo, což je nový Go frontend pro GNU gcc v blížícím se vydání 4.6. Gccgo umožňuje za určitých okolností přímou vazbu deklarací a přímé volání mezi Go a C kódem, tedy s menší režií než „gc“ kompilátory. Bližší podrobnosti k této problematice jsou uvedeny v sekci „C Interoperability“ návodu pro získání gccgo zdrojové větve gcc, sestavení a provoz gccgo.
Gccgo překladem Go zdrojového kódu do vnitřní reprezentace gcc získává pro Go potenciálně všechny cílové platformy gcc. To byla ta dobrá zpráva. Na druhé straně se za to zatím platí třeba i tím, že kód z gccgo používá pro gorutiny NPTL vlákna. Hodí se tedy lépe pro problémy, které jsou implementovány s omezeným počtem gorutin. Vlákna mají o hodně větší nároky na paměť i na přepnutí než gorutiny, podrobněji se o tom dozvíte v druhé části článku.
Jazyk svým návrhem nijak nebrání implementaci obou možností. Naopak by se dalo říct, že v obou případech jsou některé vlastnosti Go výhodné. Např.:
Implementace poskytovaná společností Google je kompilovaná do nativního kódu se statickým linkováním (přinejmenším v případě „gc“ kompilátorů 6g,...). Součástí distribuce je také modul interpretru, který ale ještě neimplementuje celý jazyk. Jak je možné, že po roce od prvního vydání (modul eval je v Go od prvního vydání) je tento modul stále ještě nehotový? O pár řádků výše se hovoří o nepřítomnosti direktiv, maker a podobných konstrukcí v Go. Nepřímý důsledek toho je, že v Go tedy neexistují a existovat ani nemohou žádné hlavičkové soubory (dívám se na tebe, Cčko). Neexistují-li hlavičkové soubory, je pohodlná cesta pro modulární kompilaci přes přítomnost exportovaných definicí v objektovém kódu (v angličtině „object code“, který nemá nic společného s objektovým programováním, viz též Wikipedii). To není žádná novinka, třeba Delphi se svými .dcu soubory dělá přesné totéž už hezkou řádku let. Odměnou za definice, jejichž import při kompilaci nevyžaduje syntaktickou analýzu textu, případné opětné vytváření AST a interpretaci jeho sémantiky, je rychlost kompilace.
Pokud v Go program A importuje modul B, který importuje modul C, pak zkompilovaný objektový kód modulu C obsahuje všechny exportované entity modulu C. To je zatím celkem standardní záležitost. Zkompilovaný objektový kód modulu B obsahuje totéž pro B, ale i všechny entity z C, které jsou přes B také viditelné. Například v B je exportovaná funkce, která vrací hodnotu typu, který je exportován z C. Program A nemusí C importovat vůbec, ale při kompilaci A, se objektový kód C použije až pro sestavení/linkování. Pro vytvoření objektového kódu A není objektový kód C potřeba (navíc si představme A jako levou rekurzi celé situace). Vynechány teď byly některé implementační detaily, které kontrolují třeba verzování apod., protože se dostáváme k důležitému poznatku. Pokud kompilujeme modul/program, který importuje N jiných modulů, kompilátor potřebuje: a) jen binární resp. strojově formátovaná data b) jen z N dalších modulů. Například v C a C++ jde přitom o N kořenů stromů závislostí na dalších zdrojových souborech pomocí #include a v nich dále vnořených #include atd. Náročnost zpracování takového stromu při kompilaci může snadno růst exponenciálně s velikostí projektu. V Go nejde o strom, ale o vektor a je zaručen nejvýše lineární růst složitosti kompilace.
Tím se konečně dostáváme k odpovědi na otázku o pár odstavců výše. Typická doba kompilace Go modulu na obyčejném počítači je pod 100 ms, typická doba sestavení Go programu je pod 1 sekundu. Kompilace programátory v Go zdržuje tak málo, že tlak na dokončení oficiálního interpretru je malý. I v hypotetické aplikaci používající Go jako skriptovací jazyk je dobře představitelné Go „skript“ bleskově on-demand zkompilovat před jeho „interpretací“.
Dnešní téma bylo větším dílem pohled na Go jako takové a jeho konkrétní implementace. V příští části se zase naopak dostaneme více k přehledu o samotnému programování v Go, tedy například jaké typy, hodnoty a konstrukce s ním lze vytvářet, co by na něm kodéra asi mělo nebo možná mohlo zaujmout. Například co chtěl básník říci sloganem v záhlaví článku.
Jan Mercl a Ondřej Surý pracují v Laboratořích CZ.NIC, výzkumném a vývojovém centru správce české národní domény.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
14.1.2011 10:14
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
20.1.2011 07:30
Bedňa | skóre: 34
| blog: Žumpa
| Horňany
Vítejte na stránkách které si kladou za cíl poskytovat v češtině informace o programovacím jazyku D.
13.1.2011 12:59
alblaho | skóre: 17
| blog: alblog
az do momentu, ked ho ide vykonat.no to je jaksi vlastnost interpretovanych jazykov kolega. svojim sposobom silne typy a kompilacne chyby su implicitne unit testy, ktore nemusite robit.
Skor by som povedal, ze to je vlastnost iba urciteho (relativne maleho) poctu programov napisanych v dynamickom jazyku. Rozhodne to nie je vlastnost vsetkych programov, dokonca v realnom svete to nie je ani vlastnost vacsiny programov. To, ci program pre svoje fungovanie nutne potrebuje dynamicke crty Pythonu, je vlastnost toho konkretneho programu. Neprijemna zaludnost Pythonu z tohto pohladu je, ze Python dynamickost *vnucuje* aj programom, ktore tu dynamickost vobec nepotrebuju (a takych programov v Pythone, ktore to nepotrebuju, je vacsina).az do momentu, ked ho ide vykonat.no to je jaksi vlastnost interpretovanych jazykov kolega.
Neprijemna zaludnost Pythonu z tohto pohladu je, ze Python dynamickost *vnucuje* aj programom, ktore tu dynamickost vobec nepotrebuju (a takych programov v Pythone, ktore to nepotrebuju, je vacsina).Lol, vetsih hovadinu jsem letos necetl. Hned archivuju, at se mame nad cim s kolegy bavit :D Proste lol
Ocividne Ste sa ani len naznakom nesnazili pochopit, co som tym myslel. Gratulujem, len tak dalej.Neprijemna zaludnost Pythonu z tohto pohladu je, ze Python dynamickost *vnucuje* aj programom, ktore tu dynamickost vobec nepotrebuju (a takych programov v Pythone, ktore to nepotrebuju, je vacsina).Lol, vetsih hovadinu jsem letos necetl. Hned archivuju, at se mame nad cim s kolegy bavit :D Proste lol
13.1.2011 13:42
alblaho | skóre: 17
| blog: alblog
14.1.2011 01:40
grubber | skóre: 6
| blog: grubber
| Břeclav / Brno
13.1.2011 12:55
alblaho | skóre: 17
| blog: alblog
... neviem, ako to popisat, tak aby to bolo zrozumitelne, ide mi len o to, ze python mi dovoluje "prasit", netlaci ma do prisnej povinne logickej struktury (ktora moze byt logicka pre designerov jazyka, ale nemusi byt logicka pre mna), ale mi ponechava slobodu...Zaujimalo by ma, kolko programovacich jazykov Ste sam osobne vytvorili alebo pomohli vytvorit, ked tych designerov tak kritizujete.
styri ;) z toho dva sa komercne vyuzivaju... takze tudy cesta nevede :(Zaujimave. Napriek tomu, myslim, ze by tadialto mohla ta cesta predsa len viest ... A su to vsetko interpretovane dynamicke jazyky bez typoveho systemu? A su to vsetko general-purpose jazyky, alebo special-purpose? Podla mojho nazoru (a skusenosti), staticky typovany general-purpose jazyk s kompilatorom si vyzaduje niekolko rokov prace. (Napriklad: jazyk Go je vo vyvoji cca 2-3 roky.) Aky algoritmus pre alokaciu CPU registrov Ste pouzivali?
Aky algoritmus pre alokaciu CPU registrov Ste pouzivali?Tohle bych vůbec neřešil a použil bych cizí backend.
[Python ma] netlaci do prisnej povinne logickej struktury (ktora moze byt logicka pre designerov jazyka, ale nemusi byt logicka pre mna)Tejto vete vobec nerozumiem. Napriklad Python neumoznuje programatorovi explicitne specifikovat rozmiestnenie dat v pamati pocitaca. V niektorych situaciach to moze byt na obtiaz, a moze to tlacit programatora do pozicie, v ktorej by sa radsej nenachadzal. Dali by sa najst aj dalsie obmedzujuce vlastnosti jazyka Python (nema double-dispatch pre binarne operacie, Python interpretere nie su (z dost dobreho dovodu) napisane v Pythone, atd). Zoznam veci, ktore Python programatorovi neumoznuje vyjadrit, a veci ktore z urciteho dovodu nie je vhodne implementovat v Pythone alebo pre Python, je dostatocne dlhy. Vyhlasenia ako "Python ma netlaci do prisnej povinne logickej struktury" sa mi zdaju prilis silne na to, aby som im uveril. PS: Preferujem staticky typovane jazyky, a mam silny odpor k redundandnemu vykonavaniu CPU instrukcii (je jedno ci z dovodu pomaleho algoritmu alebo pomaleho programovacieho jazyka).
Napriklad Python neumoznuje programatorovi explicitne specifikovat rozmiestnenie dat v pamati pocitaca. V niektorych situaciach to moze byt na obtiaz, a moze to tlacit programatora do pozicie, v ktorej by sa radsej nenachadzal.tak rekni rovnou, ze python je k nicemu, protoze to neni C++
Python interpretere nie su (z dost dobreho dovodu) napisane v Pythone, atd).pypy
PS: Preferujem staticky typovane jazyky, a mam silny odpor k redundandnemu vykonavaniu CPU instrukcii (je jedno ci z dovodu pomaleho algoritmu alebo pomaleho programovacieho jazyka).to musi byt pekne nudne programovani.
13.1.2011 20:46
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
to musi byt pekne nudne programovani.Mno, spíš zodpovědné.
14.1.2011 01:38
grubber | skóre: 6
| blog: grubber
| Břeclav / Brno
Tejto vete vobec nerozumiem. Napriklad Python neumoznuje programatorovi explicitne specifikovat rozmiestnenie dat v pamati pocitaca. V niektorych situaciach to moze byt na obtiaz, a moze to tlacit programatora do pozicie, v ktorej by sa radsej nenachadzal.Když je programátor idiot a neumí si pro danou úlohu správně zvolit jazyk, dobře mu tak.
Dali by sa najst aj dalsie obmedzujuce vlastnosti jazyka Python (nema double-dispatch pre binarne operacie, Python interpretere nie su (z dost dobreho dovodu) napisane v Pythone, atd).Double dispatch je v Pythonu možný, i když není součástí jazyka. Interpret Pythonu napsaný v Pythonu existuje. Nejdřív by sis měl o tématu něco nastudovat, než začneš plácat blbosti.
Zoznam veci, ktore Python programatorovi neumoznuje vyjadrit, a veci ktore z urciteho dovodu nie je vhodne implementovat v Pythone alebo pre Python, je dostatocne dlhy.To se dá prohlásit o libovolném programovacím jazyce.
Zabudli Ste poznamenat, ze transformacia PyPy (predpokladam, ze myslite PyPy) interpretera do C trva asi tak pol dna a zaberie viac pamate ako je adresny priestor 32-bitoveho CPU. Toto nie su dva "dost dobre dovody", preco Python interpreter NIE je vhodne implementovat v Pythone? Inac, proti implementovaniu Pythona v Pythone nemam vyhrady. Ked problem takehoto typu niekoho bavi a vidi v tom zmysel, tak mu nijako nebranim, aby sa tym zaoberal. Ja osobne by som take nieco nerobil, pretoze to je podla mna akosi bez zmyslu.Dali by sa najst aj dalsie obmedzujuce vlastnosti jazyka Python (nema double-dispatch pre binarne operacie, Python interpretere nie su (z dost dobreho dovodu) napisane v Pythone, atd).Double dispatch je v Pythonu možný, i když není součástí jazyka. Interpret Pythonu napsaný v Pythonu existuje. Nejdřív by sis měl o tématu něco nastudovat, než začneš plácat blbosti.
S tym suhlasim.Zoznam veci, ktore Python programatorovi neumoznuje vyjadrit, a veci ktore z urciteho dovodu nie je vhodne implementovat v Pythone alebo pre Python, je dostatocne dlhy.To se dá prohlásit o libovolném programovacím jazyce.
14.1.2011 01:43
grubber | skóre: 6
| blog: grubber
| Břeclav / Brno
pokud budeš zároveň psát blbosti jako "interpretované dynamické jazyky bez typového systému", tak budeš akorát k smíchu.Asi Vam nedoslo, ze "interpreter vs. kompilator", "dynamicke crty" a "(compile-time) type checking" programovacieho jazyka su viacmenej ortogonalne vlastnosti - z coho zrejme vyplyva, ze je mozne ich pouzit v jedinom slovnom spojeni tak, aby toto slovne spojenie davalo zmysel.
13.1.2011 12:19
Saljack | skóre: 28
| blog: Saljack
| Praha
13.1.2011 12:22
Saljack | skóre: 28
| blog: Saljack
| Praha
To je pravda! Navrhuji udělat seznam nejběžnějších činností, jaké může procesor dělat a tento seznam zakódovat do co nejmenšího množství bitů. Jo počkat, ono už to existuje. Proč v tom případě existují jazyky jako asm, C, Pascal, Perl, Python, Java, ..., když můžeme psát instrukce i s operandy přímo na úrovni bitů?
Já nevím, co třeba abstrakce, aby se v tom mohl vyznat i tak primitivní tvor, jako je člověk? Proč psát závorky, když nejsou potřeba? Inu, zas to samý, člověk je bez závorek moc otevřenej a lítá sem a tam a pak se nesoustředí na práci. To je věda pane, fakt že jo.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
13.1.2011 11:24
13.1.2011 23:48
if bla bla:
neco 1
if abc:
neco 11
neco 12
sem budu přesouvat
neco 2
for xyz:
if ble ble:
tohle chci
tohle taky
neco 3
neco 4
A co se stane po přesunu toho kousku kódu, který nemá jen dva řádky, ale mnohem víc a ještě to psal někdo jiný?
if bla bla:
neco 1
if abc:
neco 11
neco 12
tohle chci
tohle taky
sem budu přesouvat
neco 2
for xyz:
if ble ble:
neco 3
neco 4
Tak a teď mi řekni, jak to má editor poznat… ?
Přitom by to mohlo vypadat takto:
if bla bla {
neco 1
if abc {
neco 11
neco 12
}
tohle chci
tohle taky
sem budu přesouvat
neco 2
}
for xyz {
if ble ble {
neco 3
}
neco 4
}
Rozdíl? Otevírací závorka místo dvojtečky a navíc jen uzavírací závorka, která funguje podobně jako tečka za větou.
Výsledek: Na první pohled je vidět, kde je chyba. Není potřeba vůbec nic číst, prostě to je vidět. Na první pohled a klidně i během scrollování.
Navíc ta chyba tam ani není, takže je možné kód ihned vyzkoušet a teprve potom řešit formátování (což se hodí např. při zjišťování, kde je chyba).
]x, kde x je příkaz vložení, typicky je to ]P (vložení před kurzor) nebo ]p (vložení za kurzor) a vim automaticky přizpůsobí vkládaného bloku řádku, na kterém vkládám. Takže:
x - vyjmu řádky
]P - vložím řádky nad "neco2" (odsazení bude stejné jako u neco2)Navíc ta chyba tam ani není, takže je možné kód ihned vyzkoušet a teprve potom řešit formátování (což se hodí např. při zjišťování, kde je chyba).Vložit to správně a mít tím formátování vyřešené hned, má taky něco do sebe
13.1.2011 12:45
Saljack | skóre: 28
| blog: Saljack
| Praha
Dokonalosti není dosaženo tehdy, když už není co přidat, ale tehdy, když už nemůžete nic odebrat.
— Antoine de Saint-Exupéry
.
Jediné, co mě trochu mrzí je, že místo diskuze o jazyce Go, která by mohla být zajímavá, se v komentářích rozběhla diskuze o Pythonu...tedy spíš flamewar.
Takže pokud byste měli třeba nějaký (konstruktivní) návrh, čemu se v příštím díle seriálu o Google Go věnovat, nebo se chcete na něco (konstruktivně) zeptat, tak máte ještě chvíli čas než začneme na dalším díle pracovat. Honza Mercl (primární autor článku) vám jistě rád vyhoví nebo rovnou odpoví.
Díky,
Ondřej Surý
$ goinstall bitbucket.org/dethe/gocairo/