Oficiálně potvrzeno: Microsoft kupuje GitHub za 7,5 miliardy dolarů

Oficiálně potvrzeno: Microsoft kupuje GitHub za 7,5 miliardy dolarů.

4.6.2018 15:44 | Ladislav Hagara | Komunita

Komentáře

[Roman]

Je to v p**i. V dobe, kdy konecne spousta svobodneho SW nasla prijemnou platformu na spolupraci mezi vyvojari, prijde opet na radu business a ten slizky Microsoft. A zas to zbytecne nasere spoustu lidi a nadela zbytecnou praci s prechodem. Koupit se da opravdu cokoliv. Ach jo...

[NN]

Doufam, ze si panove z GitHubu koupi nejaky ten ostrov a az skonci ta velka party nikdo si na ne ani nevzpomene.. blby penize.. nechapu.

[Grunt]

Též by mě zajímalo co s těma prachama ti lidi dělají.

[Kockomil]

Věděl bych, co s nimi.

[Jendа]

Mě by fakt zajímalo, jestli ti lidé, co tu opěvují GitHub, ToS nečetli, nebo jim fakt nevadí, co se tam píše.

a ten slizky Microsoft

Tohle není problém Microsoftu, tohle je problém toho, že jste se stali závislí na jedné nesvobodné centralizované službě.

[kralyk z abclinuxu]

Mě by fakt zajímalo, jestli ti lidé, co tu opěvují GitHub, ToS nečetli, nebo jim fakt nevadí, co se tam píše.

U mě za b). S tím, že Github jako firmu jsem nikdy neměl moc rád, ale zároveň k nim nebo jejich ToS nemam dostatečně negativní vztah na to, aby to převážilo přínos, který mi GH přináší, který vnímám jako velký.

[AsciiWolf]

Tohle není problém Microsoftu, tohle je problém toho, že jste se stali závislí na jedné nesvobodné centralizované službě.

+1

[Roman]

Jasne TOS bylo i predtim, ale: 1. Premium privatni repa si ted bude prohlizet Microsoft 2. Cast lidi odejde jinam a vznikne zbytecna fragmentace, bude treba mit kupu uctu do dalsich sluzeb pro prizpivani 3. Microsoft zmeni strukturu vedeni a mozna dost puvodnich vyvojaru odejde 4. Microsoft muze zpoplatnit a omezit free sluzby, zmenit TOS k horsimu, jak je zvykem 5. Zavede zasr* Microsoft account

Staci se podivat na Nokia a Skype. Ano, bude to fungovat i dal, ale nemam z toho vubec radost. :(

[Bystroushaak]

RIP

[pokrytec]

za 7.5 miliardy dolarov vela z nas urobi horsie veci :)

[Ovoce]

Já bych z toho zase nedělal drama, aspoň ne dopředu. Vzpomeňte si na to haló kolem Novellu v roce 2006 nebo kdy to bylo. To byly všude apokalyptický vize a bojkot Suse, ale co se pak opravud stalo? Vůbec nic.

IMHO ti lidi, co teď budou horečně migrovat kód a tak dál, hlavně ztratí čas a zbytečně se budou stresovat-

[xkucf03]

IMHO ti lidi, co teď budou horečně migrovat kód a tak dál, hlavně ztratí čas a zbytečně se budou stresovat

Sice už „včera bylo pozdě“ – ale stále se odtamtud jde odstěhovat relativně bez stresu a v klidu. Co bys radil ty? Začít stěhováním, až se to tam sesype? To bych naopak považoval za zbytečný stres.

[Ovoce]

já bych na to relativně v klidu a bez stresu kašlal, dokud by se fakt něco nestalo.

[Josef Kufner]

Je to dobrá příležitost k tomu si připomenout a procvičit, jak takové repozitáře odzálohovat včetně issues a pull requestů.

[Petr]

Zase se mi líbí, že mají s GitHubem evidentně dlouhodobý plány, když si spočítali, že se jim vyplatí to koupit než platit $21 měsíčně :)

[Ladislav Hagara]

Prezentace Microsoftu:
Microsoft ♥ Developers
Microsoft ♥ Open Source

[Bystroushaak]

No jo, jenže ♥ není komutativní.

[Michal Kubeček]

symetrická

[Bystroushaak]

Hah, pravdu díš.

[pc2005]

♥

A papír^W powerpoint snese cokoliv.

[VM]

Jenže to u Microsoftů vypadá takhle: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish

[mngnt]

Uz nie embrace, Empower, ako je to v prezentacii.

[_]

nic se nedeje, je jedno komu github patri

[Bystroushaak]

Co to je za blbost?

[_]

na licenci hostovanych projektu to proste nema zadny vliv

no issue, nic se nedeje, rozejdete se

[Bystroushaak]

Co to meleš za sračky? Kdy naposledy MS něco koupil a neměl na to žádný vliv? Naprosto nikdy.

[mirec]

Keď kúpil linkedin. Predtým to bola neprehľadná spamovacia sračka. Teraz je to tiež neprehľadná spamovacia sračka akurát, že má plochejšie a neprehľadnejšie UI ;)

[koroptev]

No hlavně (pokud to neopravidli) zrušili možnost pozastavit si účet, takže mi chodí několik pracovních nabídek týdně a nemohu s tím nic dělat (leda ten účet zrušit, ale to samozřejmě kvůli kontaktům nechci).

[_]

Sračky meleš ty. Tak nám pro pobavení vylož svoji konspirační teorii. Udělám si kafe.

[Bystroushaak]

Konspirační teorii? Fakt si myslíš, že potřebuju konspirační teorii? Microsoft zkurvil doslova vše na co sáhl. Jestli si myslíš, že to kupují jen tak z dobra duše, tak jsi ještě větší dement, než jsem si původně myslel.

[_]

Nemyslim si, ze by Mircosoft zkurvil, na co sahl. Tobe ovsem zatemnila mozek slepa nenavist.

[ehm]

Zkurvil jenom celé IT.

[_]

Jestli někdo zkurvil většinu IT, tak to byl SUN s Javou...

[ehm]

Ne.

[heh]

Ale ano.

[Max]

Ne.
Zdar Max

[Freshmouse]

Ano

Freshmouse

[Bluebear]

Také se obávám, že ano. Java je krystalické zlo.

[Max]

Nesouhlasím.
Navíc nemá v dnešní době žádnou náhradu a asi ani dlouho mít nebude, pokud tedy nepomyslíme na C#
Zdar Max

[Bluebear]

To už i C# je mnohem lepší. ALe osobně bych se bez jazyku podobného typu velmi rád obešel.

[kralyk z abclinuxu]

Navíc nemá v dnešní době žádnou náhradu a asi ani dlouho mít nebude

Pokud jde jen o jazyk, pak náhrady určitě jsou - Scala, Kotlin, Clojure, ...

Pokud myslíš náhradu za JVM, napadá mě ten C#, případně asi i Go, ačkoli asi ne na všechno...

[Fluttershy, yay!]

Pokud jde jen o jazyk, pak náhrady určitě jsou - Scala, Kotlin, Clojure, ...

Asi tak.

Pokud myslíš náhradu za JVM, napadá mě ten C#, případně asi i Go, ačkoli asi ne na všechno...

C# je VM? To spíš .NET CLR.

Jinak…

[Grunt]

Ono jsou to spíš dvě mouchy jednou ranou. Bude-li GitHub dostatečně dobrý aby si na sebe vydělal i v budoucnu (resp. je-li to dobře rozjetý start-up) Microsoft ho bude podporovat s tím že bude držet strategickou pozici v rozhodování (třeba o licencích a bůh ví co). No a pokud ne a zemře, holt se jim podaří zasadit bolestnou ránu do týlu úhlavního nepřítele. Prostě strategicky výhodná akvizice. Nic víc.

[Petr Ježek]

Konečně rozumný názor. Problém je ale v tom, že stačí zaplacený krtek, který prostě vykrade myšlenky tvůrců v githubu a po právním vývaru z toho udělá Win 13... Dnes každé západní korporaci teče do bot...

[Michal Kubeček]

A teď máte na mysli veřejné repozitáře, do kterých takový "krtek" může už teď, nebo privátní repozitáře, které si platí jednotlivé firmy? U veřejných to totiž nedává žádný smysl, přestože se většina diskuse vede v duchu, jako by právě tohle byl ten hlavní problém. Co se týká privátních, tak tam mi urychlený odchod dává smysl daleko víc a zejména u přímých konkurentů Microsoftu se také dá očekávat. Ale tím tady kupodivu nikdo neargumentuje…

[Grunt]

V těch privátních může být něco zajímavého? Proč to vůbec lidi používají pokud ano?

[Michal Kubeček]

Lidé IMHO moc ne. Spíš bych tipoval, že to využívají hlavně firmy, kterým se z nějakého důvodu nechce (nebo nevyplatí) rozjíždět a udržovat vlastní řešení. Ty tam můžou vyvíjet nějaké closed source věci, interní nástroje a nebo třeba i jen rozpracované projekty (klidně i open source), které ještě nejsou určené ke zveřejnění.

[Grunt]

No to jsem pochopil, jen jsem nepobral proč tak prostě činit u někoho kdo má očividně k citlivým datům libovolný přístup. Já se obávám že Codeplex neuspěl právě z toho důvodu. U Microsoftu by si nechal citlivá data hostovat jen blázen a nebo sebevrah.

[Michal Kubeček]

Mně by to taky bylo proti srsti, ale překvapivě je dost běžné pro interní komunikaci používat externí služby. Úplně stoprocentně se sdílení dat s cizími firmami ani vyhnout nejde, často je k řešení bugu potřeba crash dump nebo packet capture, což jsou věci, které se úplně sanitizovat dost dobře nedají, a ne všechno lze zreprodukovat v nějaké laboratoři, kde žádná citlivá data nejsou.

Já se obávám že Codeplex neuspěl právě z toho důvodu. U Microsoftu by si nechal citlivá data hostovat jen blázen a nebo sebevrah.

Proto jsem také psal, že u těch privátních firemních repozitářů vidím mnohem větší důvod k panice než u komunitních open source projektů. Jedna věc je svěřit část dat externí firmě a důvěřovat, že vás nepodrazí, ale pokud je ta externí firma váš konkurent, je to úplně jiná úroveň problému. A Microsoft vzhledem k šíři svého záběru konkuruje ledaskomu.

[kralyk z abclinuxu]

Mně by to taky bylo proti srsti, ale překvapivě je dost běžné pro interní komunikaci používat externí služby. Úplně stoprocentně se sdílení dat s cizími firmami ani vyhnout nejde, často je k řešení bugu potřeba crash dump nebo packet capture, což jsou věci, které se úplně sanitizovat dost dobře nedají

No... to si tak zvykneš na to, že lidi ochotně pošlou dump, a pak ti jednoho dne přistane bugreport od $výrobce_stíhaček a na dotaz na crashdump jsi poslán někam, že to je secure system, ale že by byli velice rádi, kdyby to bylo vyřešeno... (měli jsme tehdá štěstí, že nedlouho na to stejnou chybu nahlásil i úplně obyčejný dumpy sdílející zákazník).

[Michal Kubeček]

No, někteří zákazníci holt moc sdílní nejsou. Už jsem se setkal i s tím, že na požadavek na (konkrétní) dodatečné informace přišla odpověď (přibližně): "Předpokládáme, že máte dostatečně chytré vývojáře, aby jim tohle stačilo." To už jeden neví, jestli si z něj dělají legraci nebo to myslí fakt vážně.

[pc2005]

Předpokládáme, že máte dostatečně chytré věštce, aby jim tohle stačilo.

FTFY

[xkucf03]

Na druhou stranu jsem slyšel i historky o tom, jak dodavatel víceméně šikanoval zákazníka s tím, že má dodat další a další podklady, i když to zjevně šlo vyřešit na základě těch již dodaných. Zřejmě s cílem, že to část zákazníků vzdá a „přestane otravovat“. Pokud jsi dostatečně velký jako třeba Oracle nebo Microsoft a máš vendor lock-in, tak si to můžeš dovolit a zákazníci ti přesto jen tak neutečou.

[kralyk z abclinuxu]

Technická: Gitlab.com byl dlouhou dobu hostován na MS Azure a nedávno se přesunul na Google Cloud Platform.

Tohle imho ty hromadné migrace z GH na GL.com trochu ironizuje...

[Grunt]

Blázni. K tomu se nedá víc co dodat.

[Jendа]

No to jsem pochopil, jen jsem nepobral proč tak prostě činit u někoho kdo má očividně k citlivým datům libovolný přístup.

Protože dneska je doba cloudová, dokumenty máme na Google Docs, soubory na Dropboxu, maily na GMailu, zdrojáky na GitHubu…

[Grunt]

Tož nevím kde je máte vy, ale já je mám tady na disketě vedle sebe…

[Jendа]

Jak kde. Mám/měl jsem jak zákazníky, kteří měli všechno v cloudu, tak zákazníky, kteří lpí na tom mít to u sebe. Já mám v cloudu šifrované zálohy a bohužel VPS s weby, maily a IRC, protože jsem ještě nenašel odvahu provozovat server na domácím internetu.

[pc2005]

Ale jak tu už lidi psali, tak vlastní webserver s gitem je fakt triviální.

[aubi]

Gitlab je super až na to, že každý upgrade se rozbije a je potřeba to řešit ručně. Teď mi zrovna na debianu asi dva měsíce neběží, neměl jsem čas to řešit.

Ve firmě na to máme člověka, ale taky blahem nehýká.

[Josef Kufner]

Za poslední více jak rok si nevybavuju žádný problém při upgrade pomocí balíčků pro Debian.

[Fluttershy, yay!]

Vůbec nemáš představu, co všechno dokázal M$ zmařit. Jako ochutnávku viz třeba BTRON:

Business TRON (BTRON), is a computer operating system with a graphical user interface (GUI) built upon Central TRON (CTRON), itself a subproject of The Real-time Operating system Nucleus (TRON). TRON was launched in Japan in 1984 as an initiative to create a single, universal operating system with an open architecture.

The Japanese government planned to introduce the Matsushita PC in its schools, but the Office of the United States Trade Representative objected, claiming that the plan constituted market intervention and threatened Japan with sanctions; not coincidentally, the former official of the United States Trade Representative office who issued the threats against the Japanese government, Tom Robertson, had been offered by Microsoft the very lucrative position of being their Tokyo-based director for government affairs in Asia.

[Michal Kubeček]

Samozřejmě že to nedělají z nějakého altruismu. Ale stejně tak je nesmysl myslet si, že primární motivací je škodit. Je to komerční firma, jejím cílem je produkovat zisk, ne páchat zlo (nebo dobro).

[Bluebear]

tak nejak, mezi Suse a Microsoftem neni rozdil

[Dušan]

Problém je to že zisk je skryté zlo. Aj keď ešte väčšie je úrok.

[M.]

Ale on se dá zisk produkovat různými způsoby. Hitler kdysi taky zaměstnal celý Německo a produkovali zisky. A zkušenosti mluví zcela jasně, musela by to být výjimka potvrzující pravidlo, aby GH přežil bez úhony.

[Michal Kubeček]

Godwin's law… check. Let's move on.

[jdsulin2]

Na licenci to samozrejme vliv nema, ale dejme tomu, ze bys mel nejaky open source projekt - spolehal by jsi na zalohovani pouze na GitHubu nebo ne ? Ja teda rozhodne ne. Microsoft se jednoho dne rozhodne, ze meni podminky - samozrejme projekt nejspis nezrusi, ale zpoplatni nebo zprisni podminky repozitaru nebo zmeni podminky tak, ze kod na nem umisteny je vlastnictvim GitHubu. A co budes delat. Ja bych radsi vzhledem k historii migroval ihned.

[Bystroushaak]

Ja bych radsi vzhledem k historii migroval ihned.

Jo, ale kam?

[Bluebear]

smarja, bitbucket, gitlab, moznosti je plno...

[Bystroushaak]

smarja, bitbucket, gitlab, moznosti je plno...

Možností možná, ale alternativ nikoliv. Jak už jsem psal ve vedlejší diskuzi:

Osobně vidím výhodu Githubu právě v té sociální části. Ostatně nebýt GH tak jsem se asi nikdy tolik nezapojil do opensource projektů a když už, tak asi jen do těch větších. Díky GH čas od času posílám commity i do těch úplně mrňavých, čistě protože se dají jednoduše najít a nebýt githubu, tak bych se o nich ani nedozvěděl.

Taky se mi líbí ta filosofie „code first“ a že člověk u menších projektů nemusí vymýšlet žádnou prezentaci - samotný kód je tou prezentací. Vzpomínám si ještě na doby, kdy si člověk musel dělat pro svoje projekty vlastní stránky, což i když už náhodou udělal, tak zabilo objevitelnost (než to zaindexuje google a na jakou pozici to asi tak dá) a u ostatních lidí ochotu zapojit se (nebudou vymýšlet jak kód stáhnout, provést patche a dát mi o nich vědět).

Tu komunitu, otevřenost a jednoduchost editace a discoverabilitu ti ani gitlab, ani bitbucket (který mimochodem používám a mám tam okolo desítky repozitářů) prostě nenabízí. Github je především komunitní web, který organizuje issue, diskuze a wiki, uživatelské profily, followování a tak podobně. o že zároveň ještě i hostuje gitové repozitáře je fajn, ale to umí kde co.

[Bluebear]

A v čem se to liší od gitlabu?

[odin]

Pro Bystroušku je to málo facebook.

[Bystroushaak]

A v čem se to liší od gitlabu?

Gitlab si hostuješ sám. Například já si nahostuju Gitlab u sebe na serveru, nahraju tam těch 60 projektů co mám teď na githubu a budu čekat, až to někdo sám najde a bude mít náladu se tam zaregistrovat a přihlásit a posílat mi pull requesty, což ze zkušenosti vím, že se prostě nikdy nestane.

Oproti tomu ty projekty na githubu měly návštěvnost a pull requesty občas prostě jen proto, že na to někdo narazil a líbilo se mu to. Rozdíl je asi jako mezi tvým osobním webem a abclinuxu, což je stejně jako github web primárně o komunitě. Zcela běžně mám pod blogy stovky diskuzních příspěvků. Víš kolik jsem jich měl na webu, když ještě umožňoval diskuze? Určitě to uhodneš.

Github je komunitní projekt. Gitlab není. Bitbucket částečně, ale neusnadňuje to.

[Bystroushaak]

Github je komunitní projekt. Gitlab není. Bitbucket částečně, ale neusnadňuje to.

Špatně řečeno. Github je komunitní web. Gitlab není.

Komunitní projekty jsou to oba.

[Bedňa]

Aký názor máš na Giteu?

[Bystroushaak]

Hele, žádný. Neznám to. Od pohledu to vypadá pěkně a čistě.

Může to být fajn projekt, ale je to zase Self hosted. Když to budeš hostovat, tak tam nebude nikdo z tvých známých a kamarádů, nikdo se ti tam nebude chodit registrovat a zakládat ti tam issue a povídat si s tebou o návrzích. Nikdo jen tak náhodně nepřijde a nenapíše ti na wiki jak vyřešit nějaký problém. Nikdo pravděpodobně ani nebude vědět, že to vůbec existuje.

Fajn pro vlastní projekty, pro malé teamy a pro firmy, ale opět to vůbec není náhrada toho, co dělá Github unikátním; ta sociální síť pro programátory.

[kralyk z abclinuxu]

Může to být fajn projekt, ale je to zase Self hosted. Když to budeš hostovat, tak tam nebude nikdo z tvých známých a kamarádů, nikdo se ti tam nebude chodit registrovat a zakládat ti tam issue a povídat si s tebou o návrzích. Nikdo jen tak náhodně nepřijde a nenapíše ti na wiki jak vyřešit nějaký problém. Nikdo pravděpodobně ani nebude vědět, že to vůbec existuje.

+1

[Bedňa]

Príde mi to ako dobrý základ pre takú nodovú Gitovú sieť. Proste nad tým postaviť jednotnú registráciu na všetkých nódoch, jednotné vyhľadávanie, forkovanie ... aby to pôsobilo zvonku ako jeden server.

Toto si viem predstaviť do budúcnosti ako dobrý základ pre vyvívoj slobodného kódu.

Súhlasím s tebou, že najsilnejšou stránkou GitHubu je sociálny faktor. Plus sú tam aj iné vychytávky, príde mi že oboje Gitea zláda dobre.

[sonicpp]

+1 internet. Taky nevím kam migrovat :(

[Bystroushaak]

Related: GitHub has sold us out. This is the GitHub Evacuation Center.

[Jendа]

Komunitní projekty jsou to oba.

Github není komunitní projekt, GitHub je služba běžící na proprietárním softwaru vyvíjeném komerčním týmem.

[Bystroushaak]

Jo, ale komunita se na tom afaik podílela formou nějakých issues, co zakládali a github se tomu přizpůsobil. Takhle tuším vznikl třeba Code of conduct.

[Michal Kubeček]

A v čem se to liší od gitlabu?

Gitlab si hostuješ sám. Například já si nahostuju Gitlab u sebe na serveru, nahraju tam těch 60 projektů co mám teď na githubu a budu čekat, až to někdo sám najde a bude mít náladu se tam zaregistrovat a přihlásit a posílat mi pull requesty, což ze zkušenosti vím, že se prostě nikdy nestane.

Tady vidím nedorozumění: je potřeba rozlišovat gitlab jako software (to je to, o čem mluvíte vy) a gitlab jako službu (resp. portál), tj. konkrétní instanci toho prvního, která běží na gitlab.com

[Bystroushaak]

Tady vidím nedorozumění: je potřeba rozlišovat gitlab jako software (to je to, o čem mluvíte vy) a gitlab jako službu (resp. portál), tj. konkrétní instanci toho prvního, která běží na gitlab.com

Hmm, ok. Prozkoumám.

[Michal Kubeček]

Před chvílí jsem se tam díval a připadá mi, že ten web reaguje ukrutně pomalu. Zajímalo by mne, do jaké míry je to způsobené zvýšeným zájmem kvůli zprávám o akvizici Githubu. :-)

[Martin]

Patrně do značné

[Bystroushaak]

Jinak tady jsou ty grafy live: https://monitor.gitlab.net/dashboard/db/github-importer?orgId=1. Hrozně to laguje, ale občas se načtou.

[Grunt]

Však už to začíná. To je je jak nějaký maraton. Jen Microsoft vystřelí na startovní čáře, už začíná úprk.

[Roman]

Do jiste miry je to ted ochromeno privalem lidi, ale bylo to relativne pomalejsi vzdy. On je gitlab napsany v Ruby a co jsem ho zkousel v dockeru u sebe, moc nadseny sem nebyl. U nich na gitlab.com sem dokonce jeden cas mel nejak rozhozeny session, asi me to prehazovalo mezi instancemi co nebyli spravne syncovane. A tak mimo sem zahlid stiznosti ruzne problemy s gitlab.com. Oproti tomu mi prisla github infrastruktura profi a dost rychla... Krom gitlab je nadejny Gogs psany v Go, ten vypadal rychle a kdybych si mel hostovat github clone tak bych prvne zvazil jej.

[Bystroushaak]

Whoa: Implement cross-server (federated) merge requests

[Bedňa]

Aj po niekoľkých minútach mŕtve.

[kralyk z abclinuxu]

To zní nadějně.

[Grunt]

Kralyku, proč máš tak stupidní nick a žádný avatar? Matení nepřítele?

[kralyk z abclinuxu]

jo

[Grunt]

Tak když už tak aspoň nějaký vtipný avatar nech je nepřítel zmaten ještě víc a nech tě normální čtenáři plátku rozpoznají pouhým mrknutím oka.

[Agent]

Říká někdo, kdo si změnil Avatar a já ho teď nemohu poznat...

[Grunt]

Nemám páru o čem je řeč.

[pc2005]

Grunt má stejnýho avatara roky.

[kralyk z abclinuxu]

Ještě včera nebo předevčírem tam byl jinej...

[pc2005]

Ledaže by ho změnil tak na den, ale první výskyt v 2011.

[k3dAR]

potvrzuju, nevim jestli na den, ale kdyz Agent psal mel Grunt avatara jineho, dival se na druhou stranu a pokud si pamatuju byl cervenej se zelenou tlamou

[xxxs]

tusim mas prehodene farby, ale inak ok.

[Grunt]

LOL já když to čtu tak to radši objasním: Lidi (očividně čímkoliv od Blizzardu nepolíbení) si pletou Grunta (přitom je to snad válečný zlobr nebo co) a trola i když tyhle dvě jednotky nemají společného vůbec nic než příslušnost k hordě. Pouze sem se snažil vyjít vstříc, protože horda nejen čítá trola vyvrhovače, ale celou rasu různých druhů trolů, lesních trolů a nevímčehovšehoještě. Takže prostě vycházím vstříc a dělám z trolování svou hlavní pracovní náplň. Doufám že to je každému dostatečně srozumitelné.

Jo mimochodem, gratujluju. Právě jste byli vytrolováni.

[pc2005]

Ten původní avatar byl hezčí :-P

[Grunt]

Byl ale teď prostě troluju. Až budu v náladě a budu naprosto ničit tak si ho změním ještě jednou

[Jendа]

Nějakou chvíli měl jinou zelenou věc. Bylo to dostatečně podobné, takže mi to bylo fuk .

[Grunt]

Bože, chytám se za hlavu. Co ste sakra v pětadevadesátém a šestadevadesátém jako dělali?

[kralyk z abclinuxu]

Tak to jsem zrovna pařil Age a pak přišlo Diablo. WC jsem nějak nepřišel na chuť za celou dobu...

[Grunt]

Já zas dostal Diablo (a to bylo mimochodem tak až někdy po roce 1998 protože si pamatuju ještě trailer na CD StarCraftu) a vytrejdoval sem ho za RPGčko jako řemen. Té klikačce jsem zas na chuť nemohl přijít já. Ale když by si někdo cokoliv z toho udělal avatara tak jsem si jistý že bych to aspoň poznal. Že nějaké zelené věci, to mně normálně uráží.

[pc2005]

Já měl kompa až od 2000 .

[Grunt]

Buď rád. Ses aspoň jednou dostal jako děcko ven na slunce.

[pc2005]

