Jak efektivně studovat programování?

[Idris]

Silná stránka C++ jsou šablony, které fungují jinak než v Javě. Šablony v Javě jsou jen syntax sugar místo castování. Šablony v C++ generují zdrojový kód jako makro a tím jednak umožňují v kontejnerech uložit zadaný typ přímo bez balení do objektu a navíc instance šablony ten typ zná a proto jej může instanciovat metoda v šabloně. Kontejner v šabloně může jen ukládat reference na objekty vytvořené mimo kontejner.

Kód: [Vybrat]

map<int,vector<int>> multimapa;
multimapa[5].push_back(6);  // operátor [] najde existující vector nebo automaticky vytvoří nový

A generika v Go 2 se jako na potvoru inspirovala javovskou verzí. Aneb Go se v ..... obrací.

[Reklama]

[Jiří Havel]

Jsem silně poznamenaný funkcionálním programováním a způsob ošetřování chyb v Go se mi extrémně nelíbí.

V žádném jazyce, co má rozumné součtové typy a pattern matching, jsem neviděl že by někdo vracel chyby tuplem. Ono to nedává smysl. Obvyke nechci vrátit hodnotu A chybu, ale hodnotu NEBO chybu. Go mě nutí aby každý typ měl nějakou defaultní/prázdnou/nesmyslnou hodnotu, kterou můžu vrátit v případě chyby, i když jinak není k ničemu a ani nedává smysl.

Až moc mi to připomíná Hoareho bilionový omyl.

Z Go mám nepříjemný pocit promrhaného potenciálu. Ten jazyk by mohl být o tolik lepší, kdyby jeho autoři (záměrně?) neignorovali skoro všechno "nové" kolem překladačů a jazyků.

[okalousek]

Jsem silně poznamenaný funkcionálním programováním a způsob ošetřování chyb v Go se mi extrémně nelíbí.

V žádném jazyce, co má rozumné součtové typy a pattern matching, jsem neviděl že by někdo vracel chyby tuplem. Ono to nedává smysl. Obvyke nechci vrátit hodnotu A chybu, ale hodnotu NEBO chybu. Go mě nutí aby každý typ měl nějakou defaultní/prázdnou/nesmyslnou hodnotu, kterou můžu vrátit v případě chyby, i když jinak není k ničemu a ani nedává smysl.

Až moc mi to připomíná Hoareho bilionový omyl.

Z Go mám nepříjemný pocit promrhaného potenciálu. Ten jazyk by mohl být o tolik lepší, kdyby jeho autoři (záměrně?) neignorovali skoro všechno "nové" kolem překladačů a jazyků.

Tady jde o to, že Go zaplnilo díru na trhu. Ale myslím že se tato diskuze dostala až moc daleko od tématu.

[Idris]

Jsem silně poznamenaný funkcionálním programováním a způsob ošetřování chyb v Go se mi extrémně nelíbí.

V žádném jazyce, co má rozumné součtové typy a pattern matching, jsem neviděl že by někdo vracel chyby tuplem. Ono to nedává smysl. Obvyke nechci vrátit hodnotu A chybu, ale hodnotu NEBO chybu. Go mě nutí aby každý typ měl nějakou defaultní/prázdnou/nesmyslnou hodnotu, kterou můžu vrátit v případě chyby, i když jinak není k ničemu a ani nedává smysl.

Až moc mi to připomíná Hoareho bilionový omyl.

Z Go mám nepříjemný pocit promrhaného potenciálu. Ten jazyk by mohl být o tolik lepší, kdyby jeho autoři (záměrně?) neignorovali skoro všechno "nové" kolem překladačů a jazyků.

Go nemá zrovna světobornou syntax, jeho síla je v runtimu (kanály a korutiny). Ale výjimky (stack unwinding) má, jen se jim říká jinak. A ano, součtové typy by to vyřešily, autoři zřejmě mají jiné priority. Ruku na srdce, kdo by chtěl psát síťové služby v Haskellu?

[neregistrovany]

Zmínil jsi skriptování. Na skriptování pro sysadminy ve windows asi budeš chtít použít powershell, na skriptování v linuxu bash, zsh ....

Proc ve Win doporucovat objektovy scripting a v Linuxu textovy? Ve Win bych urcite zatim neodepisoval cmd.exe, MS vyvratil spekulace ze bude s nastupem powershellu deprecated a potvrdil ze ho hodla v systemu drzet jeste desitky let (v nejakem pruzkumu jim vyslo ze cmd.exe je druhy nejpouzivanejsi vestaveny program Win, hned po web Browseru). Na trivialni veci je PS prilis slozity a cmd.exe se od WXP temer nezmenil, takze napsany script pujde prakticky spustit temer na jakekoliv Win masine na svete....

[Reklama]

[BoneFlute]

Jsem silně poznamenaný funkcionálním programováním a způsob ošetřování chyb v Go se mi extrémně nelíbí.

