Má Haskell budoucnost?

[gamer]

ne, to není ono

Dobře já to rozepíšu, jen nástřel:

Kód: [Vybrat]

std::timed_mutex mutex;
...
while (current_time < max_time) {
    mutex.try_lock_for(std::chrono::milliseconds(100));
    if (zustatek > obnos) {
        zdroj -= obnos;
        cil += obnos;
        mutex.unlock();
        return true;
    }
}
return false;
stačí jeden mutex.

[Reklama]

[andy]

ne, to není ono

Dobře já to rozepíšu, jen nástřel:

Kód: [Vybrat]

std::timed_mutex mutex;
...
while (current_time < max_time) {
    mutex.try_lock_for(std::chrono::milliseconds(100));
    if (zustatek > obnos) {
        zdroj -= obnos;
        cil += obnos;
        mutex.unlock();
        return true;
    }
}
return false;
stačí jeden mutex.

Fajn, a teď zruš to aktivní čekání a udělej pasivní.

[v]

ne, to není ono

Dobře já to rozepíšu, jen nástřel:

Kód: [Vybrat]

std::timed_mutex mutex;
...
while (current_time < max_time) {
    mutex.try_lock_for(std::chrono::milliseconds(100));
    if (zustatek > obnos) {
        zdroj -= obnos;
        cil += obnos;
        mutex.unlock();
        return true;
    }
}
return false;
stačí jeden mutex.

neměl byste kontrolovat návratovou hodnotu try_lock_for?

[gamer]

Koukám, že nemáš moc zkušeností s psaním paralelních programů. Jakmile máš více než 1 mutex, musíš si dávat majzla, v jakém pořadí je zamkneš. Takže buď skončíš na globálním mutexu, nebo ne, ale v tom případě hodně štěstí. Já to s STM navrhovat nemusím. Neřeším. Prostě se nestane - za cenu o něco menší výkonnosti.

Multithread věcí jsem už C++ řešil dost, myslím že o tom něco málo vím. Ale nechci si tady poměřovat velikosti zdrojových kódů, myslím že je to zbytečné. Je to celé o tom, jak to navrhneš. Dva mutexy můžou být problém, musíš si dávat pozor. Ty se toho bojíš, takže mutexy radši vůbec nepoužíváš. Já se toho taky bojím a když už něco paralelního dělám, snažím se mít v rámci kontextu jen jeden mutex. Když si řeknu, že už to mentálně nedávám, použiju místo mutexů něco jiného, třeba STM.

A jak psal v - podívej se na condition variable, a pak si zkus napsat kód, který dělá to samé... a pak se zamysli, jestli je něco takového vůbec srovnatelné s tím, co bez problému napíšeš v haskellu....

Na tohle primitvní čekání, jestli je na účtu dost peněz, bych condition variable v C++ asi nepoužil, je to zbytečně složité.

[andy]

Porovnávat C++ a Haskell je kompletně mimo. Implementují jiná paradigmata a slouží pro úplně jiné aplikace. Jestli se naseru, tak sem natáhnu nějakýho Javystu, ať je aspoň sranda.

Tak je fakt, že z C++ se stal takový lepší systémový jazyk... má to blízko k HW a je to lepší než C. Ale je to škoda - proč by nějaký microservice webová aplikace nemohla být napsaná v C++?

OMG, tak si tu STM sračku udělá i v C++ ... STM nemaj nic do činění s FP ...

STM tak, jak je implementované v Haskellu, je prakticky nemožné udělat v jazyku bez typů, které jsou v Haskellu. Rozhodně ne s ani vzdáleně srovnatelnou mírou bezpečnosti.

[Reklama]

[gamer]

neměl byste kontrolovat návratovou hodnotu try_lock_for?

Jasně že měl, byl to jen nástřel, jak to udělat, bez nároku na funkčnost .

[andy]

Multithread věcí jsem už C++ řešil dost, myslím že o tom něco málo vím. Ale nechci si tady poměřovat velikosti zdrojových kódů, myslím že je to zbytečné. Je to celé o tom, jak to navrhneš. Dva mutexy můžou být problém, musíš si dávat pozor. Ty se toho bojíš, takže mutexy radši vůbec nepoužíváš. Já se toho taky bojím a když už něco paralelního dělám, snažím se mít v rámci kontextu jen jeden mutex. Když si řeknu, že už to mentálně nedávám, použiju místo mutexů něco jiného, třeba STM.