No tak to je teda spíš nevýhoda. Kdybych měl kompa už v 90. letech (ideálně s linuxem), tak bych byl teďka jinde .

[Grunt]

Je to naprosto šílený offtopic co tu pokračujeme, ale budiž:

Kdybych měl kompa už v 90. letech (ideálně s linuxem), tak bych byl teďka jinde

Nemyslím si. Já strašně záviděl kamarádovi (resp. to byl kluk od sousedů) co měl už v té době nějaké Pentium s Windowsama (za těžkých 40litrů – otec byl hraničář, takže si to mohly dovolit) zatímco já si okýnka kreslil jen na Didaktiku. Pařil na tom tehdy Age of Empires (zatímco já o něco málo později právě ten WC2) a že by ho to někam posunulo… To stejné vlastně druhý soused. To býval těžký borec protože dovedl nainstalovat Win 3.11 z disket na obstarožní 286 co tata kdesi sehnal. Myslíš že by tě to někam posunulo? Navíc jak říká Liška, nezapomeň že v té době si se mohl učit tak maximálně číst a psát, ne dělat něco vážného. Ten BASIC byla v mém případě spíš náhoda a úplně první vážnější "jazyk", tedy VRML97 přišlo právě až po přelomu milénia. V 90. letech býval Linux něco absolutně mimo svět běžných smrtelníků (navíc tak jádra 2.4) a představa že jako capart sedím před nějakou 486kou a kompiluju natvrdo do jádra ovladače – to už bych byl větší kinder-hipster než Kolíbáč.

[k3dAR]

jadra 2.4? ja mel Linux s jadrem 0.9 na Amize a hromadu programu, XTerm, XCalc, XEyes

[Grunt]

No jo, to je až 2001. Pche. To vůbec. To jako s klidným svědomím přiznám že to bych v devadesátých letech jako děcko nedal ani když bych se na čtyři rozkrájel. Tu Amigu maximálně. Když bych nějakou měl, resp. když by na ni rodiče měli prachy

[deda.jabko]

Já strašně záviděl kamarádovi (resp. to byl kluk od sousedů) co měl už v té době nějaké Pentium s Windowsama (za těžkých 40litrů – otec byl hraničář, takže si to mohly dovolit) zatímco já si okýnka kreslil jen na Didaktiku

Taky jsem mel osmibitovy pocitac, kdy mezi beznou populaci byly k dispozici 386ky a 486ky. Tehdy me to trochu stvalo, s odstupem casu toho nelituju. Na osmibitech jsem si mohl pohodlne osahat veci, ktere uz dnesni decka nezazijou.

Kde si dneska muzou decka v klidu bez nejakeho laborovani zkouset primy zapis na porty jednotlivych zarizeni nebo zapisovat primo do pameti namapovane zarizenimi? Psat rucne strojovy kod na Z80 je o fous pohodlnejsi nez s AMD64.

V 90. letech býval Linux něco absolutně mimo svět běžných smrtelníků (navíc tak jádra 2.4)

RedHat 5.x nebo 6.x byly na tu dobu konkurence schopne desktopove Unixy. Co hodne chybelo byl kancelarsky balik, proto se to moc nechytalo.

[Grunt]

Jasně. Jenže doporučuju to vysvětlit děcku školou povinnému. Já měl zase hodně dlouhou dobu 80486 i v době kdy byly běžné Pentia (na svoje první Pentium II jsem si vlastně musel vydělat). A pomalý disk, snad 3000rpm a ještě se to suspendovalo. Pamatuju se jak si ze mě spolužáci dělaly srandu když mi počítaly přístupový čas když klikly na „Tento počítač“ a samozřejmě než se to roztočilo tak snad 10 nebo 20 sekund. Kokoti. To byly traumátka. No když si vezmu že bych přišel o skvosty jako Crusader nebo bych neprošel v koooperativě celého Dooma 2…

V retrospektivě už se na to samozřejmě dívá člověk jinak a navíc co se v mládí naučí…

RedHat 5.x nebo 6.x byly na tu dobu konkurence schopne desktopove Unixy

Jenže v dobách kdy vrchol mých sil byla instalace ilegálních Win98 bych to nedal. To si nebudu lhát do kapsy. Ani bych neměl důvod.

[Josef Kufner]

Dnes je na hraní Arduino, Raspberry Pi a docela se rozmáhá jednoduchá robotika.

[deda.jabko]

Dnes je na hraní Arduino, Raspberry Pi a docela se rozmáhá jednoduchá robotika.

Su rad, ze dneska uz jsou takove moznosti. Ale v Raspi zavazi kernel a Arduino je druhy pocitac (+ je potreba chvilku laborovat s IDE a pripojenim), takze to neni uplne ono.

U tech osmibitu bylo bozi, ze clovek mel okamzity pristup ke vsemu, co ten hardware mel. A kdyz na to doslo, slo to treba kombinovat s Basicem. (Na druhou stranu tam byla spousta veci, kde se dalo neco jednoduse rozbit a clovek musel zacit od zacatku.)

[pc2005]

Kde si dneska muzou decka v klidu bez nejakeho laborovani zkouset primy zapis na porty jednotlivych zarizeni nebo zapisovat primo do pameti namapovane zarizenimi?

V bashi přes devmem prográmek. Polovina mých embedded pokusů má skripty, kde přes to něco nastavuje .

Dokonce jsem si musel napsat ekvivalent na ioporty.

Vlastně můj první C kód zapisoval natvrdo na porty superio čipu (BIOS zapomněl vypnout POST kódy směrované na LPT a mě to rušilo LPT2LPT konektivitu).

[pc2005]

No já kompa dostal tak ve 13 letech a byla to zavirovaná 386 (myslím). Tam se dalo programovat maximálně v qbasicu. Ale už tak ve 14 jsem získal pascal a mohl programovat v něm. Kdybych začal rovnou v céčku, tak bych si to osvojil mnohem líp, protože bych se to učil mladší. Pak jsem z netu získal Athelp, to byla výhoda, tam jsem udělal znalostní skok tak během 14 dní. Ale pořád to bylo maximálně tak win98se (nebo dualboot do málo používanýho linuxu, první linux/live suse mě vybouchl v CDROMce, protože se teplem vyvlékl plastovej protikus co držel CDčko na motoru). Ale je fakt, že po opuštění windowsů v 19 letech (2006) jsem měl následující rok bugreport v kernelu .

[Grunt]

No já kompa dostal tak ve 13 letech a byla to zavirovaná 386 (myslím).

Odviruješ a máš echt komp k dispozici.

Tam se dalo programovat maximálně v qbasicu.

A na čem si myslíš že jsem asi v té době „programoval“ já? A to jen z toho důvodu, že to bylo jako volitelný addon na CD s W95. Jinak by to byly BAŤáky v M602.

Kdybych začal rovnou v céčku, tak bych si to osvojil mnohem líp, protože bych se to učil mladší.

Tak to si nenech nakecat. Oh, what the hell…tak dobrá, když zpověď, tak zpověď (doufám že to vytáhne zas nějaký anonymní debílek):

Tak v sedmé, osmé třídě jsem měl „nehodu“. Skončil jsem v rehabilitačním centru/léčebně pro děcka přes léto. Běžná průměrná populační retardace, takže se tam stejně moc nedalo dělat, nicméně jednoho dne tam přišel takový nerdson, jak ho popsat? Béžový pletený svetr, na hlavě místo vlasů atomový hřib, "ř" nedovedl pořádně vyslovit když by měl u sebe pravítko tak by ho použil jako katanu a rozsekl mě vejpůl. Prostě buchar jako kráva. Ten byl jiný už od pohledu. Potkávali jsme se u 386-ky protože Pentium s internetem bylo určeno pro starší plnoleté osazenstvo ústavu či populárnější nebo prostě zasloužilejší ptáky. A taky z toho důvodu že oba jsme uměli s dosem (první věc co mně zaujala, protože ten počítač býval jinak z toho důvodu úplně prázdný a také první člověk z druhého stupně ZŠ co dovedl ovládat příkazovou řádku). Takže jsme se nějak skamarádili a ten my vykládal jak trávil léta na Delphi táboře, uměl snad s nějakým FoxPro nebo co, prostě něco jako synátor Billa Gatese. No já si připadal jak nějaký untermenš. Ať to vysvětlím. Ještě než se mi to stalo jsme se u nás se spolužákem dali na to že se naučíme programovat ať můžeme psát oblíbené počítačové hry, napsat něco třikrát lepšího než Q3A, pětkrát akčnějšího než Duke Nukem a naprosto trhnout tržní rekordy v prodejích a všem těm lamám ukázat Proto to VRML97. V té době kdy jsem byl v léčebně jsem se učil PHP (z CHIPu a programoval jsem si do sešitku protože jinak nebylo absolutně na čem, Pentium bylo těžce využíváno mazáky na Need for Speed, Xchaty, porno nebo něco takového), JavaScript, HTML, pomalu programoval pro NASA a teď přede mně nakráčí nějaký borec mladší než já a píše opravdové spustitelné aplikačky (tzv. eksáče) a tráví léta na programovacím táboře zatímco já saju bůhvíkde? Bože to byla závist.

Hned jak jsem se dostal domů, spolužák už samozřejmě pokročil, a taky skončil a dal se na trávu a tak mi prodal nějakou učebnici Céčka a já se mohl zadrhnout. Já to nedával. Jako představ si osmou třídu, z BASICu, PHP, Macromedia Flashe na Céčko a snažíš se to stůj co stůj naučit. To byla válka, to byl boj urputný. To jsem měl hodně co dělat abych pochopil vůbec nějaké základy, pointry a pokročilejší věci vůbec. Doslova peklo.

No v čem je pointa? S tím Céčkem jsem válčil snad až do výšky kdy jsem ho plně bez problémů pochopil, ale jen díky tomu že jsem se tam učil Assembler a vůbec nějaké základy o počítačích, kompiloval jsem si svoje vlastní progarmy v GNU a taky už jsem na to asi měl věk. A v tom je ta pointa. Pokud si „Ficovi z predkožky nevyskočil“ a fakt si nebyl nějak druh mladého génia, tak si se mohl snažit, pokoušet, ale o moc dál než si teď by ses stejně pravděpodobně nedostal a to konkrétně do doby než by si dospěl. A jestli si nakecáváš že jo (a nebo si někým druhým nakecávat necháš), tak děláš chybu. Prostě by si stejně jako většina z nás mastil Warcraft II, "programoval" v QBASICu, apod. Ostatně jak daleko zmiňovaný mladý nerdík se kterým jsem měl tu čest skončil by mě vážně zajímalo.

Ale pořád to bylo maximálně tak win98se (nebo dualboot do málo používanýho linuxu, první linux/live suse mě vybouchl v CDROMce, protože se teplem vyvlékl plastovej protikus co držel CDčko na motoru

No Linux byla další závist, tentokrát v tom zakomponovaný spolužák a to by bylo na další příběh. Očividně jsem to dal. Taky.

[pc2005]

Odviruješ a máš echt komp k dispozici.

Antivir jsem sehnal až za 2-3 roky na střední .

S tím Céčkem jsem válčil snad až do výšky kdy jsem ho plně bez problémů pochopil...

Tak já se Cčko začal učit až když jsem získal GCC, což bylo nejspíš až v roce 2006, to mě bylo 19 (na střední jsme měli blésdelphi, blésmrtvisualbasic nebo super assembler 8051). Právě proto píšu, že kdybych se ho učil ještě na zakladce, tak by to bylo efektivnější. Sice ano hrozilo by, že se vyhnu 8086 assembleru z DOSu, ale zase bych se k němu dostal stejně oklikou z céčka a embedded věcech, takže bych se k němu stejně dostal +- ve stejný čas. Koneckonců jsem na rané vejšce ručně s ndisasm rozebral asi třetinu BIOSu mýho notebooka, což nezáviselo na tom, jakej jsem se učil jazyk na střední.

[deda.jabko]

Kdybych začal rovnou v céčku, tak bych si to osvojil mnohem líp, protože bych se to učil mladší

Pascal je na prvni seznameni s programovanim nasobne lepsi nez C.

Spousta veci se da vysvetlit (promenne, cykly, pole) bez toho, aniz by nekde vyhrezavaly pointery.

Civilizovana prace se vstupy/vystupy a retezci, aniz by nekde vyhrezavaly pointery.

Takze zacinajici programator se muze venovat reseni algoritmu misto toho, aby zapasil s jazykem a jeho implementaci. Kdyz dojde na slozitejsi struktury a ukazatele (seznamy, stromy, apod.), uz ma dobry zaklad, na kterem se da stavet.

Pascal ma jeste jednu nedocenenou vlastnost a to moznost deklarovat procedury/funkce uvnitr procedur a funkci. Nauci to cloveka rozdelit rozsahly problem na problemy mensi.

Obcas vidim kod lidi 40+ a z jeho struktury jde velice casto poznat, kdo si prosel v mladi Pascalem a kdo ne.

[Bystroushaak]

Ono je obecně problém, že lowlevel jazyky, jako třeba C, po tobě chtěj lowlevel znalosti počítače, specificky CPU a paměti. A ty začátečníkům většinou nikdo nesdělí, protože v podstatě vyžadují naučit je ještě k tomu assembler a povyprávět jim o architektuře.

V tomhle mají výhodu highlevel jazyky (python / java), protože nejenom že přesné pochopení nevyžadují, ale taky navíc díky vyšší abstrakci nabízejí větší produktivitu. Což pro začátečníky znamená vyšší pocit že jim to k něčemu je. Vypisovat hvězdičky do terminálu v C je sice zábava, ale jen chvíli. A udělat v tom pak cokoliv netriviálního stojí hrozné množství práce. Oproti tomu v pythonu jde na desíti řádcích začít programovat grafické aplikace a whatnot.

[ehm]

Ono je obecně problém, že lowlevel jazyky, jako třeba C, po tobě chtěj lowlevel znalosti počítače, specificky CPU a paměti. A ty začátečníkům většinou nikdo nesdělí, protože v podstatě vyžadují naučit je ještě k tomu assembler a povyprávět jim o architektuře.

CPU ani moc ne. Spíš jde o tu paměť, datové typy atp. Se zbytkem komentáře souhlasím.

[Bystroushaak]

Tak třeba se hodí vědět, že CPU má nějaké registry, k čemu slouží, jak funguje přímá a nepřímá adresace paměti a tak. Pak nemáš problém pochopit pointery.

[ehm]

Tak třeba se hodí vědět, že CPU má nějaké registry, k čemu slouží, jak funguje přímá a nepřímá adresace paměti a tak.

K čemu?

Pak nemáš problém pochopit pointery.

Jak to souvisí?

[pc2005]

No pokud člověk programuje (nejen v céčku) a tohle neví, tak pak z něj padaj dost šílený algoritmy, co sice matematicky fungujou, ale na reálném HW se chovají naprosto nemožně neefektivně.

[ehm]

No pokud člověk programuje (nejen v céčku) a tohle neví, tak pak z něj padaj dost šílený algoritmy, co sice matematicky fungujou, ale na reálném HW se chovají naprosto nemožně neefektivně.

Jak ti znalost cílového procesoru, konkrétně registrů a adresace paměti, o kterých byla řeč, pomůže optimalizovat programy? Nota bene tak, aby to bylo víc než mikrooptimalizace.

[Michal Kubeček]

Spíš to pomůže nepsat je zoufale neefektivní. Není samozřejmě potřeba (až na výjimky) znát detaily specialit konkrétní architektury, i když je žádoucí třeba povšechné povědomí, že existuje big endian a že ne všude jsou základní typy stejně dlouhé. Programátor bez základní představy, co se vlastně při zpracování děje, mívá tendenci považovat volání knihovních funkcí za atomické elementární operace a nemá cit pro to, co je triviální a co náročné.

Setkal jsem se třeba s tím, že zpracování čísla po (desítkových) číslicích se řešilo převedením čísla na string, rozsekáním na číslice a převáděním jednotlivých číslic (stringů) zase na číslo. Pokud člověk nechápe, že aritmetické operace přímo odpovídají instrukcím procesoru, zatímco převod čísla na string nebo naopak je mnohonásobně náročnější, tak mu prostě nedojde, co je na tom špatně.

[pc2005]

Setkal jsem se třeba s tím, že zpracování čísla po (desítkových) číslicích se řešilo převedením čísla na string, rozsekáním na číslice a převáděním jednotlivých číslic (stringů) zase na číslo.

To byl jardíkův blogpost ne? Pamatuju si to taky .

[Michal Kubeček]

Možná… ale myslím, že jsem se s tím (nebo něčím velmi podobným) setkal víckrát.

[pc2005]

A jo, tak mě to vrtalo hlavou a donutilo mě to ten blog najít. Velmi podobné tomu co jsi psal .

P.S. Ty technické flamewary s ponkrácem mi chybí .

[ehm]

Jenže na to stačí základní představa o tom, jaké operace že to CPU zhruba umí provádět. Vysvětlovat to na reálném CPU vůbec není potřeba. Stačí nějaký hodně abstraktní a zjednodušený popis.

[Michal Kubeček]

Jistě, vždyť jsem psal, že není potřeba znát speciality konkrétní architektury, ale že je žádoucí mít nějakou základní představu, jak to funguje. Dnes ale bohužel programuje spousta lidí, kterým chybí i ta základní všeobecná představa.

[ehm]

Souhlasím.

[pc2005]

Chybně předpokládáš, že všechny kompilátory mají nejlepší možné mikrooptimalizace pro všechny architektury. Vlastně stačí i jen pokud nějaký kompilátor nemá mikrooptimalizaci pro konkrétní architekturu, kterou potřebuješ. Příklad iwMMXt v GCC nemá podporu autovektorizace, takže jde použít jen neefektivní intrinsic funkce nebo assembler. Nebo něco modernějšího: DSP c64x kernely.

[xkucf03]

Řešením by v takovém případě ale mělo být rozšíření kompilátoru – nikoli zanášení implementačních detailů do aplikace.

Chápu, že v praxi nemáš někdy na vybranou, nemůžeš čekat, až tvoje vylepšení kompilátoru přijmou a až se dostatečně rozšíří, takže to musíš nějak ohackovat, abys mohl program dokončit podle plánu. Ale nedělal bych z nouze ctnost a nepovyšoval tenhle přístup na nějaké umění nebo vzor.

[pc2005]

Hmm souhlas, zrovna v případě intelu je ta firma natolik velká, že by měla být samozřejmost, aby dodala kompletní mikrooptimalizační podporu do všech majoritních kompilátorů. Samozřejmě jiná věc je, že v realitě je to spíš utopie. Realistická možnost pak je buď ty mikrooptimalizace napsat sám (tedy nutná jejich znalost), nebo napsat inline mikrooptimalizovaný kód/dsp kernel sám (opět nutná znalost registrů), nebo to nechat neoptimalizovaný (ehmův post neplatí).

Teďka jsem si uvědomil, že já vlastně píšu programy tak, aby byly co nejvíc nezávislé do externích prostředků. Proto mám radši nízkoúrovňové jazyky, ke kterým jsem schopnej v případě krize napsat i hloupý kompilátor, než dependency hell jako je třeba nodeJS.

[ehm]

Chybně to předpokládám patrně proto, že to je naprosto minoritní case. Původní komentář mluvil obecně:

No pokud člověk programuje (nejen v céčku) a tohle neví, tak pak z něj padaj dost šílený algoritmy, co sice matematicky fungujou, ale na reálném HW se chovají naprosto nemožně neefektivně.

Tak jak to je? Znalost registrů a adresace paměti je zcela nezbytná pro to, aby dotyčný mohl navrhovat efektivní algoritmy, a nebo je užitečná ve speciálních případech, ale spíše až těch, kde je nezbytná spíše celková znalost assembleru?

[pc2005]

Původní komentář

Pak jsem z netu získal Athelp, to byla výhoda, tam jsem udělal znalostní skok tak během 14 dní

Když jsem psal o athelpu, tak se dá předpokládat, že se zabývám hlavně minoritními případy.

Když chce člověk zkopírovat C strukturu, tak je dobrý vědět, že se nevykoná najednou, protože ten příkaz je třeba jednořádkovej, ale že se ty data například nasypou do registrů a pak zase někam jinam do paměti. Samozřejmě pokud máš architekturu, kde máš malo registrů nebo nemáš registry vůbec, tak to bude fungovat jinak než v té první. Lowlevel (extrémní) příklad, USB host driver v kernelu. Je rychlejší udělat polling bufferu nebo inicializovat DMA? Kupodivu je rychlejší udělat polling, protože zápis control paketu má míň kroků než zápis registrů DMA řadiče (ale v céčku to je jeden příkad).

[Jendа]

ale že se ty data například nasypou do registrů a pak zase někam jinam do paměti

To podle mě potřeba není (a alespoň já tohle ve svém modelu nepotřebuju), stačí se zamyslet, že struktura je větší než třeba int a tak to asi bude trvat dýl.

USB host driver v kernelu. Je rychlejší udělat polling bufferu nebo inicializovat DMA?

Chtěl bych připomenout, že vlákno začalo totálními začátečníky.

[pc2005]

Důležité je to zda takhle uvažuje někdo, kdo začne na vyšším jazyku a jde dolů nebo programátor co začal a chce se zlepšovat.

No původně to bylo vlákno o gruntově trolím avataru . A pak se diskuze změnila na to, zda je potřeba být si vědom architektury počítače na to aby šly napsat efektivní programy. Jinak já za pořádnej začátek programování považuju stáhnutí (teda vlastně recover athelpu přes víkend, kterej jsem si stáhnul v pátek na disketě a byly chybný sektory) teprve pak jsem měl prostředky na to, abych mohl počítač skutečně ovládat.

[Bystroushaak]

K čemu? Jak to souvisí?

Vždyť to přímo jsou pointery :D

[ehm]

Na pochopení pointerů nepotřebuješ vědět nic o adresaci paměti v assembleru. Nebo jak ti pomůže vědět, co jsou třeba segmentové a bázové registry, jak funguje virtuální paměť apod.?

[pc2005]

Měli jsme přednášku na vejšce od Martina Mareše o tom jak optimalizovat umístění velkých matic do stránkované paměti .

Když někdo napíše hello world, tak je to samozřejmě jedno jak neefektivní kód bude. Ale když píšeš enkodéry dekodéry videa a zvuku, engine her, DSP nebo i blbé zpracovávání bitmap, tak se s inline assemblerem setkáš. A u vektorových operací si musíš pamatovat jak se ty vektorové registry skládaj do skalárů.

A nebo embedded MCU, kritické průmyslové aplikace a možná okrajově i HW/SW codesign.

[deda.jabko]

Ale když píšeš enkodéry dekodéry videa a zvuku, engine her, DSP nebo i blbé zpracovávání bitmap, tak se s inline assemblerem setkáš. A u vektorových operací si musíš pamatovat jak se ty vektorové registry skládaj do skalárů.

A nebo embedded MCU, kritické průmyslové aplikace a možná okrajově i HW/SW codesign.

Coz opravdu zacinajici programatori delaji kazdou chvili. Plus toto je tak specificka oblast, ze temer pro kazdy typ procesoru se to clovek musi naucit extra.

[Bystroushaak]

Na pochopení pointerů nepotřebuješ vědět nic o adresaci paměti v assembleru. Nebo jak ti pomůže vědět, co jsou třeba segmentové a bázové registry, jak funguje virtuální paměť apod.?

Samozřejmě to můžeš chápat jako abstraktní koncept, ve skutečnosti ale pořád nechápeš celek, neboť ti chybí odpověď na otázku „a proč to tak je? proč zrovna takhle a ne jinak?“ Což nemusí vadit, ale těžko někdy překročíš svůj stín a navrhneš například lepší systém, nebo pochopíš, kdy je možné ho obejít, nebo řešit úplně jinak.

[ehm]

To je ovšem mimořádně zajímavé, protože ještě před chvílí:

V tomhle mají výhodu highlevel jazyky (python / java), protože nejenom že přesné pochopení nevyžadují, ale taky navíc díky vyšší abstrakci nabízejí větší produktivitu. Což pro začátečníky znamená vyšší pocit že jim to k něčemu je.

Teď jsme u toho, že společně s C je potřeba vyučovat i assembler, protože to sice k ničemu není, ale rozšiřuje to obzory a budoucí kernel hackeři, kterých se ze všech programátorů v C rekrutuje zlomek, se bez toho stejně neobejdou. To pak můžeme jít rovnou přes elektrotechniku a pak fyziku a zkoumat, z jakých atomů a jak je složen tranzistor a jak jsou z tranzistorů poskládána hradla a jak funguje atomová elektrárna, která počítačům dodává proud, protože to všechno taky rozšiřuje obzory, někomu by se to mohlo v budoucnu hodit a zanedbatelný zlomek lidí se bez toho v budoucnu neobejde, tak to raději budeme učit všechny.

[pc2005]

Přesně tak .

[Bystroushaak]

To je ovšem mimořádně zajímavé, protože ještě před chvílí:

V tomhle mají výhodu highlevel jazyky (python / java), protože nejenom že přesné pochopení nevyžadují, ale taky navíc díky vyšší abstrakci nabízejí větší produktivitu. Což pro začátečníky znamená vyšší pocit že jim to k něčemu je.

Ano.

Teď jsme u toho, že společně s C je potřeba vyučovat i assembler, protože to sice k ničemu není, ale rozšiřuje to obzory a budoucí kernel hackeři, kterých se ze všech programátorů v C rekrutuje zlomek, se bez toho stejně neobejdou. To pak můžeme jít rovnou přes elektrotechniku a pak fyziku a zkoumat, z jakých atomů a jak je složen tranzistor a jak jsou z tranzistorů poskládána hradla a jak funguje atomová elektrárna, která počítačům dodává proud, protože to všechno taky rozšiřuje obzory, někomu by se to mohlo v budoucnu hodit a zanedbatelný zlomek lidí se bez toho v budoucnu neobejde, tak to raději budeme učit všechny.

Tak ale samozřejmě. O tom jsem mluvil už od začátku! To je přece úplně normální obsah výuky elektro/IT průmky. Nebo vy jste neměli fyziku a číslicovou techniku? To píšeš, jak kdyby to bylo něco extra.

Ten přístup kdy to začátečníky nenaučíš je jako učit matematiku jako vzorce. Pokud se naučíš používat vzorec pointerů, tak ti to sice může stačit, ale těžko můžeš dělat matematiku. Je to pro tebe jen fakt co si pamatuješ, ale ve skutečnosti mu nerozumíš, nechápeš konsekvence a myslíš si, že to tak je prostě protože ti to někdo řekl. Imho je lepší začít od axiomů a postupně si skládat obraz světa, kde jsi schopný si odvodit, protože pak můžeš skládat libovolné jiné korektní vzorce a například plynule přejít k programování FPGA, tvorbě vlastního kompilátoru, nebo na úplně jiné architektury. Dokud to nechápeš, tak jsi odsouzen bloudit v limitech toho, co ti určili jiní.

Já jsem psal o problémech, které s tím mají začátečníci, kterým se další teorie nedostane. To jsem tak nějak viděl kolem sebe a vůbec nedivím, že jsou pro ně pointery opruz co pořád zapomínají a všechno ostatní je taky oser, protože C bez assembleru nejde skutečně pochopit, ve smyslu že nepochopíš designové rozhodnutí, které za ním stály a je z toho pro tebe jen kopa bullshitu, který si někdo náhodně vymyslel, když se nudil. Asi jako když tě někdo naučí ax² + bx + c = 0. Může to být pro tebe použitelný nástroj, kterému ale nerozumíš, dokud nechápeš i zbytek a ideálně i historii.

[xkucf03]

Imho je lepší začít od axiomů a postupně si skládat obraz světa, kde jsi schopný si odvodit, protože pak můžeš skládat libovolné jiné korektní vzorce a například plynule přejít k programování FPGA, tvorbě vlastního kompilátoru, nebo na úplně jiné architektury. Dokud to nechápeš, tak jsi odsouzen bloudit v limitech toho, co ti určili jiní.

Myslíš, že dneska může existovat renesanční člověk, který bude rozumět všemu, obsáhne všechny ty vrstvy? Podle mého už dávno ne, protože lidské poznání je tak rozsáhlé, že to v silách jednoho člověka není.* Takže si musíš vybrat, kterou část toho vědění si načteš do paměti a u zbytku jsi odkázaný na spolupráci s jinými lidmi. Pokud začneš odspodu, tak sice můžeš psát efektivní algoritmy pro konkrétní procesor, ale chybí ti to nad tím – tam ti musí někdo jiný říct, co má ten program dělat, jak má komunikovat s člověkem, s jakými jinými systémy se má spojit… Naopak když se soustředíš na tu horní část, vrchní vrstvy abstrakce, tak občas můžeš potřebovat někoho, kdo ti pomůže s těmi nízkoúrovňovými optimalizacemi.

Pokud zvládneš oboje, tak fajn, tím líp pro tebe, ale pokud bych si měl vybrat, tak bych se soustředil víc na ty vyšší vrstvy**, protože ty nižší vrstvy za tebe většinou vyřeší kompilátor a rychlý HW (stačí to nepsat vyloženě hloupě a nedělat zjevné chyby, na které člověk přijde i selským rozumem bez znalosti registrů procesoru) a kdyby bylo nejhůř tak si najdeš někoho, kdo ti s tím pomůže.

*) spíš mi přijde, že lidstvo jako celek dokonce ztrácí některé znalosti/dovednosti, které dřív mělo – něco je zapsané v knihách, takže se to dá načíst zpět, ale není tam všechno a některé postupy je potřeba složitě reprodukovat, v podstatě je objevit znovu

