Má Haskell budoucnost?

[v]

ale ten můj prvotní kód je pro typy co se dají sčítat!
naopak ten váš kód není, vždyť pro sčítání platí a+b=b+a, platí to u toho vašeho?

Aha, rigidní matematik... Doporučuju nechat veřejně zostudit všechny tvůrce programovacích jazyků, kteří si dovolili pro operaci spojení řetězců použit operátor +, protože se těžce provili proti a+b=b+a.

ne, pragmatický pogramátor, živící se c++ a bavící se haskellem, celou dobu mluvíte o sčítání a zároveň do toho taháte řetězce, v tom je těžké se vyznat

[Reklama]

[gamer]

ne, pragmatický pogramátor, živící se c++ a bavící se haskellem, celou dobu mluvíte o sčítání a zároveň do toho taháte řetězce, v tom je těžké se vyznat

Uznávám, je to velmi těžké, zvlášť když 90% programovacích jazyků používá pro spojení řetězců operátor +. Mě nekamenujte, já jsem ten zmatek nezavedl, jenom ho dál udržuju .

[andy]

ale ten můj prvotní kód je pro typy co se dají sčítat!
naopak ten váš kód není, vždyť pro sčítání platí a+b=b+a, platí to u toho vašeho?

Aha, rigidní matematik... Doporučuju nechat veřejně zostudit všechny tvůrce programovacích jazyků, kteří si dovolili pro operaci spojení řetězců použit operátor +, protože se těžce provili proti a+b=b+a.

Jenže haskellisti to takhle mají rádi, protože na rozdíl od lidí v C++ ty typeclassy masivně používají. A ke každé typeclass je dobrým zvykem vymyslet pravidla, která by ta typeclass měla splňovat. Aby nebyl v kódu bordel. Takže když pak implementuješ něco, co má na vstupu "Num a", tak prostě neřešíš, jestli je sčítání komutativní, prostě to to je jeden z předpokladů, aby to bylo Num a. U Monoidu se třeba předpokládá, že mu nebude vadit různá asociativita. Takže opět, když budeš vytvářet kód s Monoidem, tak to prostě bude fungovat na všechny Monoidy. I na ty, na které jsi nemyslel.

Ale teď jsem si vzpomněl na jeden jednoduchý příklad něčeho, co IMO v C++ jednoduše nevyjádříš, přitom je to Haskell98. Máš záznam Osoba s atributy třeba Věk, Plat, Jméno. Chceš je setřídit sestupně podle věku, vzestupně podle platu a jména v tomto pořadí. Haskellový kód:

Kód: [Vybrat]

setrid = sortBy (flip (comparing vek) <> comparing plat <> comparing jmeno)A teď to zkus v C++....

[v]

Když ty data schovám do nějaké třídy, tak je zvenku nikdo nezmění.

Kód: [Vybrat]

#include <iostream>

class A {
public:
int get_x() { return x; }
A() : x(0) {}
private:
int x;
};

int main () {
A a;
*(int*)&a = 666;
std::cout << a.get_x() << std::endl;
return 0;
}


[v]

Ale teď jsem si vzpomněl na jeden jednoduchý příklad něčeho, co IMO v C++ jednoduše nevyjádříš, přitom je to Haskell98. Máš záznam Osoba s atributy třeba Věk, Plat, Jméno. Chceš je setřídit sestupně podle věku, vzestupně podle platu a jména v tomto pořadí. Haskellový kód:

Kód: [Vybrat]

setrid = sortBy (flip (comparing vek) <> comparing plat <> comparing jmeno)A teď to zkus v C++....

tohle je hezké, já jsem to naposledy použil pro plánování úloh (doba čekání <> priorita), taky je Monoid definovaný pro STM akce, příklad z praxe: dorazily nové data ze socketu <> timeout vypršel

[Reklama]

[gamer]

Kód: [Vybrat]

#include <iostream>

class A {
public:
int get_x() { return x; }
A() : x(0) {}
private:
int x;
};

int main () {
A a;
*(int*)&a = 666;
std::cout << a.get_x() << std::endl;
return 0;
}