Já se toho nebojím. Já nechci ztrácet čas a nervy a energii s tím dělat něco složitě, když to jde jednoduše.

Na tohle primitvní čekání, jestli je na účtu dost peněz, bych condition variable v C++ asi nepoužil, je to zbytečně složité.

QED?

[čumil]

Porovnávat C++ a Haskell je kompletně mimo. Implementují jiná paradigmata a slouží pro úplně jiné aplikace. Jestli se naseru, tak sem natáhnu nějakýho Javystu, ať je aspoň sranda.

Tak je fakt, že z C++ se stal takový lepší systémový jazyk... má to blízko k HW a je to lepší než C. Ale je to škoda - proč by nějaký microservice webová aplikace nemohla být napsaná v C++?

OMG, tak si tu STM sračku udělá i v C++ ... STM nemaj nic do činění s FP ...

STM tak, jak je implementované v Haskellu, je prakticky nemožné udělat v jazyku bez typů, které jsou v Haskellu. Rozhodně ne s ani vzdáleně srovnatelnou mírou bezpečnosti.

STM je jen nějakej kus abstrakce nad atomickejma instrukcema, nic víc nic míň, to samí můžeš mít i v C++, Jave, Ruby a já nevím v čem jiným. Pokud v něčem není Haskell unikátní, tak v tomhle. Děláš Haskellu vcelku blbou službu.

[gamer]

Já se toho nebojím. Já nechci ztrácet čas a nervy a energii s tím dělat něco složitě, když to jde jednoduše.

V pohodě, je to tvoje volba, když chceš STM, používej STM, nic proti tomu nemám. Dělal jsem v C++ věci, u kterých byl kritický výkon a STM nebyla volba. I u mutexu se často řešila režije a hledala se nějaká lockless alternativa.

QED?

Matematický důkaz ti nedám, je to prostě můj subjektivní dojem. Než se drbat s condition variables mezi thready, tak na takové jednoduché čekání prostě použiju timed_mutex s nějakým rozumným sleepem. Není to úplně ideální řešení, protože když je tam ten sleep, jsou tam nějaké probuzení threadu navíc a o změně se dozvíš až se zpožděním sleepu, ale pokud to nevadí, je pro mě timed_mutex jasná volba.

[andy]

STM tak, jak je implementované v Haskellu, je prakticky nemožné udělat v jazyku bez typů, které jsou v Haskellu. Rozhodně ne s ani vzdáleně srovnatelnou mírou bezpečnosti.

STM je jen nějakej kus abstrakce nad atomickejma instrukcema, nic víc nic míň, to samí můžeš mít i v C++, Jave, Ruby a já nevím v čem jiným. Pokud v něčem není Haskell unikátní, tak v tomhle. Děláš Haskellu vcelku blbou službu.

Mohl bys mi ukázat kus kódu STM v C++, Javě nebo Ruby, který je srovnatelný z hlediska type-checking, composability apod. s Haskellem? Já to neznám, rád se poučím.

[andy]

Matematický důkaz ti nedám, je to prostě můj subjektivní dojem. Než se drbat s condition variables mezi thready, tak na takové jednoduché čekání prostě použiju timed_mutex s nějakým rozumným sleepem. Není to úplně ideální řešení, protože když je tam ten sleep, jsou tam nějaké probuzení threadu navíc a o změně se dozvíš až se zpožděním sleepu, ale pokud to nevadí, je pro mě timed_mutex jasná volba.

Já to myslel jinak:

Troufám si tvrdit, že C++ nebo Java nabízí minimálně stejně dobrou míru abstrakce jako Haskell a fungují jak pro jedno kolečko v převodovce, tak pro celé auto.

Tak jenom, že jsi právě prohlásil, že v C++ použiješ v té převodovce plastové kolečko, protože použít kovové je strašný opruz. Tak nějak se mi víc líbí to auto v haskellu...

[JS]

Ohledně otázky, zdali je pro člověka přirozenější funkcionální nebo imperativní paradigma je myslím odpověď jasná. Stačí nebejt "provinční" a zvednout hlavu od monitoru.

V jaké formě je psaná každá kuchařka? Ve stylu:
= rozděl vejce na žloutek a bílek
= bílek utři na sníh
= přimíchej tam žloutek, cukr a mouku a olej
= nalejte do formy
= pečte hodinu při 200 stupních