**) pokud není podstatou mojí práce to Jádro nebo optimalizace algoritmů, jak už jsem tu psal

[Bystroushaak]

Myslíš, že dneska může existovat renesanční člověk, který bude rozumět všemu, obsáhne všechny ty vrstvy? Podle mého už dávno ne, protože lidské poznání je tak rozsáhlé, že to v silách jednoho člověka není.* Takže si musíš vybrat, kterou část toho vědění si načteš do paměti a u zbytku jsi odkázaný na spolupráci s jinými lidmi. Pokud začneš odspodu, tak sice můžeš psát efektivní algoritmy pro konkrétní procesor, ale chybí ti to nad tím – tam ti musí někdo jiný říct, co má ten program dělat, jak má komunikovat s člověkem, s jakými jinými systémy se má spojit… Naopak když se soustředíš na tu horní část, vrchní vrstvy abstrakce, tak občas můžeš potřebovat někoho, kdo ti pomůže s těmi nízkoúrovňovými optimalizacemi.

Záleží na úrovni. Vědění je do jisté míry fraktální a záleží, jak moc hluboko do toho fraktálu jdeš. Ale všechno to o čem jsem psal byly běžné věci, které se učili na střední ještě před 10 lety. My jsme třeba probírali modely atomu, jak fungují vodiče, nevodiče a polovodiče na úrovni valenčních sfér, jak jsou z toho pak postaveny diody a tranzistory a jak jsou z nich tvořeny logická hradla a z nich (to už ale až na VŠ) počítače, jak se řeší časování, jak je udělaný procesor a jak pro něj vypadá assembler (na to jsme měli emulátor toho CPU). A pak ti na to krásně naváže C a vyšší jazyky pak na C. A stejně si nepřipadám, že by mě to nějak omezovalo v pochopení třeba Lispu, nebo Smalltalku, nebo lambda calculu.

Co jsem chtěl původně říct je, že pokud si v hlavě nestavíš axiomatický model reality, tak to prostě nemůžeš pořádně pochopit. Je to jako se učit matematiku tím že se budeš učit vzorce nazpaměť a nechápat přitom vztah třeba s geometrií, nebo ekvivalentní úpravy a transformace. Je to možné tak provozovat, ale je to nesrovnatelně těžší a nepraktické oproti tomu chápat jak spolu vše souvisí, protože to prostě dává v tvém interním modelu světa smysl.

[ehm]

Takže pro výuku C je potřeba jít do těch low level záležitostí, vč. fyzikálních zákonů a nanotechnologií, ale u Pythonu to potřeba není? Protože o tom se bavíme celou dobu. Ne o vzdělávání obecně a o tom, že je skoro vždycky výhodné rozumět věcem do co největší hloubky, ale o tom, že podle tebe je nezbytné pro výuku C zabřednout do assembleru (a jako příklad jsi uváděl registry a adresaci paměti na úrovni CPU).

Já se nepřu o to, že C jako první jazyk většinou není vhodné (pokud o to dotyčný z nějakého důvodu nemá sám zájem), právě proto, že je příliš technické a programování v něm je náročnější než ve vysokoúrovňových jazycích, ale to fakt ještě neznamená, že musíš jít do assembleru/konrétních detailů CPU. Reálně potřebuješ lidem vysvětlit Von Neumannovu architekturu, na jakém principu fungují datové typy (ve smyslu, že z libovolného místa v paměti můžeš přečíst pár bajtů a interpretovat je jako libovolný typ, ale nemusí to pak dávat smysl) a pro jistotu se zmínit o tom, že adresní prostor jednotlivých programů je oddělený. Ani není potřeba vysvětlovat virtuální paměť a jak funguje překlad virtuálních adres na fyzické apod., protože kdyby existovaly jen fyzické adresy a operační systém si nějak „pohlídal“, aby se bloky paměti přidělené jednotlivým procesům nikdy nepřekrývaly a „nějak“ (emulací) si pohlídal přístupy adresy z jiných rozsahů, tak to pro tebe v drtivé většině případů nebude hrát vůbec žádný rozdíl.

[Bystroushaak]

Takže pro výuku C je potřeba jít do těch low level záležitostí

Jestli mi ještě někdo vloží do úst slovo potřeba, tak se vystavuje nebezpečí vypíchnutí oka propiskou.

Pythonu to potřeba není? Protože o tom se bavíme celou dobu. Ne o vzdělávání obecně a o tom, že je skoro vždycky výhodné rozumět věcem do co největší hloubky, ale o tom, že podle tebe je nezbytné pro výuku C zabřednout do assembleru (a jako příklad jsi uváděl registry a adresaci paměti na úrovni CPU).

Python (ale i taková Java) je od toho hodně odstíněná, doslova oba jazyky se tě snaží odstínit od hardware kde to jen jde. Takže si troufám tvrdit, že by to byl sice bonus, ale důležité to není. Oproti tomu C je přímo svázané s hardwarem počítače, je to v podstatě jen takový makroassembler, který sice odstiňuje konkrétní instrukční sadu, ale například už ne detaily paměti.

Reálně potřebuješ lidem vysvětlit Von Neumannovu architekturu, na jakém principu fungují datové typy (ve smyslu, že z libovolného místa v paměti můžeš přečíst pár bajtů a interpretovat je jako libovolný typ, ale nemusí to pak dávat smysl) a pro jistotu se zmínit o tom, že adresní prostor jednotlivých programů je oddělený. Ani není potřeba vysvětlovat virtuální paměť a jak funguje překlad virtuálních adres na fyzické apod., protože kdyby existovaly jen fyzické adresy a operační systém si nějak „pohlídal“, aby se bloky paměti přidělené jednotlivým procesům nikdy nepřekrývaly a „nějak“ (emulací) si pohlídal přístupy adresy z jiných rozsahů, tak to pro tebe v drtivé většině případů nebude hrát vůbec žádný rozdíl.

Tak samozřejmě. Taky nemusíš vysvětlit nic, prostě před ně dát kompilátor a nechat je programovat. Dokonce i děti jsou schopné se to prostě jen tak naučit používat a budou schopny to používat. Jenže se podívej na to kolik lidí je takhle naučeno C třeba ve škole a kolik lidí to skutečně pochopí a má snahu v tom dál pokračovat. Z mých zkušeností plyne, že asi tak něco kolem 20 až 30%.

[ehm]

v podstatě vyžadují naučit je ještě k tomu assembler

?

[Bystroushaak]

v podstatě vyžadují naučit je ještě k tomu assembler

[ehm]

¯\_(ツ)_/¯

[Bystroushaak]

¯\_(๏̯͡๏)_/¯

[xkucf03]

Na druhou stranu: pokud se budeš hrabat v implementačních detailech procesorů a assemblerech, tak ti nezbude mentální kapacita na to, abys vymyslel něco nového na vyšších úrovních abstrakce. Jde o to, jak hluboko se chceš ponořit a co ti to přinese. Nakonec k vytvoření lepšího softwaru nebo k nějakému revolučnímu objevu ti může pomoci víc třeba studium ekonomie, psychologie nebo náhodné jiné vědy nebo oboru, než studium vnitřností x86. Jde o to, co je efektivněji investovaný čas do studia. Pokud chce někdo přispívat do Jádra nebo psát nějaké extrémně optimalizované algoritmy, tak jistě zvolí to první. Pokud ale někdo chce tvořit aplikace a pohybovat se spíš na vyšších úrovních abstrakce, dál od procesoru a blíž k uživateli, tak bych doporučoval studovat raději jiné věci.

[Grunt]

No ono se ještě v době DOSu přímo přistupovalo k HW, takže jedno nevylučovalo druhé. Naopak. Chtěl si-li napsat něco co i fungovalo (podívej se někdy do zdrojáků DOOMa) tak to ani jinak než bez podrobných znalostí toho na čem to píšeš nešlo. Žádný optimalizátor to za tebe neudělal.

[deda.jabko]

No ono se ještě v době DOSu přímo přistupovalo k HW, takže jedno nevylučovalo druhé.

Abstrakce, ktere se v te dobe pouzivaly, byly z duvodu omezeni hardwaru hodne primitivni. Proto se taky software pri prechodu na windows prepisoval od nuly, misto toho, aby se jen vymenila vrstva UI.

Žádný optimalizátor to za tebe neudělal.

Ano, tehdy byli ruzni guru, kteri vedeli, ze ++i je v tom a tom pripade rychlejsi nez i++. Nebo, ze volani funkci a procedur je drahe, proto vsechno naprali do jedne velke funkce. Kde je jim konec?

[pc2005]

Souhlas, ale programátor vyšší abstrakce je pak závislý na těch low level knihovnách a pokud se mu nelíbí jejich výkon, tak se musí ponořit do jejich kódu plného low level optimalizací.

[Michal Kubeček]

To není IMHO moc pravděpodobné. Dneska už je to prostě jiný obor. Samozřejmě se najdou výjimky schopné (a ochotné) začít se po letech najednou věnovat něčemu úplně jinému (a třeba i úspěšně), ale jsou to opravdu spíš výjimky.

[pc2005]

Jenže pokud jedna pomalá high level knihovna používá jinou pomalou high level knihovnu, tak se to pak nasčítá a není nikdo, kdo by to optimalizoval.

[Gilhad]

Klasika u Arduina :) (A většina začátečníků silně věří, že to přesně takto musí být)

Koupil jsem si modul se sedmisegmentovkama, k tomu knihovna od výrobce, tak samozřejmě člověka první napadne udělat hodiny. No, šly. Refreš displeje tak 10/sec, procesor vytížený na 100%, blikání při tom neuvěřitelné a navíc předchozí číslice měly "duchy" ze všech následujících - no katastrofa.

Tak kouknu do knihovny, zbastlená hrozně, ale v jakési poznámce obložené rozsypaným čajem číslo obvodu. Na tom modulu se taky dalo najít, takže stáhnu datasheet a je jasno. Ty prasárny v tom kódy byly jen nepatrná špička ledovce. Ten obvod byl posuvný registr, byl tam dvakrát, číňan do něj sypal bity jeden za druhým, každý rovnou přepsal na výstup a výstup povolil (pokaždé, ačkoli povolený od minula už byl)

Tak jsem to tak trochu úplně přepsal, jak to asi tvůrce chipu zamýšlel - nasypat tam celou délku tech obvodů dat, pak to jedním příkazem poslat na výstup, který se povolil jen jednou, při startu funkce. Navíc voláno z interruptu 100/sec, číslice si ani neblikly, duchové zmizeli, procesor se vyloženě flákal.

A celá knihovna byla o polovinu kratší a násobně přehlednější. (Jo, šlo by to ještě řádově urychlit, kdybych použil dedikované piny a stroják, ale jaksi už nebylo proč se tím zabývat, takhle to bylo obyčejné Céčko a přehledné, ušetřit pár promile výkonu za tu komlikaci a vazbu na konkrétní piny mi už nestálo.)

[pc2005]

Jo to je častý

[Gilhad]

Na druhou stranu už to, že mám v ruce příklad, že HW funguje a jak se to ovládá (a co za šváby tam je a že takhle blbé fungování odpovídá specifikaci) a dá se od něčeho odpíchnout je lepší, než nevědět zhola nic. A pak se to dá dostat "postupně zlepšovací metodou" do příčetného stavu, přičemž když to přestane chodit, tak vím, že chyba je jen v posledním kroku a ne v tom, že jsem zapoměl inicializovat nějaký obskurní vnitřní registr v přesně ten správný okamžik ...

V tomhle je Arduino dobré, že pro skoro každý obskurní HW je nějaká (byť často úděsně zpatlaná) knihovna, která ho "nějak" zinicializuje a předvede "nějaké" použití. a tak je z čeho vyjít.

Pokud to člověk nebere jako Slovo Boží, ale jako první přiblížení k preview demo verzi, tak to docela pomáhá.

[Bystroushaak]

Na druhou stranu: pokud se budeš hrabat v implementačních detailech procesorů a assemblerech, tak ti nezbude mentální kapacita na to, abys vymyslel něco nového na vyšších úrovních abstrakce.

To mi přijde jako velmi, velmi, velmi hrubé podcenění kapacity lidského mozku. Asi jako říct, že pokud si přečteš Euklidovy základy, tak už ti nezbyde kapacita na to pochopit abstraktní matematiku.

[xkucf03]

I kdyby se ti to do hlavy vešlo, tak musíš počítat ty hodiny nebo dny, které strávíš studiem dané věci, a které jsi mohl věnovat něčemu jinému – např. psaní programů se svými stávajícími znalostmi.

[ehm]

To asi myslel souběžně, tj. v jednu chvíli řešit technické detaily i vyšší abstrakci, a to těžké opravdu je. Nebo rozhodně těžší než věnovat se jen té abstrakci.

[Gilhad]

No já jsem pořádně začal programovat až v TurboPascalu (jasně, předtím nějaké ty basicy, jiné pascaly, assemblery a tak, ale 100 řádků už byl sakra dlouhý a složitý program, v TP 1000 řádků pohoda) a když přišel TP 5.5 s objekty a TurboVision, tak ty vyšší abstrakce pořád ne a ne naskočit, dokud jsem si v TurboDebuggeru neprošel, jak vlastně ty objekty fungují pod pokličkou (že to je jen starý známý record s tabulkou virtuálních funkcí a nějakou hlavičkou před sebou) a jak fungujou ty message v TV (že to vlastně je jen nějaký record, co si mezi sebou přeposílají určité funkce v určitém pořadí podle zanoření visuálních objektů). Pak to najednou začlo dávat všechno smysl a šlo psát i na vyšší úrovni abstrakce (takže si objekty posílaly zprávy o stošest a dědilo se horem dolem).

Dokud jsem se věnoval jen té abstrakci, tak to nějak moc smysl nedávalo a bylo tam moc magie pod povrchem a věci se "nějak děly samy" aniž bych tušil proč a jak. pak jsem za dvě odpoledne prolezl základy té implementace a najednou ta abstrakce byla jasná a bez magie (že bych ta střeva tehdy dokonale pochopil se sice říct nedá, ale aspoň rámcově bylo jasné o co tam fakt jde a magie zmizela, nahrazena dostatečně pokročilou technologií).

Takže aspoň za mě ANO, mít nějaké základní ponětí co je pod povrchem velice pomáhá v pochopení a přijmutí vyšších abstrakcí.

(jak si stěžovala ta blondýna: "Učitel matiky si na mě zasednul. Samozřejmě, že vím, že pravoúhlý trojelník je A^2 + B^2 = C^2, ale on mi zadal D, E, F a to jsme ještě nebrali ...")

[ehm]

Takže aspoň za mě ANO, mít nějaké základní ponětí co je pod povrchem velice pomáhá v pochopení a přijmutí vyšších abstrakcí.

O to se určitě nepřu. Myslel jsem to tak, že při současném řešení abstrakce i technických detailů výsledek nebude tak dobrý, jako kdyby se člověk jen jedné z těch dvou věcí. To je rozdíl, který pociťuji, když dnes zkouším něco psát v C (které jsem víceméně opustil ve prospěch vyšších jazyků). Ale po opětovném přečtení #304 musím říct, že to není to, co měl Franta na mysli.

Ono je to dost individuální. Obecně je dobré toho umět co nejvíc, ale naučit se všechno nelze, takže je to vždy něco na úkor něčeho. Pak je to o nějakém kompromisu. Já jsem v tomhle anarchista a prostě ať se každý učí, co uzná za vhodné.

[Gilhad]

No mě tady právě přesně k pochopení té vyšší abstrakce a řešení věcí na její úrovni velice pomohlo krátké zabrousení do technických detailů.

Pravda teď píšu převážně v Pythonu, občas v céčku, ale i tak mi "tušení souvislostí" čas od času velice pomůže, zvlášť když jde o nějaké složitější, nebo časově kritičtější místa - aniž bych přesně znal detaily, tak dokážu odhadnout, která to tak asi jsou a jak to asi řešit efektivněji a následné testy mi většinou dají za pravdu.

[pc2005]

Jj "tušení souvislostí" to je přesný .

[Jendа]

Já furt nějak nechápu proč je pro použití pointerů potřeba „vědět, že CPU má nějaké registry, k čemu slouží, jak funguje přímá a nepřímá adresace paměti“. Respektive proč je to potřeba vědět více, než když chci na podobné úrovni chápat nějaký high-level jazyk - tam se k tomu navíc přidává bytecode, JIT a další věci.

[Bystroushaak]

Já furt nějak nechápu proč je pro použití pointerů potřeba „vědět, že CPU má nějaké registry, k čemu slouží, jak funguje přímá a nepřímá adresace paměti“. Respektive proč je to potřeba vědět více, než když chci na podobné úrovni chápat nějaký high-level jazyk - tam se k tomu navíc přidává bytecode, JIT a další věci.

Já jsem ale nepsal, že je to potřeba, jen že se to hodí.

Jinak viz #311. Tldr: pokud začneš od axiomů, tak ti věci dávají větší smysl, protože budovaný mentální model je vnitřně konzistentní a obsahuje minimum informací typu "tady je fakt X, který prostě uznávám že tak je, protože proto". Pokud víš jak funguje assembler (a adresování a způsoby přístupu k paměti), pointery jsou pro tebe naprosto přirozená věc, která dává logický smysl.

[ehm]

To jsi to otočil fakt ale hodně jinam.

Ono je obecně problém, že lowlevel jazyky, jako třeba C, po tobě chtěj lowlevel znalosti počítače, specificky CPU a paměti. A ty začátečníkům většinou nikdo nesdělí, protože v podstatě vyžadují naučit je ještě k tomu assembler a povyprávět jim o architektuře.

CPU ani moc ne. Spíš jde o tu paměť, datové typy atp. Se zbytkem komentáře souhlasím.

Tak třeba se hodí vědět, že CPU má nějaké registry, k čemu slouží, jak funguje přímá a nepřímá adresace paměti a tak. Pak nemáš problém pochopit pointery.

^ Prostě ne.

Že se někdy nějak hodí umět asm, elektrotechniku, fyziku, matematiku a whatnot? Jasně. Ale určitě to není pro učení úplných začátečníků C potřeba o mnoho víc než u high level jazyku.

[Bystroushaak]

To jsi to otočil fakt ale hodně jinam.

Ono je obecně problém, že lowlevel jazyky, jako třeba C, po tobě chtěj lowlevel znalosti počítače, specificky CPU a paměti. A ty začátečníkům většinou nikdo nesdělí, protože v podstatě vyžadují naučit je ještě k tomu assembler a povyprávět jim o architektuře.

CPU ani moc ne. Spíš jde o tu paměť, datové typy atp. Se zbytkem komentáře souhlasím.

Tak třeba se hodí vědět, že CPU má nějaké registry, k čemu slouží, jak funguje přímá a nepřímá adresace paměti a tak. Pak nemáš problém pochopit pointery.

^ Prostě ne.

Jak, prostě ne? To se tu hádáš, že když rozumíš assembleru, tak že budeš mít problém pochopit pointery?

Že se někdy nějak hodí umět asm, elektrotechniku, fyziku, matematiku a whatnot? Jasně. Ale určitě to není pro učení úplných začátečníků C potřeba o mnoho víc než u high level jazyku.

Ok, tak to máme nějaké tvrzení. Teď ho podlož argumenty. Já už jsem argumentoval dost.

[ehm]

To se tu hádáš, že když rozumíš assembleru, tak že budeš mít problém pochopit pointery?

Hádám se, že porozumění assembleru není prerekvizitou pro pochopení pointerů.

Ok, tak to máme nějaké tvrzení. Teď ho podlož argumenty.

To je na úrovni axiomu. Nevím, jak mám podložit argumenty, že paměť jako indexovatelné pole bajtů je koncept pochopitelný sám o sobě a např. znalost toho, jak dementně se na 80286 adresuje paměť pomocí dvojice registrů, nebo toho, jak se inicializuje long mode, je vůči tomu zcela irelevantní.

To je jako bys v diskuzi o učení prvňáčků řekl, že pochopení čísel v podstatě vyžaduje pochopit číselné soustavy a obory čísel a argumentoval, že člověk, který umí z hlavy převádět mezi dvojkovou a sedmičkovou soustavou asi nebude mít problém s počty. Asi nebude. Ale je to rozšiřující, prohlubující znalost, nikoliv znalost, kterou je potřeba si osvojit pro naučení se základního používání desítkové soustavy (na úrovni té první třídy).

Taky existují věci jako LLVM IR, které od těch technických detailů odstiňují a vytváří abstrakci, která je blíže tomu, o čem jsem mluvil já v #316. To by nebylo možné, kdyby v C prostě nešlo psát bez pochopení těch registrů a adresace.

[Bystroushaak]

To je jako bys v diskuzi o učení prvňáčků řekl, že pochopení čísel v podstatě vyžaduje pochopit číselné soustavy a obory čísel a argumentoval, že člověk, který umí z hlavy převádět mezi dvojkovou a sedmičkovou soustavou asi nebude mít problém s počty. Asi nebude. Ale je to rozšiřující, prohlubující znalost, nikoliv znalost, kterou je potřeba si osvojit pro naučení se základního používání desítkové soustavy (na úrovni té první třídy).

Ok, tenhle argument uznávám. Jenže to není všechno, protože po těch prvňácích hned chvíli potom při v podstatě úplně libovolném programu ty znalosti vyžaduješ. V C ti nestačí pochopit jen tu základní úroveň, protože hned jakmile se dostaneš z úrovně triviálních příkladů, tak potřebuješ chápat všechno možné, kde dokonce i po letech sám s překvapením shledávám, že se mám pořád hodně co učit.

[pc2005]

No u lowlevel jazyků jsi od reálného Hw jen velmi málo odstíněn na rozdíl od high level jazyků, kde to filtruje třeba interpreter nebo VM. Na lowevel jazyku vlastně přímo záležíš na kompilátoru, jehož podpora HW nemusí být kompletní. U třeba javy záležíš na VM, což je ale jen jiný program. VM u jednoho jazyka je obvykle méně než targetů kompilátoru C jazyka.

[Jendа]

Já jsem ale nepsal, že je to potřeba, jen že se to hodí.

Ono je obecně problém, že lowlevel jazyky, jako třeba C, po tobě chtěj lowlevel znalosti počítače, specificky CPU a paměti. V tomhle mají výhodu highlevel jazyky (python / java), protože přesné pochopení nevyžadují

---

Tldr: pokud začneš od axiomů, tak ti věci dávají větší smysl, protože budovaný mentální model je vnitřně konzistentní a obsahuje minimum informací typu "tady je fakt X, který prostě uznávám že tak je, protože proto".

protože C bez assembleru nejde skutečně pochopit, ve smyslu že nepochopíš designové rozhodnutí, které za ním stály a je z toho pro tebe jen kopa bullshitu, který si někdo náhodně vymyslel, když se nudil

A taková cesta bude mnohem delší k Pythonu než k C.

---

(a adresování a způsoby přístupu k paměti)

