Má Haskell budoucnost?

[Mirek Prýmek]

hlavně ale interpretace toho co vektor znamená nemá vliv na sčítání vektorů, asi

Já bych to asi řekl tak, že o "zobecnění" se dá mluvit tam, kde nějakou operaci aplikuju na něco jinýho za zachování všech vlastností té operace - což je taky ten princip za type classes. Když mám třeba operaci sčítání na celých číslech (+_Z) a operaci sčítání na reálných číslech (+_R), tak můžu smyslupně mluvit o tom, že +_R je zobecněním +_Z.

Jakmile ale použiju stejnej symbol v jiným kontextu, kde začne mít jiný vlastnosti, tak mi to nepřijde jako zobecnění, ale jenom prostě jako použití stejnýho symbolu pro jinou operaci.

[Reklama]

[zboj]

U plus mě taky nic nenapadá, ale u součinu už ano

U součinu jo, třeba násobení matic žejo. Ale to beztak vzniklo tak, že nějakýho poťapanýho matematika nenapadlo nic lepšího, než pro něj použít stejnej symbol a pak už se s t tím nic nedalo dělat. Matematici vůbec se symboly pracují dost volně a kreativně Jako člověka odchovanýho programováním mě v matice vždycky rozčilovalo, jak se občas někde vypustí nějakej index, protože "všichni ví, že se tím myslí ...."

U součinu už jen skalární součin, ale zase třeba u matic je třeba přiznat, že se berou spíše jako skládání, protože matice představují funkce (transformace). Jinak u těch řetězců to taky smysl má, na konkatenaci řetězců se dá prostě dívat jako na aditivní monoid, použitý symbol je jen konvence.

Jestli tě rozčiluje vypouštění částí rovnic, tak se v zájmu vlastního zdraví vyhýbej Einsteinově sčítací notaci

[Mirek Prýmek]

Jestli tě rozčiluje vypouštění částí rovnic, tak se v zájmu vlastního zdraví vyhýbej Einsteinově sčítací notaci

Doposud se mi to dařilo a nehodlám na tom nic měnit!

[Kit]

Pokud stojíš na rovníku a vydáš se nejprve 5000 km na sever a pak 5000 km na východ, tak se dostaneš do jiného místa, než když jdeš nejprve 5000 km na východ a pak teprve 5000 km na sever.

Máš pravdu, to jsem si neuvědomil, že jakmile tu kouli aspoň jednou obkroužíš, tak už to nevychází. (EDIT: blbost!)

No, každopádně je otázka, jestli se dá mluvit o "zobecnění". To bysme taky museli říct třeba že "zobecněné" rovnoběžky se můžou protínat, "zobecněný trojúhelník" může mít nulový obsah a tak...

V principu si asi vždycky můžeš vymyslet nějaký haluzoidní prostor, kde něco přestane platit, takže pak by "obecně" nebyla pravda nic, ne?

Projektant, který staví dům, si může směle dovolit toto zakřivení prostoru ignorovat, geodet už ne. Astronom, který by se zakřivením prostoročasu nepočítal, by dnes už nenašel uplatnění. GPS by nefungovalo, kdyby ta krabička v ruce se zakřivením prostoročasu nepočítala.

Zvykli jsme si běžné věci počítat v Euklidovském prostoru, ve kterém platí komutativní pravidla, a je to v pořádku. Stačí však operaci sčítání přetížit například na počítání v zeměpisných souřadnicích, které už v Euklidovském prostoru nejsou, a komutativní pravidlo použít nemůžeš.

BTW: 5000 km je jen 1/8 obvodu Země, ale zakřivení 2D prostoru je v něm už snadno představitelné.

[zboj]

hlavně ale interpretace toho co vektor znamená nemá vliv na sčítání vektorů, asi

Já bych to asi řekl tak, že o "zobecnění" se dá mluvit tam, kde nějakou operaci aplikuju na něco jinýho za zachování všech vlastností té operace - což je taky ten princip za type classes. Když mám třeba operaci sčítání na celých číslech (+_Z) a operaci sčítání na reálných číslech (+_R), tak můžu smyslupně mluvit o tom, že +_R je zobecněním +_Z.