V žádném jazyce, co má rozumné součtové typy a pattern matching, jsem neviděl že by někdo vracel chyby tuplem. Ono to nedává smysl. Obvyke nechci vrátit hodnotu A chybu, ale hodnotu NEBO chybu. Go mě nutí aby každý typ měl nějakou defaultní/prázdnou/nesmyslnou hodnotu, kterou můžu vrátit v případě chyby, i když jinak není k ničemu a ani nedává smysl.

To je otázka zvyku a nedostatku představivosti.

Haskelliho Maybe/Either taky není jen hodnota. Vždycky vracíš dvojici. V Go to prostě udělali bez typu. Může se ti to nelíbit, může se mi to nelíbit, ale principielně je to prašť jak uhoď - v porovnání s výjimkama.

[BoneFlute]

- Výjimky byli vymyšleny, aby se dalo psát toto:

Kód: [Vybrat]

if (((countOfFilesIn(dir1) + countOfFilesIn(dir2)) / countOfFilesIn(dir3)) == 0) { ... }. Což bez nich prostě nejde.

Ve funkcionálních jazycích to jde Akorát dá o dost víc práce pochopit, jak kód v takovém případě funguje.

Právě.

[Idris]

Jsem silně poznamenaný funkcionálním programováním a způsob ošetřování chyb v Go se mi extrémně nelíbí.

V žádném jazyce, co má rozumné součtové typy a pattern matching, jsem neviděl že by někdo vracel chyby tuplem. Ono to nedává smysl. Obvyke nechci vrátit hodnotu A chybu, ale hodnotu NEBO chybu. Go mě nutí aby každý typ měl nějakou defaultní/prázdnou/nesmyslnou hodnotu, kterou můžu vrátit v případě chyby, i když jinak není k ničemu a ani nedává smysl.

To je otázka zvyku a nedostatku představivosti.

Haskelliho Maybe/Either taky není jen hodnota. Vždycky vracíš dvojici. V Go to prostě udělali bez typu. Může se ti to nelíbit, může se mi to nelíbit, ale principielně je to prašť jak uhoď - v porovnání s výjimkama.

Zrovna Maybe/Either je implementačně to, co v Go interface{}, ale ono jde spíš o koncept. Ono ale není tak snadné rozumně spojit podtypový polymorfismus a generické typové operátory, mám čerstvou zkušenost s implementací a je to peklo, ten typový systém vždycky někde kulhá, není třeba sound, potřebuje podporu v runtimu apod. Po takové zkušenosti se člověk nediví, že v Javě je typový systém tak tupý, ono totiž každé jeho rozšíření přináší bolehlav.

[Idris]

- Výjimky byli vymyšleny, aby se dalo psát toto:

Kód: [Vybrat]

if (((countOfFilesIn(dir1) + countOfFilesIn(dir2)) / countOfFilesIn(dir3)) == 0) { ... }. Což bez nich prostě nejde.

Ve funkcionálních jazycích to jde Akorát dá o dost víc práce pochopit, jak kód v takovém případě funguje.

Právě.

Ale stojí to za to

[BoneFlute]

Jsem silně poznamenaný funkcionálním programováním a způsob ošetřování chyb v Go se mi extrémně nelíbí.

V žádném jazyce, co má rozumné součtové typy a pattern matching, jsem neviděl že by někdo vracel chyby tuplem. Ono to nedává smysl. Obvyke nechci vrátit hodnotu A chybu, ale hodnotu NEBO chybu. Go mě nutí aby každý typ měl nějakou defaultní/prázdnou/nesmyslnou hodnotu, kterou můžu vrátit v případě chyby, i když jinak není k ničemu a ani nedává smysl.

To je otázka zvyku a nedostatku představivosti.

Haskelliho Maybe/Either taky není jen hodnota. Vždycky vracíš dvojici. V Go to prostě udělali bez typu. Může se ti to nelíbit, může se mi to nelíbit, ale principielně je to prašť jak uhoď - v porovnání s výjimkama.

Zrovna Maybe/Either je implementačně to, co v Go interface{}, ale ono jde spíš o koncept. Ono ale není tak snadné rozumně spojit podtypový polymorfismus a generické typové operátory, mám čerstvou zkušenost s implementací a je to peklo, ten typový systém vždycky někde kulhá, není třeba sound, potřebuje podporu v runtimu apod. Po takové zkušenosti se člověk nediví, že v Javě je typový systém tak tupý, ono totiž každé jeho rozšíření přináší bolehlav.

Java je stará věc. Člověk to chápe.
Jenže pak vyšel C# a člověk se zděšením zjišťuje, že je to úplně stejná záležitost. V ničem není vidět ty desítky let zkušeností a vývoje.
A pak narazíš na kód a zjišťuješ, že i to C# je pro mnoho programátorů složité...

Jak velká práce by bylo v jazyce vyškrtnout null? A kolik zisku by to přineslo. Ale on ten problém je v tom vyškrtnout ho z hlavy programátorů.