Asi nevím co máš na mysli adresováním a způsoby přístupu k paměti, protože to, co si pod tím představím já, je před programem v C skryto…

Oproti tomu C je přímo svázané s hardwarem počítače, je to v podstatě jen takový makroassembler, který sice odstiňuje konkrétní instrukční sadu, ale například už ne detaily paměti.

Můžeš uvést příklad takových detailů?

[Bystroushaak]

A taková cesta bude mnohem delší k Pythonu než k C.

Jo, to určitě bude. Rozdíl je v tom, že v pythonu jsi z 99% schopný bez toho žít. V C na to narazíš hned jak chceš třeba otevřít socket a poslat něco do internetu (to tě najednou endianita zajímá).

Asi nevím co máš na mysli adresováním a způsoby přístupu k paměti, protože to, co si pod tím představím já, je před programem v C skryto…

Pokud znáš a chápeš assembler (a nemusí to být zrovna x86 assembler), C je pro tebe otázkou syntaxe. Jestliže pochopíš princip fungování skoků a porovnání hodnoty v assembleru, for smyčka je naprosto přirozený pattern, který jsi v assembleru používal a který je v C vyjádřený zkrácenou syntaxí. Funkce to samé. Když umíš adresovat paměť přes registr, což je v assembleru naprosto nativní záležitost na dvě instrukce, tak chápeš pointery. A to ne nějak abstraktně, jako "když se před tím udělá hvězdička, tak dostaneš hodnotu", ale skoro na hardwarové úrovni. Ano, konkrétní implementace je ti v C skryta, ale bavím se tu o opačném procesu - pokud to pochopíš odzdola, tak je pro tebe to co se děje v C naprosto logický důsledek. Přitom naučit se jednoduchý assembler je otázkou pár hodin. Není to složitější, ale naopak jednodušší! A získáš tím axiomy, ze kterých jsou složeny vyšší jazyky.

Ve chvíli, kdy s tím začínáš naopak (odshora), tak to pak končí tak jak popisoval pc2005, tedy že lidi mají problém s pointery. Což je mimochodem úplně běžná záležitost. Například u nás ve třídě o 20 lidech to chápala možná tak 1/4, možná míň. A na VŠ, kam nás na hodiny C chodily stovky lidí udělalo napoprvé zkoušky asi tak těch zmiňovaných 20-30%. Osobně jsem tenkrát nechápal, proč když chápou Javu je C tak strašně sere. Teď si zpětně říkám, že to pro ně možná prostě byla kolekce věcí, co jim nedávají žádný smysl a jednoduše si je musí pamatovat. Asi jako když se učíš dějiny jako data (kdy kdo co), versus když se udíš dějiny jako navazující příběhy v kontextu doby. Tím nechci tvrdit, že se to nikdo nenaučí, ale že naopak je to jednodušší, dává to větší smysl a má to lepší úspěšnost, i přestože to vyžaduje větší časovou investici.

Můžeš uvést příklad takových detailů?

Tak konkrétně třeba ta endianita. Šířka slova. Segmenty paměti a její ochrana. Pokud se bavíme i mimo pamět, tak například podmínky, smyčky a funkce mají přímý protikus v assembleru, kde když v něm chvíli děláš (stačí i docela triviální programy na pár odpolední nepřesahující tisíc instrukcí), tak si prostě musíš všimnout, že některé patterny instrukcí se neustále opakují. Přestává to pro tebe být otázkou pochopení úplně neznámých konceptů, ale je to jen otázkou syntaxe těch konceptů. A navíc máš porozumění nejenom jak ty koncepty vypadají a jak spolu fungují, ale taky proč existují, co k tomu vedlo proč to nevypadá jinak.

[Jendа]

to tě najednou endianita zajímá

Nezajímá, getaddrinfo se dává description jako string a pak udělám connect rovnou na to co to vrátilo . A pokud jde o interpretaci dat protistranou, tak ve vyšším jazyku to také musím nějak zabalit (tam je navíc začátečníkovi potřeba vysvětlit, že spousta serializačních způsobů umožňuje při deserializaci spustit libovolný kód).

for smyčka je naprosto přirozený pattern, který jsi v assembleru používal a který je v C vyjádřený zkrácenou syntaxí. Funkce to samé. Když umíš adresovat paměť přes registr, což je v assembleru naprosto nativní záležitost na dvě instrukce, tak chápeš pointery.

No dobře, a proč je pochopení for cyklu, funkcí a pointrů v C něco jiného než pochopení for cyklu, funkcí a pass-by-reference v high-level jazycích?

lidi mají problém s pointery [...] i když chápou Javu

Dal bych jim nějaký test na věci jako

a = [3, 1, 2]
def f(x):
    x.sort()
f(a)

(a podobné ekvivalenty s poli a objekty v Javě), podle mě bys pak to „chápou Javu“ přehodnotil.

Šířka slova.

IMHO ekvivalentní s datovými typy třeba v Javě.

Segmenty paměti a její ochrana.

S tímhle se v C nesetkáš dokud nezačneš dělat nějakou pokročilou magii (a pak budeš podobné znalosti potřebovat i v jiných jazycích).

[ehm]

pass-by-reference v high-level jazycích

*pass-by-value

[Bystroushaak]

No dobře, a proč je pochopení for cyklu, funkcí a pointrů v C něco jiného než pochopení for cyklu, funkcí a pass-by-reference v high-level jazycích?

Protože je to přímo spjaté s assemblerem. Funkce v C se přímo mapuje na sekvenci instrukcí. Oproti tomu funkce v pythonu je naprosto abstraktní koncept, který je ve skutečnosti objekt, mimo jiné například podporujicí closures. For smyčka je rozbalovač iterátorů, který se vůbec nemapuje na sekvence instrukcí „porovnej a skoč“ atd..

IMHO ekvivalentní s datovými typy třeba v Javě.

Až na to že je to na každé architektuře rozdílné.

S tímhle se v C nesetkáš dokud nezačneš dělat nějakou pokročilou magii (a pak budeš podobné znalosti potřebovat i v jiných jazycích).

S tím se setkáš hned jak ti to padne na sigsegv.

[xkucf03]

V C na to narazíš hned jak chceš třeba otevřít socket a poslat něco do internetu (to tě najednou endianita zajímá).

Tak zrovna ta tě zajímá vždycky i v jakkoli vyšším jazyce. Vždy musíš řešit, jak se číslo jakožto abstraktní koncept serializuje do proudu bajtů na výstupu. Nebo naopak, jak z posloupnosti bajtů naplnit nějakou číselnou proměnnou v tvém jazyce.

Když umíš adresovat paměť přes registr, což je v assembleru naprosto nativní záležitost na dvě instrukce, tak chápeš pointery.

Proč nestačí si představit paměť jako dlouhé pole bajtů a ukazatel jako číslo pozice v tomto poli? Proč je potřeba do toho tahat nějaké registry? Nebo to potřeba není, ale když to člověk pochopí, tak bude s ukazateli pracovat nějak líp a bude dělat méně chyb?

Možná mi něco zásadního uchází, ale já vidím úskalí a možné chyby hlavně v tom, že zapomeneš ukazatel nastavit a on bude ukazovat na nějaké nesmyslné místo v paměti, NPE, že paměť/data, kam ukazuje smažeš a pak použiješ ukazatel nebo naopak smazat zapomeneš a máš únik paměti. A aby ses s tímhle vypořádal, tak stačí ten abstraktní koncept (pole bajtů + číslo pozice), ne?

[Bystroushaak]

Možná mi něco zásadního uchází, ale já vidím úskalí a možné chyby hlavně v tom, že zapomeneš ukazatel nastavit a on bude ukazovat na nějaké nesmyslné místo v paměti, NPE, že paměť/data, kam ukazuje smažeš a pak použiješ ukazatel nebo naopak smazat zapomeneš a máš únik paměti. A aby ses s tímhle vypořádal, tak stačí ten abstraktní koncept (pole bajtů + číslo pozice), ne?

Samozřejmě že stačí. Jak jsem už v téhle diskuzi psal několikrát, tak určitě se dá všechno naučit jako abstraktní koncept. Osobně tady ale argumentuji ve stylu, že to má nižší úspěšnost, než když se věci učíš na základě axiomatických principů, tedy když jdeš odzdola, což navíc ještě jako bonus zajišťuje lepší porozumění. Napsal jsem to sem už asi potřetí, naposledy dokonce v příspěvku, na který reaguješ a už to nebudu opakovat. Přijde mi blbé to psát pořád dokola, když na to nikdo nereaguje.

[pc2005]

Jo může to být blackbox, takhle jsem na céčku vlastně taky začal. Ale pak člověk považuje segfaulty, ladění stacku v GDB, NULL za magii.

[pc2005]

C, po tobě chtěj lowlevel znalosti počítače, specificky CPU a paměti. A ty začátečníkům většinou nikdo nesdělí, protože v podstatě vyžadují naučit je ještě k tomu assembler a povyprávět jim o architektuře.

Jo tak proto mě céčko nikdy nějak nevadilo, já byl vždycky spíš lowlevel guy.

[funny story]Ještě před tím než jsem dostal počítač si ho snažil na základce postavit ho sám, aniž bych ještě věděl základy číslicovky. Někde mám snad dokonce i schéma, že jsem se snažil udělat něco jako registr pomocí pole tyristorů (protože to byla tehdy jediná součáska, kterou jsem znal, co měla paměťové vlastnosti). Pak jsem dostal pravej počítač (myslím konec 2000?), takže pokusy odvodit sčítačku z NANDu (bez znalosti demorgana) skončily. Ale zase už na konci střední se znalostmi 8051, a číslicovky jsem si sepisoval instrukční sadu vlastní procesorový architektury (před Cčkem). [/funny story]

[Bystroushaak]

[funny story]Ještě před tím než jsem dostal počítač si ho snažil na základce postavit ho sám, aniž bych ještě věděl základy číslicovky. Někde mám snad dokonce i schéma, že jsem se snažil udělat něco jako registr pomocí pole tyristorů (protože to byla tehdy jediná součáska, kterou jsem znal, co měla paměťové vlastnosti). Pak jsem dostal pravej počítač (myslím konec 2000?), takže pokusy odvodit sčítačku z NANDu (bez znalosti demorgana) skončily. Ale zase už na konci střední se znalostmi 8051, a číslicovky jsem si sepisoval instrukční sadu vlastní procesorový architektury (před Cčkem). [/funny story]

Jo, já si kdysi přečetl Astronauty od Lema a pak se to snažil vymyslet pomocí relátek implementovaných jako výhybky v kolejnici modelové železnice, kterou jsme měli na půdě. Nutno říct, že s naprostým neúspěchem.

[kralyk z abclinuxu]

Já se někdy loni na podzim bavil navrhováním trojkové architektury pro cosi něco jako jednoduchou herní konzoli (něco jako bývaly segy nebo podobně). Dokonce jsem napsal i základní ternární integery v Rustu, pro emulaci na běžném kompu, někde to mam... Ale vzdal jsem to a radši se vrátil k věcem, kde vidím větší reálnou využitelnost...

[pc2005]

Tak já se dostal jen k tomu "registru", pak už jsem si řešení vyspoiloval kompem a na střední v číslicovce (a teda hlavně samostudiem). Kdybych byl na opuštěným ostrově tak 20 let, tak bych se možná nakonec k něčemu jako eniac dostal .

[pc2005]

aniz by nekde vyhrezavaly pointery.

Já jsem nikdy nepochopil, proč lidi tolik řeší vyhřezávající pointery v Céčku, já si je normálně pamatuju o_O. Ale uznávám, že píšu krátký prográmky a GUI nemám rád.

Takze zacinajici programator se muze venovat reseni algoritmu misto toho, aby zapasil s jazykem a jeho implementaci.

To souhlas, ale zase v mladém věku je člověk víc flexibilnější a pokud se naučí v mechanismu Cčka myslet, tak tím zase kompenzuje tu strmou učící křivku.

Obcas vidim kod lidi 40+ a z jeho struktury jde velice casto poznat, kdo si prosel v mladi Pascalem a kdo ne.

Hmm podle mého kódu bys mě tipnul na malbolge :-P.

No při přechodu mezi pascalem a céčkem se ten pascal občas doslova plete do cesty.

[deda.jabko]

Já jsem nikdy nepochopil, proč lidi tolik řeší vyhřezávající pointery v Céčku, já si je normálně pamatuju o_O.

Protoze nejsi schopen se vzit do role cloveka, ktery zacina s programovanim uplne od zacatku.

Pro blbou praci s textem nebo vstupem od uzivatele (coz je snad ten nejvetsi zaklad) potrebujes mit predstavu o tom, jak pocitac funguje ve vnitr, coz je pro cloveka, ktery ma problem udelat for-loop to posledni, co ho zajima.

v mladém věku je člověk víc flexibilnější a pokud se naučí v mechanismu Cčka myslet

Tak programy od nej ve vyssich programovacich jazycich jsou docela peklo. Ceckar programujici v Jave to je kapitola sama pro sebe.

No při přechodu mezi pascalem a céčkem se ten pascal občas doslova plete do cesty.

Protoze kazdy ten jazyk ma jiny cil. V Pascalu mas duraz na srozumitelnost kodu, v C na jeho efektivitu. Coz jsou veci, ktere jdou evidentne proti sobe. Ale bavime se tu o zacinajicich programatorech, ... kde si myslim, ze by prioritou melo byt to prvni.

[Josef Kufner]

Já začínal v C po krátkém setkání s QBasicem. Pointery opravdu problém nejsou. Je potřeba pochopit, jak počítač funguje, jak vypadají data v paměti, a pak je to v pohodě. C je v podstatě jen o pointerech a funkcích. Když se tyhle dvě věci pochopí, C je zvládnuto.

Výhodou C je, že je rozlezlé úplně všude. Jeho pochopení pak usnadní pochopení ostatních technoologií, neboť z C vyrostly.

Aby se člověk mohl považovat za programátora, je nutné pak udělat krok stranou a očuchat si několik vysokoúrovňových jazyků – něco objektového, funkcionálnícho, a pak i něco obskuronějšího.

Pascal je jazyk na nic. Vysokoúrovňový není, aby se v tom dalo něco smysluplného dělat, a nízkoúrovňový, aby se věci daly pochopit, taky ne. Jediné, co se na něm začátečník má šanci naučit jsou cykly a podmínky. To ale v C jde taky, ale pak může v klidu pokracovat dál.

[xkucf03]

Pointery opravdu problém nejsou. Je potřeba pochopit, jak počítač funguje, jak vypadají data v paměti, a pak je to v pohodě.

Myslím, že nejde jen o to, to pochopit, ale hlavně to pak vždy a za všech okolností uhlídat, nedělat chyby, mít disciplínu… dát si s tím prostě tu práci. Pak třeba zjistíš, že hlídání nějakých pointerů, úniků paměti a ošetřování chybových kódů věnuješ víc úsilí než vlastní logice aplikace. Což je podle mého špatně a používáš nevhodný jazyk.

Aby se člověk mohl považovat za programátora, je nutné pak udělat krok stranou a očuchat si několik vysokoúrovňových jazyků – něco objektového, funkcionálnícho, a pak i něco obskuronějšího.

Souhlasím, že je dobré poznat víc jazyků a rozšiřovat si obzory. Ale otázka je, s čím začít a co přidat až později, čemu se věnovat primárně a co mít jen jako doplněk pro představu, jak to funguje jinde.

Ono to jsou dost odlišné světy a každý má svoje vlastní pravidla. V dnešní praxi to sice funguje tak, že ty vyšší jazyky se interpretují pomocí těch nižších nebo se do nich překládají a pod tím je vždycky nějaký procesor s nějakou architekturou a instrukční sadou. Ale smyslem té abstrakce je právě to, abych nemusel řešit, co je pod ní – pokud to řešit musím, tak je to špatná abstrakce. Je skutečně nutné ovládat principy těch nižších vrstev, když se pohybuješ v těch vyšších? A budou ty nižší vždy stejné, jako jsou teď?

Představ si třeba nějaký datový formát – má vlastní pravidla, vlastní gramatiku a pomocí něj tvoříš data, ze kterých se nakonec vyrobí třeba PDF. První implementaci daného formátu napsal někdo tak, že vzal třeba Perl, v něm přechroustal data, vygeneroval z nich zdroják v LaTeXu a to předal programu pdflatex. Možná to není optimální a nejčistší řešení, ale byl to způsob jak dosáhnout cíle a dát světu nějaký použitelný nástroj. Až v praxi se ukáže, zda má takový formát smysl, a časem třeba někdo napíše efektivnější, čistější nebo elegantnější implementaci. Tebe jako autora dokumentů v tom formátu by ale neměl zajímat Perl ani LaTeX – tyto implementační detaily bys neměl vůbec řešit a měl by ses soustředit na to, abys dodržoval pravidla daného formátu a pohyboval se v jeho paradigmatu, myslel na té úrovni abstrakce. Později se objeví jiný interpret/kompilátor toho formátu, který bude napsaný třeba v Javě a místo (La)TeXu bude používat FOP, nebo bude napsaný v Rustu či C++ a pro generování PDF bude používat jinou knihovnu. Kdybys psal svoje dokumenty s ohledem na Perl a LaTeX, tak by najednou nefungovaly, výstup by ti nevyhovoval. Musíš je psát pouze s ohledem na pravidla toho formátu. A stejně tak by se těmi pravidly měl řídit autor interpretu/kompilátoru. Pokud to nejde, tak je něco špatně s tím formátem. Dobrý formát by měl sloužit jako rozhraní, které tě odstíní od toho, co je na druhé straně a umožní bezproblémovou spolupráci různých implementací téhož standardu.

[pc2005]

A budou ty nižší vždy stejné, jako jsou teď?

Pořád to budou tranzistory . A až se přejde na kvantovou mechaniku, tak do toho stejně budu muset to učení investovat.

[kralyk z abclinuxu]

Ale smyslem té abstrakce je právě to, abych nemusel řešit, co je pod ní – pokud to řešit musím, tak je to špatná abstrakce.

Tohle IMHO není úplně význam abstrakce. Myslimže jsem ještě za celý život neviděl abstrakci, která by byla skutečně nezávislá na implementačních detailech. To IMHO není možné.

IMHO smyslem abstrakce není ani tak to, abys nemusel vůbec řešit, co je pod ní, ale abys to nemusel řešit příliš často, příliš do hloubky a aby ses nemusel opakovat (princip DRY).

Čiliže u abstrakce je IMHO stále potřeba chápat alespoň do nějaké míry ty detaily, ten benefit je v tom, že jakmile tu abstrakci vstřebáš, máš to už 'načtené' a nemusíš to řešit pokaždé, spíš než v tom, že to nemusíš řešit vůbec...

[deda.jabko]

Výhodou C je, že je rozlezlé úplně všude.

To bych mohl rict o Jave taky, pricemz vim, ze na vyuku programovani je Java opravdu spatny jazyk.

Pointery opravdu problém nejsou. Je potřeba pochopit, jak počítač funguje, jak vypadají data v paměti, a pak je to v pohodě. C je v podstatě jen o pointerech a funkcích.

Z vlastni zkusenosti muzu potvrdit, ze toto problem je.

Pascal je jazyk na nic. Vysokoúrovňový není, aby se v tom dalo něco smysluplného dělat, a nízkoúrovňový, aby se věci daly pochopit, taky ne.

Bavime se tu celou dobu o vyuce programovani. Pokud programovani zredukujes na zvladnuti programovaciho jazyka a schopnost vytvaret programy, je tvuj soud zrejme v poradku.

Ale programovani je i o dalsich vecech. Zrejme o schopnosti vzit problem a najit jeho reseni. Vzit ulohu, rozdelit ji na mensi pod ukoly, vytvorit kod, ktery bude srozumitelny, ... To C nenabizi, nebo obtezuje podruznymi detaily.

Mam nekolik programu, u nichz mam implementaci v nejakem vyssim jazyce (Java, Python, Scheme) a implementaci C (kvuli maximalni efektivite). Ty v C jsou typicky priblizne 10x vetsi co do poctu LoC. Kdybych to vztahl na toho zacatecnika, tak s C musi obrazne udelat 10x vic prace, pricemz ma 10x vic prilezitosti udelat chybu. Pricemz, to co se po nem chce, je jen implementovat algoritmus, ktery muze jinde udelat se zlomkem namahy.

Z dnesniho pohledu je Pascal uz za zenitem, ale nevidim prilis duvod, proc C jako prvni jazyk, kdyz je tu treba Python, ve kterem se da naucit programovat radove jednoduseji.

[Josef Kufner]

Výhodou C je, že je rozlezlé úplně všude.

To bych mohl rict o Jave taky,

Ne. C je to, z čeho hromady technologií vzešly. Koncepty a designová rozhodnutí v C se pak promítly do takřka všeho, co se dnes používá. Vliv Javy je v tomto ohledu docela malý.

Mam nekolik programu, u nichz mam implementaci v nejakem vyssim jazyce (Java, Python, Scheme) a implementaci C (kvuli maximalni efektivite). Ty v C jsou typicky priblizne 10x vetsi co do poctu LoC. Kdybych to vztahl na toho zacatecnika, tak s C musi obrazne udelat 10x vic prace, [...]

Úlohy musí být tvořeny s ohledem na použitý jazyk a volba jazyka se odvíjí od řešeného problému. Začátečník nebude dělat 10× více práce, neboť bude řesit jinou úlohu.

[kralyk z abclinuxu]

Mam nekolik programu, u nichz mam implementaci v nejakem vyssim jazyce (Java, Python, Scheme) a implementaci C (kvuli maximalni efektivite). Ty v C jsou typicky priblizne 10x vetsi co do poctu LoC. Kdybych to vztahl na toho zacatecnika, tak s C musi obrazne udelat 10x vic prace, pricemz ma 10x vic prilezitosti udelat chybu. Pricemz, to co se po nem chce, je jen implementovat algoritmus, ktery muze jinde udelat se zlomkem namahy.

+1, mám podobnou zkušenost.

To, že v C je vopruz dělat cokoli výše-úrovňového je dané jednak tím jazykem, ale z velké části také tím, že standardní knihovna toho moc nenabízí. Nemáš stringy, nemáš dynamické pole / vektory, stack, queue - zapomeň. Nemáš ani pitomou min/max funkci.

Z dnesniho pohledu je Pascal uz za zenitem, ale nevidim prilis duvod, proc C jako prvni jazyk, kdyz je tu treba Python, ve kterem se da naucit programovat radove jednoduseji.

+1, C mi taky nepřijde jako vhodný první jazyk... Případně když už, tak by asi bylo lepší spíš použít "Céčkové C++", tzn. psát v C++ jako v C, ale s tím, že můžeš alespoň použít std::string a std::vector, případně třeba streamy...

[pc2005]

Protoze nejsi schopen se vzit do role cloveka, ktery zacina s programovanim uplne od zacatku.

Tak já začal programovat tak, že jsem si z časopisu ABC přepisoval kousky kódů do qbasicu. V pascalu vlastně taky, z těch jejich příkladů v nápovědě (měl jsem nějakou přeloženou verzi). Kdybych měl stejnou českou napovědu i pro céčko, tak by to bylo +- stejné. Ono i ty pascalovský "ukazatele" jsem zpočátku taky nechápal (a ty v céčku mě přijdou víc intiutivnější).

Tak programy od nej ve vyssich programovacich jazycich jsou docela peklo. Ceckar programujici v Jave to je kapitola sama pro sebe.

100% guilty . Ale zase objektové programování v pascalu/delphi jsem svého času vůbec nepochopil i když jsem na pascalu začínal.

V Pascalu mas duraz na srozumitelnost kodu, v C na jeho efektivitu.

Zase když louskáš jak funguje v kernelu implementace container_of(), která je napsaná v makru, tak se člověk naučí mnohem víc, než když mu to dodá nápověda na podnose.

[deda.jabko]

Protoze nejsi schopen se vzit do role cloveka, ktery zacina s programovanim uplne od zacatku.

Tak já začal programovat tak, že jsem si z časopisu ABC přepisoval kousky kódů do qbasicu. V pascalu vlastně taky, z těch jejich příkladů v nápovědě (měl jsem nějakou přeloženou verzi).

Obavam se, ze toto nema prilis vypovidaci hodnotu.

Za poslednich N let jsem si vyzkousel ucit zacatecniky C, Scheme, assembler (x86) a Javu, a rekl bych, ze mam trochu realistictejsi predstavu, co dela problemy.

Ze zacatku je to vubec schopnost problem popsat algoritmicky (a presne). V C je typicky narocny prechod ke strukturovanym datovym typum a k dynamicke alokaci pameti. V momente, kdy se toto zacne kombinovat, jsou schopni se v tom zamotat naprosto a dokonole.

Zajimavy je i ten assembler. Lidi, kteri vetsinou programuji ve vyssich programovacich jazycich (hint: vetsina), k tomu prilis vztah nenajdou, nauci se par patternu, jak se co pouziva a obavam se, ze driv nepozdeji vsechno zapomenou.

S Javou byva nejcasteji problem v tom, ze se studenti spokoji s tim, jak nakupi jednotlive objekty a volani a ve vyslednem kodu, aby se prase vyznalo...

V Pascalu mas duraz na srozumitelnost kodu,

Zase když louskáš jak funguje v kernelu implementace container_of(), která je napsaná v makru, tak se člověk naučí mnohem víc, než když mu to dodá nápověda na podnose.

Vnimas mne vubec? Co pak je srozumitelnost kodu neco, co se da vycist z napovedy nebo precizne zpracovaneho makra?

[pc2005]

V C je typicky narocny prechod ke strukturovanym datovym typum a k dynamicke alokaci pameti. V momente, kdy se toto zacne kombinovat, jsou schopni se v tom zamotat naprosto a dokonole.

Proč to najednou kombinovat. Vždyť to spolu ani nijak zvlášť nesouvisí. Strukturované datové typy se dají naučit na globálním poli paměti a o nějakým malloc/free se můžou dozvědět až za libovolně dlouhou dobu. Pak jím stačí říct, že malloc() vezme kus RAM stejně jako to globální pole (resp to za tebe udělá OS pro .data nebo .rodata sekci).