Jakmile ale použiju stejnej symbol v jiným kontextu, kde začne mít jiný vlastnosti, tak mi to nepřijde jako zobecnění, ale jenom prostě jako použití stejnýho symbolu pro jinou operaci.

A co je podle tebe rozšíření skalárního součinu na komplexní čísla? Najednou přestane být komutativní, takže "začne mít jiné vlastnosti", ale přitom je definovaný úplně stejným vzorečkem.

Jinak hranice mezi zobecněním a abuse of notation je skutečně velmi tenká, viz například výpočet vektorového součinu determinantem (nebo operátor divergence).

[Reklama]

[Mirek Prýmek]

A co je podle tebe rozšíření skalárního součinu na komplexní čísla? Najednou přestane být komutativní, takže "začne mít jiné vlastnosti", ale přitom je definovaný úplně stejným vzorečkem.

Fakt nevím, musel bych teď horkotěžko lovit v hlavě všechny souvislosti, který už jsem zapomněl. Radši se do toho nebudu pouštět

[noef]

A neni nahodou good practise ho nepouzivat? Napr. na projektu, na kterem ted pracuji, je nastaveny linter tak, aby pri prekladu vyhazoval == jako warning.

Asi jo, ale to je právě proto, že má sémantiku doprasenou až k úplné nepoužitelnosti. Nicméně ani s === nemáš vyhráno:

Kód: [Vybrat]

js> true+true===2
true
js> true-true===0
true
js>true===1     
false
(ze stejného článku)

Tak pokud nekdo scita nebo odcita boolean, tak mu to patri . Ono ani jine jazyky nejsou o moc lepsi a muzete si to prasit jak chcete (proc ma byt vubec definovane +/- nad boolean?):

Kód: [Vybrat]

std::cout << true+true; // 2
std::cout << (true+true == true); // 0
JS ma hodne zaludnosti prave kvuli tomu automatickemu pretypovani, jenze to je IMO cena za tu dynamicnost. Ve statickych jazycich to hlida prekladac, v dynamickych programator. A bez "chytreho" pretypovani by zase kod byl plny castu, coz se myslim u dynamickych jazyku moc nenosi. Sice JS neni zadna vyhra, ale IMO PHP je na tom jeste o prapast hur (tam oproti JS nehrapruji obcas typy a nazvy metod, ale dost casto). A teda nektere veci jsou fakt lahudka:

Kód: [Vybrat]

var_dump("01" == "1"); // samebool(true)
$foo = 5 + "10 Little Piggies"; // $foo is integer (15)
PS: Moje oblibenene srovnani JS a ScalaJS:

Kód: [Vybrat]

javascript> ["10", "10", "10", "10"].map(parseInt)
[10, NaN, 2, 3] // WTF

scala.js> List("10", "10", "10", "10").map(parseInt)
List(10, 10, 10, 10) // Yay!


[Mirek Prýmek]

Tak pokud nekdo scita nebo odcita boolean, tak mu to patri .

No a to je právě ono - operátor dělá pokaždé něco jinýho, podle toho, jaký použiju parametry. Je fakt, že u JS je tou pravou příčinou zběsilý přetypování, ale výsledek je stejnej.

[noef]

No a to je právě ono - operátor dělá pokaždé něco jinýho, podle toho, jaký použiju parametry. Je fakt, že u JS je tou pravou příčinou zběsilý přetypování, ale výsledek je stejnej.

Jako ja chapu problem, ale kdyz tim "trpi" (neni to zamyslena vlastnost?) i takovi mamuti jako C a C++, tak bych rekl, ze je to spise standard na poli jazyku, nez neco neobvykleho, za co by jazyk mel byt zatracovan. A teda myslim si, ze u toho C je to mineno jako vlastnost/tradeoff - radeji vyssi vykon (v pripade JS asi odpadnuti nutnosti vsude pretypovavat), nez bezpecnost/typova cistota a nizsi vykon.