Dneska je to tady opravdu vtipné. Doporučuju zkusit taky:

Kód: [Vybrat]

cat /dev/urandom > /dev/mem
A užívat si side effecty v pure Haskellu 

[andy]

Kód: [Vybrat]

*(int*)&a = 666;
}


Jenže to je asi tak na úrovni unsafePerformIO, takže celkem argument o ničem. Spíš je to o tom, že pokud v C++ programátor neudělá někde nějaký kix, a hodně dobře si to navrhne, tak to STM fungovat bude. Když dobře pořeší locky, pořadí zamykání apod., tak mu to fungovat bude. No a v Haskellu to prostě funguje a pokud se programátor omylem pokusí k něčemu přistoupit nekorektně, tak mu to compiler řekne. Já jsem poslední dobou línej a nějak když nemusím, tak tyhle věci nechám na řešení počítač.

Mimochodem, já jsem jeden projekt komplet přepsal z Haskellu do C++ - protože to běží na pomalých počítačích a bylo potřeba z toho vymáčknout veškerý možný výkon. Ale mám tam globální zámky a pevně doufám, že je nikde nezapomínám zamknout. Zlatý haskell...

[Kit]

ale ten můj prvotní kód je pro typy co se dají sčítat!
naopak ten váš kód není, vždyť pro sčítání platí a+b=b+a, platí to u toho vašeho?

Aha, rigidní matematik... Doporučuju nechat veřejně zostudit všechny tvůrce programovacích jazyků, kteří si dovolili pro operaci spojení řetězců použit operátor +, protože se těžce provili proti a+b=b+a.

ne, pragmatický pogramátor, živící se c++ a bavící se haskellem, celou dobu mluvíte o sčítání a zároveň do toho taháte řetězce, v tom je těžké se vyznat

Obecně přece a+b==b+a neplatí.

[v]

Kód: [Vybrat]

*(int*)&a = 666;
}


Jenže to je asi tak na úrovni unsafePerformIO, takže celkem argument o ničem. Spíš je to o tom, že pokud v C++ programátor neudělá někde nějaký kix, a hodně dobře si to navrhne, tak to STM fungovat bude. Když dobře pořeší locky, pořadí zamykání apod., tak mu to fungovat bude. No a v Haskellu to prostě funguje a pokud se programátor omylem pokusí k něčemu přistoupit nekorektně, tak mu to compiler řekne. Já jsem poslední dobou línej a nějak když nemusím, tak tyhle věci nechám na řešení počítač.

Mimochodem, já jsem jeden projekt komplet přepsal z Haskellu do C++ - protože to běží na pomalých počítačích a bylo potřeba z toho vymáčknout veškerý možný výkon. Ale mám tam globální zámky a pevně doufám, že je nikde nezapomínám zamknout. Zlatý haskell...

jo a ne, protože safe haskell, ale v c++ co?
pokud bych potřeboval veškerý dostupný výkon, tak o haskellu nebudu ani uvažovat

[BoneFlute]

pro použití funcke (+) musíte mít nadefinovanou pro daný type třídu Num (ve skutečnosti nemusíte, ale slušní lidi to tak dělají)
já jsem ji pro vás napsal pro String

Kód: [Vybrat]