Zajimavy je i ten assembler. Lidi, kteri vetsinou programuji ve vyssich programovacich jazycich (hint: vetsina), k tomu prilis vztah nenajdou, nauci se par patternu, jak se co pouziva a obavam se, ze driv nepozdeji vsechno zapomenou.

Takže vlastně by bylo dobré rozdělit programování na lowlevel a highlevel. Podle tohoto rozdělení spadám spíš do lowlevel a v takovém případě pro mě bylo nevýhodné začít vyšším jazykem (interpretovaný Qbasic, výukový pascal, objektové delphi) a kdybych začal v céčku, tak bych měl náskok. Opačně, pokud se někdo řadí do highlevel sféry, tak pro naučení lowlevel jazyku musí to highlevel myšlení v dědění, třídách apod. zahodit a začít myslet v sekvenčním automatu, protože lowlevel jazyky jsou velmi blízko HW.

Vnimas mne vubec? Co pak je srozumitelnost kodu neco, co se da vycist z napovedy nebo precizne zpracovaneho makra?

No přiznám se, že pokud se táhne diskuze přes několik dní, tak jsem už dávno zapomněl co jsem psal na začátku. Ale tady jsem to myslel takhle: Je sice hezký, když tě jazyk učí přehlednosti, ale když pak čteš po někom něco velmi nepřehledného, tak nemáš žádné zkušenosti jak to číst. Naopak pokud začneš na něčem, co je na úrovni tvého aktuálního maxima přehlednosti co zvládneš zpracovat (třeba výukový C kód

V Pascalu mas duraz na srozumitelnost kodu, v C na jeho efektivitu. Coz jsou veci, ktere jdou evidentne proti sobe.

), tak pak jednak zvládneš i přehledný kód a i mírně nepřehledný kód (samozřejmě by byla blbost začít s výukou v brainfucku). (nápovědou jsem nemyslel .hlp, ale komentovaný, strukturovaný, apod. kód)

[deda.jabko]

Strukturované datové typy se dají naučit na globálním poli paměti a o nějakým malloc/free se můžou dozvědět až za libovolně dlouhou dobu

Jen to ma trochu problem, ze vyuka programovani (dle meho) nespociva v ovladnuti nejakeho programovaciho jazyka, ale v pochopeni datovych struktur a algoritmu. Pokud chces nekoho ucit treba binarni vyhledavaci strom na globalnim poli, uzij si to. Jeste jedna vec, pokud nekoho budes ucit, ze se neco dela pomoci globalniho pole, cekej, ze ti to bude pak nekolik dalsich let cpat vsude, protoze on se to tak prece ucil.

Pak jím stačí říct, že malloc() vezme kus RAM stejně jako to globální pole (resp to za tebe udělá OS pro .data nebo .rodata sekci).

Pokud budes zacatecnikovi vysvetlovat treba ten binarni strom, .data nebo .rodata jsou to posledni, co ho bude zajimat, protoze vetsinu casu bude zapasit s tim, ,,kde pouzit hvezdicku'' (receno jejich terminologii).

Podle tohoto rozdělení spadám spíš do lowlevel a v takovém případě pro mě bylo nevýhodné začít vyšším jazykem (interpretovaný Qbasic, výukový pascal, objektové delphi) a kdybych začal v céčku, tak bych měl náskok.

Otazka jaka by to byla vyhoda. Lidi, kteri zacinali s programovanim MCU (tedy meli by mit tu nejlepsi vyhodu, protoze hardware znaji do detailu) jsou typicky priserni programatori, protoze nejsou schopni se povznest na nejakou vyssi uroven abstrakce vytvaret obecne struktury, resi kazdy byte, kazdy cyklus, i kdyz to treba (vetsinou) nehraje roli.

Je sice hezký, když tě jazyk učí přehlednosti, ale když pak čteš po někom něco velmi nepřehledného, tak nemáš žádné zkušenosti jak to číst.

Ale tady se bavime o tom, jak se vubec ucit programovat. Cteni ciziho (z praseneho) kodu je az dalsi level.

[pc2005]

Pokud chces nekoho ucit treba binarni vyhledavaci strom na globalnim poli, uzij si to. Jeste jedna vec, pokud nekoho budes ucit, ze se neco dela pomoci globalniho pole, cekej, ze ti to bude pak nekolik dalsich let cpat vsude, protoze on se to tak prece ucil.

Fajn tak ty dvě věci prohoď, mě nešlo o pořadí, ale o časový odstup. Má vůbec pascal dynamicky alokované pole? Uz si to nepamatuju, mě přišlo, že jsem všechno dělal v ekvivalentu globálního pole. Když takovej člověk pak přijde k céčku tak to udělá nejbližším způsobem, co už zná nejspíš skončí u globálního pole stejně. Navíc bys měl učit i ten jazyk, kde v případě céčka zazní, že to není dobrý nápad dávat všechno do globálního pole.

Pokud budes zacatecnikovi vysvetlovat treba ten binarni strom, .data nebo .rodata jsou to posledni, co ho bude zajimat, protoze vetsinu casu bude zapasit s tim, ,,kde pouzit hvezdicku'' (receno jejich terminologii).

Opět, nejdřív naučit pointery a pak až konstrukce s pointerama. Učit pointery na binárním stromu by byl overkill.

Lidi, kteri zacinali s programovanim MCU (tedy meli by mit tu nejlepsi vyhodu, protoze hardware znaji do detailu) jsou typicky priserni programatori, protoze nejsou schopni se povznest na nejakou vyssi uroven abstrakce vytvaret obecne struktury, resi kazdy byte, kazdy cyklus, i kdyz to treba (vetsinou) nehraje roli.

No a lidi co začínali na javě pak píšou matrixy a ani pár let starý počítač to nestíhá (kuk do ps aux, editor Kate 188 MB v RSS .. proč?). Jinak na MCU to ještě pořád roli hraje. Jak jsem psal proč je nerozdělit, vyšší struktury jsou problém vyšších programátorů. To bych se mohl rozčilovat nad tím, že javistům nejdou navrhovat hradla. Je to prostě (už téměř) jinej obor.

Ale tady se bavime o tom, jak se vubec ucit programovat. Cteni ciziho (z praseneho) kodu je az dalsi level.

Ale je potřeba nehledě na to v jakém jazyku začneš. V tomhle vidím přehlednost pascalu (nehledě na to, že základní výuka může být i v přehledném céčku) jako zbytečnou komplikaci. Mě přijde (co se teďka koukám na pár ukázek v pascalu), že všechny ty konstrukce se dají lehko překonvertovat do céčka, ale narozdíl o něj pascal skoro nikdo nepoužívá, takže není tolik projektů na samostudium.

Jen to ma trochu problem, ze vyuka programovani (dle meho) nespociva v ovladnuti nejakeho programovaciho jazyka, ale v pochopeni datovych struktur a algoritmu.

Pochopení datových struktur je ale taky jazyk: model v mozku. Základní tvar toho modelu nejspíš vznikne podle prvního jazyka, který se člověk naučí a pak všechno další vztahuje ke své interní reprezentaci. Takže ideální stav je, když je ten interní model co nejblíž realitě (tedy pro lowlevel programátory HW, pro highlevel programátory interpreter nebo VM). Z toho pohledu je pak na obtíž tvořit ten model na jazyku, který nemá vysoké reálné nasazení nebo je oproti realitě zjednodušený.

P.S. motám(e) dohromady 3 věci: pascal vs céčko, vysokoúrovňový vs nízkoúrovňový jazyk a computer science vs programming. Na computer science nepotřebuješ pascal, céčko ani javu, na naučení třídících algoritmů ti stačí slovní popis, nějaký metajazyk nebo lidové tance, reálná implementace pak může být v libovolném jiném jazyku. Jeho výuka je pak ortogonální ke computer science a CS pak tedy nezávisí na obtížnosti gramatiky (teda pokud vyučující není limitovaný přidělenými hodinami a nacpe se CS do stejného předmětu k programování, kdybych neměl samostudium, tak bych se o třídících algoritmech uceleně dozvěděl až v matematice na VŠ).

[deda.jabko]

Když takovej člověk pak přijde k céčku tak to udělá nejbližším způsobem, co už zná nejspíš skončí u globálního pole stejně

Kdyz takovy clovek prijde k C a je nucen ty dve veci kombinovat, zacne se v tom ztracet a motat. Overeno.

Učit pointery na binárním stromu by byl overkill.

Pricemz binarni stromy lze hezky vysvetlit treba na teckovych parech jako ma Lisp, bez bolesti explicitni manipulace s pointery a alokace pameti. Prechod k pointeru ve smyslu C je v opacnem smeru mnohem pohodlnejsi.

Ale je potřeba nehledě na to v jakém jazyku začneš.

A matematika by se mela ucit tak, ze deti nechame zirat na definici riemanova integralu. A v citance pro prvni tridu si deti prectou Nesnesitelnou lehkost byti. Taky je to posune dal, .... ale jenom ty, co to pochopi.

ale narozdíl o něj pascal skoro nikdo nepoužívá, takže není tolik projektů na samostudium.

Boze, vsak jsem tu psal, ze Pascal uz je za zenitem a dnes by byl lepsi Python.

pascal vs céčko, vysokoúrovňový vs nízkoúrovňový jazyk a computer science vs programming.

To jsou veci, ktere si ty rozdelujes, ale pritom spolu souvisi.

Bavime se tu o vyuce programovani a oddelovat computer science a (nejaky) programming je vyslovene pitomost, protoze jedno bez druheho je k nicemu (bavime-li se stale o vyuce programovani).

[pc2005]

zacne se v tom ztracet a motat.

Ale jenom když začal ve vysokoúrovňovém jazyku ne?

binarni stromy lze hezky vysvetlit treba na teckovych parech jako ma Lisp

Jaká je úspěšnot člověka, co se naučí binární strom v lispu a pak se z toho binárního stromu má učit pointery v céčku? Jinak i v céčku jde binární strom učit bez explicitních pointerů.

A matematika by se mela ucit tak, ze deti nechame zirat na definici riemanova integralu

Však přesně tak, matematika se učí od úplných mechanických lowlevel základů třeba i na kuličkovým počítadle a ne na vysokoúrovňové abstraktní grupové teorii.

dnes by byl lepsi Python

Pythonem neuděláš druhý linux kernel.

protoze jedno bez druheho je k nicemu (bavime-li se stale o vyuce programovani).

V té matematice na VŠ jsme nic neprogramovali a kombinatorické úlohy jsme počítali bez optřeby jakéhokoliv jazyka. Jinak:

Computer science is no more about computers than astronomy is about telescopes. --Edsger Dijkstra

[Bystroushaak]

Pythonem neuděláš druhý linux kernel.

To je sice pravda, ale zas tím uděláš všechno ostatní, kromě embeded (ehm, ehm, micropython, ehm). A hlavně bez velkého sraní. Přepisuji teď některé performance-critical věci do Rustu a přestože je Rust docela vysokoúrovňový jazyk a přestože používám knihovnu, co mi hodně šetří práci, tak prostě všechno je 5x tak těžší a trávím spoustu času věcma, které vůbec nijak nepřispívají k řešení problému.

[pc2005]

micropython

Yet it is compact enough to fit and run within just 256k of code space and 16k of RAM.

Ale tam končí ty největší MCU do DILu, vlastně ani žádnej takovej nemám (mám jenom 128k/8k).

[deda.jabko]

Ale jenom když začal ve vysokoúrovňovém jazyku ne?

Ne, uplni zacatecnici s tim maji +/- stejne problemy.

Jaká je úspěšnot člověka, co se naučí binární strom v lispu a pak se z toho binárního stromu má učit pointery v céčku?

Takhle otazka nestoji. Ukolem je naucit, co je to binarni strom, a ne pomoci nej ucit pointery.

Pythonem neuděláš druhý linux kernel.

A? Bavime se tu porad o vyuce programovani uplnych zacatecniku... Programovani kernelu je obyvkle hned druha kapitola, hned po pointerech.

Však přesně tak, matematika se učí od úplných mechanických lowlevel základů třeba i na kuličkovým počítadle a ne na vysokoúrovňové abstraktní grupové teorii.

Jsem rad, ze potvrzujes me argumenty. V tomto kontextu je Pascal bliz tomu kulickovemu pocitadlu (proto tu nekteri vcetne tebe tvrdi, ze je k nicemu). Pointery jsou ta tezka abstraktni vec. Pro tebe mozne ne, pro zacatecniky ano.

V té matematice na VŠ jsme nic neprogramovali

Ano, je dobre, ze v matematice jste nic neprogramovali. Ale my se tu bavime o vyuce programovani!

Computer science is no more about computers than astronomy is about telescopes. --Edsger Dijkstra

Cekal jsem, ze presne tento citat vytahnes. Jen akorat sem vubec nezapada.

Pokud pristoupim na tve deleni a bude ucit oddelene "computer science" a "programming".

Kdo bude lepsi programator?

(1) Ten, co zvlada jazyk, ale struktury a algoritmy jsou mu cizi. (2) Ten, co zvlada algoritmy a struktury, ale nezvlada jazyk.

[xkucf03]

Pointery jsou ta tezka abstraktni vec. Pro tebe mozne ne, pro zacatecniky ano.

Co na nich má být vlastně tak těžkého?

• ten abstraktní koncept
• syntaxe * a &
• rutina, disciplína – nedělat chyby při jejich používání

[kralyk z abclinuxu]

Pointery jsou těžké z několika důvodů. Mapují astraktní n-rozměrné / abstraktní věci na do jednorozměrného prostoru. Zároveň ale nevíš pořádně, jak je tam mapují - jsou často randomizované. Navíc ten jednorozměrný prostor je sice jednorozměrný, ale (typicky) velký a plný nebezpečných děr. Když v něm šlápneš do díry, sletí ti program nebo způsobíš nějaké podivné nechtěné chování.

To je prostě pro začátečníka velká komplikace, navíc její zvládnutí mu vlastně v nejbližší budoucnosti vůbec nic nepřinese.

Já bych v tomhle threadu souhlasil s dědou.jabkem. Céčko a low-level přístup není pro začátečníky. Já začínal s PHP (blefuj, rest in peaces) někdy v 13 letech a kráce na to jsem přešel na Object Pascal / Delphi, kde jsem se naučil asi nejvíc v tom začátku. Vzpomínám si, že místo polí / dynamických polí jsem používal (aspoň na stringy) nějakou GUI listbox komponentu, což je sice z programátorského hlediska hrozně špatně a zbytečné, ale bylo super mít stálou možnost to "pole" vidět před sebou jako na dlani. To mi obrovsky pomáhalo. Teprve o dost později a dost postupně jsem řešil pointery... Resp. asi jsem je používal i předtim, ale nevěděl jsem pořádně, co dělám...

[deda.jabko]

Diky, Kraliku, usetrils mi praci. ;-]

[Jendа]

Mapují astraktní n-rozměrné / abstraktní věci na do jednorozměrného prostoru. Zároveň ale nevíš pořádně, jak je tam mapují - jsou často randomizované.

Já si pořád nějak nedokážu představit, co bych měl s pointery dělat, abych tohle potřeboval vědět/vadilo mi to.

Navíc ten jednorozměrný prostor je sice jednorozměrný, ale (typicky) velký a plný nebezpečných děr. Když v něm šlápneš do díry, sletí ti program nebo způsobíš nějaké podivné nechtěné chování.

Takže ti vadí spíš absence bounds checkingu?

což je sice z programátorského hlediska hrozně špatně a zbytečné, ale bylo super mít stálou možnost to "pole" vidět před sebou jako na dlani

To by chtělo IDE, kde klikneš na pole a vybereš „add watch“.

[Michal Kubeček]

Já si pořád nějak nedokážu představit, co bych měl s pointery dělat, abych tohle potřeboval vědět/vadilo mi to.

Třeba práce s vícerozměrným polem v C není úplně přímočará a často je jediný způsob, jak se v tom neztratit, představit si, jak vypadá layout v paměti.

Nebo si vezměme struktury, teoreticky lze napsat container_of() (a to patří k těm jednodušším) i bez představy, jak to prakticky funguje, ale snad se shodneme, že to není úplně optimální. Ono už jen vysvětlit, proč je vlastně potřeba alignment a proč jsou ve struktuře díry (a proč není dobrý nápad to "řešit" tím, že se všechno udělá packed), jde na nějakém abstraktním modelu dost těžko. Možná tak dogmatikům, kteří jsou spokojení, když se jim řekne "takhle to prostě je" a nemají ve zvyku se ptát "proč".

Osobně mi ovšem na práci s pointery v C nejvíc vadí nešťastně (a nekonzistentně) navržená syntaxe.

[pc2005]

Třeba práce s vícerozměrným polem v C není úplně přímočará a často je jediný způsob, jak se v tom neztratit, představit si, jak vypadá layout v paměti.

Z éry pascalu už si všechno nepamatuju, ale na to, že jsem ten layout řešil i tam při zápisu do videoRAM si vzpomínám.

Začátečnící nejspíš s tím 2D polem nebudou dělat věci jako: jde udělat lineární memcopy pro sloupec nebo řádek? Spíš budou projíždět přes klasické i,j indexy a u nich budou vědět limity.

[kralyk z abclinuxu]

Já si pořád nějak nedokážu představit, co bych měl s pointery dělat, abych tohle potřeboval vědět/vadilo mi to.

No tak dejme tomu třeba tak základní věc jako procházení pole. K tomu potřebuješ vědět počet prvků v poli. Pokud je to statické pole, potřebuješ vědět, že sizeof(pole) nevrací počet prvků, pokud jsou prvky větší než bajt. Pokud sis ho alokoval dynamicky, musíš vědět, že sizeof ti je nanic, při alokaci si máš říct o počet prvků * velikost a musíš si tu velikost někde držet / předávat.

Takže ti vadí spíš absence bounds checkingu?

No, mně na pointerech nevadí nic. Ale začátečníkům (IMO) tyhle věci dělají problémy. Bounds-checking je jedna věc - problematický na tom je hlavně to, že když ti někde přelezou bounds, nedovíš se o tom nic moc pořádného - program prostě nefunuje a nevíš proč. Další nepříjemnost je nemožnost posoudit, jestli pointer ukazuje na něco nebo už ne. A do třetice další nepříjemnost je "neprůhlednost" pointerů - když chceš vytáhnout nějaký informace, musíš na to mít vlastní kód nebo umět používat debugger (což začátečníci typicky neumí / nejsou z toho moudrý).

Porovnej to například s tím Pythonem. Velikost pole zjistíš jednoduše pomocí len(), reference je vždy platná a můžeš si obsah toho, na co ukazuje, prostě vypsat na výstup, interpreter ti vypíše co to je za objekt a jeho obsah.

To by chtělo IDE, kde klikneš na pole a vybereš „add watch“.

Si myslíš, že jsem tehdy věděl, co je debugger?

[pc2005]

Ne, uplni zacatecnici s tim maji +/- stejne problemy.

Takže je jedno zda začneš v nízkoúrovňovém (cécko, pascal) jazyku nebo vysokoúrovňovém (python, java, delphi) s pointerama budeš mít stejné problémy. Na druhou stranu, pokud si zvykneš na neefektivní kód, tak IMO půjdeš nerad proti proudu času zpět k céčku.

Ukolem je naucit, co je to binarni strom, a ne pomoci nej ucit pointery.

Tak znova, pro naučení binárního stromu žádný jazyk nepotřebuješ. Maximálně jen model problému v mozku. Každopádně třídící stromy vznikly kvůli potřebě optimalizaci a efektivitě, takže učit to na jazycích, kde se to mikrooptimalizace nemusíš starat (java), je IMO vyloženě kontraproduktivní (proč bych měl řešit třídění prvků, když to za mě udělá orákulum virtuálního stroje).

Bavime se tu porad o vyuce programovani uplnych zacatecniku

Úplný začátečník by měl vědět, jak šla posloupnost počítačů od mechanických strojů, po stroje s adresovatelnou pamětí, assembleru, portovatelného programovacího jazyka, objektového jazyka apod. Ne že se skočí hnedka do abstrakce a pak případně jde proti proudu času.

V tomto kontextu je Pascal bliz tomu kulickovemu pocitadlu (proto tu nekteri vcetne tebe tvrdi, ze je k nicemu)

Já jsem navrhl to rozdělení, ty to mícháš dohromady s výukou. Proti výuce v pascalu jsem, protože nemá reálné využití a moderní cécko (ne K&R co vznikl až dva? roky po pascalu) umí ty algoritmy zapisovat stejně přehledně jako pascal. Navíc céčko je tomu počítadlu blíž než Pascal. U výuky v pascalu vs v javě, jsem spíš pro pascal než pro javu (ale jen pro výuku lowlevel programátora, pro highlevel by to bylo naopak, proč ne, nikdy se s kernelem nesetká). Pro výuku stromů nepotřebuješ žádný jazyk.

Ano, je dobre, ze v matematice jste nic neprogramovali.

To bylo myslím mé první oficiální setkání s třídícími algoritmy. Ale zase já začínal na elektroprůmce (programování jsme tam ale měli). Za to "pointery" jsme měli při výuce 8051 na střední (v céčku jsou ty registry s ukazatelema víceméně jako symbolická proměnná).

Kdo bude lepsi programator?

(1) Ten, co zvlada jazyk, ale struktury a algoritmy jsou mu cizi. (2) Ten, co zvlada algoritmy a struktury, ale nezvlada jazyk.

Jasně jsem psal, že to je ortogonální a ne vzájemně výlučné. Pokud student dokončí úspěšně studium, tak bude umět obojí. Nejdřív se musíš naučit samotné jazyky (pointery například) a teprve pak v nich můžeš psát díla (stromy). Z hlediska computer science žádný jazyk nepotřebuješ, z hlediska programování bych začal chronologicky a vyhodil bych jazyky, co se už nepoužívají (například bych vyučoval jen jeden z každého paradigmatu).

[kralyk z abclinuxu]

Na druhou stranu, pokud si zvykneš na neefektivní kód, tak IMO půjdeš nerad proti proudu času zpět k céčku.

Na základě čeho si tohle myslíš? Já třeba postupoval v zásadě takhle. Začal jsem někde v prostřed spektra a vzdělával jsem se časem na obě strany (s tím, že raději jdu dolů).

To už bys, dotaženo ad absrudum, rovnou mohl tvrdit, že je blbost začínat v C, že by měl člověk nejdřív napsat něco v asembleru. A pak bys došel k tomu, že i to je moc vysoko a skončíš se zmagnetizovanou jehlou a pevnou rukou... Nebo výrobou analytical engine z Merkuru.

Každopádně třídící stromy vznikly kvůli potřebě optimalizaci a efektivitě, takže učit to na jazycích, kde se to mikrooptimalizace nemusíš starat (java), je IMO vyloženě kontraproduktivní

Není, protože při výuce programování je IMHO ze všeho naprosto nejdůležitější, aby si to člověk mohl osahat. A ve vyšším jazyce si to prostě osaháš snáz, snáz získáš základní intuice o proměnných, funkcích, flow control atd. atd. který ty asi považuješ za samozřejmé, ale začátečník to tak nemá.

[pc2005]

Na základě čeho si tohle myslíš?

Mě přijde, že možnost se přestat starat o lowlevel věci při postupu nahoru je tak nějak jednodušší než neustále analyzovat nižší a nižší vrstvy při obráceném směru. Ale možná to je bias z toho že mě vždycky přišlo, že spolužáci, co znali třeba python ty nižší jazyky moc rádi neměli.

To už bys, dotaženo ad absrudum, rovnou mohl tvrdit, že je blbost začínat v C, že by měl člověk nejdřív napsat něco v asembleru

Však jsem psal, že s počítačema (pokud nepočítám pařby "cihly" na školních consulech) jsem se setkal tak, že jsem si ho chtěl naivně postavit z tyristorů . Každopádně by bylo dobré na té historii ukázat to jak jednotlivé generace zvyšovali míru abstrakce, což se pak použije pro ukázání rozdílu mezi nízkoúrovňovými jazyky a vysokoúrovňovými.

A ve vyšším jazyce si to prostě osaháš snáz, snáz získáš základní intuice o proměnných, funkcích, flow control

Až na to, že intuice založená na abstraktním modelu bude mimo realitu toho jak funguje procesor. A to nemůže dělat dobrotu. Moje nejpoužívanější funkce v céčku je hexdump paměti tam si můžeš přímo osahat to jak jsou ty data přímo uložená v RAM, jak si tohle chceš osahat třeba v javaskriptu?

[xkucf03]

Mě přijde, že možnost se přestat starat o lowlevel věci při postupu nahoru je tak nějak jednodušší než neustále analyzovat nižší a nižší vrstvy při obráceném směru.

Když postupuješ odshora dolů, tak si nabiješ hubu, třeba ti program SEGFAULTuje, Valgrind a ASan hlásí hromadu chyb, program nefunguje, tvoje naučené postupy nejdou použít… což tě donutí to buď vzdát nebo si dostudovat, jak se to píše správně v tom nízkoúrovňovějším jazyce. Zatímco při postupu opačným směrem ti v zásadě nic nebrání tomu, abys psal Céčko v Javě nebo Pythonu – sice to bude špatně, ale nějak ti to fungovat bude, takže tě přímo nic nenutí se naučit, jak se píše v tom vyšším jazyce.

[pc2005]

třeba ti program SEGFAULTuje

Nebo nesegfaultuje, ale má v sobě bezpečnostní chyby.

[xkucf03]

Na to zase pomáhá AFL nebo obecně fuzzer. Aspoň na některé.

[kralyk z abclinuxu]

Mě přijde, že možnost se přestat starat o lowlevel věci při postupu nahoru je tak nějak jednodušší než neustále analyzovat nižší a nižší vrstvy při obráceném směru. Ale možná to je bias z toho že mě vždycky přišlo, že spolužáci, co znali třeba python ty nižší jazyky moc rádi neměli.

To zálaží na osobních preferencích. Vím o nemálo lidech, kteří měli první jazyk vyšší a šli směrem dolů.

Až na to, že intuice založená na abstraktním modelu bude mimo realitu toho jak funguje procesor. A to nemůže dělat dobrotu. Moje nejpoužívanější funkce v céčku je hexdump paměti tam si můžeš přímo osahat to jak jsou ty data přímo uložená v RAM, jak si tohle chceš osahat třeba v javaskriptu?