Co třeba Kotlin dokonce Scala? Ty se s těmi typy IMHO poprali velice slušně.

- Výjimky byli vymyšleny, aby se dalo psát toto:

Kód: [Vybrat]

if (((countOfFilesIn(dir1) + countOfFilesIn(dir2)) / countOfFilesIn(dir3)) == 0) { ... }. Což bez nich prostě nejde.

Ve funkcionálních jazycích to jde Akorát dá o dost víc práce pochopit, jak kód v takovém případě funguje.

Právě.

Ale stojí to za to

Proč myslíš?

Domníváš se, že Efekty nejsou lepší řešení takovýchto záležitostí? Nic nebrání, aby to bylo součástí signatury. Jen ta informace teče jinudy - cukr. Řekl bych.

[Idris]

Java je stará věc. Člověk to chápe.
Jenže pak vyšel C# a člověk se zděšením zjišťuje, že je to úplně stejná záležitost. V ničem není vidět ty desítky let zkušeností a vývoje.
A pak narazíš na kód a zjišťuješ, že i to C# je pro mnoho programátorů složité...

Jak velká práce by bylo v jazyce vyškrtnout null? A kolik zisku by to přineslo. Ale on ten problém je v tom vyškrtnout ho z hlavy programátorů.

Co třeba Kotlin dokonce Scala? Ty se s těmi typy IMHO poprali velice slušně.

Jo, Scala to má celkem rozumně, v rámci možností. V hlavách bych neškrtal, vždyť ten null se občas hodí. Uživatelsky nejlepší je sice mít typovou kontrolu, ale bez uvádění typů (plná inference), protože pak se jazyk tváří jako dynamický, ale zároveň je typově bezpečný. Většina moderních jazyků to tak do značné míry má. I to C# se snaží.

Skutečná lahůdka je typová inference pro generické typy, protože typové operátory jsou v podstatě takový Prolog a vše stojí a padá s unifikací. Byl by z toho pěkný kurz na VŠ pro všechny, kteří naříkají nad příliš teoretickou výukou tvorby překladačů

[Idris]

Domníváš se, že Efekty nejsou lepší řešení takovýchto záležitostí? Nic nebrání, aby to bylo součástí signatury. Jen ta informace teče jinudy - cukr. Řekl bych.

Je to v podstatě to samé, prašť jako uhoď. A furt to je složité, běžný Franta to nepobere. V praxi je nejlepší co nejjednodušší jazyk, aby v něm nešla páchat zvěrstva FP je v podstatě pro fajnšmekry, kteří jsou schopní si napsat vlastní překladač, takže do detailu vědí, kudy v programu tečou data.

[BoneFlute]

V hlavách bych neškrtal, vždyť ten null se občas hodí.

Co se na tomto hodí?

Kód: [Vybrat]

[TestMethod]
public void Test()
{
Print(null);
}

private void Print(Foo x)
{
System.Console.WriteLine(x.GetType());
}

Tohle beru:

Kód: [Vybrat]

[TestMethod]
public void Test()
{
Print(null);
}

private void Print(int? x)
{
if (x != null) {
System.Console.WriteLine(x.GetType());
}
}


[BoneFlute]

Domníváš se, že Efekty nejsou lepší řešení takovýchto záležitostí? Nic nebrání, aby to bylo součástí signatury. Jen ta informace teče jinudy - cukr. Řekl bych.

Je to v podstatě to samé, prašť jako uhoď. A furt to je složité, běžný Franta to nepobere. V praxi je nejlepší co nejjednodušší jazyk, aby v něm nešla páchat zvěrstva FP je v podstatě pro fajnšmekry, kteří jsou schopní si napsat vlastní překladač, takže do detailu vědí, kudy v programu tečou data.

Já chci jazyk, který mě nepustí udělat chybu. Je mi jedno, zda to bude jednoduchostí, nebo díky AI.
Za druhé chci, aby když dělám něco špatně, tak abych to byl schopen z té chybovky pochopit ("no jo, text místo čísla, jasný").

Navrhnout jednoduchý jazyk je jednoduché (Lua, Python) - stačí vyrazit typy. Napsat jazyk, kterej mě bude hlídat, a přitom budu produktivní, to už je jinej kumšt (Rust).

[Idris]

V hlavách bych neškrtal, vždyť ten null se občas hodí.

Co se na tomto hodí?

Kód: [Vybrat]

[TestMethod]
public void Test()
{
Print(null);
}

private void Print(Foo x)
{
System.Console.WriteLine(x.GetType());
}

Tohle beru:

Kód: [Vybrat]

[TestMethod]
public void Test()
{
Print(null);
}

private void Print(int? x)
{
if (x != null) {
System.Console.WriteLine(x.GetType());
}
}


Ber to jako v ObjC, null je taky jen objekt a má své metody Tam se teda jmenuje nil.

Tenhle kiks jde samozřejmě ošetřit jen za běhu, ale ten druhý kód je v podstatě to, o čem jsem psal. Čili asi se shodneme.