{-# LANGUAGE FlexibleInstances #-}
instance Num [Char] where
(+) = (++)
(*) _ _ = error "na tohle je už dneska moc hodin"
abs = id
signum _ = ":-)"
fromInteger = show
negate = reverse
asi to není problém pro žádný typ, ale někdy to moc nedává smysl

To je to řešení, které jsem hledal, díky. Připadá mi to teda trochu jako hack, ale budiž, když to bude fungovat... C++ mi z toho vychází líp, nemusím takové opičárny dělat, stačí aby se ten objekt uměl sčítat. Třeba pro vektor bez obalovací classy, která se nelíbila:

Logická chyba: U Haskellu si stěžuješ, že nelze sčítat objekt, který sčítat neumí, zatímco v C++ si pochvaluješ, že lze sčítat objekt, který se sčítat umí.

[Mirek Prýmek]

To je to řešení, které jsem hledal, díky. Připadá mi to teda trochu jako hack

Protože to JE hack. Je to způsob, jak se tvářit, že string má vlastnosti, které nemá*. Nikdo rozumný by to imho v praxi takhle neudělal. Podle mě je správný ten druhý způsob - nadefinovat si třídu s potřebnými funkcemi (class Scitej) a vytvořit implementaci pro všechny typy, které chci podporovat. A pak v té "inkrementační" fci pracovat s touhle třídou (incrementTVar :: Scitej a => ...).

* protože být instancí třídy znamená přesně tohle - mít nějaké vlastnosti. A některé vlastnosti Num prostě pro string neplatí, tak nemá smysl ho tam rvát.

Aha, rigidní matematik... Doporučuju nechat veřejně zostudit všechny tvůrce programovacích jazyků, kteří si dovolili pro operaci spojení řetězců použit operátor +, protože se těžce provili proti a+b=b+a.

Nejde o rigidní matematiku, ale o konzistentní sémantiku. Pokud nějaký operátor má jiný VÝZNAM pro typ A a jiný pro typ B, tak to není dobře. Jestli o tom pochybuješ, užij si, kam to vede, v JavaScriptu

Obecně přece a+b==b+a neplatí.

Pokud "+" má označovat "běžné aritmetické sčítání", tak platí. Pokud to má označovat něco jiného, tak v principu může platit cokoli si pro to "něco jiného" vymyslíme. Jsou i tací koumáci, kteří jsou schopní operátor "+" předefinovat tak, aby dělal print a ještě si myslí, jak jsou chytří

I pokud se pojem "sčítání" používá v nějakém zobecněném/přeneseném smyslu, tak se komutativita afaik bere jako základní nutná vlastnost, bez které by ten pojem ztratil svůj smysl. Viz třeba https://cs.wikipedia.org/wiki/S%C4%8D%C3%ADt%C3%A1n%C3%AD#Obecn.C3.A1_algebra a https://en.wikipedia.org/wiki/Addition#Addition_in_abstract_algebra

Jak říkal správně "v", řetězce se prostě nesčítají, řetězce se řetězí. A pokud bych je kór chtěl sčítat, tak jako vektory - tj. sčítat po prvcích ASCII hodoty. Ale to by asi nebylo k ničemu dobré

[Kit]

Obecně přece a+b==b+a neplatí.

Pokud "+" má označovat "běžné aritmetické sčítání", tak platí. Pokud to má označovat něco jiného, tak v principu může platit cokoli si pro to "něco jiného" vymyslíme. Jsou i tací koumáci, kteří jsou schopní operátor "+" předefinovat tak, aby dělal print a ještě si myslí, jak jsou chytří

Podstatné je to slovo "obecně". V Euklidovském prostoru samozřejmě komutativita sčítání platí.

[Mirek Prýmek]

Podstatné je to slovo "obecně". V Euklidovském prostoru samozřejmě komutativita sčítání platí.

Obecně pokud pro operaci x neplatí komutativita, tak dost dobře nemá smysl takovou operaci označovat symbolem "+". Máš nějaký příklad zaužívaného "+", které není komutativní? Mě fakt nenapadá (pokud teda nepočítám ty programátorské úlety).

[zboj]

Podstatné je to slovo "obecně". V Euklidovském prostoru samozřejmě komutativita sčítání platí.

Obecně pokud pro operaci x neplatí komutativita, tak dost dobře nemá smysl takovou operaci označovat symbolem "+". Máš nějaký příklad zaužívaného "+", které není komutativní? Mě fakt nenapadá (pokud teda nepočítám ty programátorské úlety).

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

[Kit]

Podstatné je to slovo "obecně". V Euklidovském prostoru samozřejmě komutativita sčítání platí.

Obecně pokud pro operaci x neplatí komutativita, tak dost dobře nemá smysl takovou operaci označovat symbolem "+". Máš nějaký příklad zaužívaného "+", které není komutativní? Mě fakt nenapadá (pokud teda nepočítám ty programátorské úlety).

Například sčítání dvou 2D vektorů na povrchu Země.