Jenže to ti na začátku k ničemu není. Proč bys řešil, jak je třeba proměnná uložena v RAM, když ani nevíš, co je proměnná nebo nemáš pořádně intuici, k čemu je taková proménná dobrá? Na začátku ani nevíš pořádně, co jsou datové typy. Ditto třeba funkce.

Tyhle věci si prostě zjistíš ve chvíli, kdy se k tomu dostaneš. A pokud nemáš chuť se k tomu dostat, neměl bys k tomu chuť ani na začátku.

Třeba to, že (nativní) funkce mají nějaký prolog a epilog a jak vlastně předávají argumenty na různých architekturách jsem zjistil až po letech jejich spokojeného používání...

Netvrď mi, že ses tohle naučil všechno najednou. (A jestli jo, tak jsi výjimka.)

[pc2005]

Proč bys řešil, jak je třeba proměnná uložena v RAM, když ani nevíš, co je proměnná

Tak zrovna tohle jsem věděl ještě před tím, než jsem měl první počítač. Ono když člověk sbírá eletroodpad, tak se dostane k věcem jako EPROM, hradla, čítače apod.

Ditto třeba funkce.

No to jsem nevěděl ani po absolvování qbasicu, ještě v prvních programech v pascalu jsem psal vlastní implementaci hledače min jako obrovský strom plný goto.

že (nativní) funkce mají nějaký prolog a epilog a jak vlastně předávají argumenty na různých architekturách

No technicky to bylo zmíněno už v AThelpu, což se dá brát jako počátek mého reálného programování, ale setkal jsem se s tím teprve až ve chvíli, kdy jsem začal psát assembler v kernelu nebo ho debugovat. Do té doby jsem je taky prostě nepotřeboval. A kdybych nepotřeboval debugovat linux na FPGA, tak je nepotřebuju až do teď (já vlastně normální programy ani moc nedebuguju, nepotřebuju).

Já jsem prostě začal odspodu a funguje to (ovšem co je metrika, že to funguje). Souhlasím s tím, že bych měl problém asi něco napsat třeba v prologu nebo haskellu a v javě bych psal céčkařsky. Ale úlohy co řeším tu vysokoúrovňovou abstrakci prostě nepotřebujou, nebo je dokonce škodlivá (většina mých věcí by byla s overheadem interpreteru/VM moc pomalá, moc velká).

[deda.jabko]

Tak znova, pro naučení binárního stromu žádný jazyk nepotřebuješ. Maximálně jen model problému v mozku

Aby ses naucil plavat, bazen taky nepotrebujes, staci ti jeho mentalni model.

Nejdřív se musíš naučit samotné jazyky (pointery například) a teprve pak v nich můžeš psát díla (stromy). Z hlediska computer science žádný jazyk nepotřebuješ, z

Aneb jak zabit vnitrni motivaci snadno a rychle.

Úplný začátečník by měl vědět, jak šla posloupnost počítačů od mechanických strojů, po stroje s adresovatelnou pamětí, assembleru, portovatelného programovacího jazyka, objektového jazyka apod. Ne že se skočí hnedka do abstrakce a pak případně jde proti proudu času.

Tato debata zacina byt znacne nesmyslna, koncim. Jde videt, ze ses opravdu nestkal s vyukou zacatecniku, proto nemam sanci argumentovat proti tve znacne idealizovane predstave vyuky.

[pc2005]

Aby ses naucil plavat, bazen taky nepotrebujes, staci ti jeho mentalni model.

Tak předpokládám, že před vhozením do vody řekne instruktor plavání jak hejbat rukama apod.

Aneb jak zabit vnitrni motivaci snadno a rychle.

Mě například motivaci zabíjela syntaxe pythonu, nebo syntaxe a gramatika VHDL.

Úplný začátečník by měl vědět, jak šla posloupnost počítačů od mechanických strojů, po stroje s adresovatelnou pamětí, assembleru, portovatelného programovacího jazyka, objektového jazyka apod

Jde videt, ze ses opravdu nestkal s vyukou zacatecniku

Vždyť tak začíná i wikipedie.

[Bystroushaak]

Mě například motivaci zabíjela syntaxe pythonu

Myslíš to jak nemusíš psát spoustu zbytečných závorek a středníků a jediné co to po tobě chce je odsazení, které bys psal tak jako tak?

[Michal Kubeček]

Syntakticky významné formátování whitespace je špatný nápad. Autora make omlouvá nevědomost, autor pythonu už se nemá na co vymlouvat.

[Bystroushaak]

A já tvrdím, že není. *pokývne kloboukem*

[ehm]

To není úplně srovnatelné. V Makefile se pro odsazování používá \t, v Pythonu si odsazování zvolíš a interpreter po tobě následně vyžaduje jen konzistenci.

Ve výsledku není moc rozdíl oproti C-like jazyku, kde chceš odsazování taky držet konzistentně a kontrolovat to lintem. Rozdíl je jen v tom průběhu, kdy Python prostě odmítne vyhodnotit kód se špatným formátováním a nelze to tedy ani vyzkoušet (umím si představit, že to někomu pije krev při kopírování ze StackOverflow apod.). Mně osobně občas vadí zalamování řádků, ale jinak je to docela OK.

Spekuloval bych, že pro výuku programování je to lepší než C-like syntaxe právě z toho důvodu, že to odsazování musí být v pořádku. Ze zkušenosti vím, že pro začátečníky to odsazování není intuitivní a v C-like jazycích ho vždycky udělají blbě. Tím jim to ale nic neusnadní, naopak; při dohledávání chyby se jim kód ještě hůře čte.

[pc2005]

Tím jim to ale nic neusnadní, naopak; při dohledávání chyby se jim kód ještě hůře čte.

O tom jsme se už bavili před pár dny, mě to nepřijde jako nevýhoda. Špatně odsazený kód Cčka není tak nečitelný, aby to znemožnilo výuku.

v Pythonu si odsazování zvolíš

Takže ve třídě bude mít každej jiný odsazování a když si budou muset poradit, tak budou zmatený, že se jim ty kousky kódu nechtějí zkompilovat. To pak ale padá argument, že python je přehlednější.

[Bystroushaak]

Takže ve třídě bude mít každej jiný odsazování a když si budou muset poradit, tak budou zmatený, že se jim ty kousky kódu nechtějí zkompilovat. To pak ale padá argument, že python je přehlednější.

Python hned při startu vypíše IndentationError, ukáže ti přesně řádek kde je problém a napíše co tam je za problém. Jinak docela standard bývá si zapnout zobrazování bílých znaků a pak to prostě vidíš na první pohled.

[ehm]

Jinak docela standard bývá si zapnout zobrazování bílých znaků a pak to prostě vidíš na první pohled.

To už bych se spíš porozhlédl po editoru s dobrou kontrolou syntaxe. PyDev to myslím uměl.

[pc2005]

Doufám, že ukáže všechny, abych ho nemusel spouštět 50x za sebou jen kvůli opravě indentation. [vsuvka]Ekvivalent u VHDL by trval pár dní, protože syntéza může klidně trvat půl hoďky.[/vsuvka]

bývá si zapnout zobrazování bílých znaků

Nemám, resp v MC jsem si to vypnul, protože to je fujtajbl implementace. V Kate je identifikátor tabu, ale mezery bych v tom nerozpoznal, navíc i ten tab není pořádně vidět. Céčko v takovém nastavení funguje, tak proč se v tom hrabat (bych si musel nastavit 100% intenzitu obarvení, abych to na tonhle LCD viděl), když všechny moje projekty jsou víceméně v céčku. V něčem jako terminálu nic takovýho neexistuje (třeba pro skripty v bashi).

[ehm]

Nemám, resp v MC jsem si to vypnul, protože to je fujtajbl implementace.

Já používám editor, který má problém se zobrazováním složených závorek, a protože ho už 31 let nikdo nevyvíjí, opravy se asi nedočkám. Považuji to za solidní argument, proč nevyučovat C.

[pc2005]

Jako že je MC starej? v čem přes ssh spravuješ vzdáleně soubory? Někdy je nejrychlejší prostě dát shift+f4 a napsat testovací minikód.

V MC to je fujtajbl implementace, protože to nahrazuje tab copypastovatelným (z terminálu) stringem "<---->"

[Fluttershy, yay!]

v čem přes ssh spravuješ vzdáleně soubory?

Emacs

[xkucf03]

A poradíš nějaké dobré nastavení kolem tabulátorů a neviditelných znaků?

Protože to výchozí chování je prostě nedostatečné. Často právě musím otevřít soubor v MC, abych se podíval, kde jsou tabulátory a kde mezery, nebo zda tam nejsou hnoje typu CR. V mceditu je tohle hezky hned vidět a to i ve výchozím nastavení (tzn. na jakémkoli stroji s MC, ne jen tam, kde mám svoje osobní vyladěné nastavení).

[Jendа]

Často právě musím otevřít soubor v MC, abych se podíval, kde jsou tabulátory a kde mezery

Snad všechny grafické editory umí místo tabu zobrazovat »        a místo mezery na začátku a na konci řádku ·.

[pc2005]

To jde? (jako třeba chmod, symlinky, hexviewer, exec) o_O

[Bystroushaak]

Jako že je MC starej? v čem přes ssh spravuješ vzdáleně soubory? Někdy je nejrychlejší prostě dát shift+f4 a napsat testovací minikód.

Vim, emacs. Když nic jiného, tak nano, nebo cat >, nebo mountnutí přes sshfs, ale mc by mě fakt ani nenapadlo.

[pc2005]

Zajímavý, já používám MC i na desktopu na přehrávání písniček.. První věc co po zapnutí Xek spouštím je obvykle mc v terminálu.

[xkucf03]

V MC to je fujtajbl implementace, protože to nahrazuje tab copypastovatelným (z terminálu) stringem "<---->"

A jde to vůbec u terminálové aplikace jinak? Maximálně měnit barvu pozadí, ale znaky nechat " " (mezera).

Tohle je jeden z příkladů, který ukazuje omezenost editorů a obecně aplikací pro terminál / textový režim. Tenhle druh aplikací má sice jiné výhody a často to tak nevadí, takže stále dává perfektní smysl je používat, alespoň na některé úlohy. Ale oproti GUI aplikacím budou vždy v něčem omezené.

[pc2005]

Jo takové má obarvení syntaxe Makefile, tab je červenej. Mnohem lepší.

Tak já taky normálně programuju v Kate, ale zase nebudu na stroji, na kterým vzdáleně ladím PCI komunikaci (a který spadne jednou za 10 minut) nastavovat Xka a připojovat kláavesnici jen, abych si prohlédl dump nebo napsal mikroskript.

[Fluttershy, yay!]

sshfs, barvičky v terminálu, lepší klient (např. tramp v emacsu), editor s architekturou klient-server (např. emacs)

[pc2005]

Ony ty barvičky v sériovém terminálu často dost nejdou.

[Fluttershy, yay!]

To máš blbý.

Stejně jako to, že jsi úspěšně ignoroval ten zbytek.

[pc2005]

On umí emacs fungovat i jako sériový terminál? o_O

Emacs ale ani neumím nepoužívat, vlastně ho ani v systému nemám.

[ehm]

Špatně odsazený kód Cčka není tak nečitelný, aby to znemožnilo výuku.

Mám opačnou zkušenost. Když jsem pak v takovém kódu dohledával chybu, špatné odsazování to komplikovalo velmi výrazně. Byla to Java, ne C, ale to zde nehraje roli.

Takže ve třídě bude mít každej jiný odsazování a když si budou muset poradit, tak budou zmatený, že se jim ty kousky kódu nechtějí zkompilovat.

Jako kdyby byl problém nakonfigurovat všem stejné odsazení, nebo jim prostě vysvětlit, jak to funguje. Nevidím moc velký rozdíl někoho učit psát složené závorky, nebo mu vysvětlit, k čemu je ta klávesa nad Caps Lockem.

Problém může nastat, pokud někdo bude používat jiný nebo jinak nastavený editor doma než ve škole a v jednom zdrojovém souboru se mu smíchají mezery a tabulátory. Právě proto by bylo dobré to předem vysvětlit.

Velmi mírně to zvedá vstupní bariéru (zadávat chlupaté závorky naučíš člověka, který z počítačů nemá panickou hrůzu a čudlíky nemačká s hrůzou v očích, docela rychle), ale je to investice, která dává velmi dobrý smysl. V C to můžeš ignorovat, ale pak jejich zdrojáky budou vypadat jako rozsypaný čaj.

[pc2005]

Když jsem pak v takovém kódu dohledával chybu, špatné odsazování to komplikovalo velmi výrazně

Hmm zajímavé, nestačí si na to jen zapamatovat v céčkoidní syntaxi v jak moc vnořeném bloku zrovna jsem? Což je divný, protože já bych se třeba v závorkách lispu lehko ztratil, ale intuitivně vědět, kde jsem v bloku v céčku mě moc velký problém nedělá. Samozřejmě občas omylem vymažu ukončovací "}" na konci funkce a pak to musím hledat, ale taková nehoda by byla méně častější než chyba indentace u pythonu.

Problém může nastat, pokud někdo bude používat jiný nebo jinak nastavený editor doma než ve škole a v jednom zdrojovém souboru se mu smíchají mezery a tabulátory.

No právě, zdrojáky se můžou obecně kopírovat z celého světa.

Právě proto by bylo dobré to předem vysvětlit.

Stejně tak to jde vysvětlit i pro céčko. Vyučující dokonce může zavést checkpatch pravidla. Nevidím důvod, proč by to mělo být ale fundamentální vlastností jazyka.

[ehm]

Hmm zajímavé, nestačí si na to jen zapamatovat v céčkoidní syntaxi v jak moc vnořeném bloku zrovna jsem?

Musíš číst celý kód od začátku. Nemůžeš to jen rychle projet očima.

Nevidím důvod, proč by to mělo být ale fundamentální vlastností jazyka.

Protože ti to šetří jeden zbytečný řádek kódu využitím informace, která by v tom kódu jinak stejně byla?

[Fluttershy, yay!]

informace, která by v tom kódu jinak stejně byla

Což je jeden z prvních výsledků hledání: Why Python’s whitespace rule is right

When you really analyse it, Python’s whitespace sensitivity is actually the only logical choice for a programming language, because you only communicate your intent one way, and that intent is read the same way by humans and computers.

[pc2005]

Chybějící jedné závorky na konci bloku si všimnu, jednoho chybného odsazení na konci bloku si nevšimnu. V první případě mě seřve kompilátor v druhém případě vznikne kód, který funguje, ale chybně.

only logical choice

Většina ostatních jazyků to tak nemá a jsou taky populární. Nemyslím si, že to je jen historická setrvačnost.

same way by humans and computers

Ok chci počítačem vygenerovat kus skriptu. Bude to jednodušší nebo zložitější s povinných odsazováním nebo bez něj?

[Fluttershy, yay!]

Chybějící jedné závorky na konci bloku si všimnu, jednoho chybného odsazení na konci bloku si nevšimnu.

Dělám na asi větším projektu (a se špagetovým kódem), kde bych to musel přepočítávat, potažmo někdo za závorku píše v komentáři, co za blok se tím končí (např. úvodní podmínka), což se blbě udržuje.

Naštěstí to řeší editor.

Ok chci počítačem vygenerovat kus skriptu. Bude to jednodušší nebo zložitější s povinných odsazováním nebo bez něj?

RTFA

Generátor kódu si musí vždy vést informaci o stavu odsazení, což je technické zesložitění – to je fakt, ale ne argument, když jde o člověkem užívaný formát (jazyk).

[Michal Kubeček]

Mimochodem, gcc od verze 6 (možná 5) má warning na to, když něco podle odsazení vypadá, jako by to patřilo do bloku, ale syntakticky nepatří.

[pc2005]

RTFA

Právě že jsem četl, argumentoval tam tím, že je to odsazení výhodné i pro stroj, což oproti {} není.

[pc2005]

Protože ti to šetří jeden zbytečný řádek kódu využitím informace, která by v tom kódu jinak stejně byla?

Pro jeden příkaz nepotřebuješ v céčku {}, pro dvou a více příkazový blok, potřebuješ v céčku {}, ale v pythonu máš na obou (a více) řádcích indentaci. V nekonečně příkazovém bloku, budeš mít nekonečně indentací, ale v C stále dvě závorky.

Ale to už se fakt bavíme o extrémech.

[Bystroushaak]

Pro jeden příkaz nepotřebuješ tu indentaci ani v pythonu (if True: print 1 je zcela validní). Jinak jsem tu myšlenku asi úplně nepochopil.

[pc2005]

Nutnost indentovat nebo opravovat indentaci po copypaste roste s počtem zasažených řádků. V případě céčka je konstantní (1x {}) a v případě copypaste nulová.

[xkucf03]

Když jsem pak v takovém kódu dohledával chybu, špatné odsazování to komplikovalo velmi výrazně. Byla to Java

Pokud je odsazení natolik špatné, že brání tomu, aby ses v kódu vyznal, tak to prostě celé v IDE nebo jiném nástroji přeformátuj.

Jinak takový brutální zásah není moc dobrý kvůli verzování a dohledatelnosti, ze které verze který řádek pochází… takže běžně přeformátovávám spíš jen řádky, které jsem měnil. Ale pokud je kód v takovém bordelu, tak bych ho přeformátoval jednorázově celý.

Případně to po nalezení chyby můžeš vrátit do původního stavu.

[ehm]

Furt se bavím o výuce programování...

Přeformátovat u něj/ní: Ne, pokud nepoužívá automatické formátování sám/sama, dělat to nebudu.

Přeformátovat u sebe: Většinou chybu najdu rychleji i s tím blbým formátováním než bych to vůbec stihl dostat k sobě do IDE (týká se zdrojáků poslaných přes Pastebin aj.).

[pc2005]

Závorky a středníky udělám jednou dvakrát za funkci. Prohánění bloků copypaste kódu dělám pořád. Občas kód dočasně vyřadím zakomentováním, ladící asserty a pracovní komentáře dělám zásadně bez odsazení i v bloku, kde je odsazení několik tabů. Tyhle věci musí být viditelné jako pěst na oko, protože to jsou obvykle místa, kde dochází k problémům. Před commitem to samozřejmě vyčistím a zformátuju, check-patchi ani maintainerům to nevadí (protože se to k nim nedostane).

[Bystroushaak]

Závorky a středníky udělám jednou dvakrát za funkci

A taky u každého ifu, a na každém řádku za každým výrazem a ..

Prohánění bloků copypaste kódu dělám pořád. Občas kód dočasně vyřadím zakomentováním, ladící asserty a pracovní komentáře dělám zásadně bez odsazení i v bloku, kde je odsazení několik tabů. Tyhle věci musí být viditelné jako pěst na oko, protože to jsou obvykle místa, kde dochází k problémům. Před commitem to samozřejmě vyčistím a zformátuju, check-patchi ani maintainerům to nevadí (protože se to k nim nedostane).

Já tohle taky dělám pořád, kde v tom má python problém?

[pc2005]

Já tohle taky dělám pořád, kde v tom má python problém?

Reformátovací IDE? Já píšu některé C programy v MC editoru.

[Bystroushaak]

Reformátovací IDE? Já píšu některé C programy v MC editoru.

Cože? Prostě posun bloku doleva / doprava. To má i Vim a úplně každý programátorský editor, co jsem kdy viděl. Ostatně to potřebuješ i v tom C, pokud se z toho nechceš zeblejt. Pokud píšeš programy v MC editoru, tak prostě budeš muset posouvat bloky doleva / doprava nějak jinak, například manuálním přidáváním/mazáním mezer, nebo si na to napiš script nebo co já vím.

Jako, tohle mě na lidech pomlouvajících python vždycky úplně nejvíc zarazí. Vždyť je to proboha naprosto nejvíc triviální blbost. Doslova to není vůbec problém, ani hypoteticky. A tvrdit, že se ti kvůli tomu python nelíbí je jako odmítnout si vzít zadarmo auto, protože se ti nelíbí odstín žárovky, jakou svítí zadní světla. Asi jako říct, že v C nebudeš programovat, protože tam ty středníky musíš psát a úplně ignorovat všechny ostatní očividné výhody.

[pc2005]

Myslel jsem, že z mého postu bude jasný, že to během procesu nepoužívám. Dokud je kód WIP, tak je IMO zbytečný ho stylizovat. Když v céčku vkopíruju blok kódu do funkce, tak nemusím hnedka řešit zarovnání, aby to vůbec začalo fungovat.

Nebyla to jen syntaxe pythonu (i když to, že když chci, tak si musím na začátku definovat tabsize je o_O), celý ten jazyk mě přijde gramaticky zbytečně komplikovaný, namátkou koukám: víceřádkový komentář, kde není jasný, kde je začátek a kde konec, dvojtečka uvádějící nový blok (pokud to má řešit ten problém s {} v céčku, tak bych čekal, že tam nic takovýho nebude). Ale hlavně mě v minulosti vadily nekompatibility interpreterů a chybějící, nekompatibilní moduly (?). To začátečníka dokáže odradit.

[Bystroushaak]

(i když to, že když chci, tak si musím na začátku definovat tabsize je o_O)

Nic takového dělat nemusíš.

celý ten jazyk mě přijde gramaticky zbytečně komplikovaný

Gramatika je naopak dost jednoduchá, jednodušší než většina jazyků. Plné BNF má o 100 řádků míň než C a to jsou v tom komentáře a prázdné řádky pro přehlednost.

[pc2005]

Já mluvil o použití nedefaultní hodnoty, ale hlavně o tom, že taková volba vůbec existuje.

Gramatika je naopak dost jednoduchá

Bash bude mít nejspíš jednodušší gramatiku, ale window manager v něm asi programovat nebudeš. Brainfunk má jednodušší gramatiku zcela určitě a taktéž. Měřítko není velikost BNF, ale přívětivost pro člověka, když mě parser může zprudit za odsazení každé řádky vs za jedno chybějící "}", tak je to první prostě nepřívětivý. Jako můžu použít editor, aby to odsazení řešil, ale to je rovnák na vohebják.

[Bystroushaak]

Já mluvil o použití nedefaultní hodnoty, ale hlavně o tom, že taková volba vůbec existuje.

Co to vůbec znamená? Nic jako defaultní hodnota tam není. Můžeš odsazovat libovolným počtem tabulátorů, mezer, či jejich kombinacemi. Jediné pravidlo je, že když chceš odsadit blok, tak musí být odsazený víc, než ten předchozí.

Bash bude mít nejspíš jednodušší gramatiku, ale window manager v něm asi programovat nebudeš.

Ve skutečnosti jí má složitější (o pár desítek řádek), to ovšem neřeší věci jako že každý druhý program má rozdílné argumenty a samotný bash má asi sto různých nastavení, jak se může chovat. Což z něj činí jazyk složitější o mnoho víc, když vynechám že podpora čísel saje prdel, je stringově orientovanej a složitější datovej typ ani nevím, jestli se vůbec dá udělat.

Měřítko není velikost BNF, ale přívětivost pro člověka, když mě parser může zprudit za odsazení každé řádky vs za jedno chybějící "}", tak je to první prostě nepřívětivý. Jako můžu použít editor, aby to odsazení řešil, ale to je rovnák na vohebják.

Díky, vysmál jsem se dobře. Prosímtě, dělal jsi v tom vůbec někdy? Protože já s tím mám desítiletou zkušenost, s C mám historicky ještě delší a o přívětivosti u něj nemůže být ani řeč, ať už se bavíme o syntaxi, hlášek kompilátoru, nebo o jazyce jako takovém, který je přívětivý a pohodlný asi jak dřevěná postel v Osvětimi.

BTW: Kolikrát v životě se ti stalo, že jsi napsal if () bez {}, pak jsi tam přidal řádek a program byl funkčně blbě, i když se syntakticky tvářil funkční? Protože v Rustu je to například zakázané, jelikož šlo o častou chybu.

[pc2005]

Co to vůbec znamená? Nic jako defaultní hodnota tam není. Můžeš odsazovat libovolným počtem tabulátorů, mezer, či jejich kombinacemi.

Aha tak to pardon, moje chyba, špatně jsem usoudil, že se to musí předdefinovat. Já v pythonu neprogramuju.

složitější datovej typ ani nevím, jestli se vůbec dá udělat.

Tak "dá" ...

přívětivosti u něj nemůže být ani řeč, ať už se bavíme o syntaxi

Tak je to subjektivní, ale mě prostě možnost napsat několik příkazů na jeden řádek společně s podmínkou, přijde přívětivá.

Kolikrát v životě se ti stalo, že jsi napsal if () bez {}, pak jsi tam přidal řádek a program byl funkčně blbě, i když se syntakticky tvářil funkční?

Možná tak jednou dvakrát, mě naopak NAKujou patche, protože píšu {} všude. Dopředu nevím zda tam nebudu muset házet assert, takže pro jistotu.

[Fluttershy, yay!]

Tak je to subjektivní, ale mě prostě možnost napsat několik příkazů na jeden řádek společně s podmínkou, přijde přívětivá.

To v Pythonu jde – oddělovat příkazy středníkem na řádku.

[pc2005]

Tak to pak ale nechápu, proč to dovoluje tohle, ale libovolné (ne)odsazení ne.

[Fluttershy, yay!]

Odsazení musí být konzistentní v rámci bloku, toť vše.

[pc2005]

P.S.

Tato debata zacina byt znacne nesmyslna, koncim.

To škoda, mě ta diskuze bavila . Minimálně jsem si díky ní uvědomil, že je víc kritérií, pomocí kterých se dá daný postup hodnotit. A že existujou lidi jako je kralyk, co začli uprostřed a chápou lowlevel věci jako přímé a nepřímé reference bez problému .

Moje představa může být idealizovaná, ale celá tahle větev vlákna vznikla z toho že se Grunt ptal co jsme dělali na konci 90. let (já psal, že jsem se učil programovat v pro mě neefektivních jazycích). Rozhodně nejsem učitel programování i když kdybych někdy někoho učil, tak bych začal tak jak jsem popisoval. Ale "vzal" bych to jen kdyby se někdo chtěl naučit lowlevel jazyky.

[ehm]

Každopádně třídící stromy vznikly kvůli potřebě optimalizaci a efektivitě, takže učit to na jazycích, kde se to mikrooptimalizace nemusíš starat (java), je IMO vyloženě kontraproduktivní (proč bych měl řešit třídění prvků, když to za mě udělá orákulum virtuálního stroje).