Nebo stylem:
= bílek a žloutek získáte rozdělením vejce
= sníh získáte ušleháním bílku
= těsto na bábovku získáte smíšením sněhu, žloutku, cukru a mouky a oleje
= neupečenou bábovku získáte nalitím těsta do formy
= bábovku získáte hodinovým pečením neupečené bábovky při 200 stupních.
(ideálně ještě nikoliv tomto pořadí :-))
?

No, mne treba pripada to druhe lepsi... Podle me zalezi, jestli umis varit, nebo ne (i kdyz sam varit neumim). Zkuseny clovek vi jak ziskat zloutek a jak uvarit babovku, takze se proste soustredi na tu prostredni vec a nemusi cist cely recept. :-)

Podobny priklad dava Dave Thomas ve svem slavnem "Herding horses, racing sheep" - mluvi o tom, jak si lide s ruznou urovni zkusenosti zapisuji recepty. U zacatecnika je to jak pises. U experta by to bylo treba jenom - testo jako na babovku, akorat se tam jeste prida tohle.

[gamer]

Mohl bys mi ukázat kus kódu STM v C++, Javě nebo Ruby, který je srovnatelný z hlediska type-checking, composability apod. s Haskellem? Já to neznám, rád se poučím.

Tak třeba podpora v GCC: https://gcc.gnu.org/wiki/TransactionalMemory, je to implementováno podle toho Draft Specification of Transactional Language Constructs for C++ dole v odkazu.
Ale v C++ se STM zase tak moc nepoužívá, není moc velká poptávka. V C++ všichni řeší výkon a STM do toho úplně nepasuje.

[andy]

Mohl bys mi ukázat kus kódu STM v C++, Javě nebo Ruby, který je srovnatelný z hlediska type-checking, composability apod. s Haskellem? Já to neznám, rád se poučím.

Tak třeba podpora v GCC: https://gcc.gnu.org/wiki/TransactionalMemory, je to implementováno podle toho Draft Specification of Transactional Language Constructs for C++ dole v odkazu.
Ale v C++ se STM zase tak moc nepoužívá, není moc velká poptávka. V C++ všichni řeší výkon a STM do toho úplně nepasuje.

Nepřipadá mi, že by to umělo retry, jak je použito v tom příkladu výše? Pletu se?

[gamer]

Nepřipadá mi, že by to umělo retry, jak je použito v tom příkladu výše? Pletu se?

Nepleteš se, retry to neumí, ale zkus přijmout, že retry i případný timeout je naprosto minoritní funkcionalita, kterou si snadno doděláš. Trochu jsem si s tím v C++ hrál a zajímalo by mě, jestli tohle dokážeš napsat stejně elegantně a abstraktně i v Haskellu? Uznávám, že je to trochu školometský příklad:

Kód: [Vybrat]

#include <string>
#include <thread>
#include <iostream>

template<typename T>
class ThreadSafeClass
{
public:
    ThreadSafeClass() : m_value(T()) {}

    T get() const {
        return m_value;
    }

    ThreadSafeClass& operator += (const T value) {
        __transaction_relaxed { m_value += value; }
        return *this;
    }

private:
    T m_value;
};


template<typename T>
void updateThread(ThreadSafeClass<T>& tsc, const T value)
{
    for (int i = 0; i < 100; ++i) {
        tsc += value;
    }
}


int main()
{
    ThreadSafeClass<int> safeInt;
    ThreadSafeClass<double> safeDouble;
    ThreadSafeClass<std::string> safeString;

    std::thread t1([&]{updateThread(safeInt, 1);});
    std::thread t2([&]{updateThread(safeInt, 2);});
    std::thread t3([&]{updateThread(safeDouble, 1.0);});
    std::thread t4([&]{updateThread(safeDouble, 2.0);});
    std::thread t5([&]{updateThread(safeString, std::string("A"));});
    std::thread t6([&]{updateThread(safeString, std::string("B"));});

    t1.join();
    t2.join();
    t3.join();
    t4.join();
    t5.join();
    t6.join();

    std::cout << safeInt.get() << std::endl;
    std::cout << safeDouble.get() << std::endl;
    std::cout << safeString.get() << std::endl;

    return 0;
}
Obecná třída pro thread safe operaci + nad libovolným datovým typem (včetně stringu), máš to kompletní i s testem. Pokud vím, v Haskellu to musí být TVar? V C++ žádné takové omezení není, může to být libovolná proměnná.