Osobne si typu vazim a prestoze nedelam v Haskellu, ktery zvladne odvodit skoro vse, tak porad preferuji oddeleny typ boolean a jen mnozinu operatoru, ktere davaji pro dany typ smysl.

[BoneFlute]

Tak pokud nekdo scita nebo odcita boolean, tak mu to patri . Ono ani jine jazyky nejsou o moc lepsi a muzete si to prasit jak chcete (proc ma byt vubec definovane +/- nad boolean?):

No, já bych čekal že to vyhodí výjimku: "Tato operace není pro tento typ definována."

JS ma hodne zaludnosti prave kvuli tomu automatickemu pretypovani,

Ano. Že přetypovává i to, co by se přetypovávat nemělo.

jenze to je IMO cena za tu dynamicnost.

To imho s dynamičností nesouvisí.

Ve statickych jazycich to hlida prekladac, v dynamickych programator. A bez "chytreho" pretypovani by zase kod byl plny castu, coz se myslim u dynamickych jazyku moc nenosi.

IMHO není problém v tom, že se něco automaticky přetypovává, nebo, že je to dynamické (haskell má automatický extends, a funguje to skvěle), ale v tom, že javascript ani python nejsou silně typované, takže ten automatický cast nemá informace o tom, co může a na co přetypovávat. A možná je to i tím, že v tom maj prostě bordel.

[Mirek Prýmek]

Jako ja chapu problem, ale kdyz tim "trpi" (neni to zamyslena vlastnost?) i takovi mamuti jako C a C++

Však taky C++ není žádný vzorově čistý jazyk Skoro bych řekl, že je asi tak druhý třetí nejhorší

ze u toho C je to mineno jako vlastnost/tradeoff - radeji vyssi vykon (v pripade JS asi odpadnuti nutnosti vsude pretypovavat), nez bezpecnost/typova cistota a nizsi vykon.

To, o čem je řeč (konzistentní chování operátorů) imho s výkonem nijak nesouvisí. Souhlasím s BoneFlute, že

1. pokud jazyk dělá typovou kontrolu, měl by vyhodit výjimku u operací, které nedávají smysl

2. se statičností/dynamičností to nesouvisí - ta jenom říká, jestli se kontrola dělá při překladu nebo až při běhu

[zboj]

Tak pokud nekdo scita nebo odcita boolean, tak mu to patri .

No a to je právě ono - operátor dělá pokaždé něco jinýho, podle toho, jaký použiju parametry. Je fakt, že u JS je tou pravou příčinou zběsilý přetypování, ale výsledek je stejnej.

Tak ale sčítat boolean jde celkem dobře, stačí vzít plus z Boolovy algebry.

[Mirek Prýmek]

Tak ale sčítat boolean jde celkem dobře, stačí vzít plus z Boolovy algebry.

To by tam ale nesmělo být přetypování na int ani by nesměl být true definovaný jako 1 (což je myslím v C).

[zboj]

Tak ale sčítat boolean jde celkem dobře, stačí vzít plus z Boolovy algebry.

To by tam ale nesmělo být přetypování na int ani by nesměl být true definovaný jako 1 (což je myslím v C).

Jasně, v C to je jako v assembleru, jen říkám, že to jde udělat logicky, ne že to tak jazyky mají.

[noef]

Tak ale sčítat boolean jde celkem dobře, stačí vzít plus z Boolovy algebry.

To by tam ale nesmělo být přetypování na int ani by nesměl být true definovaný jako 1 (což je myslím v C).

Jasně, v C to je jako v assembleru, jen říkám, že to jde udělat logicky, ne že to tak jazyky mají.

Ja bych rekl, ze s tim + je problem, ze se kryje s programatory vice pouzivanym a zazitym || nebo or. Jak jste psali vyse (doufam ze to bylo toto vlakno ), IMO jde o podobny konflikt mezi IT a matematikou.