Pleteš si mikrooptimalizaci a optimalizaci. Není rozdíl, jestli jeden krok trvá milisekundu nebo dvě, ale je rozdíl, jestli se dělá tisíc kroků nebo milion kroků.

[pc2005]

Aha sorry, ona celá ta věta je divně konstruovaná navíc jsem si původně zavřel omylem tab a psal jsem to podruhý z paměti. Každopádně jde o to, že spoustu těhle třídících funkcí mají vysokoúrovňové jazyky už implementované.

[Fluttershy, yay!]

No a? Stromy se používají i jinde.

[pc2005]

Což není argument pro nepoužití céčka.

[ehm]

Ani pro jeho použití.

[pc2005]

Pro použití je to, že u céčka nejsou stromy součástí libc a tak si je obvykle musíš implementovat nebo aspoň prozkoumat hypotetickou knihovnu, zda je implementace OK pro tvoje použití. V céčku se se stromem setkáš častěji.

[ehm]

To už je fakt můžeš vysypat někde mimo civilizaci a počkat, až si nějaký počítač znovuvynaleznou sami. Vyzdvihovat zoufale omezenou standardní knihovnu jako výhodu je totiž ekvivalentně hloupé.

Lidi zpravidla mají zájem se něco učit proto, aby jim to umožnilo něco dělat. Proto dobrá výuka začíná vždy shora a teprve pak se probublává dolů k principům, aby člověk trochu víc tušil, co dělá. Z tohoto důvodu by byl nesmyslný argument, že když se dříve lidi učily programovat v manuálně kompilovaném assembleru, protože nic lepšího nebylo, tak je to jistě dobré i dnes. Není. Lidi používají počítače dnes a denně, vidí, co všechno to je schopné dělat a očekávají, že oni se k tomu dostanou taky. Ne že to kompletně downgraduješ a začneš je učit nesmyslně nízko.

Pokud je třeba seřazení pole čísel tisíckrát vyřešené, tak naprosto není důvod, proč lidem bránit to udělat, dokud si to neimplementují.

[pc2005]

Vyzdvihovat zoufale omezenou standardní knihovnu jako výhodu je totiž ekvivalentně hloupé.

Na Hw obvykle moc jiných možností nemáš. Dokonce byla standardní knihovna tak přeplněná funkcema, že i nějaký zrušili (uclibc, musl, eglibc, newlib).

Proto dobrá výuka začíná vždy shora

Jak moc shora, pro jak moc nízkou aplikaci?

učily programovat v manuálně kompilovaném assembleru

No vidíš, my se učili v 2005 assembler na 8051 i když se v té době už dalo očekávat, že kapacity čipů půjdou prudce nahoru a nejspíš se vyplatí používat i C.

[ehm]

https://soundcloud.com/cora-sanches/fuck-this-shit-im-out

[Fluttershy, yay!]

Vlákno je – zhruba od #263 – o učení se začátečníka programování.

Nerozporuji, že „ajťák“ by třeba měl mít představu o relevantních implementačních detailech, což práce s pamětí [v Céčku] bezpochyby je.

Reagoval jsem v návaznosti na pasáž

binarni stromy lze hezky vysvetlit treba na teckovych parech jako ma Lisp

Jaká je úspěšnot člověka, co se naučí binární strom v lispu a pak se z toho binárního stromu má učit pointery v céčku? Jinak i v céčku jde binární strom učit bez explicitních pointerů.

Ukolem je naucit, co je to binarni strom, a ne pomoci nej ucit pointery.

Tak znova, pro naučení binárního stromu žádný jazyk nepotřebuješ. Maximálně jen model problému v mozku. Každopádně třídící stromy vznikly kvůli potřebě optimalizaci a efektivitě, takže učit to na jazycích, kde se to mikrooptimalizace nemusíš starat (java), je IMO vyloženě kontraproduktivní (proč bych měl řešit třídění prvků, když to za mě udělá orákulum virtuálního stroje).

Takže: [binární] strom je struktura, která se používá všude možně mimo třídění: namátkou v algoritmech „umělé inteligence“ / „strojového učení“ nebo napříč obory od biologie po lingvistiku.

Ostatně, tihle lidé, kteří se soustřeďují na jinou doménu, se typicky učí Python (dřív Perl) – proč asi? Jednak jsou v tom ty knihovny k lepení, jednak se v tom snadno abstrahuje (odtud se také berou ty knihovny).

Také jsou to často zajímavé (a tedy motivující) implementační úlohy i pro „ajťáka“. Přitom není žádoucí řešit technické detaily nebo syntaktické orgie [C] na úkor problému samotného.

[pc2005]

Ostatně, tihle lidé, kteří se soustřeďují na jinou doménu

..nespadají do nízkoúrovňového programování, není problém, aby se to neučili v pythonu.

Také jsou to často zajímavé (a tedy motivující) implementační úlohy i pro „ajťáka“. Přitom není žádoucí řešit technické detaily nebo syntaktické orgie [C] na úkor problému samotného.

Pokud je jeho hlavní jazyk python, tak proč ne. Pokud začal (nebo výhradně používá) céčko, tak se asi nebude učit jazyk, který nezná, od nuly jen aby vyřešil úlohu obsahující strom.

[Fluttershy, yay!]

Je to analogické k psaní textu: minimalistický značkovací jazyk nebo WYSIWY(G|M) editory obsahují méně balastu irelevantního k vyjádření myšlenky; např. LyX > LaTeX > plainTeX.

V Céčku je mimo nízkoúrovňové úlohy více boilerplate kódu, potažmo vůbec manipulace s ukazateli/pamětí představuje kognitivní (i mechanickou) režii, která není relevantní k řešení úlohy.

[pc2005]

V Céčku je mimo nízkoúrovňové úlohy více boilerplate kódu

Však už od půlky diskuze rozděluju jazyky na nízkoúrovňové a vysokoúrovňové.

[Fluttershy, yay!]

#361

A? Bavime se tu porad o vyuce programovani uplnych zacatecniku... Programovani kernelu je obyvkle hned druha kapitola, hned po pointerech.

Tady je prostě řeč o ortogonálních případech užití.

Jestli je někdo začátečník třeba v rozblikávání diod (třída problémů), je (zatím) volba něčeho jako Céčko vcelku nasnadě. Ale k tomu AFAIK nepotřebuje binární strom ani většinu konceptů souvisejících se „softwarovým inženýrstvím“.

Naopak pokud jde o úlohy mimo hardware, nedává užití nízkoúrovňových nástrojů smysl – ve výuce, dokud nejde o vyšší dívčí v oblasti optimalizací, systémového programování apod.

[pc2005]

Souhlas? Tahle větev už je strašně úzká ... o tom rozděleném užití jsem psal ještě před #361.

[Fluttershy, yay!]

Tahle větev už je strašně úzká

To záleží na obrazovce a stylopisu. S tím Jendovým patchem to není takový problém.

[xkucf03]

Trochu mi v téhle diskusi chybí člověk, který by řekl: „ale s knihovnou/frameworkem XYZ se dá i v Céčku psát celkem vysokoúrovňově a pohodlně.“

Nechcete se někdo ujmout téhle role? :-)

[kralyk z abclinuxu]

Trochu mi v téhle diskusi chybí člověk, který by řekl: „ale s knihovnou/frameworkem XYZ se dá i v Céčku psát celkem vysokoúrovňově a pohodlně.“

Protože pro C prostě neuděláš knihovnu/framework tak, aby se v tom psalo vysokoúrovňově a pohodlně...

[xkucf03]

v mladém věku je člověk víc flexibilnější a pokud se naučí v mechanismu Cčka myslet

Otázka je, jestli je to k dobru věci. Pokud bude jeho prací převážně tvorba aplikací a bude se většinu profesního života pohybovat na vyšší úrovni abstrakce, tak si myslím, že je to spíš na škodu a že „myslet v Céčku“ (nebo nedejbože v instrukcích procesoru) ho zkazí, bude psát horší kód a spolupráce s ním bude obtížnější.

Jde o to, že zdrojový kód – kromě toho, že se nakonec přeloží na instrukce procesoru – slouží jako komunikační prostředek mezi lidmi. A ignorovat tuto funkci kódu je fatální chyba. Neříkám, že se má psát záměrně neefektivně, ale pokud se rozhoduji, jestli napsat něco a) výkonově optimálněji nebo b) čitelněji pro člověka, tak se dobře zamyslím, jestli ten výkonnostní rozdíl je vůbec relevantní. Je měřitelný, všimne si někdo, že to je rychlejší? Není náhodou ta optimalizace o řád nebo dokonce několik řádů pod tím, co v programu/algoritmu žere nejvíc času? Stručně řečeno: optimalizovat je potřeba úzké hrdlo a ne nějaké náhodné pasáže, které ve mně vyvolávají nějaké pocity nebo které bych dokázal napsat úsporněji (ovšem za cenu horší čitelnosti).

Ty hodiny, které jiný programátor nebo tvoje budoucí já, stráví zkoumáním programu a hledáním toho místa, kde je potřeba něco upravit nebo kam a jak dopsat novou funkčnost, jsou mnohem dražší než nějaké cykly CPU.

Tím nechci říct, že se má plýtvat výkonem – spousta aplikací se píše dnes velmi neefektivně a to jak z hlediska výkonu, tak z hlediska srozumitelnosti a rychlosti vývoje. Naskládá se na sebe hromada vrstev abstrakce, což snižuje výkon, ale teoreticky by to mělo zvyšovat efektivitu programátorů, ale ono to selhává i v tomto směru – další a další vrstvy nepřinášejí očekávaný vývoj, ale spíše nové problémy a znepřehledňují situaci. Třeba takový webový prohlížeč – to je neskutečně komplexní záležitost a má klidně i 50 milionů řádků kódu. A na tom velká část dnešních aplikací závisí.

Oproti tomu takové OpenJDK má „jen“ 13 milionů. Rust nebo Python „jen“ milion. Perl 2. GCC 9,5. GTK 1,1. Qt 12. …

Podle mého má smysl se vrátit trochu zpátky a začít znovu, odhodit některé vrstvy, které nepřináší slibovaný užitek, a dělat software trochu jednodušeji. Ale rozhodně nevidím smysl v mikrooptimalizacích a v těsné vazbě na hardware (kromě výjimečných případů). Smysluplné vrstvy abstrakce je naopak potřeba zachovat. Např. je užitečné, když operační systém odstíní aplikaci od toho, na jakém CPU běží, nebo z jakého souborového systému načítá data. Taky je dobré umět pracovat s daty nezávisle na tom, jestli se nacházejí na lokálním disku nebo na síti, zda jsou v souboru, nebo zda je generuje jiná aplikace atd. Ale k tomu stačí nějaký vyšší (než C) programovací jazyk a poměrně jednoduché knihovny a nebo návrhové vzory.

[Grunt]

Můj názor je takový že v mládí by se hlavně člověk neměl ničit nějakým Céčkem nebo Javou, ale měl by si víceméně hrát a snažit se pochopit jak programování a počítače fungují. Musím uznat že v době osmibitů to bylo nadmíru jednoduché. Téměř přímý přístup k HW na straně jedné, BASIC na straně druhé. A jestli bude někdo nadávat, tak dodám že to byl jazyk natolik jednoduchý že ho pochopí i školák a na druhou stranu dosti komplexní že se v něm daly psát zajímavé programy jako např. konverzační program. Kurňa, vždyť v něm psal hry i Bill Gates. Nějaká obdoba dnes chybí.

[Bystroushaak]

Obdobou je více/méně python. I v tom, že se ho dneska učí na univerzitách jako první jazyk studenti nestudující IT. Jediný podstatný rozdíl je v tom, že není předinstalovaný na Windows (na linuxu většinou všude jo).

[pc2005]

Otázka je, jestli je to k dobru věci. Pokud bude jeho prací převážně tvorba aplikací a bude se většinu profesního života pohybovat na vyšší úrovni abstrakce, tak si myslím, že je to spíš na škodu a že „myslet v Céčku“ (nebo nedejbože v instrukcích procesoru) ho zkazí, bude psát horší kód a spolupráce s ním bude obtížnější.

Jo to souhlas, ale tím pádem by člověk nesměl k céčku ani páchnout (pokud chce dělat dobře v javě). Protože ono to funguje i naopak. Člověk co umí myslet ve vyšších jazycích, pak píše v céčku kód, že se céčkař chytá za hlavu.

Je měřitelný, všimne si někdo, že to je rychlejší?

Njn rozdíl mezi lidma, co začínali na táhnoucí se 386 a ještě v 16 si nemohli naráz pouštět písničky (wavy :-P) a kopírovat na disketu a lidma, co předpokládají, že všichni mají minimálně tak rychlý počítač jako oni sami .

Třeba takový webový prohlížeč – to je neskutečně komplexní záležitost a má klidně i 50 milionů řádků kódu. A na tom velká část dnešních aplikací závisí.

Dillo je poměrně malé, funguje mi i na stroji s 64MB RAM (~30MB sežerou xka) .

[xvasek]

Myslíš že by tě to někam posunulo? Navíc jak říká Liška, nezapomeň že v té době si se mohl učit tak maximálně číst a psát, ne dělat něco vážného. Ten BASIC byla v mém případě spíš náhoda a úplně první vážnější "jazyk", tedy VRML97 přišlo právě až po přelomu milénia.

Toto je s prominutím pěkná blbost. Basic byl a je zcela regulérně jazyk bez uvozovek. Je to historie, ale hledat někde čáru a říkat "doteď to bylo takové plácání, odteď už je to seriózní věda" - to bych určitě nedělal. Stejně jako tabulátory IBM posloužily za války jako efektivní nástroj pro logistiku, má i basic za sebou spoustu aplikací a programů, které ve své době přinesly absolutně nové věci a možnosti.

Tehdy bylo trochu jiné paradigma, než dnes. Jednak byly počítače podstatně méně časté, druhak jsme k problémům přistupovali jinak. Dnes, když chceme něco řešit, tak hledáme program, který daný problém řeší, nebo možná už jsme trochu dál a často hledáme spíš nějakou online službu. V době basicu nás takové věci nenapadly, měli jsme problém, tak jsme si program pro jeho řešení prostě _napsali_. Pro toto použití byl ten jazyk designovaný.

I dnes při těch gigahertzích a gigabytech řešíme často stejné problémy, jako v dobách basicu a s ohrnutým nosem klidně napíšu, že programování samotné i běh těch systémů jsou s těmi historickými bohužel plně srovnatelné.

Pro mě osobně byl přechod na PC (tehdy 8088, resp. NEC V20) poměrně šokující. Říkal jsem si - to jako z tak nabouchaného hardwaru, tak rychlého CPU, tolika kilobytů RAM a harddisku (!) dokázali ti žabaři dostat jenom toto?

To jsem ale fosílie...

[Bystroushaak]

Bože, chytám se za hlavu. Co ste sakra v pětadevadesátém a šestadevadesátém jako dělali?

Já jsem se zrovna učil psát.

[Grunt]

To je fakt. To je tak první, druhá třída. To mohl být maximálně Jetpac, Pssst a Kuchárik. Warcraft musel být pozdějc.

[Bystroushaak]

Ve třetí už jsme někam chodili pařit Wolfensteina. Stylem že jeden hrál a dvacet dalších fascinovaně koukalo, co že se to tam děje.

[Kosac]

Jetpac, pssst atd. bylo tak 89-90 - muj prvni pocitac HC Didaktik Gama (5. trida). 1993 byla 80386 (jeste bez kopru, s emulatorem) a na ni Duna 1, Another world, Lemmings, v 1996 Pentium a Jagged Aliance, Canon Fodder, Crusader:No regret. Nekde mezi tim jeste Stunts, Lotus apod.

[Grunt]

Jetpac, pssst atd. bylo tak 89-90

Vydáno. Jenže než se to dostalo do Skalice (dodám že výrobní družstvo stojí dodnes tam kde stávalo, akorát se už nezabývá výrobou počítačů), než můj tata koupil první porevoluční počítač (to muselo být na 100% po revoluci), než jsem se vůbec naučil ovládat joystick, to by tak odpovídalo. Teď v retrospektivě si vzpomínám že první číslo Počítače pro každého vyšlo v roce 1998 (poctivě jsem zakládal do šanonu) a tak v druhém čísle bylo něco o tom že nejlevnější počítač (myšleno asi nějaké Pentium) stálo něco kolem 19 000Kč a nad tím sem slintal jak děcko nad lízátkem. Někdo holt měl prachů dost a nebo spíš bohaté rodiče

[Kosac]

Jo, mozna jsem o rok vedle, ale 1991 to muselo byt urcite. A 1998 nebylo o bohatejch rodicich, ale o vyrobnim prostredku s CAD. Jinak levnejsi bylo rysovaci prkno, samozrejme...

[k3dAR]

no fuj, AnotherWorld, Lemmings, Canon Fodder a Lotus sem paril na Amize, na PC to bylo vse mnohem hnusnejsi

[k3dAR]

no, v 95 sem se setkal s Blizzardem, kdyz sem si od Phase5 tuhle turbokartu s 68040 instaloval do Amiga1200, zadnej troll u toho nebyl

[Agent]

Co se dělali? Já pařil automaty. Dnes ty hry sjíždím přes MAME.

Twin Eagle

[Ovoce]

Pro mě byl formativní zážitek, když jsem na nějakým školním výletu na prvním stupni viděl automat a TVL na tom GOLDEN AXE. Jaká byla radost, když jsem to pak znovuobjevil o pár let později, když mi to kámoš nahrál na disketu. To bylo maso na 486ce s VGA/písíspíkrem. Jo, já u her tý doby nikdy nezažil tu originál hudbu. Výše zmíněný Diablo sem zase měl nějakej crack/hack, takže taky bez hudby(!), tu sem zažil akorát v demu, který jsem hrál snad 50x lol.

Škoda, že jsem nikdy nezjistil, co za arkádovou vesmírnou střílečku bylo na automatu v bazénu, vždycky jsme na to koukali. Bylo to viděný z vrchu, a když člověk hodil bombu nebo už byl na obrazovce kráter s šipkou a "IN", tak se do něj dalo vletět. V intru byla animace s pilotem jak běží a naskakuje do stíhačky, IIRC.

[pc2005]

Jo golden axe bylo super to jsme pařili na základce ve školním klubu. Jednou jsem přišel kvůli scorched earth domů ze školy až skoro v noci .

[JZD]

Příloha:

• cas-20-28-grunt-06-06-2018.png (32183 bytů)

Aktuální foto.

[Grunt]

Proč si mě fotíš? Není náhodou moje podoba soukromý údaj nebo tak něco?

[JZD]

Vztahuje se snad na virtuální podobu GDPR nebo tak něco?

[Grunt]

¯\_(ツ)_/¯

[ehm]

https://www.abclinuxu.cz/blog/BLB/2017/3/wow-jsem-fakt-znechucenej/diskuse#333

[Grunt]

Takové rýpnutí, když teď vidím to velké stěhování národů: Co Microsoftu brání v odkoupení Gitlabu řekněme třeba po roce až provede úplnou akvizici Githubu a vzaintegrování do svých služeb podobně jako to provede (pravděpodobně) s Githubem? Je to úplně stejně obchodovatelná společnost jako ten Github.

[xkucf03]

Je otázka, kolikrát by to byl MS ochotný absolvovat, když by mu uživatelé vždycky utekli. Při každé iteraci navíc odtečou peníze z Microsoftu k někomu jinému. Zároveň při tom uživatelé snad pochopí, že je lepší mít decentralizovanou/distribuovanou platformu, která je trvale udržitelná a nezávislá, než se pořád stěhovat od jednoho poskytovatele k druhému. Chápu, že je těžké, aby se tohle stalo třeba u takového Facebooku, protože ten používají v drtivé většině lidé, kteří takovou platformu vytvořit neumí. Ale GitHub používají převážně programátoři…

[Grunt]

Je otázka, kolikrát by to byl MS ochotný absolvovat, když by mu uživatelé vždycky utekli. Při každé iteraci navíc odtečou peníze z Microsoftu k někomu jinému.

Se podívej kolik mají akvizicí. To je co rok několik majoritních (v řádu mld. dolarů) To je takový moloch že tam snad na ty akvizice musí vést nějaký pořadník. Něco ve smyslu „V klidu, v pohodě, na každého se dostane, ale hybaj do fronty, šup, šup…“.

[Josef Kufner]

Rozdíl mezi Githubem a Gitlabem je hlavně v tom, že Gitlab lze docela snadno spustit na vlastním VPS. To výrazně zjednodušuje možnost Gitlab.com opustit. Dokonce na to má Gitlab integrovaný nástroj.

[Grunt]

Což se může velice rychle změnit poté co tu společnost která ho vyvíjí někdo odkoupí.

[Josef Kufner]

Gitlab je open-source, takže se to nezmění, alespoň ne pro starší verze. Export by sice vypnout/zakázat mohli, ale to se zas nestane ze dne na den bez varování, že se něco děje. A když by se k něčemu schylovalo, tak si uživatelé alespoň mohou udělat zálohu.

[Grunt]

Ok. Schválně jsem zvědavej…

The king is dead, long Live the GitLab.

[Michal Kubeček]

The king is dead, long Live the GitLab.

Na takové výkřiky je IMHO ještě příliš brzy. Spíš se obávám, aby těch pár hektických dnů Gitlabu nakonec neuškodilo, když potenciální uživatelé a zákazníci uvidí, jaké problémy má zvládnout těch pár tisíc přemigrovaných (většinou asi spíš zkopírovaných) projektů.

[Grunt]

Očividně neškodí, ba naopak

[Bluebear]

Gilab si muzes hostovat sam. Ale nemusis.

[Jendа]

Oproti tomu ty projekty na githubu měly návštěvnost a pull requesty občas prostě jen proto, že na to někdo narazil a líbilo se mu to.

Jak se stane, že na GitHubu na to náhodným browsením narazí, ale na obecném webu ne?

[Bystroushaak]

Protože je jednoduchá discoverabilita. Můžeš se lehce podívat, co kdo dělal na kterém projektu, jaké jsou jeho další projekty a tak podobně. Mě takhle followuje asi 30 lidí, z nihž většinu vůbec neznám, jen se jim prostě líbilo něco co dělám.

[mirec]

Ja často potrebujem vyhľadať určitý kus kódu v určitom jazyku. Vtedy si otvorím github, dám do vyhľadávania fragment, ktorý ma zaujíma a jazyk v ktorom ho potrebujem. Nedávny príklad: importujem dáta z nemenovaného PHP-čkoveho CMS do djanga a potreboval som zmigrovať hashované heslá. Viem, že hash má určitý prefix, tak ho dám do vyhľadávania, obmedzím jazyk na Python a ako prvý výsledok mám rovno auth backend do djanga. Keď to isté dám do googlu s textom python / django nenájde nič.

[xkucf03]

Příloha:

• github.com - smazáno - 2018-06-04.png (9806 bytů)

Osobně vidím výhodu Githubu právě v té sociální části.

V první řadě je chyba, že jsi to nechal zajít tak daleko a stal jsi se závislý na proprietární službě (resp. bude ti nějak výrazněji chybět). Že to dneska koupil Microsoft je už jen taková třešnička na dortu – ale špatný byl ten stav už dávno před tím.

Ostatně: There is no cloud …just other people's computers.

protože se dají jednoduše najít a nebýt githubu, tak bych se o nich ani nedozvěděl

Já to mám jinak – přestože jsem z GitHubu postahoval spousty softwaru, nikdy jsem ho tam nehledal. Odkazy na ty projekty jsem vždy nacházel normálně na webu, v diskusích, přes obecný vyhledávač, v e-mailových konferencích atd.

Taky se mi líbí ta filosofie „code first“ a že člověk u menších projektů nemusí vymýšlet žádnou prezentaci - samotný kód je tou prezentací. Vzpomínám si ještě na doby, kdy si člověk musel dělat pro svoje projekty vlastní stránky, což i když už náhodou udělal, tak zabilo objevitelnost (než to zaindexuje google a na jakou pozici to asi tak dá) a u ostatních lidí ochotu zapojit se (nebudou vymýšlet jak kód stáhnout, provést patche a dát mi o nich vědět).

Na tohle mám trochu jiný názor. Chápu, že ušetřený čas, který nestrávíš vytvářením webu, můžeš věnovat psaní kódu, což by teoreticky mělo být přínosnější. Ale v praxi má tahle myšlenka docela trhliny. Např. schopnost srozumitelně popsat vlastní projekt, považuji za stejně tak důležité jako psát kvalitní kód. Bohužel spousta „projektů“ na GitHubu je tak, jak to autorovi odpadlo od ruky, bez pořádného popisu, bez dokumentace, v neznámém stavu. Ono napsat řádky kódu vlastně moc neznamená a někdy mají dokonce zápornou hodnotu, spousta projektů se topí ve statisících nebo milionech řádků kódu a brzdí to další rozvoj i úplně obyčejnou údržbu. Software je pak mnohem víc než jen ty řádky kódu.

I když jsem GitHub reálně ani nepoužíval, účet jsem aspoň symbolicky zrušil. Dnešní událost bych nevnímal nijak tragicky – špatné to bylo už dávno před tím – teď si akorát pár lidí přišlo k pěkným penězům a pro ostatní to snad bude impulzem k hledání lepší cesty. Ostatně to přelití části peněz z rukou MS do rukou někoho jiného je v zásadě pozitivní věc – snad s nimi naloží líp než MS.

[Grunt]

Ostatně to přelití části peněz z rukou MS do rukou někoho jiného je v zásadě pozitivní věc – snad s nimi naloží líp než MS.

Třeba si za ně koupí něco pěkného. Je ti doufám jasné že pro takové korporace jsou peníze něco jako chcánky v moři, denní chleba který se přelévá odněkud někam, čísla na kterými ani moc nikdo nepřemýšlí. Ostatně celou akci až a pár nastrčených koňů zaštiťuje ta nejdůležitější osoba a tou je ta CFO. Já bych tyhlety akvizice zakázala.

[Bystroushaak]

V první řadě je chyba, že jsi to nechal zajít tak daleko a stal jsi se závislý na proprietární službě (resp. bude ti nějak výrazněji chybět). Že to dneska koupil Microsoft je už jen taková třešnička na dortu – ale špatný byl ten stav už dávno před tím.

Závislý jsem taky na jídlu a na pití a na internetu (elektřině, teplu, sociálním kontaktu, ..). Samozřejmě, že kdybych nebyl, tak bych na tom byl líp v případě, že nebudu mít jídlo, pití, nebo internet (nebo ..), ale to tak nějak ztrácí pointu. Bez Githubu bych se těžko vůbec někdy takhle zapojil.

Na tohle mám trochu jiný názor. Chápu, že ušetřený čas, který nestrávíš vytvářením webu, můžeš věnovat psaní kódu, což by teoreticky mělo být přínosnější. Ale v praxi má tahle myšlenka docela trhliny. Např. schopnost srozumitelně popsat vlastní projekt, považuji za stejně tak důležité jako psát kvalitní kód.

Na to ti právě často stačilo jedno readme.

[xkucf03]

On je ale dost velký rozdíl být a) závislý na jídle obecně a b) závislý na jídle od jednoho konkrétního výrobce.

V prvním případě ti jídlo může dodat kdokoli nebo si ho můžeš vyrobit sám. Ale v tom druhém jsi závislý třeba na jídle od Babiše nebo na službě od Microsoftu.

Přijde mi, jako by spousta lidí zapomněla, že Git je v první řadě svobodný software, že si ho můžou spustit na celkem libovolném serveru resp. ani ne serveru, ale počítači a že k němu můžou přistupovat přes SSH nebo jiným protokolem. Pokud se nad úložištěm zdrojáků mají budovat nějaké (sociální) vztahy, tak stačí nějaký formát na popis souvisejících metadat + nástroj, který tato (meta)data bude indexovat. Ostatně to je princip webu – hostovat ho můžeš kdekoli a lidé si ho čtou jedním z mnoha prohlížečů a najdou jedním z mnoha vyhledávačů nebo katalogů nebo si předají odkaz jinou cestou. Bylo by absurdní, kdyby všichni museli hostovat svoje weby u jednoho centrálního poskytovatele (byť Facebook se o to vlastně snaží resp. pokouší se nahradit web jako takový svojí proprietární službou).

BTW: existuje nějaký standard pro unikátní identifikaci repozitáře, aby ho šlo poznat i po přesunu na jiný hosting? Mohlo by to být např. UUID nebo otisk veřejného klíče – k tomu bys připojil URL aktuálního hostingu a podepsal klíčem soukromým. Tím bys deklaroval kontinuitu a fakt, že to jsi pořád ty. Resp. asi by to bylo víc párů klíčů – jednotliví vývojáři by připojili svůj podpis k deklaraci, na jaké adrese se projekt aktuálně nachází.

[Bystroushaak]

Přijde mi, jako by spousta lidí zapomněla, že Git je v první řadě svobodný software, že si ho můžou spustit na celkem libovolném serveru resp. ani ne serveru, ale počítači a že k němu můžou přistupovat přes SSH nebo jiným protokolem. Pokud se nad úložištěm zdrojáků mají budovat nějaké (sociální) vztahy, tak stačí nějaký formát na popis souvisejících metadat + nástroj, který tato (meta)data bude indexovat. Ostatně to je princip webu – hostovat ho můžeš kdekoli a lidé si ho čtou jedním z mnoha prohlížečů a najdou jedním z mnoha vyhledávačů nebo katalogů nebo si předají odkaz jinou cestou. Bylo by absurdní, kdyby všichni museli hostovat svoje weby u jednoho centrálního poskytovatele (byť Facebook se o to vlastně snaží resp. pokouší se nahradit web jako takový svojí proprietární službou).

Já s tím souhlasím. Jen to prostě nikdo zatím neudělal. Tohle tomu naopak může pomoct.

[Grunt]

Závislý jsem taky na jídlu a na pití

Nevím proč jsem si vzpomněl na Aquacolu (Hint:Mad Max).

[Bystroushaak]

Jen čistě pro potěšení z offtopicu:

Tohle je asi nejvíc epický soundtrack co byl kdy stvořen; Mad Max: Fury Road OST - Brothers In Arms. Jsem to slyšel snad 20x a stejně je to zaručený audiogasmus pokaždé když to znova pustím.

[Grunt]

Výborně, takže bacha na vodu ať se na ní nestaneš závislý nebo sám moc dobře víš kde skončíš. Tolik k tvé potřebě jíst a pít.

[Agent]

Šílený... :-O

[Jendа]

Závislý jsem taky na jídlu a na pití a na internetu (elektřině, teplu, sociálním kontaktu, ..).

Na jídlu, nikoli na produktu jedné konkrétní firmy vyrábějící jídlo. Na teplu, nikoli na jedné konkrétní teplárně. Atd.

[Bystroushaak]

Moje pointa byla, že závislostem se nevyhneš a nemusí být nutně problém. Samozřejmě je lepší je nemít ve chvíli, kdy problém být začnou. Github je hezká ukázka projektu, který pro mě asi osm let problémem nebyl.

[Fluttershy, yay!]

Na jídlu, nikoli na produktu jedné konkrétní firmy vyrábějící jídlo.

Rád bych tomu věřil, ale…

[_]

Mit zalohu jen na githubu je demence bez ohledu na to, komu github patri. Privlastnit si kod nemuze, to by bylo protizakonne. Takze opet paranoia a konspiracni teorie.

[Nic]

Takže Microsoft je jakože záruka, že se nebude nic dít protizákonně? Haha, to je vtip roku.

[Grunt]

Ne, tou by měla být EU a Government US, v plánu je dosáhnout approval do konce roku, jenže:

We are confident about our prospects for obtaining regulatory approval by end of this calendar year.

Takže moc nadějí že zrovna ti něco zatrhnou bych neviděl. Asi prachy.

[Nic]

"tou by měla být EU a Government US"

Ty máš nějaké ambice udělat z toho ještě vtip desetiletí?

[Love_Dali]

Přesně tak tomu bude - ostatně nejsme tomu jinak třeba na googlu..

[ehm]

Fuck This Shit I'm Out

[ehm]

Kdyby měl někdo třeba tip, jak vypnout to zkurvené automatické přehrávání další sračky, tak to sem může napsat pro ostatní. To je fakt nějaká konspirace dělat UX tak, aby se to chovalo co nejmíň předvídatelně a nasralo to co nejvíc lidí?

[Jacob]

Vyvíjet svobodný software na jedné centralizovaé proprietární platformě není úplně nejšťastnější. Copak se nikdo nepoučil z incidentu Bitkeeper? Říkal jsem to už dávno a Github jsem proto nikdy nepoužíval. To, že masa FOSS se přesunula téměř výhradně na Github mi zavánělo uložením všech křehkých a důležitých vajec do jednoho koše. Třeba to inspiruje vývojáře, aby se buď strategicky rozprchli na různé strany, aby odstavení jedné služby nepoložilo 95% FOSS projektů, nebo aby sestavili něco jako peer-to-peer Git se sociální dimenzí na způsob Diaspory, kdy spolu různé serverové instance komunikují. Ale nedělám si moc velké iluze, že se něco z toho stane.

[elenril]

+100500 Stále žasnu jak hodně lidí je ochotno se stát kriticky závislými na jedné specifické korporaci, pro kterou navíc nejsou ani zákazníkem. Pak jsou hrozně překvapení, že se ta korporace k ním jako k zákazníkům nechová. Schválně kolik lidí tady má gmailovou adresu.

[Marián Kyral]

+100500 Schválně kolik lidí tady má gmailovou adresu.

Tipuji, že naprostá většina těch, co mají Android. To ale neznamená, že to je jejich jediná adresa.

[jdsulin2]

Jako osobne bych ihned premigroval, ale myslim si, ze tento pripad spis souvisi s danovou optimalizaci - proste maji spoustu hotovosti, kterou by museli zdanit a nakup nove (prosperujici) spolecnosti se danit nemusi. Je to proste normalni investice.

[Grunt]

Můj názor je úplně ten stejný. Microsoft je prostě moloch kde na jedné straně peníze přitékají (licence, patenty) a na druhé se hromadí a aby se nehromadili tak moc, resp. aby se dalo říct že se k něčemu využijí, mají prostě tým který připravuje možnosti akvizic a až z potůčku přiteče dost, prostě se to pleskne na nějakou z možných připravených akvizici a jede se dál. Z potoku teče další mana. Blbé je že to trvá prostě už moc dlouho a nikdo s tím nic nenadělá.

To že produkt vymře je pouze důsledek toho že Microsoft nebyl nikdy zrovna průkopníkem v oboru inovací. No hřbitov vypadá nějak takto. Obávám se že asi přibude o jeden hrobeček navíc.

[Shini]

Github dvakrat moc prosperujici neni, momentalne by tech 7.5Giga splatili zhruba tak nikdy. Tj. bud najdou nejaky zpusob, jak uzivatele dukladne oskubat, nebo to pro ne ma jinou hodnotu - pristup ke spooouste zdrojaku. Osobne hlasuju za B.

[jdsulin2]

Proste prijemne s uzitecnym. Co s tema prachama chces jinak delat ? Zdanit ?

[Odin]

V kontextu .net core a azure to dava z jejich pohledu smysl.

[Bystroushaak]

To vysvětli víc. Smysl to asi dává, jinak by to nedělali, ale já to pozadí neznám.

[Odin]

Github zajistuje repozitar a veci okolo pro obrovske mnozstvi projektu. Na azure cloudu bezi velke mnozstvi linuxovych stroju. .net core sam pouziva github a bezi na linuxu ( btw koho by to pred par lety napadlo). Na githubu se nachazi obrovska komunita, kterou timto muze microsoft alespon castecne pritahnout. Urcite dojde k integraci githubu do azure. Zde osobne vidim ja motivaci.

[Odin]

Jeste mne napadlo, ze by se urcite hodilo integrovwt funkcionalitu githubu do tfs. To jiste take dava komercni smysl.

[Abcdefgh]

Este by mohli kupit Red Hat.

[Grunt]

Nebo Canonical.

[Odin]

Canonical je mrtvy kun, ale to rozhodne neplati v pripade redhatu... Vzdyt existuje snad i nejaka dohoda o strategickem partnerstvi. Nedivil bych se, kdyby ms koupil rh.

[Luboš Doležel (Doli)]

Já bych počkal, co z toho bude. Přemigrovat jinam je otázka chvilky.

[Abcdefgh]

Zacne to povinnym prihlasovanim cez Microsoft account :D

[Nic]

Polil mě studený pot. Brr.

Týden nebudu spát.

[kralyk z abclinuxu]

Taky bych s tim měl problém, ale přijde mi to nepravděpodobný. Koneckonců třeba na LinkedInu se to nestalo, ne?

[randy]

Hlavne ze pred rokom ukoncili codeplex. Asi im tam nik nelozil, tak kupili github :)

Btw. Za linkedin dali podstatne viac prachov. Asi CVcka maju vacsiu hodnotu :)

[Grunt]

Asi CVcka maju vacsiu hodnotu

Spíš je to ukázka toho jakou reálnou hodnotu mají prachy.

[Bedňa]

Tak záléži na tebe kde si tu "raálnu" hodnotu postavíš, preto že všetci sme bratia ktorí boli stvorený z častíc pri prvom vzniku vesmíru, tak na tie prachy, čo? Nasrat.

[Grunt]

preto že všetci sme bratia

To je fakt. Vy na tom Slovensku jste všichni nějak jedna rodina…

[Nic]

To, co jsi právě napsal, vypovídá daleko víc o tobě než o něm.

[Bedňa]

Dík, hoci mám Gruntíka rád, prachy sú fakt posledné meradlo či už na kvalitu prácu, úspech, alebo hocičo iné.

[ehm]

Řekl vidlák. Je zázrak, že má většina z vás deset prstů, přitom jak tak všichni lezete po sobě jako křečci. Máma, teta, ségra, babča... to je pro vás vše povolený cíl.

[Grunt]

Je to jen můj pocit nebo do mně ryjou a vozí se po mně nějací anonymní rýpalové?

[k3dAR]

Je to jen tvuj pocit, jsou to anonymni tro(t)love...

[Ovoce]

ehm je nová identita toho spamujícího magora, iirc?

[Fluttershy, yay!]

ehm je nejspíš tenhle.

[k3dAR]

to by asi odpovidalo https://github.com/tadeaszima/pi

[Ovoce]

Aha, tak to sorry, já myslel ten ptermf... to se omluovám za tak odporné osočení.

[ehm]

Nechcete si založit detektivní kancelář? Nejsem nějaký pučmeloun z Brna, tady máte můj FB

[Nic]

Co máš z toho, já taky nejsem anonym, jen jsem tu zpravidla línej se přihlásit - ale nebudem jim brát jejich pocit převahy, ať si ho klidně užijou… nic jiného by jim totiž potom už nezbylo, a je to stejně jen jejich pocit. Něco jako když necháš dítěti lízátko, se Spidermanem na obalu třeba.

[kralyk z abclinuxu]

xkcd#774

[Nic]

To není ten případ, Grunt ví moc dobře kdo jsem, není to poprvé.

[Grunt]

No já ti jen chtěl navrhnout vážený anonyme že by si ses s mohl jít třeba vyjebat (tzv. by si mohl ojebat sám sebe). Nejsem na to voje rýpání absolutně zvědavý. Stačí mi pejsek, nepotřebuju ještě osobního trotla do vínku, zvláště když o něj absolutně nestojím. Dík. Pac a pusu, podepsán Grunt.

[Nic]

Děkuji za návrh, ovšem jako správný gentleman ti samozřejmě nabídnu celkem obvyklou dohodu "Až po tobě". Jinými slovy, nerýpej ty první do druhých lidí a národností jenom proto, že napsali něco, čemu úplně nerozumíš, nemáš to jak strávit a žere tě to nebo co (což je jen tvůj problém), a pak ti nikdo nebude palbu opětovat.

[Grunt]

Běž se vycpat, šašku počmáraný. Jdu spat.

[xvasek]

Co tady všichni bečíte, dyť se nic neděje, jaká "jedinečná" komunita githubu? Vždyť je to jenom normání zakuklený další facebook. Repozitáře jsou furt jenom repozitáře a k tomu je potřeba jenom git a webserver, kdo dělá nějakou dobrou věc, toho si lidi najdou přes stránky a klidně si to zmigruje za deset minut jinam, upraví si odkaz na webu na repo a uživatelská komunita může klidně používat co já vím třeba nntp nebo redmine, dyť je to úplně jedno.

[Bystroushaak]

Ty jsi github moc nepoužíval, co?

[xvasek]

V jedné éře jsme přenášeli software na audiokazetách a dokonce jsem viděl program na něčem plastovém, co bylo přílohou časopisu a dalo se strčit do gramofonu a asi třikrát přehrát. Sociálno jsme u toho měli krásné. Nemyslím, že by zrovna github měl být svatá kráva.

[Bystroushaak]

Stačilo napsat "ne".

[xvasek]

To bych neřekl. Zvlášť když dnes jde "github nepoužívat" asi stejně dobře, jako nepoužívat javascript. Já bych spíš řekl, že je mi v podstatě jedno, do jaké míry jsem používal právě zrovna github.

[_]

nepouzivam ani github, ani javascript

[ehm]

Ne? A jak jsi sem právě anonymně přispěl bez JS?

[_]

uplne normalne

[deda.jabko]

Asi budu extra asocial, ale na githubu me vzdycky zajimal kod, ne lidi. A vlastne nechapu, o jakych socialnich funkcich githubu tu neustale mluvis.

Kdyz to tady ctu, nechapu, jak jsme mohli ty roky pred githubem vubec fungovat. Sdilet zdrojaky, hlasit chyby, posilat patche, ...

[Bystroushaak]

Budu parafrázovat:

Asi budu extra asociál, ale na abclinuxu mě vždycky zajímal text, ne lidi. A vážně nechápu, o jakých sociálních funkcích abclinuxu tu neustále mluvíš.

Když to tady čtu, nechápu, jak jsme mohli ty roky před abclinuxu vůbec fungovat. Psát si, komentovat, posílat odkazy na zajímavosti, ...

Samozřejmě, že je možné se obejít bez Githubu a sociálních aspektů. Tak jsi ty sociální části nepoužíval. Ok. Dobré pro tebe (nebo ne? vždyť ani nevíš o co jsi přišel). Netřeba je ovšem zpochybňovat, spoustě ostatních lidí vyhovovaly.

Github je přímo zodpovědný za uvedení spousty lidí do světa opensource. Lidí, kteří by se k tomu třeba ani nedostali. Nejde o to, že by udělal něco vysloveně revolučního, ale snížil hranici znalostí a hlavně množství naprosto zbytečného opruzu, který musíš podstoupit pokud chceš někam přispívat. Vyřešil (a dobře!) lidský, sociální aspekt problému; jak přivést víc lidí k tomu aby se zapojili do projektů.

[Pasky]

A co kdyby Bystrouška a další sissies místo fňukání do gitlabu doplnili, co jim chybí. Je to opensource, takže nechápu, proč tady fňukáte nad akvizící komerčního proprietárního produktu Microsoftem.

[Bystroushaak]

Ale tak proč ne.

[Agent]

Takové podniky určitě vzniknou. Problém je získat ty lidi okolo, to může trvat zase pár let. Navíc se pravděpodobně komunita fragmentuje mezi vícero takových projektů. Třeba se to časem vyprofiluje a zvítězí jeden nejlepší, ale bude to zbytečně pár let opruz a ztráta času.

[ehm]

Protože je tlučhuba co nic neumí?

[Max]

Tak to vypadá, že exodus pomalu začíná : GitLab Sees Huge Traffic Spike After News of Microsoft Buying GitHub
Jsem na to zvědavý. Jednak kolik projektů přejde a jak případný nápor GitLab zvládne.
Zdar Max

[Ladislav Nešněra]

Mě přijde, že tato parta na ICT totálně kašle. Nebo víte o případu, kdy by zatrhli nějakou SW akvizici?

Každopádně jsem velmi zvědav, zda lidi opravdu zahlasují nohama.

[Gilhad]

Ja se chystal prez leto tam nasypat vetsinu projektu, ktere aspon nejak by mohly lidi zajimat.

Misto toho jsem odtamtud vcera stahnul i tech par pokusnych, na kterych jsem si zkousel, jak nastavit co nejjednodussi workflow projektu hostovaneho zaroven na mem gitovym serveru a githubu.

spis si ted zprovoznim nekde "frontface git server" pro verejne sdilene projekty, kam budu lidi zatim odkazovat a uvidim, jak se veci vyvrbi. (Stejne zakladem zustava server pod moji kontrolou)

[Aleš Kapica]

Jistě chápeš proč jsem řešil kupř. tohle.

[Gilhad]

Díky, přesně něco takového jsem se právě chystal začít hledat :)

[pc2005]

Ja se chystal prez leto tam nasypat vetsinu projektu, ktere aspon nejak by mohly lidi zajimat.

Taky! :-/ Holt kouknu se po jiném mirroru.

Nechtěli by majitelé abíčka nainstalovat gitlab?

[Aleš Kapica]

Rozbij prase a rozjeď ho sám.

Ale vážně. Každá charita musí mít nějaké financování. Pokud se najdou lidé ochotní pustit chlup a přispět na provoz, není problém takový server rozjet. Problém nastane, když pak ten, co to rozjel, dostane nabídku jaká se neodmítá. Jako se to stalo v případě Githubu.

[pc2005]

S DSL uploadem a hučícím serverem u postele? To spíš zůstanu u neveřejného domácího mirroru :-/. Resp náklady by byly vyšší než i třeba férově placené repo.

[Grunt]

Stále stejný problém.

[Aleš Kapica]

Kde máš psáno, že to musí být fyzický krám doma pod postelí?

Provoz jakéhokoliv serveru stojí prachy. Každý si ale musí rozmyslet, za co vyhodí co 5 let 15 litrů. Jsou částky, které není problém oželet a jsou částky, při jejichž obětování už očekáváš návratnost, nebo nějakou protihodnotu co tě uspokojí – jako je kupř. pocit dobře vykonané práce. Ale financování a údržba serveru, na kterém by byly veřejné git repozitáře, by mě osobně asi moc uspokojení nepřineslo. I když, kdo ví…

[Odin]

Pri cenach dnesnich cloudovych stroju penize opravdu resit nemusis.

[pc2005]

No 3 litry za rok kvůli mým blésmrt skriptům se mě fakt vyhazovat nechce, takovou cenu nemají (možná tak v desetikorunách až stovkách ). Proto jsem se ptal na úrovni komunitního projektu, kde se složí víc lidí.

[Bystroushaak]

VPS se dá koupit za pár korun. U forpsi stojí asi 32kč/měsíc s 20G diskem a 1G RAM.

[pc2005]

Až se dokopu k napsání blogu, tak můžeme zhodnotit zda to má cenu aspoň >0Kč/∞ .

[xvasek]

Náhodou já to používám a super. Migroval jsem z AWS, když mi "došla" free tier a za dva měsíce, co jsem platil AWS, než jsem si našel čas to přesunout, mám teď asi dva a půl roku Forpsi.

[Grunt]

Tak když jsme u toho tak tady v EU máme TFEU article 102 a nějakou komisařku. Nebylo by to poprvé. Ale:

1. Troufne si jí někdo napsat?
2. Co jí chceš napsat? Je to úplně obyčejná akvizice firmy bez peněžních prostředků. Na papíře je vše naprosto sněhobílé.

[ehm]

nějakou komisařku

Vypadá jako by předsedala sdružení bojujícímu za práva hermafroditů, nebo tak něco.

[Grunt]

Zato ty určtitě vypadáš jak šohaj.

[Bedňa]

GitLab je sr...., sorry jako.

Keď ľudia utekajú k niečomu čo sa naozaj nedá nazvať komunitným projektom, tak niekde je chyba. Je tu diera a ako som písal vššie, pre mňa by bolo ideálne riešenie postaviť niečo nad Giteou, kde jednotlivé nody by mali jednotnú registráciu, forkovanie, vyhľadávanie a zvonku by to proste pôsobilo ako jeden projekt. Proste ako GitHub.

GitLab je proste hrozná katastrofa, nevidím jediný dôvod sa tam registrovať.

[Ivo]

Gitlab je fajn a popravde nevidim moc rozdil od Githubu...

[Bedňa]

Tak zrejme si GitHub neskúsil, je to výborne zviazané s komunitou a na IRC môžeš s vývojárom kecať a poukázať na veci ktoré tam od iných užívateľov vysia a snažiť sa vyriešiť ten svoj problém.

GitLab je len webGit a to ostané nerieši.

[ehm]

Nebýt GitHubu, tak si na IRC nepokecáš vůbec s nikým.

[Bedňa]

GitHub je výborná komunitná nadstavba nad Gitom a funguje to výborne. Ako som písal, dá sa potom konkrétny problém doriešiť aj na IRC, pretože ako býva zvykom, na GitHube už issue je, len treba dokopať vývojára, aby mi to opravil :)

[Ivo]

Co je to s prominutím za kecy? Na IRC jsem se s vývojáři bavil už v dobách, kdy svn byla výkřikem moderní techniky.

[k3dAR]

A take si jim posilal odkaz na radky kodu v repu, pull req atd? btw: nepouzivam fcb, twit, instagr, ale u github sem vyznam spojeni chapal... btw: pouzival sem irc v dobe kdy svn neexiatovalo

[Conscript89]

To se posilaly patche (dnes moderne pull/merge request) do mailing listu.

[k3dAR]

ML? ne, FidoNet

[Bedňa]

Budem sa opakovať, ale GitHub má zviazanú komunitu a riešenie problémov v jednom. Takže si stačí skočiť na IRC a len sa snažiť problém ktorý už nahlásený bol, aby sa vyriešil.

[_]

Ale přesně tak se to dělalo už v dobách před githubem.

Prostě kecáš z hladu.

[k3dAR]

doufam ze na Abclinuxu prispivas vyhradne pres BBS, protoze tak sme to delali pred internetem

[xvasek]

Na abclinuxu posílám patche zásadně přes děrné štítky.

[Conscript89]

Emulovane na s390x? :)

[Ovoce]

To mi připomíná, jak x264 nikdy za deset+ let exisence nemělo bugtracker, jenom ML a IRC.

[ehm]

Dá se nějak k tomuto kroku přispět? Líbí se mi, jak Bystroushaak bulí, protože mu možná zatrhnou obdobu proprietárního facebooku

[_]

+1

[Bystroushaak]

Dá se nějak k tomuto kroku přispět? Líbí se mi, jak Bystroushaak bulí, protože mu možná zatrhnou obdobu proprietárního facebooku

Můžeš si koupit Windows.

[Ovoce]

https://arstechnica.com/gadgets/2018/06/everyone-complaining-about-microsoft-buying-github-needs-to-offer-a-better-solution/

GitHub almost certainly needed buying

As a private company, we don't know exactly what GitHub's bank account looks like, but we can make some reasonable inferences. The company has had two rounds of venture capital funding, one for $100 million, a second for $250 million. Leaked financials from 2016 painted a picture of a company burning cash at a prodigious rate, with salary and benefits alone rivalling revenue. Even a more positive analysis of the numbers suggests that GitHub was on track to have burned through that $250 million by around the middle of this year.

[GeoRW]

LOL. Od Microsoftu vyborny tah. Nic ine nedokaze rozbit open-source komunitu ako toto

[pc2005]

Má někdo zkušenosti s http://repo.or.cz/?

[joke] Zprávička o kolizi pojmenování GVFS na slashdotu před tou akvizicí:

Microsoft has officially refused to change the name, despite a large public backlash on GitHub and social media

Konspirativnímu teoretikovi hnedka nahazuje fantazie :-P [/joke]

[Grunt]

GNOME nech klidně Microsoft koupí. A můžou do něj portovat ten file Exploreru co nedávno otevřeli.

[Bystroushaak]

První vlaštovky už se začínají objevovat: GitPub: federating Git services

[Josef Kufner]

• #4013: Implement cross-server (federated) merge requests
• #46309: self-hosted instances with federated search (hound or similar?)

[Bystroushaak]

Jo, to jsem tu už afaik postoval. Ten odkaz mam z jednoho toho issue.