Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Onestone 22. 04. 2017, 21:14:09
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.
-
Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.
To můžu samozřejmě dělat v kompilovaných jazycích taky. A nebo nemusím, záleží na vhodnosti pro danou aplikaci.
-
Jako jediná výhoda mě napadá, že teoreticky můžu sdílet nějakou část kódu s frontendem (validace apod.), ale jestli se to tak používá, netuším.
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
JS nemá s neblokujícím IO nic společného a na straně serveru to je mor. Kdysi dávno se pro každý požadavek dělal na serveru fork, později se přešlo na vlákna (jež jsou na všech OS poměrně těžkotonážní) a multiplexing je výdobytkem poměrně nedávným (ano, už POSIX měl select a poll, ale teprve kqueue přišlo s efektivní implementací). Kqueue (a analogické implementace) jsou jen syscall do jádra, takže logicky to jde nejsnáze v C, C++ nebo nějakém novějším nativním jazyce (Rust, Swift, Go, take your pick of the languages on offer...) Existují ostatně i NIO implementace pro Javu. JS je v tomto případě jen nepodstatná úchylnost. Koho to zajímá do hloubky, může se podívat na zdrojáky Go, tam můžou na běžném PC koexistovat statisíce korutin, aniž by to stálo přespříliš paměti nebo času CPU. Smyčka událostí je obecný koncept, jeden while, syscall pro file deskriptory a pak zpracování příchozích dat. Žádná magie v tom není a celý slavný node.js se dá v C napsat na jednu obrazovku.
-
Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.
To můžu samozřejmě dělat v kompilovaných jazycích taky. A nebo nemusím, záleží na vhodnosti pro danou aplikaci.
AFAIK, když použijete nějakou existující knihovnu, provádějící blokující IO, tak to volání musíte spustit ve vlastním vlákně.
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
NIO nemá s vlákny nic společného a upřímně, OS vlákna by byla kontraproduktivní overkill.
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.
Ne, nepoužívá.
-
Výhodou Node.JS je právě ten JavaScript – můžete psát klientskou i serverovou stranu webové aplikace v jednom jazyce (tzv. izomorfní aplikace), můžete mezi nimi sdílet kód.
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.
Ne, nepoužívá.
Používá. I Go používá thread pool systémových vláken. Jediný rozdíl je v tom, že Go routiny jsou preemptivní. Což může někdo považovat za výhodu, ale u IO náročných aplikací je to k ničemu.
-
P.S. Jakmile začne někdo v souvislosti s node.js mluvit o thread poolu, demonstruje esenciální neznalost node.js a NIO obecně. Účelem NIO je obejít vlákna a klasické implementace běží kompletně v jednom vlákně (například node.js), byť rozumný kód si vytvoří tolik vláken, kolik má procesorů (resp. logických vláken v případě HT). Kqueue (a zkriplený epoll) má výhodu právě v tom, že nevyžaduje vlákna (pomíjím opičárny à la Go, korutiny jsou něco zcela jiného než vlákna).
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
NIO nemá s vlákny nic společného a upřímně, OS vlákna by byla kontraproduktivní overkill.
Jenže diskové IO na Linuxu nikdy non-blocking není, takže pokud mě trápí neresponzivita během zápisu fakt velkého souboru, musím si to do smyčky naplánovat po nějakých malých blocích, nebo pustit vlákno. U socketů to samozřejmě neplatí a tam je totální nesmysl to řešit jinak než epollem.
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.
Ne, nepoužívá.
Používá. I Go používá thread pool systémových vláken. Jediný rozdíl je v tom, že Go routiny jsou preemptivní. Což může někdo považovat za výhodu, ale u IO náročných aplikací je to k ničemu.
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
NIO nemá s vlákny nic společného a upřímně, OS vlákna by byla kontraproduktivní overkill.
Jenže diskové IO na Linuxu nikdy non-blocking není, takže pokud mě trápí neresponzivita během zápisu fakt velkého souboru, musím si to do smyčky naplánovat po nějakých malých blocích, nebo pustit vlákno. U socketů to samozřejmě neplatí a tam je totální nesmysl to řešit jinak než epollem.
100% souhlas ohledně souborů, bavím se výhradně o síťové komunikaci.
-
Jenže diskové IO na Linuxu nikdy non-blocking není, takže pokud mě trápí neresponzivita během zápisu fakt velkého souboru, musím si to do smyčky naplánovat po nějakých malých blocích, nebo pustit vlákno. U socketů to samozřejmě neplatí a tam je totální nesmysl to řešit jinak než epollem.
100% souhlas se soubory, bavím se výhradně o síťové komunikaci.
OK, tam je to fakt v C na jednu obrazovku, jak říkáš. A pokud už člověk používá nějaký C nebo C++ framework, ještě jsem nenarazil na to, že by neměl podporu pro poll, epoll, select nad deskriptorem. Ostatně třeba V4L2 se používá taky s (e)pollem a bylo naprosto bez problémů ho připojit jednou proxy třídou do Qt aplikace.
Já jenom nevím, proč se zbytečně izolovat od low level implementace už na úrovni jazyka, když to můžu udělat stejně dobře knihovnou a v případě nouze se můžu povrtat i níž.
Mimochodem, za coroutines v C bych vraždil. Kolikrát člověk nepotřebuje paralelismus, jen víc kontextů, zejména na bare-metal hw.
-
Jenže diskové IO na Linuxu nikdy non-blocking není, takže pokud mě trápí neresponzivita během zápisu fakt velkého souboru, musím si to do smyčky naplánovat po nějakých malých blocích, nebo pustit vlákno. U socketů to samozřejmě neplatí a tam je totální nesmysl to řešit jinak než epollem.
100% souhlas se soubory, bavím se výhradně o síťové komunikaci.
OK, tam je to fakt v C na jednu obrazovku, jak říkáš. A pokud už člověk používá nějaký C nebo C++ framework, ještě jsem nenarazil na to, že by neměl podporu pro poll, epoll, select nad deskriptorem. Ostatně třeba V4L2 se používá taky s (e)pollem a bylo naprosto bez problémů ho připojit jednou proxy třídou do Qt aplikace.
Já jenom nevím, proč se zbytečně izolovat od low level implementace už na úrovni jazyka, když to můžu udělat stejně dobře knihovnou a v případě nouze se můžu povrtat i níž.
Mimochodem, za coroutines v C bych vraždil. Kolikrát člověk nepotřebuje paralelismus, jen víc kontextů, zejména na bare-metal hw.
V C se mi osvědčily bloky ve spojení s kqueue nebo epoll. Jinak předpokládám, že v normálním případě člověk použije něco jako libevent nebo libev nebo libuv.
-
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.
1. - o tom opravdu nic nevím.
2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.
goroutina != coroutina
http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
A proč je uchylný :) ?
JS je unikat.
Neříkám že je nejlepší, ale plno věcí je tam na úplne jinem levelu nez maji ostatni jazyky.
Namatkou first class async support.
Reactivity ve skoro kazdem novem frameworku.
Prototype oop ...
Na js obvykle hazi spinu lidi ktery to delaj jen proto ze spinit js je free a kuul a vubec strasne in.
-
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.
1. - o tom opravdu nic nevím.
2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.
goroutina != coroutina
http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine
Používáš preemptivní ve významu kooperativní, což je pravý opak.
-
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.
1. - o tom opravdu nic nevím.
2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.
goroutina != coroutina
http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine
Používáš preemptivní ve významu kooperativní, což je pravý opak.
preemptivní používám ve významu nekooperativní. V Go přepíná kontext runtime bez toho, abyste mu to explicitně museli říct. Kooperativní jsou právě coroutiny v js, pythonu nebo c#. Zboj používá to slovo špatně.
-
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.
1. - o tom opravdu nic nevím.
2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.
goroutina != coroutina
http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine
Používáš preemptivní ve významu kooperativní, což je pravý opak.
preemptivní používám ve významu nekooperativní. V Go přepíná kontext runtime bez toho, abyste mu to explicitně museli říct. Kooperativní jsou právě coroutiny v js, pythonu nebo c#. Zboj používá to slovo špatně.
Tak si počti: http://blog.nindalf.com/how-goroutines-work/
Buď neznáš Go, nebo význam slova kooperativní. Sorry jako, ale preferuji diskusi s někým, kdo má aspoň základní znalosti. V Go jde scheduler vyšachovat, což znamená kooperativnost. (Doufám, že Babiš nemá na "sorry jako" copyright...).
-
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.
1. - o tom opravdu nic nevím.
2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.
goroutina != coroutina
http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine
Používáš preemptivní ve významu kooperativní, což je pravý opak.
preemptivní používám ve významu nekooperativní. V Go přepíná kontext runtime bez toho, abyste mu to explicitně museli říct. Kooperativní jsou právě coroutiny v js, pythonu nebo c#. Zboj používá to slovo špatně.
Viz ještě https://news.ycombinator.com/item?id=4704898, a pokud teď neuznáš svůj přešlap, tak jsi do skonání světa lopata.
-
package main
import "fmt"
import "runtime"
import "sync"
var wg sync.WaitGroup
func cpuIntensive(p int) {
cycles := 100000000
for i := 1; i <= cycles; i++ {
if i == cycles/2 {
fmt.Printf("%d running\n", p)
}
}
fmt.Printf("%d done\n", p)
wg.Done()
}
func main() {
runtime.GOMAXPROCS(1)
wg.Add(4)
go cpuIntensive(1)
go cpuIntensive(2)
go cpuIntensive(3)
go cpuIntensive(4)
wg.Wait()
}
žádná explicitní kooperativnost tam není.
vypíše:
4 running
1 running
2 running
3 running
4 done
1 done
2 done
3 done
kdyby Go bylo nepreemptivní, tak bych dostal:
1 running
1 done
2 running
2 done
3 running
3 done
4 running
4 done
-
package main
...
No..preemptivní typicky znamená, že to scheduler přeruší bez ohledu na to, co to dělá. Když vyhodíš ten printf z prostředka, tak to vypíše co? Kooperativní znamená, že to scheduler může přerušit na přesně definovaných místech. Dřív to bývalo explicitní volání yield(), v dnešních jazycích to bývá třeba při volání funkcí, při alokaci paměti apod.. Na týhle úrovni je to (až na nějaké extrémní případy) v praxi v podstatě jedno. Ale jestli to CPU intenzivní smyčku bez volání funkcí není schopno přerušit, tak to preemptivní není.
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
A k čemu by mi to mělo být dobré? Celý async await je jenom kvůli tomu, že ten blbý JS není schopen dělat non-blocking IO jinak než přes callbacky... navíc to ani neni pořádně composable.
-
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
A k čemu by mi to mělo být dobré? Celý async await je jenom kvůli tomu, že ten blbý JS není schopen dělat non-blocking IO jinak než přes callbacky... navíc to ani neni pořádně composable.
await je právě náhrada callbacků. Jak funguje non-blocking IO v Javě nebo C++ v jednom vlákně bez callbacků? Co umí Java navíc oproti C#, že nepotřebuje await nebo yield?
-
package main
...
No..preemptivní typicky znamená, že to scheduler přeruší bez ohledu na to, co to dělá. Když vyhodíš ten printf z prostředka, tak to vypíše co? Kooperativní znamená, že to scheduler může přerušit na přesně definovaných místech. Dřív to bývalo explicitní volání yield(), v dnešních jazycích to bývá třeba při volání funkcí, při alokaci paměti apod.. Na týhle úrovni je to (až na nějaké extrémní případy) v praxi v podstatě jedno. Ale jestli to CPU intenzivní smyčku bez volání funkcí není schopno přerušit, tak to preemptivní není.
Výše jsem psal, že se goroutiny přerušují při volání funkcí. Nejen IO funkcí. Přiznávám, použil jsem špatné názvosloví.
-
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
A k čemu by mi to mělo být dobré? Celý async await je jenom kvůli tomu, že ten blbý JS není schopen dělat non-blocking IO jinak než přes callbacky... navíc to ani neni pořádně composable.
await je právě náhrada callbacků. Jak funguje non-blocking IO v Javě nebo C++ v jednom vlákně bez callbacků? Co umí Java navíc oproti C#, že nepotřebuje await nebo yield?
Ok v C++ jdou implementovat coroutiny
http://www.boost.org/doc/libs/1_62_0/libs/coroutine/doc/html/index.html
přiznávám, jsem lopata
-
await je právě náhrada callbacků. Jak funguje non-blocking IO v Javě nebo C++ v jednom vlákně bez callbacků? Co umí Java navíc oproti C#, že nepotřebuje await nebo yield?
Blbě a nic. Nějaký důvod, proč to JS nemá pořešené stejně jako třeba Go?
-
await je právě náhrada callbacků. Jak funguje non-blocking IO v Javě nebo C++ v jednom vlákně bez callbacků? Co umí Java navíc oproti C#, že nepotřebuje await nebo yield?
Blbě a nic. Nějaký důvod, proč to JS nemá pořešené stejně jako třeba Go?
Nevím. K podobným účelům se používaly generátory. Async funkce jsou jen syntaktický cukr pro speciální případ. Osobně v přístupu Go vidím jen zvýšenou komplexitu a žádnou výhodu.
-
await je právě náhrada callbacků. Jak funguje non-blocking IO v Javě nebo C++ v jednom vlákně bez callbacků? Co umí Java navíc oproti C#, že nepotřebuje await nebo yield?
Blbě a nic. Nějaký důvod, proč to JS nemá pořešené stejně jako třeba Go?
Žeby byl JS starší hlavo dubová?
Nehledě na to že JS používá async operace pro úplně všechno, nejen IO. Go tu asynchronost před vývojářem schovává. To je někdy dobře a jindy na škodu.
-
Žeby byl JS starší hlavo dubová?
Nerozumím. Jakýkoliv jazyk, který podporuje user-thready to umí. Což je spousta jazyků, které podporovaly green-thready, a pokud dobře čtu, tak i ta Java dneska má many-to-many thready, takže to umí také.
Nehledě na to že JS používá async operace pro úplně všechno, nejen IO. Go tu asynchronost před vývojářem schovává. To je někdy dobře a jindy na škodu.
Go zas tak moc neumím, ale "na škodu" mi připadá v tomhle případě jako zoufat si, že nové jazyky nemají "goto". Jo, některé problémy se s "goto" řeší líp a někdy to může být i podstatně rychlejší.
Osobně v přístupu Go vidím jen zvýšenou komplexitu a žádnou výhodu.
Teď nevím, o čem se tu bavíme... v pseudokódu:
text = readFile("soubor")
if (text = "a")
text2 = readFile("xxx")
else
text2 = readFile("yyy");
udelejNeco(text2);
# vs.
readFile("soubor", text -> if (text == "a") readFile("xxx", text2 -> udelejNeco(text2)) else readFile("yyy", text2 -> udelejNeco(text2)))
# vs. to same jako priklad 1, akorat s async await
Co je na příkladu 1 "zvýšená komplexita"? Naopak, takhle by měl vypadat všechen kód. Celý async await je snaha, se k tomuhle dostat, ale ve výsledků to prostě není pořádně composable (https://github.com/tc39/ecmascript-asyncawait/issues/7). Je to stejně blbě composable jako generátory třeba i v pythonu. Dobře to má udělaný Purescript v Aff monadu, jenomže to asi do vanilla JS jde propašovat dost těžko.
-
Žeby byl JS starší hlavo dubová?
Nerozumím. Jakýkoliv jazyk, který podporuje user-thready to umí. Což je spousta jazyků, které podporovaly green-thready, a pokud dobře čtu, tak i ta Java dneska má many-to-many thready, takže to umí také.
Python umí obojí. Vlákna mají větší paměťovou náročnost a musíte myslet na thread safety datových struktur a funkcí, atomicitu operací a synchronizaci. Případně používat zámky.
Nehledě na to že JS používá async operace pro úplně všechno, nejen IO. Go tu asynchronost před vývojářem schovává. To je někdy dobře a jindy na škodu.
Go zas tak moc neumím, ale "na škodu" mi připadá v tomhle případě jako zoufat si, že nové jazyky nemají "goto". Jo, některé problémy se s "goto" řeší líp a někdy to může být i podstatně rychlejší.
V JS máte jistotu, že posloupnost operací přistupující ke sdíleným prostředkům proběhne bez přerušení. V Go tu jistotu nemáte.
Osobně v přístupu Go vidím jen zvýšenou komplexitu a žádnou výhodu.
Teď nevím, o čem se tu bavíme... v pseudokódu:
text = readFile("soubor")
if (text = "a")
text2 = readFile("xxx")
else
text2 = readFile("yyy");
udelejNeco(text2);
# vs.
readFile("soubor", text -> if (text == "a") readFile("xxx", text2 -> udelejNeco(text2)) else readFile("yyy", text2 -> udelejNeco(text2)))
# vs. to same jako priklad 1, akorat s async await
Co je na příkladu 1 "zvýšená komplexita"? Naopak, takhle by měl vypadat všechen kód. Celý async await je snaha, se k tomuhle dostat, ale ve výsledků to prostě není pořádně composable (https://github.com/tc39/ecmascript-asyncawait/issues/7). Je to stejně blbě composable jako generátory třeba i v pythonu. Dobře to má udělaný Purescript v Aff monadu, jenomže to asi do vanilla JS jde propašovat dost těžko.
Awaitovat můžete jen uvnitř async funkce. Composable to je. Můžete awaitovat vše co vrací promise, tedy i jiné async funkce. Tomu tazateli by stačilo místo forEach použít obyčejný for.
Pythonovské generátory jsou composable. Co jiného dělá yield from?
Dokonce můžete kombinovat generátory s async await a vytvářet async generátory. V Go podobné věci zdaleka tak elegantně zapsat nejdou.
-
V JS máte jistotu, že posloupnost operací přistupující ke sdíleným prostředkům proběhne bez přerušení. V Go tu jistotu nemáte.
A ani ji nepotřebuje - což je přesně to, o co jde, proč to má Go udělané dobře :) Komponenty nemají nic sdílet, pokud to není opravdu nezbytně nevyhnutelně nutné.
-
V JS máte jistotu, že posloupnost operací přistupující ke sdíleným prostředkům proběhne bez přerušení. V Go tu jistotu nemáte.
A ani ji nepotřebuje - což je přesně to, o co jde, proč to má Go udělané dobře :) Komponenty nemají nic sdílet, pokud to není opravdu nezbytně nevyhnutelně nutné.
Proč potom existují tooly jako tento?
https://blog.golang.org/race-detector
-
Proč potom existují tooly jako tento?
https://blog.golang.org/race-detector
A proč ne?
-
V JS máte jistotu, že posloupnost operací přistupující ke sdíleným prostředkům proběhne bez přerušení. V Go tu jistotu nemáte.
Ale to přece není otázka blocking/non-blocking, ale důsledek toho, že JS nemá žádnou podporu pro multithreading (i user-level). Ale dobrá reklama na JS: je to super-jazyk, nemusíte řešit zámky, protože to neumí multithreading a rozhodně mezi 2 příkazy vám "omylem" nic nevleze, protože kód "po" tom prvním příkazu musíte dát jako callback a tím pádem je vidět, že tam něco vleze. Ale blbě se s tím programovalo, takže jsme vynalezli "async await", který způsobí, že vám mezi ty 2 příkazy něco klidně může vlízt a tím pádem se to chová jako ty všechny ostatní jazyky, ale jinak je to fakt lepší....
Awaitovat můžete jen uvnitř async funkce. Composable to je. Můžete awaitovat vše co vrací promise, tedy i jiné async funkce. Tomu tazateli by stačilo místo forEach použít obyčejný for.
Pythonovské generátory jsou composable. Co jiného dělá yield from?
Vida, vývoj pythonu už delší dobu nesleduju, to tam tehdy nebylo :) Ovšem bez "yield from" to taky bylo composable, stačilo použít for...yield... to je v podstatě další syntaktický cukr, podobně jako async await. Prostě to není composable ale nějak to syntaxí přiohnem, aby se aspoň ty nejčastějc používané věci dali rozumně použít a člověk se přitom neškrábal nohou za uchem.
Ale jo, ty jazyky se postupně zlepšují. Ještě pár desítek let a budou všechny docela použitelné....
Dokonce můžete kombinovat generátory s async await a vytvářet async generátory. V Go podobné věci zdaleka tak elegantně zapsat nejdou.
Protože je (často) prostě zapsat nepotřebuju. Celý async-await je prostě automaticky zapnutý....
-
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.
1. Puvodni JS neumel filesystem IO, node je proste evoluce a pridali tam moznost pouzivat systemove knihovny aby IO nemuseli vymyslet od piky. BFU receno dohackovali tam linkovani .so :)
2. Nekompilovany jazyk je zamer, proste se na to divej stejne jako na perl, python, php...
3. JS na serveru ma vyhodu napr. v tom, ze muzes stejnou knihovnu pouzit jak na frontendu v browseru tak na backendu na servru. Napr. takova validace dat v html formulari. Checknes to na forntendu, a pak jeste jednou na backendu (kvuli moznym hackum abotum co se pchaji primo na API) tou samou knihovnou. Kdybys mel na backendu treba Javu tak musis ty validatory prepsat z JS do Javy a stav se ze chybka se vloudi a nbudou validovat stejne..
4. Rychlost http servru v node - je default nenoblocking, async atd.
-
V JS máte jistotu, že posloupnost operací přistupující ke sdíleným prostředkům proběhne bez přerušení. V Go tu jistotu nemáte.
Ale to přece není otázka blocking/non-blocking, ale důsledek toho, že JS nemá žádnou podporu pro multithreading (i user-level). Ale dobrá reklama na JS: je to super-jazyk, nemusíte řešit zámky, protože to neumí multithreading a rozhodně mezi 2 příkazy vám "omylem" nic nevleze, protože kód "po" tom prvním příkazu musíte dát jako callback a tím pádem je vidět, že tam něco vleze. Ale blbě se s tím programovalo, takže jsme vynalezli "async await", který způsobí, že vám mezi ty 2 příkazy něco klidně může vlízt a tím pádem se to chová jako ty všechny ostatní jazyky, ale jinak je to fakt lepší....
Awaitovat můžete jen uvnitř async funkce. Composable to je. Můžete awaitovat vše co vrací promise, tedy i jiné async funkce. Tomu tazateli by stačilo místo forEach použít obyčejný for.
Pythonovské generátory jsou composable. Co jiného dělá yield from?
Vida, vývoj pythonu už delší dobu nesleduju, to tam tehdy nebylo :) Ovšem bez "yield from" to taky bylo composable, stačilo použít for...yield... to je v podstatě další syntaktický cukr, podobně jako async await. Prostě to není composable ale nějak to syntaxí přiohnem, aby se aspoň ty nejčastějc používané věci dali rozumně použít a člověk se přitom neškrábal nohou za uchem.
Ale jo, ty jazyky se postupně zlepšují. Ještě pár desítek let a budou všechny docela použitelné....
Dokonce můžete kombinovat generátory s async await a vytvářet async generátory. V Go podobné věci zdaleka tak elegantně zapsat nejdou.
Protože je (často) prostě zapsat nepotřebuju. Celý async-await je prostě automaticky zapnutý....
Ono celé slavné async/await je jen mnoho povyku pro nic, je to nic nepřinášející zhnusnění kódu. Čistě formálně je to jen zbytečně složitě vyjádřená monáda.
-
Ono celé slavné async/await je jen mnoho povyku pro nic, je to nic nepřinášející zhnusnění kódu. Čistě formálně je to jen zbytečně složitě vyjádřená monáda.
Nemohl bys uvést ukázku pěkného kódu, který se tím zhnusí? Jak vypadá jednoduše vyjádřená monáda?
-
Ono celé slavné async/await je jen mnoho povyku pro nic, je to nic nepřinášející zhnusnění kódu. Čistě formálně je to jen zbytečně složitě vyjádřená monáda.
Nemohl bys uvést ukázku pěkného kódu, který se tím zhnusí? Jak vypadá jednoduše vyjádřená monáda?
Tak když vezmu Purescript Aff (https://pursuit.purescript.org/packages/purescript-aff/3.0.0) monad, což je v podstatě přesně to, co řeší async-await.
Tak když vezmu ty příklady - ten originál z té stránky (https://github.com/tc39/ecmascript-asyncawait/issues/7#issuecomment-148748622):
All getJSON operations will happen in parallel, and the application will wait until all requests are complete before adding them all to the page at once.
(await Promise.all(urls.map(getJSON))).forEach(j => addToPage(j.html));
-- vs.
parTraverse getJSON urls >>= traverse (addToPage _.html)
All getJSON operations will happen in parallel, and each object will be added to the page as it arrives (possibly out of order).
await Promise.all(urls.map(getJSON).map(async j => addToPage((await j).html)));
-- vs.
parTraverse_ (getJSON >=> addToPage (_.html)) urls
All getJSON operations will happen in parallel, with the results being added to the page sequentially as they come in.
for (let j of urls.map(getJSON)) {
addToPage((await j).html);
}
A tady tohle standardně nejde, protože to je imperativní kód, nicméně když si definujeme malé funkce...
async f = do
v <- makeVar
forkAff (f >>= putVar v)
pure v
await = takeVar
Take ten kód můžeme napsat:
parTraverse (\url -> async (getJSON url)) urls >>= traverse_ (\promise -> await promise >>= addToPage _.html)
(nebo zkráceně)
parTraverse (async <<< getJSON) urls >>= traverse_ (await promise >=> addToPage _.html)
A ta sranda je, že parTraverse je jenom normální funkce, která někde volá "traverse" (obdoba forEach), takže funguje se všemi strukturami, které podporují Traversable. A na implementaci "async" a "await" (který je navíc potřeba jen, když nepoužíváme sekvenční kód) není potřeba modifikovat jazyk, ale dají se normálně naprogramovat...
-
All getJSON operations will happen in parallel, and each object will be added to the page as it arrives (possibly out of order).
await Promise.all(urls.map(getJSON).map(async j => addToPage((await j).html)));
-- vs.
parTraverse_ (getJSON >=> addToPage (_.html)) urls
Tohle není úloha, kde by použití await vyniklo. Await se hodí hlavně tam, kde byste jinak řetězil několik then.
S bluebirdem bych to zapsal asi takto:
Promise.map(urls, getJSON).each(j => addToPage(j.html));
Je to stejně dlouhé jako vaše řešení v purescriptu.
V JS máte jistotu, že posloupnost operací přistupující ke sdíleným prostředkům proběhne bez přerušení. V Go tu jistotu nemáte.
Ale to přece není otázka blocking/non-blocking, ale důsledek toho, že JS nemá žádnou podporu pro multithreading (i user-level). Ale dobrá reklama na JS: je to super-jazyk, nemusíte řešit zámky, protože to neumí multithreading a rozhodně mezi 2 příkazy vám "omylem" nic nevleze, protože kód "po" tom prvním příkazu musíte dát jako callback a tím pádem je vidět, že tam něco vleze. Ale blbě se s tím programovalo, takže jsme vynalezli "async await", který způsobí, že vám mezi ty 2 příkazy něco klidně může vlízt a tím pádem se to chová jako ty všechny ostatní jazyky, ale jinak je to fakt lepší....
to se týká pouze IO operací. Posloupnosti ne-IO operací jsou v JS zcela bezpečné, v Go musíte řešit zámky.
-
All getJSON operations will happen in parallel, and each object will be added to the page as it arrives (possibly out of order).
await Promise.all(urls.map(getJSON).map(async j => addToPage((await j).html)));
-- vs.
parTraverse_ (getJSON >=> addToPage (_.html)) urls
Tohle není úloha, kde by použití await vyniklo. Await se hodí hlavně tam, kde byste jinak řetězil několik then.
No jo, ale to pak vypadá jako:
funkce = do
r <- zavolejAjax
b <- zobrazUzivateliDialogAPockejAzKlikneNaOK r
zavolejJinyAjax b
což je docela primitivní záležitost, se kterou se moc nemusí přemýšlet :) Tohle byl aspoň trošku challenge, jak to napsat (obzvlášť to poslední...)
to se týká pouze IO operací. Posloupnosti ne-IO operací jsou v JS zcela bezpečné, v Go musíte řešit zámky.
Jo, takhle se před 20 lety implementoval kooperativní multitasking. Go je přece jen trošku novější....
-
S bluebirdem bych to zapsal asi takto:
Promise.map(urls, getJSON).each(j => addToPage(j.html));
Je to stejně dlouhé jako vaše řešení v purescriptu.
...což bude nejspíš tím, že Promise je instance monády, akorát se to nesmí říkat, aby to javascriptaře neděsilo ;)
-
S bluebirdem bych to zapsal asi takto:
Promise.map(urls, getJSON).each(j => addToPage(j.html));
Je to stejně dlouhé jako vaše řešení v purescriptu.
...což bude nejspíš tím, že Promise je instance monády, akorát se to nesmí říkat, aby to javascriptaře neděsilo ;)
Nestraš :P
Ale teď vážně, co je "instance monády"? Řekl bych, že "promise je monáda", je v tom něco hlubšího nebo jde jen o přešlap v terminologii?
-
Ale teď vážně, co je "instance monády"? Řekl bych, že "promise je monáda", je v tom něco hlubšího nebo jde jen o přešlap v terminologii?
Chtěl jsem zdůraznit (pro javascriptaře), že ten Promise v JS je jednou z instancí obecného konceptu "monáda". "Promise je monáda" je terminologicky správnější - stejně jako "sčítání nad celými čísly je grupa", akorát to může někoho zmýlit - může si myslet, že když umí sčítat, tak pochopil, co je to grupa, a když umí použít Promise, tak ví, co je to monáda :)
-
Ale teď vážně, co je "instance monády"? Řekl bych, že "promise je monáda", je v tom něco hlubšího nebo jde jen o přešlap v terminologii?
Chtěl jsem zdůraznit (pro javascriptaře), že ten Promise v JS je jednou z instancí obecného konceptu "monáda". "Promise je monáda" je terminologicky správnější - stejně jako "sčítání nad celými čísly je grupa", akorát to může někoho zmýlit - může si myslet, že když umí sčítat, tak pochopil, co je to grupa, a když umí použít Promise, tak ví, co je to monáda :)
Nesouhlasím, ale nebudu rejpat (slovíčkařit) ;)
-
Nesouhlasím, ale nebudu rejpat (slovíčkařit) ;)
Nehádal bych se s tebou, vím, že je to špatně. Stejně jako pes není instance savce, ale pes je savec :)
-
S bluebirdem bych to zapsal asi takto:
Promise.map(urls, getJSON).each(j => addToPage(j.html));
Je to stejně dlouhé jako vaše řešení v purescriptu.
...což bude nejspíš tím, že Promise je instance monády, akorát se to nesmí říkat, aby to javascriptaře neděsilo ;)
Mě neděsí nic. Jen si nechci komplikovat život používáním jazyka kompilovaného do JS s malou komunitou a nejistou budoucností. Vaši hlavní výhradu k JS - neexistenci vláken, to stejně neřeší.
-
Vaši hlavní výhradu k JS - neexistenci vláken, to stejně neřeší.
Když už, tak: moje hlavní výhrada vůči JS je, že to je neuvěřitelně splácaný jazyk, který je snad vůbec nejvíc nepředvídatelný ze všech, co jsem kdy viděl. Pokud někdo hodlá JS obhajovat, ať prvně srovná třeba s Lua, to je jazyk podobného typu, ale udělaný dobře, koncepčně (nemusí se mi líbit, nemusí mi vyhovovat, ale má logiku a jasnou myšlenku).
WTF vtípků ohledně nelogičností JS je plný net, ale vlastní zkušenost je k nezaplacení:
Mám prostě neutuchající pocit, že vývojáři Javascriptu mají obzvláštní talent vymlet úplně každý výmol, který se na cestě nachází - i kdyby to měli vzít oklikou, aby do něj najeli.
https://plus.google.com/+MiroslavPrymek/posts/euSuscZtbyj
(nehodlám startovat flejm, jenom uvádím na pravou míru, že neexistence rozumné konkurentnosti fakt není ani zdaleka největší problém JS)
-
Chování je přesně definované, nemusíte ho považovat za logické. Stačí se ho naučit za zlomek času, který strávíte přechodem na jiný jazyk. Z dlouhodobého hlediska to vaši produktivitu nijak nesníží i kdyby to bylo nelogické. Osobně považuji importy celkem za zbytečné, jsou nutné asi hlavně pro lepší fungování IDE.
-
Chování je přesně definované
Jistě. Například operátor == je "přesně definován" tak, že "nemusí" být tranzitivní. Proč přecházet na jazyk, kde == je tranzitivní, když se stačí naučit navzpaměť případy, kdy == v JS tranzitivní není. A to se, Horste, vyplatí!
-
Chování je přesně definované
Jistě. Například operátor == je "přesně definován" tak, že "nemusí" být tranzitivní. Proč přecházet na jazyk, kde == je tranzitivní, když se stačí naučit navzpaměť případy, kdy == v JS tranzitivní není. A to se, Horste, vyplatí!
Používejte === a ruční konverzi když si nejste jistý.
Já zde netvrdím, že je JS dokonalý jazyk, ale vám na jednu stranu vadí maličkosti v JS a na druhou stranu obhajujete Go, kde vám různé speciální případy a nedokonalosti jazyka skutečně komplikují život.
-
Používejte === a ruční konverzi když si nejste jistý.
Vymyslel jsem lepsi reseni: nepouzivam JavaScript :)
ale vám na jednu stranu vadí maličkosti v JS a na druhou stranu obhajujete Go, kde vám různé speciální případy a nedokonalosti jazyka skutečně komplikují život.
Ze v jazyce funguji veci naprosto neocekavatelnym zpusobem neni malickost, ale zcela zasadni showstopper, pokud clovek nechce zesilet.
O jakych konkretne "speciálních případech" a "nedokonalostech" se bavime u Go? BTW, neni pravda, ze bych ho obhajoval - nepouzivam ho aktivne a na muj vkus je to jazyk prilis jednoduchy, ale aspon ma (stejne jako ta Lua) svou logiku, ktera se da pochopit bez toho, aby si clovek zoufalosti vytrhal vsechny vlasy (specialita JS a C++) a ma velice user-friendly vyresenou konkurentnost, coz je aspon respektuhodne, kdyz uz nic jinyho.
-
Používejte === a ruční konverzi když si nejste jistý.
Vymyslel jsem lepsi reseni: nepouzivam JavaScript :)
ale vám na jednu stranu vadí maličkosti v JS a na druhou stranu obhajujete Go, kde vám různé speciální případy a nedokonalosti jazyka skutečně komplikují život.
Ze v jazyce funguji veci naprosto neocekavatelnym zpusobem neni malickost, ale zcela zasadni showstopper, pokud clovek nechce zesilet.
O jakych konkretne "speciálních případech" a "nedokonalostech" se bavime u Go? BTW, neni pravda, ze bych ho obhajoval - nepouzivam ho aktivne a na muj vkus je to jazyk prilis jednoduchy, ale aspon ma (stejne jako ta Lua) svou logiku, ktera se da pochopit bez toho, aby si clovek zoufalosti vytrhal vsechny vlasy (specialita JS a C++) a ma velice user-friendly vyresenou konkurentnost, coz je aspon respektuhodne, kdyz uz nic jinyho.
Jen tak pro informaci: http://www.i-programmer.info/news/150-training-a-education/10716-stanford-cs-moves-to-javascript.html
-
Jen tak pro informaci: http://www.i-programmer.info/news/150-training-a-education/10716-stanford-cs-moves-to-javascript.html
A co? Inteligentní lidé se naučí JS bez problémů.
-
Používejte === a ruční konverzi když si nejste jistý.
Vymyslel jsem lepsi reseni: nepouzivam JavaScript :)
Takže vlastně říkáte, že porovnáváte věci různého datového typu, ale přijde vám to v pohodě a může z to JavaScript.
WTF vtípků ohledně nelogičností JS je plný net, ale vlastní zkušenost je k nezaplacení:
Mám prostě neutuchající pocit, že vývojáři Javascriptu mají obzvláštní talent vymlet úplně každý výmol, který se na cestě nachází - i kdyby to měli vzít oklikou, aby do něj najeli.
https://plus.google.com/+MiroslavPrymek/posts/euSuscZtbyj
Takže opět, vaši neznalost vydáváte za chybu JS. Ano, vtípků o JS je plný net, ale opět, v drtivé většině případů to vychází z neznalosti autorů. Jak jinak interpretovat to, že JavaScriptu vyčítají to, co vrací na [] == {}, apod. To, že jazyk něco *umožňuje*, neznamená, že je dobrý nápad to dělat. ;)
To je jako vyčítat Perlu, že se v něm dá kód snadno prasit. Když to neumím, tak v tom nepíšu. Ale chlubit se tím veřejně...
Když už, tak: moje hlavní výhrada vůči JS je, že to je neuvěřitelně splácaný jazyk, který je snad vůbec nejvíc nepředvídatelný ze všech, co jsem kdy viděl.
A PHP znáte?
####################
Dodatek - I když to tak možná nevypadá, tak JS mě spoustou věcí štve/nesedí či spousta věcí okolo něj. Ale nelíbí se mi, když někdo něco kritizuje na základě své nevědomosti.
-
Jen tak pro informaci: http://www.i-programmer.info/news/150-training-a-education/10716-stanford-cs-moves-to-javascript.html
Ve skutecnosti zacinali s Karlem ;) http://web.stanford.edu/class/cs106a/lectures.shtml
(BTW, ten nadpis nejspis klame, "CS 106A" zjevne porad existuje, jenom k nemu je nova alternativa "CS 106J")
-
O jakych konkretne "speciálních případech" a "nedokonalostech" se bavime u Go? BTW, neni pravda, ze bych ho obhajoval - nepouzivam ho aktivne a na muj vkus je to jazyk prilis jednoduchy, ale aspon ma (stejne jako ta Lua) svou logiku, ktera se da pochopit bez toho, aby si clovek zoufalosti vytrhal vsechny vlasy (specialita JS a C++) a ma velice user-friendly vyresenou konkurentnost, coz je aspon respektuhodne, kdyz uz nic jinyho.
věci, které jsou jinde triviální se v Go musí řešit copy pastováním 10+ řádků.
řešili jsme tu generátory
http://www.golangpatterns.info/concurrency/generators
ve všech moderních jazycích by to bylo na dva řádky. Při čtení toho kódu potom těžko odlišujete mezi boilerplatem a podstatnými částmi. Přijde mi, že je to jazyk pro hipstery co se holí břitvou a jezdí na kole bez brzd.
-
Takže vlastně říkáte, že porovnáváte věci různého datového typu, ale přijde vám to v pohodě a může z to JavaScript.
A to's vymyslel hlavou? Rikam, ze pouzivam jazyky, ktere se chovaji tak, jak by clovek ocekaval, ne tak, jak by ho ani v nejdivocejsim snu nenapadlo.
Takže opět, vaši neznalost vydáváte za chybu JS.
Jakou konkretne neznalost? Ten post je o semanticke nekonzistentnosti JS. Popravde, kdybych tenhle rys neznal, byl bych radsi.
Jak jinak interpretovat to, že JavaScriptu vyčítají to, co vrací na [] == {}, apod. To, že jazyk něco *umožňuje*, neznamená, že je dobrý nápad to dělat. ;)
Tak to je jiste velmi zajimava myslenka. Ostatne by treba v jazyce mohlo platit, ze 1+1=3. Pokud by nekdo ocekaval dvojku, tak je to jeho neznalost a kdyz nechce dostat trojku, tak tenhle rys jazyka nemusi pouzivat, no ne?
A PHP znáte?
Vubec. A nehodlam na tom nic menit, nechci zbytecne utracet za psychiatra.
Dodatek - I když to tak možná nevypadá, tak JS mě spoustou věcí štve/nesedí či spousta věcí okolo něj. Ale nelíbí se mi, když někdo něco kritizuje na základě své nevědomosti.
Jeste jednou: jake nevedomosti?!
-
věci, které jsou jinde triviální se v Go musí řešit copy pastováním 10+ řádků.
Porad nevim, o cem je rec. Ze Go nema generika? Jo, to se mi na nem taky nelibi. Ale neni to zhovadilost, je to vedoma volba, ktera mi nemusi vyhovovat, ale ma svou logiku.
ve všech moderních jazycích by to bylo na dva řádky. Při čtení toho kódu potom těžko odlišujete mezi boilerplatem a podstatnými částmi. Přijde mi, že je to jazyk pro hipstery co se holí břitvou a jezdí na kole bez brzd.
Fakt? Jak se napise v pythonu na dva radky konkurentni (paralelizovatelny) generator?
-
Dodatek - I když to tak možná nevypadá, tak JS mě spoustou věcí štve/nesedí či spousta věcí okolo něj. Ale nelíbí se mi, když někdo něco kritizuje na základě své nevědomosti.
Jeste jednou: jake nevedomosti?!
na použití == upozorňuje linter. Nevím jestli je to nevědomost, nebo to záměrně ignorujete.
-
věci, které jsou jinde triviální se v Go musí řešit copy pastováním 10+ řádků.
Porad nevim, o cem je rec. Ze Go nema generika? Jo, to se mi na nem taky nelibi. Ale neni to zhovadilost, je to vedoma volba, ktera mi nemusi vyhovovat, ale ma svou logiku.
ve všech moderních jazycích by to bylo na dva řádky. Při čtení toho kódu potom těžko odlišujete mezi boilerplatem a podstatnými částmi. Přijde mi, že je to jazyk pro hipstery co se holí břitvou a jezdí na kole bez brzd.
Fakt? Jak se napise v pythonu na dva radky konkurentni (paralelizovatelny) generator?
Proč bych měl generátor posloupnosti náhodných čísel psát paralelizovatelně? Jak napíšete v Go jednodušeji neparalelizovatelný generátor?
-
na použití == upozorňuje linter. Nevím jestli je to nevědomost, nebo to záměrně ignorujete.
Cili moje nevedomost spociva v tom, ze nevim, ze aby se JS choval aspon z rychliku rozumne, musi se kod prohnat linterem?
Tak jo, beru :)
P.S. predpokladam, ze tech linteru je k dispozici aspon tak dvacet. Pet neni kompatibilnich s Gruntem, dvanact s Webpackem, pet s Brunchem a u jedenacti musi clovek vedet, ze kdyz se pouziji s transpilerem do XYZ, tak dojde v nekterych situacich (neni poradne znamo jakych) k nekonecne smycce. Ani jeden z nich pak nepokryva vsechny nesmysly, ktere JS poskytuje. Predpokladam spravne? :)
-
Proč bych měl generátor posloupnosti náhodných čísel psát paralelizovatelně?
Zavadejici otazka, na to se s dovolenim nechytnu :)
Jak napíšete v Go jednodušeji neparalelizovatelný generátor?
Nevim. Jak jsem byl rekl, Go aktivne nepouzivam. Jestli mate potrebu nekomu dokazovat, ze to nejde, nejste na spravne adrese :)
Osobne ale moc nevidim duvod, proc by se to tak melo delat, kdyz je k dispozici channel - daleko lepsi abstrakce pro tenhle use case.
-
na použití == upozorňuje linter. Nevím jestli je to nevědomost, nebo to záměrně ignorujete.
Cili moje nevedomost spociva v tom, ze nevim, ze aby se JS choval aspon z rychliku rozumne, musi se kod prohnat linterem?
Tak jo, beru :)
P.S. predpokladam, ze tech linteru je k dispozici aspon tak dvacet. Pet neni kompatibilnich s Gruntem, dvanact s Webpackem, pet s Brunchem a u jedenacti musi clovek vedet, ze kdyz se pouziji s transpilerem do XYZ, tak dojde v nekterych situacich (neni poradne znamo jakych) k nekonecne smycce. Ani jeden z nich pak nepokryva vsechny nesmysly, ktere JS poskytuje. Predpokladam spravne? :)
Zbytečně to hrotíš. Pouzivat === by default je standard.
To že je trošku chaos s toolama teda pravda je...
-
Pouzivat === by default je standard.
To je sice pravda, ale nic to nemeni na tom (naopak to potvrzuje), ze == je zprasene takovym zpusobem, ze ani kdybych LSD zapijel maruihuanovym ginem, tak neco takovyho nevymyslim i kdybych chtel.
-
Vaši hlavní výhradu k JS - neexistenci vláken, to stejně neřeší.
Když už, tak: moje hlavní výhrada vůči JS je, že to je neuvěřitelně splácaný jazyk, který je snad vůbec nejvíc nepředvídatelný ze všech, co jsem kdy viděl. Pokud někdo hodlá JS obhajovat, ať prvně srovná třeba s Lua, to je jazyk podobného typu, ale udělaný dobře, koncepčně (nemusí se mi líbit, nemusí mi vyhovovat, ale má logiku a jasnou myšlenku).
WTF vtípků ohledně nelogičností JS je plný net, ale vlastní zkušenost je k nezaplacení:
Mám prostě neutuchající pocit, že vývojáři Javascriptu mají obzvláštní talent vymlet úplně každý výmol, který se na cestě nachází - i kdyby to měli vzít oklikou, aby do něj najeli.
https://plus.google.com/+MiroslavPrymek/posts/euSuscZtbyj
(nehodlám startovat flejm, jenom uvádím na pravou míru, že neexistence rozumné konkurentnosti fakt není ani zdaleka největší problém JS)
A co jsou workery omg
-
Jak napíšete v Go jednodušeji neparalelizovatelný generátor?
Nevim. Jak jsem byl rekl, Go aktivne nepouzivam. Jestli mate potrebu nekomu dokazovat, ze to nejde, nejste na spravne adrese :)
Osobne ale moc nevidim duvod, proc by se to tak melo delat, kdyz je k dispozici channel - daleko lepsi abstrakce pro tenhle use case.
Jde to snadněji pomocí uzávěru. Ale pořád je to horší než first class generátory.
-
Jde to snadněji pomocí uzávěru. Ale pořád je to horší než first class generátory.
...a generatory jsou o rad horsi nez kontinuace.
Tak jsme si pekne nahonili (ego) a pujdem delat neco rozumnejsiho ne?
-
A co jsou workery omg
Workery? To jakoze si muzu pustit v jinem vlakne nejaky kod s uplne jinym kontextem a komunikovat s nim pres sit? A to jsi chtel zminit jako dobry priklad, jak umoznit konkurentnost?!
Nebo myslis nejaky jiny workery?
-
Jde to snadněji pomocí uzávěru. Ale pořád je to horší než first class generátory.
...a generatory jsou o rad horsi nez kontinuace.
Tak jsme si pekne nahonili (ego) a pujdem delat neco rozumnejsiho ne?
Takže kritika Go je honění ega a kritika JS je šíření osvěty?
nevím co jsou kontinuace, předpokádám, že nic takového v Go neexistuje.
-
Takže kritika Go je honění ega a kritika JS je šíření osvěty?
Ne. Ale neco jineho je kritika psychedelickych haluzi zavedeneho do jazyka bez zjevneho duvodu a kritika toho, ze neco, co neni vubec nutno pouzivat, se nenapise na dva radky, ale na tri. Mimochodem, kdyz jsme ui toho, porad jeste bych rad videl konkretni kod, ktery by implementoval to same pouziti generatoru v Pythonu a v Go. Srovnavat jednovlaknovou verzi v (cem vlastne?) s konkurentni verzi v Go je dost mimo misu.
nevím co jsou kontinuace
To je skoda. Kdybyste to vedel, mohl byste dospet k nazoru, ze (bezne) generatory jsou trochu zbytecna, polovicata vec.
-
Takže vlastně říkáte, že porovnáváte věci různého datového typu, ale přijde vám to v pohodě a může z to JavaScript.
A to's vymyslel hlavou? Rikam, ze pouzivam jazyky, ktere se chovaji tak, jak by clovek ocekaval, ne tak, jak by ho ani v nejdivocejsim snu nenapadlo.
Jasně, takže Perl je podle vás taky *****, protože má "==" a "eq"?
Takže opět, vaši neznalost vydáváte za chybu JS.
Jakou konkretne neznalost? Ten post je o semanticke nekonzistentnosti JS. Popravde, kdybych tenhle rys neznal, byl bych radsi.
Tuto konkrétně neznalost - https://developer.mozilla.org/cs/docs/Web/JavaScript/Reference/Statements/import
Čekal bych, že Google dneska umí používat každý.
Jak jinak interpretovat to, že JavaScriptu vyčítají to, co vrací na [] == {}, apod. To, že jazyk něco *umožňuje*, neznamená, že je dobrý nápad to dělat. ;)
Tak to je jiste velmi zajimava myslenka. Ostatne by treba v jazyce mohlo platit, ze 1+1=3. Pokud by nekdo ocekaval dvojku, tak je to jeho neznalost a kdyz nechce dostat trojku, tak tenhle rys jazyka nemusi pouzivat, no ne?
S tím rozdílem, že váš příklad provádí operaci nad stejným datovým typem. Neznalost je (a to ještě velmi slušně řečeno), pokud čekáte, že takové dělení pole stringem je v pořádku.
A když nechcete "dostat trojku", tak nepište prasárny nebo používejte ===.
A PHP znáte?
Vubec. A nehodlam na tom nic menit, nechci zbytecne utracet za psychiatra.
Tak to jste toho moc neviděl.
-
A co jsou workery omg
Workery? To jakoze si muzu pustit v jinem vlakne nejaky kod s uplne jinym kontextem a komunikovat s nim pres sit? A to jsi chtel zminit jako dobry priklad, jak umoznit konkurentnost?!
Nebo myslis nejaky jiny workery?
Pres jakou sit ty vole.
Workery bezej pekne na stroji, maj oddeleny namespace a posilaj si mezi sebou async zpravy. Na pozadi se nikam nic neposila do site. Spawnout worker jde taky bez site, koukni se na jednu z milionu threadovych libek jak to delaj...
Naopak, workery funguji tak jak by meli fungovat vsechny real objekty ... Paralelne a samostatne.
-
Jde to snadněji pomocí uzávěru. Ale pořád je to horší než first class generátory.
...a generatory jsou o rad horsi nez kontinuace.
Zase ho strašíš další monádou? ;D
-
Jde to snadněji pomocí uzávěru. Ale pořád je to horší než first class generátory.
...a generatory jsou o rad horsi nez kontinuace.
Zase ho strašíš další monádou? ;D
Se z tech monad neposer. Ostatne, neni to zadna velka magic. Z fp muzes vedet picu a stejne monady muzes spokojene aplikovat.
-
Jasně, takže Perl je podle vás taky *****, protože má "==" a "eq"?
Nevim, Perl neznam, takze o nem nic netvrdim. Ale neprekvapilo by me, kdyby tam taky nejaka ta zhovadilost byla.
Tuto konkrétně neznalost - https://developer.mozilla.org/cs/docs/Web/JavaScript/Reference/Statements/import
Čekal bych, že Google dneska umí používat každý.
A co konkretne z toho bych nemel znat? Porad nejak nechapu pointu.
S tím rozdílem, že váš příklad provádí operaci nad stejným datovým typem. Neznalost je (a to ještě velmi slušně řečeno), pokud čekáte, že takové dělení pole stringem je v pořádku.
COZE?! Neocekavam zadne deleni stringem. Ocekavam, ze == je relace ekvivalence, tj. mj. je tranzitivni. A pokud neni obecne, tak vyjimka je maximalne jedna dve a to z VELMI dobreho duvodu (napr NaN != NaN bych jeste byl schopnej pochopit).
-
Pres jakou sit ty vole.
Workery bezej pekne na stroji, maj oddeleny namespace a posilaj si mezi sebou async zpravy.
Ahhhh, moje chyba, myslel jsem, ze komunikuji pres sockety.
"posilaj si mezi sebou async zpravy" samo o sobe nerika nic. Muze to byt paradni vec jako v Erlangu a muze to byt zoufalost jako radobyparalelismus v Rku nebo v pythonnim multiprocessing, ktery jenom zoufale obchazi GIL.
-
Se z tech monad neposer.
(http://1.bp.blogspot.com/-31eySzAIxC8/UtO5wupGfRI/AAAAAAAAAIo/U8kfcuwvLz4/s1600/1389507978063.jpg)
:))))
-
Jde to snadněji pomocí uzávěru. Ale pořád je to horší než first class generátory.
...a generatory jsou o rad horsi nez kontinuace.
Kontinuace je univerzálnější, ale taky abstraktnější (a někdy to je dost zmatek, stačí zkusit si pro kontinuaci napsat >>=). Nejlépe se tento typ kódu píše v CSP, je to triviální a univerzální.
-
Takže kritika Go je honění ega a kritika JS je šíření osvěty?
Ne. Ale neco jineho je kritika psychedelickych haluzi zavedeneho do jazyka bez zjevneho duvodu a kritika toho, ze neco, co neni vubec nutno pouzivat, se nenapise na dva radky, ale na tri. Mimochodem, kdyz jsme ui toho, porad jeste bych rad videl konkretni kod, ktery by implementoval to same pouziti generatoru v Pythonu a v Go. Srovnavat jednovlaknovou verzi v (cem vlastne?) s konkurentni verzi v Go je dost mimo misu.
channely nejsou nic jiného než fronty
from multiprocessing import Process, Queue
from random import random
def rand(q):
while True:
q.put(random())
def main():
q = Queue(0)
p = Process(target=rand, args=(q,))
p.start()
for i in range(10):
print(q.get())
p.terminate()
-
from multiprocessing import Process, Queue
from random import random
def rand(q):
while True:
q.put(random())
def main():
q = Queue(0)
p = Process(target=rand, args=(q,))
p.start()
for i in range(10):
print(q.get())
p.terminate()
A timhle kodem jsi chtel demonstrovat co? Chtel jsem videt ten kod generatoru, co jde v Pythonu napsat lip nez v Go.
-
Ahhhh, moje chyba, myslel jsem, ze komunikuji pres sockety.
"posilaj si mezi sebou async zpravy" samo o sobe nerika nic. Muze to byt paradni vec jako v Erlangu a muze to byt zoufalost jako radobyparalelismus v Rku nebo v pythonnim multiprocessing, ktery jenom zoufale obchazi GIL.
However, in the case of multi-threaded implementations, many browsers implement a structured cloning algorithm to copy the message into the receiving thread’s context (http://nickwritesablog.com/the-state-of-concurrent-javascript/#webworkersapi)
JS runtime musi predavane objekty serializovat a deserializovat. Je s tym spojeny overhead a nedokaze passnut referenciu na priamo.
-
Jasně, takže Perl je podle vás taky *****, protože má "==" a "eq"?
Nevim, Perl neznam, takze o nem nic netvrdim. Ale neprekvapilo by me, kdyby tam taky nejaka ta zhovadilost byla.
Očividně neznáte ani JavaScript, takže mě překvapuje, že o něm něco tvrdíte. ;) (a ano, je nepříjemné, když na Perl někdo přechází, když si zvykne, tak je to hned o level výš - ono to taky souvisí s tím, k čemu byl ten jazyk určený).
Tuto konkrétně neznalost - https://developer.mozilla.org/cs/docs/Web/JavaScript/Reference/Statements/import
Čekal bych, že Google dneska umí používat každý.
A co konkretne z toho bych nemel znat? Porad nejak nechapu pointu.
To bude ten problém. Že nechápete, ne JS.
S tím rozdílem, že váš příklad provádí operaci nad stejným datovým typem. Neznalost je (a to ještě velmi slušně řečeno), pokud čekáte, že takové dělení pole stringem je v pořádku.
COZE?! Neocekavam zadne deleni stringem. Ocekavam, ze == je relace ekvivalence, tj. mj. je tranzitivni. A pokud neni obecne, tak vyjimka je maximalne jedna dve a to z VELMI dobreho duvodu (napr NaN != NaN bych jeste byl schopnej pochopit).
Tak možná by bylo dobré si uvědomit, že relace ekvivalence se provádí pro prvky ve stejné množině.
-
JS runtime musi predavane objekty serializovat a deserializovat. Je s tym spojeny overhead a nedokaze passnut referenciu na priamo.
Aha, takze uplne stejna zoufalost jako v R :)
-
Očividně neznáte ani JavaScript, takže mě překvapuje, že o něm něco tvrdíte. ;)
Tak porad jeste cekam na konkretni zminku o tom, co udajne nemam znat :)
Tak možná by bylo dobré si uvědomit, že relace ekvivalence se provádí pro prvky ve stejné množině.
Znovu: COZE?!
To se vazne budeme na IT serveru dohadovat o tom, co je to relace? A o tom, ze relace ekvivalence ma byt tranzitivni? WTF?!
-
Očividně neznáte ani JavaScript, takže mě překvapuje, že o něm něco tvrdíte. ;)
Tak porad jeste cekam na konkretni zminku o tom, co udajne nemam znat :)
Odkaz jste dostal, tím můžete začít. Doporučuji si pak třeba dohledat přednášky Ondřeje Žáry pro předmět KAJ z FELu, je to hezký kurs.
Tak možná by bylo dobré si uvědomit, že relace ekvivalence se provádí pro prvky ve stejné množině.
Znovu: COZE?!
To se vazne budeme na IT serveru dohadovat o tom, co je to relace? A o tom, ze relace ekvivalence ma byt tranzitivni? WTF?!
Řekl jsem, že ekvivalence nemá být tranzitivní?! Možná se naučte číst, tím by bylo nejlepší začít.
Relace je relací ekvivalence právě když je reflexivní, symetrická a tranzitivní. Jenže zároveň je to binární relace na stejné množině. Pokud to stále nechápete, tak doporučuju navštívit 1. ročník každé slušné VŠ.
-
Odkaz jste dostal
V tom postu jsem kritizoval právě to, co jsem si vyzkoušel, čili to znám. Kdybych to neznal, tak bych to nekritizoval.
Řekl jsem, že ekvivalence nemá být tranzitivní?! Možná se naučte číst, tím by bylo nejlepší začít.
Já kritizuju, že == v JS tranzitivní není (a to ještě strašně překombinovaným způsobem), což je překvapivé/matoucí. A jelikož (příliš) překvapující jazyky se mi nelíbí, nelíbí se mi ani JS.
Pokud chcete s něčím z toho polemizovat, řekněte, s čím polemizujete, a předlože argumenty. O tahání se za nohu s dovolením nemám zájem :)
Relace je relací ekvivalence právě když je reflexivní, symetrická a tranzitivní.
Tak jest. A podle této definice operátor ekvivalence v JS není ekvivalence. Což je překvapující, jak již řečeno.
Jenže zároveň je to binární relace na stejné množině.
Jako třeba na množině "libovolná hodnota v JS"? (nicméně pořád nechápu, kam tím míříte)
Pokud to stále nechápete, tak doporučuju navštívit 1. ročník každé slušné VŠ.
Děkuji za doporučení, to jsem už učinil před mnoha lety :)
-
Řekl jsem, že ekvivalence nemá být tranzitivní?! Možná se naučte číst, tím by bylo nejlepší začít.
Já kritizuju, že == v JS tranzitivní není (a to ještě strašně překombinovaným způsobem), což je překvapivé/matoucí. A jelikož (příliš) překvapující jazyky se mi nelíbí, nelíbí se mi ani JS.
Pokud chcete s něčím z toho polemizovat, řekněte, s čím polemizujete, a předlože argumenty. O tahání se za nohu s dovolením nemám zájem :)
Kritizujete, že == není tranzitivní. Překvapivé to je, pokud JS neznáte. Kde je řečeno, že == má být tranzitivní? A váš pseudo argument s ekvivalencí je sice pěkný, ale == ekvivalencí být nemá.
Relace je relací ekvivalence právě když je reflexivní, symetrická a tranzitivní.
Tak jest. A podle této definice operátor ekvivalence v JS není ekvivalence. Což je překvapující, jak již řečeno.
Operátor ekvivalence, resp. toho, co jste chtěl, se v JS značí ===.
Jenže zároveň je to binární relace na stejné množině.
Jako třeba na množině "libovolná hodnota v JS"? (nicméně pořád nechápu, kam tím míříte)
Ne, jako třeba string, number, array... Teď už byste to chápat mohl.
Pokud to stále nechápete, tak doporučuju navštívit 1. ročník každé slušné VŠ.
Děkuji za doporučení, to jsem už učinil před mnoha lety :)
Tak teď ještě aby se to nějak projevilo. :)
#######################
Celý váš problém je, že kritizujete JS za to, že používáte špatné operátory, protože jinde se to značí jinak. Tedy klidně nadávejte na to, že je to značeno jinak, než byste si přál nebo čekal. Ale kritizovat, že A nedělá C a vy chcete, aby A dělalo C místo toho, abyste použil přímo C, je úchylné.
-
Jde to snadněji pomocí uzávěru. Ale pořád je to horší než first class generátory.
...a generatory jsou o rad horsi nez kontinuace.
Kontinuace je univerzálnější, ale taky abstraktnější (a někdy to je dost zmatek, stačí zkusit si pro kontinuaci napsat >>=). Nejlépe se tento typ kódu píše v CSP, je to triviální a univerzální.
CSP alebo CPS? Nemysleli ste CPS? Poviem vam, ze uz dost dlhu chvilu rozmyslam, ci ste naozaj nemysleli CSP (spominali sa tu kanaly a Go).
-
Kritizujete, že == není tranzitivní. Překvapivé to je, pokud JS neznáte.
Překvapivé je to proto, že 1) v každém rozumném jazyku tento operátor tranzitivní je 2) není žádný rozumný důvod, aby tranzitivní nebyl (tímto způsobem).
Ale nikde není řečeno, že == tranzitivní být má.
Tak jistě. Není ani nikde řečeno, že 1+1 má být 2. A pokud je někdo překvapený, že v JS je to 3, tak je to proto, že JS nezná. Protože + přece není sčítání. To se označuje *+*.
Čili, abychom to shrnuli, jestli má někdo problém s tím, že 1+1=3, je pitomec, nedouk a hipster.
A váš pseudo argument s ekvivalencí je sice pěkný, ale == ekvivalencí být nemá.
Na tom se zjevně neshodneme. Takže já si myslím, že == ekvivalencí být má a jazyky, kde jí není, s dovolením budu širokým obloukem obcházet stejně jako otevřený septik. Není radno do toho spadnout.
Ne, jako třeba string, number, array... Teď už byste to chápat mohl.
Ne, nemohl. Opravdu se mi snažíte říct, že pro stringy má být definován operátor (relace) ==s a pro number ==n ?
Tak teď ještě aby se to nějak projevilo. :)
Jo, projevilo - naučil jsem se nekonečné trpělivosti. I když vlastně teď nevím, jestli to nebylo díky manželství.
Celý váš problém je, že kritizujete JS za to, že používáte špatné operátory, protože jinde se to značí jinak. Tedy klidně nadávejte na to, že je to značeno jinak, než byste si přál nebo čekal. Ale kritizovat, že A nedělá C a vy chcete, aby A dělalo C místo toho, abyste použil přímo C, je úchylné.
S dovolením, jak říká klasik: budu si remcat, jak budu chtít.
A nechci, aby A bylo B. Chci aby ekvivalence byla ekvivalence. A popravdě řečeno, sledovat, jak javascriptař vysvětluje, že ekvivalence nemá být ekvivalence, je velmi zábavné, pojďme v tom pokračovat! :))
-
Jde to snadněji pomocí uzávěru. Ale pořád je to horší než first class generátory.
...a generatory jsou o rad horsi nez kontinuace.
Kontinuace je univerzálnější, ale taky abstraktnější (a někdy to je dost zmatek, stačí zkusit si pro kontinuaci napsat >>=). Nejlépe se tento typ kódu píše v CSP, je to triviální a univerzální.
CSP alebo CPS? Nemysleli ste CPS? Poviem vam, ze uz dost dlhu chvilu rozmyslam, ci ste naozaj nemysleli CSP (spominali sa tu kanaly a Go).
Myslel jsem CSP. CPS mi v tomto případě nepřijde úplně ideální.
-
Ahhhh, moje chyba, myslel jsem, ze komunikuji pres sockety.
"posilaj si mezi sebou async zpravy" samo o sobe nerika nic. Muze to byt paradni vec jako v Erlangu a muze to byt zoufalost jako radobyparalelismus v Rku nebo v pythonnim multiprocessing, ktery jenom zoufale obchazi GIL.
However, in the case of multi-threaded implementations, many browsers implement a structured cloning algorithm to copy the message into the receiving thread’s context (http://nickwritesablog.com/the-state-of-concurrent-javascript/#webworkersapi)
JS runtime musi predavane objekty serializovat a deserializovat. Je s tym spojeny overhead a nedokaze passnut referenciu na priamo.
Takže to je efektivně nepoužitelné...
-
A timhle kodem jsi chtel demonstrovat co? Chtel jsem videt ten kod generatoru, co jde v Pythonu napsat lip nez v Go.
g = (i*i for i in range(100))
-
g = (i*i for i in range(100))
No, to je jeden konkrétní případ syntaktického cukru, omezený jenom na výrazy, což je v Pythonu relativně málo co. Myslel jsem, že se bavíme o obecném generátoru, tak sofistikovaném, aby tam člověk mohl dát aspoň if ;)
Takže abysme se vrátili ke kořenům,
Já zde netvrdím, že je JS dokonalý jazyk, ale vám na jednu stranu vadí maličkosti v JS a na druhou stranu obhajujete Go, kde vám různé speciální případy a nedokonalosti jazyka skutečně komplikují život.
- fakt, že v Go se takhle jednoduchý generátor nedá (?) napsat stručně, má být příklad "speciálního případu", nebo nedokonalosti jazyka, která "skutečně komplikuje život"? :)
-
aby tam člověk mohl dát aspoň if ;)
Jo, pardon, na if vlastně taky existuje speciální syntaktický cukr.
-
aby tam člověk mohl dát aspoň if ;)
Jo, pardon, na if vlastně taky existuje speciální syntaktický cukr.
co podle vás není syntaktický cukr?
-
co podle vás není syntaktický cukr?
Třeba žirafa.
-
g = (i*i for i in range(100))
- fakt, že v Go se takhle jednoduchý generátor nedá (?) napsat stručně [...]
On Go nezná, jen se hádá z principu.
Je toto dostatečně jednoduché?
g := gen(0, 100, func(i int) int { return i * i })
-
g = (i*i for i in range(100))
No, to je jeden konkrétní případ syntaktického cukru, omezený jenom na výrazy, což je v Pythonu relativně málo co. Myslel jsem, že se bavíme o obecném generátoru, tak sofistikovaném, aby tam člověk mohl dát aspoň if ;)
obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.
-
Kritizujete, že == není tranzitivní. Překvapivé to je, pokud JS neznáte.
Překvapivé je to proto, že 1) v každém rozumném jazyku tento operátor tranzitivní je 2) není žádný rozumný důvod, aby tranzitivní nebyl (tímto způsobem).
V JS je ten operátor trošku něco jiného, než v jiných jazycích, takže opět mimo mísu.
Ale nikde není řečeno, že == tranzitivní být má.
Tak jistě. Není ani nikde řečeno, že 1+1 má být 2. A pokud je někdo překvapený, že v JS je to 3, tak je to proto, že JS nezná. Protože + přece není sčítání. To se označuje *+*.
Čili, abychom to shrnuli, jestli má někdo problém s tím, že 1+1=3, je pitomec, nedouk a hipster.
Tak ještě jednou. 1+1 je operace nad stejným datovým typem a to, co kritizujete, je chování při porovnávání různých datových typů.
Vy si stěžujete, že 1+"1" není 2, ale absolutně popíráte fakt, že jestli děláte takový prasárny, tak byste se neměl snažit programovat.
A váš pseudo argument s ekvivalencí je sice pěkný, ale == ekvivalencí být nemá.
Na tom se zjevně neshodneme. Takže já si myslím, že == ekvivalencí být má a jazyky, kde jí není, s dovolením budu širokým obloukem obcházet stejně jako otevřený septik. Není radno do toho spadnout.
To je ale vaše ignoranství a ne problém těch jazyků.
Ne, jako třeba string, number, array... Teď už byste to chápat mohl.
Ne, nemohl. Opravdu se mi snažíte říct, že pro stringy má být definován operátor (relace) ==s a pro number ==n ?
Ne, snažím se vám vysvětlit, že plácáte páté přes deváté. Neúspěšně.
Tak teď ještě aby se to nějak projevilo. :)
Jo, projevilo - naučil jsem se nekonečné trpělivosti. I když vlastně teď nevím, jestli to nebylo díky manželství.
Tak si trpělivě přečtěte specifikaci jazyka, než začnete nadávat na něco, co neznáte.
Celý váš problém je, že kritizujete JS za to, že používáte špatné operátory, protože jinde se to značí jinak. Tedy klidně nadávejte na to, že je to značeno jinak, než byste si přál nebo čekal. Ale kritizovat, že A nedělá C a vy chcete, aby A dělalo C místo toho, abyste použil přímo C, je úchylné.
S dovolením, jak říká klasik: budu si remcat, jak budu chtít.
A nechci, aby A bylo B. Chci aby ekvivalence byla ekvivalence. A popravdě řečeno, sledovat, jak javascriptař vysvětluje, že ekvivalence nemá být ekvivalence, je velmi zábavné, pojďme v tom pokračovat! :))
Ekvivalence je ekvivalence a značí se takto ===. Pokud nechcete používat JS, protože to jedno = je pro vás moc komplikovaný myšlenkový pochod, tak prosím. Ale není to chyba jazyka, ale spíš vaše neschopnost.
== ekvivalencí není a nikde není řečeno, že by měla. Nebo v céčku si taky stěžujete, že řetězce nemůžete porovnávat pomocí ==?? (Perl to má taky jinak, Pascal taky, ....).
-
V JS je ten operátor trošku něco jiného, než v jiných jazycích, takže opět mimo mísu.
Jistě. A úplně stejně "legitimně" by "něco jiného" mohl být operátor +. Proč ne?
Tak ještě jednou. 1+1 je operace nad stejným datovým typem a to, co kritizujete, je chování při porovnávání různých datových typů.
To je naprosto irelevantní. V rozumných jazycích je ekvivalence ekvivalence, tj. je tranzitivní na celé množině, na které je definovaná. Nechápu, proč se tak zarputile snažíte obhájit neobhajitelné. Nestačilo by místo těch urážek a vymýšlení nesmyslných rádobyobhajob říct prostě "jo, tohle je sprasený, ale dá se s tím žít"?
Vy si stěžujete, že 1+"1" není 2, ale absolutně popíráte fakt, že jestli děláte takový prasárny, tak byste se neměl snažit programovat.
Porovnání dvou hodnot různého typu není žádná prasárna. Zvlášt v dynamickém jazyce. Když funkce dostane dva parametry (neví jaké), tak je prasárna je porovnat?!
To je ale vaše ignoranství a ne problém těch jazyků.
Ignorantství je, když něco nevím. Ne když něco vím a kritizuju to.
Ne, snažím se vám vysvětlit, že plácáte páté přes deváté. Neúspěšně.
Nesnažíte se nic vysvětlit. Snažíte se obhájit neobhajitelné pomocí matení pojmů (v lepším případě) nebo neznalosti pojmu "relace" (v horším případě). Relace je definovaná na nějaké množině. Pro operátor == je tou množinou množina všech hodnot daného jazyka. Neexistuje žádný speciální operátor pro porovnání stringů a speciální pro porovnání čísel.
A pokud má být == použitelný, musí být tranzitivní na celé této množině. Tranzitivita na podmnožině je k ničemu a vůbec nemá smysl o ní mluvit.
Tak si trpělivě přečtěte specifikaci jazyka, než začnete nadávat na něco, co neznáte.
To jsem právě udělal už udělal a pocítil silnou nevolnost.
Každý může posoudit sám, jaký matroš musí člověk brát aby s vážnou tváří napsal tohle: http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3
Ekvivalence je ekvivalence a značí se takto ===. Pokud nechcete používat JS, protože to jedno = je pro vás moc komplikovaný myšlenkový pochod, tak prosím. Ale není to chyba jazyka, ale spíš vaše neschopnost.
== ekvivalencí není a nikde není řečeno, že by měla. Nebo v céčku si taky stěžujete, že řetězce nemůžete porovnávat pomocí ==?? (Perl to má taky jinak, Pascal taky, ....).
Plus je plus a značí se takto *+*. Pokud nechcete používat JS, protože ty dvě * je pro vás moc komplikovaný myšlenkový pochod, tak prosím. Ale není to chyba jazyka, ale spíš vaše neschopnost.
+ plusem není a nikde není řečeno, že by mělo. Nebo v céčku si taky stěžujete, že řetězce nemůžete porovnávat pomocí ==??
-
obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.
Píší se bez yield naprosto v pohodě, pokud mám k dispozici channely, které fungují prakticky stejně jako yield. Navíc oproti yield se práce s channelem dá snadněji paralelizovat. Pokud bych si měl vybrat mezi yield a channelem, určitě bych volil channel.
-
obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.
Píší se bez yield naprosto v pohodě, pokud mám k dispozici channely, které fungují prakticky stejně jako yield. Navíc oproti yield se práce s channelem dá snadněji paralelizovat. Pokud bych si měl vybrat mezi yield a channelem, určitě bych volil channel.
Paralelní generátory jsou IMHO nanic. Jdou psát i v pythonu.
Tento generáror
func generateRandomNumbers (n int) {
ch := make (chan float)
sem := make (semaphore, n)
for i := 0; i < n; i++ {
go func () {
ch <- rand.Float()
close(ch)
} ()
}
// launch extra goroutine to eventually close ch
go func () {
sem.Wait(n)
close(ch)
}
return ch
}
vypadá v pythonu takto:
@parallel
def rand():
while True:
yield random()
použitím takového wrapperu:
from multiprocessing import Process, Queue
from multiprocessing.queues import Empty
from random import random
import itertools
import functools
def run_parallel(gen, *args, **kwargs):
def task_wrapper(q, gen, *args, **kwargs):
for val in gen(*args, **kwargs):
q.put(val)
q.close()
try:
q = Queue(5)
p = Process(
target=task_wrapper, args=(q, gen) + args, kwargs=kwargs)
p.start()
while True:
yield q.get(timeout=1)
except Empty:
pass
finally:
p.terminate()
def parallel(gen):
@functools.wraps(gen)
def wrapper(*args, **kwargs):
yield from run_parallel(gen, *args, **kwargs)
return wrapper
mohu wrapovat i vestavěné funkce:
pmap = parallel(map)
pislice = parallel(itertools.islice)
pislice(pmap(str, rand())) # "pipe" běžící ve třech procesech
takovou abstrakci Go moc nezvládá. Neručím, že je to správně, je to napsané narychlo a nechci se tím zbytečným problémem více zabývat.
Mnohem užitečnější mohou být asynchronní generátory. To je novinka v Pythonu 3.6.
https://www.python.org/dev/peps/pep-0525/
-
Ne, snažím se vám vysvětlit, že plácáte páté přes deváté. Neúspěšně.
Nesnažíte se nic vysvětlit. Snažíte se obhájit neobhajitelné pomocí matení pojmů (v lepším případě) nebo neznalosti pojmu "relace" (v horším případě). Relace je definovaná na nějaké množině. Pro operátor == je tou množinou množina všech hodnot daného jazyka. Neexistuje žádný speciální operátor pro porovnání stringů a speciální pro porovnání čísel.
A pokud má být == použitelný, musí být tranzitivní na celé této množině. Tranzitivita na podmnožině je k ničemu a vůbec nemá smysl o ní mluvit.
Zkusím to naposledy. Zjednodušeně. Krátce.
Jenže ta "množina všech hodnot daného jazyka" *vznikne* tak, že se je == snaží přetypovat na stejný typ.
Může být v relaci ekvivalence (===) 1 a "1"? Ne, není to stejná množina (datový typ).
Ale můžete použít ==, které to implicitně přetypuje předtím, než to porovná.
------------
Dál už se s vámi odmítám hádat. Mám na práci důležitější věci, než čtení argumentů "v jiných jazycích je to tak, tak to tak chci i tady!".
-
obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.
Píší se bez yield naprosto v pohodě, pokud mám k dispozici channely, které fungují prakticky stejně jako yield. Navíc oproti yield se práce s channelem dá snadněji paralelizovat. Pokud bych si měl vybrat mezi yield a channelem, určitě bych volil channel.
Paralelní generátory jsou IMHO nanic. Jdou psát i v pythonu.
Tento generáror
func generateRandomNumbers (n int) {
ch := make (chan float)
sem := make (semaphore, n)
for i := 0; i < n; i++ {
go func () {
ch <- rand.Float()
close(ch)
} ()
}
// launch extra goroutine to eventually close ch
go func () {
sem.Wait(n)
close(ch)
}
return ch
}
Kterej osel to psal? Ani se to nepřeloží, a i kdyby, je to plné sémantických chyb.
-
obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.
Píší se bez yield naprosto v pohodě, pokud mám k dispozici channely, které fungují prakticky stejně jako yield. Navíc oproti yield se práce s channelem dá snadněji paralelizovat. Pokud bych si měl vybrat mezi yield a channelem, určitě bych volil channel.
Paralelní generátory jsou IMHO nanic. Jdou psát i v pythonu.
Tento generáror
func generateRandomNumbers (n int) {
ch := make (chan float)
sem := make (semaphore, n)
for i := 0; i < n; i++ {
go func () {
ch <- rand.Float()
close(ch)
} ()
}
// launch extra goroutine to eventually close ch
go func () {
sem.Wait(n)
close(ch)
}
return ch
}
Kterej osel to psal? Ani se to nepřeloží, a i kdyby, je to plné sémantických chyb.
http://www.golangpatterns.info/concurrency/generators
-
obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.
Píší se bez yield naprosto v pohodě, pokud mám k dispozici channely, které fungují prakticky stejně jako yield. Navíc oproti yield se práce s channelem dá snadněji paralelizovat. Pokud bych si měl vybrat mezi yield a channelem, určitě bych volil channel.
Paralelní generátory jsou IMHO nanic. Jdou psát i v pythonu.
Tento generáror
func generateRandomNumbers (n int) {
ch := make (chan float)
sem := make (semaphore, n)
for i := 0; i < n; i++ {
go func () {
ch <- rand.Float()
close(ch)
} ()
}
// launch extra goroutine to eventually close ch
go func () {
sem.Wait(n)
close(ch)
}
return ch
}
Kterej osel to psal? Ani se to nepřeloží, a i kdyby, je to plné sémantických chyb.
http://www.golangpatterns.info/concurrency/generators
Člověk musí být hodně mimo, aby podporoval svoje argumenty nefunkčním a neuvěřitelně debilním kódem, zvlášť když existuje playground. Fakt diskuse na úrovni.
-
Člověk musí být hodně mimo, aby podporoval svoje argumenty nefunkčním a neuvěřitelně debilním kódem, zvlášť když existuje playground. Fakt diskuse na úrovni.
napiš lepší.
-
Člověk musí být hodně mimo, aby podporoval svoje argumenty nefunkčním a neuvěřitelně debilním kódem, zvlášť když existuje playground. Fakt diskuse na úrovni.
napiš lepší.
Napiš si to sám, jsou to 3 řádky kódu. Když se to tentokrát aspoň přeloží, můžu ti pak říct, jestli to je dobrý kód nebo kravina.
-
Může být v relaci ekvivalence (===) 1 a "1"? Ne, není to stejná množina (datový typ).
Ale můžete použít ==, které to implicitně přetypuje předtím, než to porovná.
Aha, takže opravdu byl problém v tom, že máte zmatek v pojmu relace na množině.
Krátká odpověď: === je definováno správně, == je definováno špatně. Oba dva operátory jsou definovány pro libovolné typy. Tohle úplně stačí jako důkaz, že vaše argumentace je nesmyslná, typy tady vůbec nehrají roli.
Delší odpověď: aspoň neformálně:
1. To, že je relace R "definovaná na množině" M znamená něco podobného jako definiční obor funkce. Díky tomu vím, že jestliže relace nějaké dva prvky z M "spojuje", tak ty prvky "jsou v relaci", něco pro ně platí, zatímco když v relaci nejsou (a jsou z M), tak to pro ně neplatí, a pokud něco není z M, tak o tom prostě R nic neříká. Například relace "být celočíselně dělitelný" je definovaná třeba pro celá čísla a neříká nic o vztahu mezi prvky množiny savců (netvrdí, že žirafa je dělitelná hrochem, ani že jím dělitelná není, prostě vztah "být dělitelný" nedává pro savce smysl, není pro ně rozumně definovatelný).
2. Relaci nazýváme ekvivalencí právě když je reflexivní, symetrická a tranzitivní. Z toho pak plynou různé praktické důsledky. Například to, že existuje jednoznačný rozklad množiny pomocí relace RE na "třídy ekvivalence" - tj. každému prvku z množiny M (tady vidíme, jak je M důležitá - nemluvíme o hroších, ale o prvcích z M) můžeme jednoznačně přířadit "třídu" - tj. podmnožinu M.
Abysme si znovu ověřili, že o typy vůbec nejde: můžu mít relaci isSameType(x,y), která spojuje hodnoty stejného typu - tj. rozděluje množinu všech hodnot daného jazyka na podmnožiny podle jejich typu. V jedné třídě rozkladu podle takové ekvivalence jsou pak integery, v jiné stringy.
3. Ano, skutečně 1 a "1" můžou být v relaci i když ta relace je ekvivalencí. Triviálně např relace implementovaná funkcí
function isAnything(x) { return true; }
QED. Tahle funkce sice neimplementuje "operátor ekvivalence" (programátorštinou), ale je to "ekvivalence" (matematicky). Chtít po operátoru ekvivalence, aby byl ekvivalencí, je velmi rozumný požadavek. Viz 2
SHRNUTO: 1. operátor ekvivalence je možné definovat nad různými typy a pořád to může být ekvivalence v matematickém smyslu (důkazem je ===). 2. pokud relace ekvivalencí není, ztrácím různé jistoty, nemůžu o ní tvrdit to, co bych mohl, kdyby ekvivalencí byla. 3. Čili bych měl mít setsakramentsky dobrý důvod, proč se o tyto jistoty připravit. Neměl bych je zahodit (a programátora uvést ve zmatek) jenom proto, aby mohli lidi v mém jazyce patlat páte přes deváte a nedejmatkopřírodo jim to nevyhodilo runtime error.
-
tj. každému prvku z množiny M (tady vidíme, jak je M důležitá - nemluvíme o hroších, ale o prvcích z M) můžeme jednoznačně přířadit "třídu" - tj. podmnožinu M.
Pokud je tohle potřeba opravdu polopaticky "programátorsky", tak: pokud je relace ekvivalencí, tak vím přesně, kolik má M tříd rozkladu a každou třídu můžu reprezentovat jedním prvkem. Když mám skutečnou ekvivalenci (s N třídami rozkladu), tak pak můžu třeba všechny hodnoty z M (klidně všechny hodnoty daného jazyka) roztřídit do N podmnožin jenom pomocí toho, že každou podmnožinu reprezentuju jedním prvkem a x, které chci zařadit, s každým z N "reprezentantů" porovnám. Díky tomu, že je relace ekvivalencí, vím jenom na základě těhle N porovnání, že prvek "si bude rovný" se všemi ostatními prvky v podmnožině. Už ho s nimi nemusím porovnávat.
U == z JS tohle udělat nejde, protože nevím, jestli 1 patří mezi "jedničky", protože 1==1 nebo mezi "stringy 1", protože 1=='1'.
-
Může být v relaci ekvivalence (===) 1 a "1"? Ne, není to stejná množina (datový typ).
Ale můžete použít ==, které to implicitně přetypuje předtím, než to porovná.
Aha, takže opravdu byl problém v tom, že máte zmatek v pojmu relace na množině.
Krátká odpověď: === je definováno správně, == je definováno špatně. Oba dva operátory jsou definovány pro libovolné typy. Tohle úplně stačí jako důkaz, že vaše argumentace je nesmyslná, typy tady vůbec nehrají roli.
Delší odpověď: aspoň neformálně:
1. To, že je relace R "definovaná na množině" M znamená něco podobného jako definiční obor funkce. Díky tomu vím, že jestliže relace nějaké dva prvky z M "spojuje", tak ty prvky "jsou v relaci", něco pro ně platí, zatímco když v relaci nejsou (a jsou z M), tak to pro ně neplatí, a pokud něco není z M, tak o tom prostě R nic neříká. Například relace "být celočíselně dělitelný" je definovaná třeba pro celá čísla a neříká nic o vztahu mezi prvky množiny savců (netvrdí, že žirafa je dělitelná hrochem, ani že jím dělitelná není, prostě vztah "být dělitelný" nedává pro savce smysl, není pro ně rozumně definovatelný).
2. Relaci nazýváme ekvivalencí právě když je reflexivní, symetrická a tranzitivní. Z toho pak plynou různé praktické důsledky. Například to, že existuje jednoznačný rozklad množiny pomocí relace RE na "třídy ekvivalence" - tj. každému prvku z množiny M (tady vidíme, jak je M důležitá - nemluvíme o hroších, ale o prvcích z M) můžeme jednoznačně přířadit "třídu" - tj. podmnožinu M.
Abysme si znovu ověřili, že o typy vůbec nejde: můžu mít relaci isSameType(x,y), která spojuje hodnoty stejného typu - tj. rozděluje množinu všech hodnot daného jazyka na podmnožiny podle jejich typu. V jedné třídě rozkladu podle takové ekvivalence jsou pak integery, v jiné stringy.
3. Ano, skutečně 1 a "1" můžou být v relaci i když ta relace je ekvivalencí. Triviálně např relace implementovaná funkcí
function isAnything(x) { return true; }
QED. Tahle funkce sice neimplementuje "operátor ekvivalence" (programátorštinou), ale je to "ekvivalence" (matematicky). Chtít po operátoru ekvivalence, aby byl ekvivalencí, je velmi rozumný požadavek. Viz 2
SHRNUTO: 1. operátor ekvivalence je možné definovat nad různými typy a pořád to může být ekvivalence v matematickém smyslu (důkazem je ===). 2. pokud relace ekvivalencí není, ztrácím různé jistoty, nemůžu o ní tvrdit to, co bych mohl, kdyby ekvivalencí byla. 3. Čili bych měl mít setsakramentsky dobrý důvod, proč se o tyto jistoty připravit. Neměl bych je zahodit (a programátora uvést ve zmatek) jenom proto, aby mohli lidi v mém jazyce patlat páte přes deváte a nedejmatkopřírodo jim to nevyhodilo runtime error.
Opravdu nepotřebuju oprašovat znalosti relací.
Shrnuto: Takže jste vlastně řekl to, co tvrdím celou dobu. === je ekvivalencí, == ekvivalencí není, tudíž je nesmyslné chtít, aby == ekvivalencí bylo a máte použít ===.
-
A: == ekvivalencí není [=>] B: je nesmyslné chtít, aby == ekvivalencí bylo
Jak z A plyne B?
-
Může být v relaci ekvivalence (===) 1 a "1"? Ne, není to stejná množina (datový typ).
Ale můžete použít ==, které to implicitně přetypuje předtím, než to porovná.
Aha, takže opravdu byl problém v tom, že máte zmatek v pojmu relace na množině.
Krátká odpověď: === je definováno správně, == je definováno špatně. Oba dva operátory jsou definovány pro libovolné typy. Tohle úplně stačí jako důkaz, že vaše argumentace je nesmyslná, typy tady vůbec nehrají roli.
.....
Proboha, vždyť cikáda už dávno psal že
Kritizujete, že == není tranzitivní. Překvapivé to je, pokud JS neznáte. Kde je řečeno, že == má být tranzitivní? A váš pseudo argument s ekvivalencí je sice pěkný, ale == ekvivalencí být nemá.
...
Operátor ekvivalence, resp. toho, co jste chtěl, se v JS značí ===.
Tak nevím proč tu dalekosáhle vysvětluješ, že operátor == (který není ekvivalence), nemá vlastnosti ekvivalence.
Tím nechci obhajovat JS, ale tahle debata byla fakt zbytečná.
-
Tak nevím proč tu dalekosáhle vysvětluješ, že operátor == (který není ekvivalence), nemá vlastnosti ekvivalence.
Ne. Vysvětluju, že mít vlastnosti ekvivalence je velmi důležité a jenom tak pro prd je zahodit je příklad jedné z milionu zpraseností JS.
Tím nechci obhajovat JS, ale tahle debata byla fakt zbytečná.
Ne. Pro mě je hodně poučné vidět, do jakých absurdit je někdo schopný se dostat jenom aby nemusel:
Nestačilo by místo těch urážek a vymýšlení nesmyslných rádobyobhajob říct prostě "jo, tohle je sprasený, ale dá se s tím žít"?
...čímž by ta zbytečná debata okamžitě skončila a neřekl bych už ani popel.
-
@ava - děkuju
Tak nevím proč tu dalekosáhle vysvětluješ, že operátor == (který není ekvivalence), nemá vlastnosti ekvivalence.
Ne. Vysvětluju, že mít vlastnosti ekvivalence je velmi důležité a jenom tak pro prd je zahodit je příklad jedné z milionu zpraseností JS.
Tím nechci obhajovat JS, ale tahle debata byla fakt zbytečná.
Ne. Pro mě je hodně poučné vidět, do jakých absurdit je někdo schopný se dostat jenom aby nemusel:
Nestačilo by místo těch urážek a vymýšlení nesmyslných rádobyobhajob říct prostě "jo, tohle je sprasený, ale dá se s tím žít"?
...čímž by ta zbytečná debata okamžitě skončila a neřekl bych už ani popel.
Chci-li vlastnosti ekvivalence, tak nebudu ignorant a použiji ===. Dál už je diskuse opravdu zbytečná.
Hezký den :)
-
Chci-li vlastnosti ekvivalence, tak nebudu ignorant a použiji ===. Dál už je diskuse opravdu zbytečná.
Já tomu asi nerozumím - argument je, že JS je stupidní jazyk, protože (a je to jeden příklad z mnoha) '==' není ekvivalence, zatímco v drtivé většině jazyků je. Takže je to neintuitivní a nestandardní a není pro to rozumný důvod. Dá se to brát jako jeden z historických hříchů, ale nějak nechápu logiku za tím tvářit se, že tohle není negativum toho jazyka, protože to programátor má vědět.
-
Chci-li vlastnosti ekvivalence, tak nebudu ignorant a použiji ===.
Jasný. A pokud chci testovat objekt na null, tak použiju !!, protože všude jinde normální if (object) taky nefunguje.
A pokud chci ... tak musím ... . Ale je potřeba vědět, že ... a ... . Pochopitelně jenom v případě že ... . Což ví všichni, kdo nejsou ignoranti.
Fakt je to tak těžký, přiznat si "jo, je to dost zmršenej jazyk, ale i tak ho mám rád"? Co je na tom špatnýho, vyloučili by tě ze sekty?
-
Chci-li vlastnosti ekvivalence, tak nebudu ignorant a použiji ===.
Jasný. A pokud chci testovat objekt na null, tak použiju !!, protože všude jinde normální if (object) taky nefunguje.
A pokud chci ... tak musím ... . Ale je potřeba vědět, že ... a ... . Pochopitelně jenom v případě že ... . Což ví všichni, kdo nejsou ignoranti.
Fakt je to tak těžký, přiznat si "jo, je to dost zmršenej jazyk, ale i tak ho mám rád"? Co je na tom špatnýho, vyloučili by tě ze sekty?
Třeba mě se JS mimořádně nelíbí, definici relace == považuju za pitomou, rozhodnutí pojmenovat normální ekvivalenci === taky za pitomý, ale tak prostě se tak v JS rozhodli, a nedává mi moc smysl nadávat že == se nechová jako ekvivalence, když ekvivalence se v JS jmenuje ===.
-
Chci-li vlastnosti ekvivalence, tak nebudu ignorant a použiji ===.
Jasný. A pokud chci testovat objekt na null, tak použiju !!, protože všude jinde normální if (object) taky nefunguje.
A pokud chci ... tak musím ... . Ale je potřeba vědět, že ... a ... . Pochopitelně jenom v případě že ... . Což ví všichni, kdo nejsou ignoranti.
Fakt je to tak těžký, přiznat si "jo, je to dost zmršenej jazyk, ale i tak ho mám rád"? Co je na tom špatnýho, vyloučili by tě ze sekty?
Třeba mě se JS mimořádně nelíbí, definici relace == považuju za pitomou, rozhodnutí pojmenovat normální ekvivalenci === taky za pitomý, ale tak prostě se tak v JS rozhodli, a nedává mi moc smysl nadávat že == se nechová jako ekvivalence, když ekvivalence se v JS jmenuje ===.
Tak nějak, nemá smysl to řešit, stejně jako proč v asm po cmp %rax, %rbx pak jl skočí, když rbx<rax.
-
Třeba mě se JS mimořádně nelíbí, definici relace == považuju za pitomou, rozhodnutí pojmenovat normální ekvivalenci === taky za pitomý, ale tak prostě se tak v JS rozhodli, a nedává mi moc smysl nadávat že == se nechová jako ekvivalence, když ekvivalence se v JS jmenuje ===.
Pokud se jasne pojmenuje, co jsou blbosti, proc jsou blbe a jak by pripadne mely byt lip, tak s tim nemam sebemensi problem. Pokud to nekdo chce pouzivat je to jeho volba. Ale nemelo by se to vydavat za normalni a mrsit cely generace programatoru, ktery pak povazuji kravoviny za dobry reseni (viz treba i ty zmineny Workery... proste kam se v JS podivas, tam je nejhorsi mozny reseni z dostupnych. Snad jenom tu prototypovou orientaci chytli dobre. Mit to jeste nejaky dojebany OOP, tak uz by to bylo uplne na maslu ;) )
-
Pokud se jasne pojmenuje, co jsou blbosti, proc jsou blbe a jak by pripadne mely byt lip, tak s tim nemam sebemensi problem. Pokud to nekdo chce pouzivat je to jeho volba. Ale nemelo by se to vydavat za normalni a mrsit cely generace programatoru, ktery pak povazuji kravoviny za dobry reseni (viz treba i ty zmineny Workery... proste kam se v JS podivas, tam je nejhorsi mozny reseni z dostupnych. Snad jenom tu prototypovou orientaci chytli dobre. Mit to jeste nejaky dojebany OOP, tak uz by to bylo uplne na maslu ;) )
Já myslel, že už je to dávno pojmenované. Není potřeba objevovat kolo...
https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742
Některé blbosti pojmenovala přímo norma, viz třeba "use strict".
-
Já myslel, že už je to dávno pojmenované. Není potřeba objevovat kolo...
https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742
Není potřeba ho objevovat, je potřeba otevřeně přiznat, že existuje, a nemást nové programátory.
The lack of transitivity is alarming. My advice is to never use the evil twins. Instead, always use === and !==.
[z oné knihy]
-
...Snad jenom tu prototypovou orientaci chytli dobre...
Si děláte zadek, žejo?
-
Si děláte zadek, žejo?
Proc? Mne se OOP a pseudo-OOP bez trid a bez dedicnosti libi vic nez OOP ve stylu C++ nebo Javy. Jednodussi, snadno pochopitelne pseudo-OOP ala JavaScript nebo Lua je mi docela sympaticke.
Jeste lepsi nez prototypy jsou imho protokoly/interfaces/... (kazdy jazyk to nazyva jinak, proste "mnoziny operaci pro danou datovou strukturu"). Tohle ma hodne hezkych jazyku - Go, Rust, Elixir, Haskell ma to same jeste mozna o kousek lepsi (TypeClasses). Ale tak zas od JavaScriptu clovek nemuze chtit moc :)
-
Si děláte zadek, žejo?
Proc? Mne se OOP a pseudo-OOP bez trid a bez dedicnosti libi vic nez OOP ve stylu C++ nebo Javy. Jednodussi, snadno pochopitelne pseudo-OOP ala JavaScript nebo Lua je mi docela sympaticke.
Jeste lepsi nez prototypy jsou imho protokoly/interfaces/... (kazdy jazyk to nazyva jinak, proste "mnoziny operaci pro danou datovou strukturu"). Tohle ma hodne hezkych jazyku - Go, Rust, Elixir, Haskell ma to same jeste mozna o kousek lepsi (TypeClasses). Ale tak zas od JavaScriptu clovek nemuze chtit moc :)
Třebaže je JS OOP tak super, zavádí se v ES6 vcelku normální podpora tříd.
-
Třebaže je JS OOP tak super, zavádí se v ES6 vcelku normální podpora tříd.
Nerekl jsem ze je super. Jenom ze jednoduchej princip "mas mnozinu pojmenovanych funkci a kdyz se metoda nenajde tady, vyhleda se automaticky jinde" je v pohode, jednoduchy, snadno pochopitelny. Lepsi nez kdyby si vymysleli zas nejakou ujetou implementaci OOP, ktera by byla prekombinovana a pritom nesplnovala zakladni pozadavky podobne jako to dojebany == :)
Viz https://www.lua.org/pil/16.html - proc ne?
-
Si děláte zadek, žejo?
Proc? Mne se OOP a pseudo-OOP bez trid a bez dedicnosti libi vic nez OOP ve stylu C++ nebo Javy. Jednodussi, snadno pochopitelne pseudo-OOP ala JavaScript nebo Lua je mi docela sympaticke.
Jeste lepsi nez prototypy jsou imho protokoly/interfaces/... (kazdy jazyk to nazyva jinak, proste "mnoziny operaci pro danou datovou strukturu"). Tohle ma hodne hezkych jazyku - Go, Rust, Elixir, Haskell ma to same jeste mozna o kousek lepsi (TypeClasses). Ale tak zas od JavaScriptu clovek nemuze chtit moc :)
Třebaže je JS OOP tak super, zavádí se v ES6 vcelku normální podpora tříd.
To je jen syntaxe navíc, možnosti původního OOP nijak neomezuje. Vše zůstává dynamické.
-
Každý může posoudit sám, jaký matroš musí člověk brát aby s vážnou tváří napsal tohle: http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3
:O Tak vědel, jsem, že... ale tohle jsem nečekal... Tady skoro nic nedává smysl.
Mimochodem v Nodejs:
> new Boolean(true) == new Boolean(true)
false
Nemám slov.
-
Si děláte pr-del, žejo?
Proc? Mne se OOP a pseudo-OOP bez trid a bez dedicnosti libi vic nez OOP ve stylu C++ nebo Javy. Jednodussi, snadno pochopitelne pseudo-OOP ala JavaScript nebo Lua je mi docela sympaticke.
Proti prototypování nic nemám, ale provedení z JS jsem přestal považovat za povedené od doby, co jsem to 1. zkusil použít, 2. viděl implementaci v Selfu.
Jeste lepsi nez prototypy jsou imho protokoly/interfaces/... (kazdy jazyk to nazyva jinak, proste "mnoziny operaci pro danou datovou strukturu"). Tohle ma hodne hezkych jazyku - Go, Rust, Elixir, Haskell ma to same jeste mozna o kousek lepsi (TypeClasses). Ale tak zas od JavaScriptu clovek nemuze chtit moc :)
Protokoly a interfaces z podstaty neobsahují implementaci, pravděpodobně máte na mysli "interfaces" s implementací, což jsou vlastně ojebané traits/mixins. O tom tu už řeč šla, to není třeba znovu protřepávat.
-
Protokoly a interfaces z podstaty neobsahují implementaci, pravděpodobně máte na mysli "interfaces" s implementací, což jsou vlastně ojebané traits/mixins. O tom tu už řeč šla, to není třeba znovu protřepávat.
Ne, mám namysli protokoly z Elixiru a interfjsy z Go. Skládají se z definice a implementace. Že definice obsahuje implementaci jsem netvrdil.
-
...Chci-li vlastnosti ekvivalence, tak nebudu ignorant a použiji ===. Dál už je diskuse opravdu zbytečná.
Hezký den :)
Možná by se situace vyjasnila, kdyby se místo názvu "ekvivalence" operátoru === zde v diskusi používal název "identita".
-
Možná by se situace vyjasnila, kdyby se místo názvu "ekvivalence" operátoru === zde v diskusi používal název "identita".
To by situaci mohlo ještě zhoršit, protože pojem "identita" se obvykle používá pro funkci (x) -> x. Takže kdyz už, tak "testování identity".
Ale jinak jsi dobře trefil hřebíček, páč programovací jazyky, jejichž tvůrci neberou drogy, mají dva operátory - jeden testuje shodnost hodnot a druhý případně identitu. Tak to nejspíš v JS mysleli, akorát to totálně zprasili.
Ten první operátor by právě vracel
new Bool(true) == new Bool(true) -> true
-
Možná by se situace vyjasnila, kdyby se místo názvu "ekvivalence" operátoru === zde v diskusi používal název "identita".
To by situaci mohlo ještě zhoršit, protože pojem "identita" se obvykle používá pro funkci (x) -> x. Takže kdyz už, tak "testování identity".
Ale jinak jsi dobře trefil hřebíček, páč programovací jazyky, jejichž tvůrci neberou drogy, mají dva operátory - jeden testuje shodnost hodnot a druhý případně identitu. Tak to nejspíš v JS mysleli, akorát to totálně zprasili.
Ten první operátor by právě vracel
new Bool(true) == new Bool(true) -> true
Radši nezacházej moc daleko do identit, nebo na tebe vytáhnu Theseovu loď ;)
-
Protokoly a interfaces z podstaty neobsahují implementaci, pravděpodobně máte na mysli "interfaces" s implementací, což jsou vlastně ojebané traits/mixins. O tom tu už řeč šla, to není třeba znovu protřepávat.
Ne, mám namysli protokoly z Elixiru a interfjsy z Go. Skládají se z definice a implementace. Že definice obsahuje implementaci jsem netvrdil.
Pak jsou obdobou mixins nebo traits. Ale to už jsem psal.
-
...Ale jinak jsi dobře trefil hřebíček, páč programovací jazyky, jejichž tvůrci neberou drogy, mají dva operátory - jeden testuje shodnost hodnot a druhý případně identitu. Tak to nejspíš v JS mysleli, akorát to totálně zprasili.
Jinak jsem to ještě neviděl, např. Smalltalk to má taky tak (= a ==), kdy na "test identity" je kladen důraz pro jeho využití s jedináčky a test podobnosti je překrytelný. To je ale logické.
Ten první operátor by právě vracel
new Bool(true) == new Bool(true) -> true
V Nodejs nevrací. Ale už jsem to omrdal:
> !new Boolean(true) == !new Boolean(true)
true
Jako by vývojáři neměli dost jiné práce než hlídat jazyk...
-
...Ale jinak jsi dobře trefil hřebíček, páč programovací jazyky, jejichž tvůrci neberou drogy, mají dva operátory - jeden testuje shodnost hodnot a druhý případně identitu. Tak to nejspíš v JS mysleli, akorát to totálně zprasili.
Jinak jsem to ještě neviděl, např. Smalltalk to má taky tak (= a ==), kdy na "test identity" je kladen důraz pro jeho využití s jedináčky a test podobnosti je překrytelný. To je ale logické.
Ten první operátor by právě vracel
new Bool(true) == new Bool(true) -> true
V Nodejs nevrací. Ale už jsem to omrdal:
> !new Boolean(true) == !new Boolean(true)
true
Jako by vývojáři neměli dost jiné práce než hlídat jazyk...
Tady je někdo kreten.
Jazyk to nebude.
Víš, je rozdíl mezi false a new Boolean(false).
To první je unboxed primitive value a to druhé je boxed primtive value.
To boxed znamená že je to objekt s vlastním prototypem.
Což znamená že == a === porovnává reference nikoli primitivní hodnoty.
Když na boxed boolean aplikuješ negaci, vyjde ti vždycky false protože negace objektu je vždycky false (protože každý objekt mimo null je přetypovatelný na true).
!new Boolean(true) === !new Boolean(false)ti vyjde jako true.
A opět, neni to divnost jazyka, je to jenom kompletní ignorace se ho alespoň v mezích naučit.
TEČKA.
-
A opět, neni to divnost jazyka, je to jenom kompletní ignorace se ho alespoň v mezích naučit.
Pointa je v tom, že ne každý má čas a chuť se učit krávoviny, které nedávají žádný smysl.
-
Radši nezacházej moc daleko do identit, nebo na tebe vytáhnu Theseovu loď ;)
Klidně, to mi nedělá větší problémy. Víc by mě znechutilo, kdybys mi chtěl začít povídat o substanci a akcidentech ;)
-
...Ale jinak jsi dobře trefil hřebíček, páč programovací jazyky, jejichž tvůrci neberou drogy, mají dva operátory - jeden testuje shodnost hodnot a druhý případně identitu. Tak to nejspíš v JS mysleli, akorát to totálně zprasili.
Jinak jsem to ještě neviděl, např. Smalltalk to má taky tak (= a ==), kdy na "test identity" je kladen důraz pro jeho využití s jedináčky a test podobnosti je překrytelný. To je ale logické.
Ten první operátor by právě vracel
new Bool(true) == new Bool(true) -> true
V Nodejs nevrací. Ale už jsem to omrdal:
> !new Boolean(true) == !new Boolean(true)
true
Jako by vývojáři neměli dost jiné práce než hlídat jazyk...
Tady je někdo kreten.
Jazyk to nebude.
Víš, je rozdíl mezi false a new Boolean(false).
To první je unboxed primitive value a to druhé je boxed primtive value.
To boxed znamená že je to objekt s vlastním prototypem.
Což znamená že == a === porovnává reference nikoli primitivní hodnoty.
Když na boxed boolean aplikuješ negaci, vyjde ti vždycky false protože negace objektu je vždycky false (protože každý objekt mimo null je přetypovatelný na true).
!new Boolean(true) === !new Boolean(false)ti vyjde jako true.
A opět, neni to divnost jazyka, je to jenom kompletní ignorace se ho alespoň v mezích naučit.
TEČKA.
+1
A opět, neni to divnost jazyka, je to jenom kompletní ignorace se ho alespoň v mezích naučit.
Pointa je v tom, že ne každý má čas a chuť se učit krávoviny, které nedávají žádný smysl.
Nedávají (opět) smysl kvůli vaší neznalosti. ;) Fakt nechápu, že se někdo veřejně chlubí tím, že je blb. Protože pokud kritizuje něco, o čem očividně nemá ani páru, tak jinak nazvat nejde.
-
Nedávají (opět) smysl kvůli vaší neznalosti. ;)
Jasný.
Fakt nechápu, že se někdo veřejně chlubí tím, že je blb. Protože pokud kritizuje něco, o čem očividně nemá ani páru, tak jinak nazvat nejde.
Jistě. Kdo nechápe, že
(x == x) != (!x == !x)
je nade vší pochybnost blb.
-
(x == x) != (!x == !x)
je nade vší pochybnost blb.
Nejlepsi je, ze tyhle prasarny (a ano, vim, proc to tak asi je - unboxing boolu operatorem "not"), ale je to jasna prasarna) se budou ted decka ucit na skolach. Takze uz jim to bude pripadat normalni.
-
Nejlepsi je, ze tyhle prasarny (a ano, vim, proc to tak asi je - unboxing boolu operatorem "not"), ale je to jasna prasarna) se budou ted decka ucit na skolach. Takze uz jim to bude pripadat normalni.
Přesně. Jednu generaci programátorů zdegenerovalo C++, tak je na čase druhou zdegenerovat JavaScriptem.
-
(x == x) != (!x == !x)
je nade vší pochybnost blb.
pro kterou hodnotu tohle platí?
-
pro kterou hodnotu tohle platí?
Pokud to nevíš, neznáš JavaScript a tímpádem jsi blb!
-
(x == x) != (!x == !x)
je nade vší pochybnost blb.
Nejlepsi je, ze tyhle prasarny (a ano, vim, proc to tak asi je - unboxing boolu operatorem "not"), ale je to jasna prasarna) se budou ted decka ucit na skolach. Takze uz jim to bude pripadat normalni.
Not nic neunboxuje omg.
Boxed boolean je objekt dozadeke uz.
Jak mezi idiotama...
-
pro kterou hodnotu tohle platí?
Pokud to nevíš, neznáš JavaScript a tímpádem jsi blb!
Podle me jsi to nepochopil ty, == porovnává reference
proto
{} == {} // false
ale
var x = {};
x == x // true
-
(x == x) != (!x == !x)
je nade vší pochybnost blb.
pro kterou hodnotu tohle platí?
Pro boxed booleany treba.
Zdejsi garda nechce pochopit ze == se proste chova jinak nad objekty a jinak nad primitives.
-
Zdejsi garda nechce pochopit ze == se proste chova jinak nad objekty a jinak nad primitives.
Ty jsi takový blb, že ani nevíš, že se tak chová i ===?
Proč se vyjadřuješ o něčem, o čem nic nevíš?
-
Podle me jsi to nepochopil ty, == porovnává reference
A === porovnává identity.
Čili, jak každý ne-blb ví, platí to, co jsem napsal, pro oba :)
-
(x == x) != (!x == !x)
je nade vší pochybnost blb.
Nejlepsi je, ze tyhle prasarny (a ano, vim, proc to tak asi je - unboxing boolu operatorem "not"), ale je to jasna prasarna) se budou ted decka ucit na skolach. Takze uz jim to bude pripadat normalni.
Not nic neunboxuje omg.
Boxed boolean je objekt dozadeke uz.
Jak mezi idiotama...
Jasne, ze unboxuje. Z objektu udela primitivni typ s opacnou hodnotou. To je na tebe ale asi moc slozite pochopit, kdyz se to nepoda polopate, co?
-
Jasne, ze unboxuje. Z objektu udela primitivni typ s opacnou hodnotou. To je na tebe ale asi moc slozite pochopit, kdyz se to nepoda polopate, co?
negace objektu je false. Nic to neunboxuje.
-
negace objektu je false. Nic to neunboxuje.
Tak pořád ještě můžeme být rádi, že to není třeba 3, že :)
Je potřeba mít k životu optimistický přístup! :))
-
Podle me jsi to nepochopil ty, == porovnává reference
A === porovnává identity.
Čili, jak každý ne-blb ví, platí to, co jsem napsal, pro oba :)
ještě jednou. pro kterou hodnotu x tohle platí?
(x == x) != (!x == !x)
-
ještě jednou. pro kterou hodnotu x tohle platí?
Nepsal jsem, že x je hodnota. x je výraz.
-
Tady je někdo kreten.
Jazyk to nebude.
Víš, je rozdíl mezi false a new Boolean(false).
To první je unboxed primitive value a to druhé je boxed primtive value.
To boxed znamená že je to objekt s vlastním prototypem.
Což znamená že == a === porovnává reference nikoli primitivní hodnoty.
Když na boxed boolean aplikuješ negaci, vyjde ti vždycky false protože negace objektu je vždycky false (protože každý objekt mimo null je přetypovatelný na true).
!new Boolean(true) === !new Boolean(false)ti vyjde jako true.
A opět, neni to divnost jazyka, je to jenom kompletní ignorace se ho alespoň v mezích naučit.
TEČKA.
Máte recht, už jsem si to ověřil a je to tak - negace neprování nejprve unboxing (jak bych čekal, když se javaskriptaři tolik prsí transparentností boxingu/unboxingu), ale bere to přednostně jako onu "negaci" objektu. Moje nepozornost. Otázkou zůstává, zda je nutno takovýmto věcem věnovat energii. Asi to není jazyk pro mě.
Váš popis == a === nechápu, jejich funkčnost jsme tu rozebrali pár příspěvků zpět.
Je dobře, že se v JS dobře orientujete, protože nám můžete vysvětlit podstatu onoho výsledku
> new Boolean(true) == new Boolean(true)
false
A příště to zkuste slušněji.
-
Je dobře, že se v JS dobře orientujete, protože nám můžete vysvětlit podstatu onoho výsledku
> new Boolean(true) == new Boolean(true)
false
A příště to zkuste slušněji.
Porovnáváte reference dvou různých objektů. Je to stejná záludnost jako porovnávání stringů v Javě.
-
Not nic neunboxuje omg.
Boxed boolean je objekt dozadeke uz.
Jak mezi idiotama...
Že používají objektové jazyky objekty, bych pochopil, ale na co jsou jim primitiva (s následnou komplikací včetně "boxingu"), jsem ještě nepochopil.
-
Je dobře, že se v JS dobře orientujete, protože nám můžete vysvětlit podstatu onoho výsledku
> new Boolean(true) == new Boolean(true)
false
Porovnáváte reference dvou různých objektů. Je to stejná záludnost jako porovnávání stringů v Javě.
Měl jsem za to, že identity (reference) se srovnávají s ===, == je ekvivalence (obdoba), kterou má Boolean (logicky) překrytou. Opět mi něco ušlo?
-
Je dobře, že se v JS dobře orientujete, protože nám můžete vysvětlit podstatu onoho výsledku
> new Boolean(true) == new Boolean(true)
false
Porovnáváte reference dvou různých objektů. Je to stejná záludnost jako porovnávání stringů v Javě.
Měl jsem za to, že identity (reference) se srovnávají s ===, == je ekvivalence (obdoba), kterou má Boolean (logicky) překrytou. Opět mi něco ušlo?
== nejde překrýt. Kdyby to šlo, tak byste to považovali za magii a nadávali na to, protože je v módě kopnout si do javascriptu a skriptovacích jazyků obecně.
-
Je dobře, že se v JS dobře orientujete, protože nám můžete vysvětlit podstatu onoho výsledku
> new Boolean(true) == new Boolean(true)
false
Porovnáváte reference dvou různých objektů. Je to stejná záludnost jako porovnávání stringů v Javě.
Měl jsem za to, že identity (reference) se srovnávají s ===, == je ekvivalence (obdoba), kterou má Boolean (logicky) překrytou. Opět mi něco ušlo?
== nejde překrýt. Kdyby to šlo, tak byste to považovali za magii a nadávali na to, protože je v módě kopnout si do javascriptu a skriptovacích jazyků obecně.
Mno je to rekneme nestastne a ze to je podobne nestastne v Jave moc dobra omluva neni...
-
Mno je to rekneme nestastne a ze to je podobne nestastne v Jave moc dobra omluva neni...
V javě to ale afaik takhle nešťastné není, tam == porovnává identity, .equal(x) hodnoty (a dá se překrýt) a u obojího jsou dodržena (nebo mají být dodržena) pravidla relace ekvivalence, takže žádný problém není, ne?
Srovnání s == pro String v javě je dost mimo mísu imho.
-
Je dobře, že se v JS dobře orientujete, protože nám můžete vysvětlit podstatu onoho výsledku
> new Boolean(true) == new Boolean(true)
false
Porovnáváte reference dvou různých objektů. Je to stejná záludnost jako porovnávání stringů v Javě.
Měl jsem za to, že identity (reference) se srovnávají s ===, == je ekvivalence (obdoba), kterou má Boolean (logicky) překrytou. Opět mi něco ušlo?
== nejde překrýt. Kdyby to šlo, tak byste to považovali za magii a nadávali na to, protože je v módě kopnout si do javascriptu a skriptovacích jazyků obecně.
Mno je to rekneme nestastne a ze to je podobne nestastne v Jave moc dobra omluva neni...
https://www.w3schools.com/js/js_booleans.asp
tady se jasně píše, že se boolean objekt nemá používat.
používejte Boolean(val) bez new.
-
Jasne, ze unboxuje. Z objektu udela primitivni typ s opacnou hodnotou. To je na tebe ale asi moc slozite pochopit, kdyz se to nepoda polopate, co?
negace objektu je false. Nic to neunboxuje.
OK, uznavam chybu. Je to tak.
-
tady se jasně píše, že se boolean objekt nemá používat.
...a jsme opět u toho...
A pokud chci ... tak musím ... . Ale je potřeba vědět, že ... a ... . Pochopitelně jenom v případě že ... . Což ví všichni, kdo nejsou ignoranti.
-
Což ví všichni, kdo nejsou ignoranti.
přesně tak.
-
Děkuji, už jsem to pochopil. == není obvyklá ekvivalence a === identita. Dle definice ECMA jsou to prostě jakési vlastní, komplikované operátory, které se snaží pracovat s primitivy i objekty zároveň. Skutečnou ekvivalenci objektů je třeba řešit extra.
-
Tady je někdo kreten.
Jazyk to nebude.
Víš, je rozdíl mezi false a new Boolean(false).
To první je unboxed primitive value a to druhé je boxed primtive value.
To boxed znamená že je to objekt s vlastním prototypem.
Což znamená že == a === porovnává reference nikoli primitivní hodnoty.
Když na boxed boolean aplikuješ negaci, vyjde ti vždycky false protože negace objektu je vždycky false (protože každý objekt mimo null je přetypovatelný na true).
!new Boolean(true) === !new Boolean(false)ti vyjde jako true.
A opět, neni to divnost jazyka, je to jenom kompletní ignorace se ho alespoň v mezích naučit.
TEČKA.
Máte recht, už jsem si to ověřil a je to tak - negace neprování nejprve unboxing (jak bych čekal, když se javaskriptaři tolik prsí transparentností boxingu/unboxingu), ale bere to přednostně jako onu "negaci" objektu. Moje nepozornost. Otázkou zůstává, zda je nutno takovýmto věcem věnovat energii. Asi to není jazyk pro mě.
Váš popis == a === nechápu, jejich funkčnost jsme tu rozebrali pár příspěvků zpět.
Je dobře, že se v JS dobře orientujete, protože nám můžete vysvětlit podstatu onoho výsledku
> new Boolean(true) == new Boolean(true)
false
A příště to zkuste slušněji.
ok pardon, má chyba
-
(x == x) != (!x == !x)
je nade vší pochybnost blb.
Nejlepsi je, ze tyhle prasarny (a ano, vim, proc to tak asi je - unboxing boolu operatorem "not"), ale je to jasna prasarna) se budou ted decka ucit na skolach. Takze uz jim to bude pripadat normalni.
Not nic neunboxuje omg.
Boxed boolean je objekt dozadeke uz.
Jak mezi idiotama...
Jasne, ze unboxuje. Z objektu udela primitivni typ s opacnou hodnotou. To je na tebe ale asi moc slozite pochopit, kdyz se to nepoda polopate, co?
ale piča, skus to nacpat do REPLu a uvidíš že to cos napsal je pičovina.
-
Divím se, že tu ještě nikdo nezmínil Erlang... kdo ví, jak to ten starej lišák dělá...
-
Divím se, že tu ještě nikdo nezmínil Erlang... kdo ví, jak to ten starej lišák dělá...
Co? Porovnání? V tom Erlang není zajímavý - má taky dva operátory, taky jeden pro porovnání "nezávisle na typu" (1.0==1 -> true) a jeden "přesný" (1.0 =:= 1 -> false), ale oba jsou definované rozumně a předvídatelně, oba jsou použitelné a používané.
Navíc, Erlang má jednodušší situaci, protože má jenom immutable struktury, takže tam moc nedává smysl porovnávat identitu. Porovnávají se jenom hodnoty.
Možná by nás tady leda mohlo zajímat tohle:
When comparing an integer to a float, the term with the lesser precision is converted into the type of the other term, unless the operator is one of =:= or =/=. A float is more precise than an integer until all significant figures of the float are to the left of the decimal point. This happens when the float is larger/smaller than +/-9007199254740992.0. The conversion strategy is changed depending on the size of the float because otherwise comparison of large floats and integers would lose their transitivity.
http://erlang.org/doc/reference_manual/expressions.html
-
...Navíc, Erlang má jednodušší situaci, protože má jenom immutable struktury, takže tam moc nedává smysl porovnávat identitu. Porovnávají se jenom hodnoty...
Dovolím si nesouhlasit - to, že je něco immutable, neznamená, že se to nemůže objevit někde jinde a není třeba ověřit identitu, jinak řečeno s nemutovatelností to nemá co dělat. Jediným problémem je, zda v Erlangu existují struktury s identitou (Erlang neznám).
-
Dovolím si nesouhlasit - to, že je něco immutable, neznamená, že se to nemůže objevit někde jinde a není třeba ověřit identitu, jinak řečeno s nemutovatelností to nemá co dělat. Jediným problémem je, zda v Erlangu existují struktury s identitou (Erlang neznám).
Proto jsem nenapsal, že to "nejde" (ani teoreticky), ale že to "moc [resp. vůbec] nedává smysl". Erlang má (narozdíl od Scaly např.) data opravdu striktně imutabilní (nelze je změnit žádným způsobem, ani nějak výjimečně) a tímpádem tam žádné kopírování dat ani nikde neexistuje (není jak ho provést), čili není co ověřovat - "kopie dat někam jinam" se dělá tak, že se tam ta data prostě předají. Jestli je runtime fyzicky zkopíruje nebo jenom předá odkaz, programátor vůbec neví a neřeší, protože na sémantiku programu to nemá žádný vliv.
Jediná situace, kde bych si to se všema očima zavřenýma uměl představit, by byly mapy:
iex(1)> a = %{a: 1}
%{a: 1}
iex(2)> b = %{a: 1}
%{a: 1}
iex(3)> a = a |> Map.put(:b,2)
%{a: 1, b: 2}
iex(4)> b = b |> Map.put(:b,2)
%{a: 1, b: 2}
iex(5)> a =?= b
???
Takový operátor ale neexistuje, protože ho nikdo k ničemu nepotřebuje ;)
-
Divím se, že tu ještě nikdo nezmínil Erlang... kdo ví, jak to ten starej lišák dělá...
Co? Porovnání? V tom Erlang není zajímavý - má taky dva operátory, taky jeden pro porovnání "nezávisle na typu" (1.0==1 -> true) a jeden "přesný" (1.0 =:= 1 -> false), ale oba jsou definované rozumně a předvídatelně, oba jsou použitelné a používané.
Navíc, Erlang má jednodušší situaci, protože má jenom immutable struktury, takže tam moc nedává smysl porovnávat identitu. Porovnávají se jenom hodnoty.
Možná by nás tady leda mohlo zajímat tohle:
When comparing an integer to a float, the term with the lesser precision is converted into the type of the other term, unless the operator is one of =:= or =/=. A float is more precise than an integer until all significant figures of the float are to the left of the decimal point. This happens when the float is larger/smaller than +/-9007199254740992.0. The conversion strategy is changed depending on the size of the float because otherwise comparison of large floats and integers would lose their transitivity.
http://erlang.org/doc/reference_manual/expressions.html
Myslel jsem: vlákna a IO... vždyť to má být soft real time... :D
-
Myslel jsem: vlákna a IO... vždyť to má být soft real time... :D
Ajo :)
U Erlangu jsou to čtyři koncepty: 1. leightweight procesy (uvnitř VM, s vlastním user-space plánovačem) 2. žádný sdílený stav mezi nimi (kromě databáze) 3. striktně imutabilní struktury 4. komunikace mezi procesy je striktně asynchronní (pokud chci synchronní, zařídím si to protokolem nad tím)
Teprve tohle všechno dohromady dělá to, že je obsluha událostí v Erlangu taková pohoda. Nemusíš totiž řešit žádné zámky, nemusíš řešit, jaká data můžeš předat komu atd. Obvykle můžeš klidně pro vyřízení každého requestu spustit samostatný proces, v něm si všechno pořešíš v klidu synchronně, aniž by tě jiný vlákna jakkoli rušily, a výsledek pošleš kamkoli (klidně na víc míst) formou imutabilních dat. Díky těmhle vlastnostem může být i daleko jednodušší GC - nemůžou tam z principu vzniknout kruhové odkazy a spousta dat je jenom na stacku procesu, který se se skončením procesu prostě zahodí, GC se moc nemusí šťourat někde uvnitř a řešit nějaké složitosti.
Mapování interních procesů na vlákna OS se pak dělá stejně jako v jakémkoli jiném moderním runtimu - spustí se tolik vláken, kolik je (virtuálních) jader a procesy se na ně mapují podle toho, kdo má zrovna čas. Žádná velká věda ;) Z pohledu programátora tak vznikne plně konkurentní systém se slušnou latencí (sice probabilistickou, ale slušnou).
-
Ještě malá poznámka, jestli to z výš napsanýho nebylo jasný:
Díky těmhle vlastnostem může být i daleko jednodušší GC - nemůžou tam z principu vzniknout kruhové odkazy
...čímžpádem v Erlangu není ani žádný "stop the world", což taky soft-realtimovosti pomáhá.
-
Hodim sem takovou otázku ohledně Node.JS. Pokud vim, zpracovávaj se všechny požadavky v jednom vlákně. Co se tedy stane, když najednou server dostane obrovský množství požadavků. Moje představa je taková, že u prvního požadavku zpracuje např. jeden příkaz, pak jde k druhýmu.. a postupně je všechny obejde a jde zpracovávat druhej příkaz u všech. když bude takhle obsluhovat třeba X požadavků - OK, ale až jich bude 100× víc, v tu chvíli se to musí všechny požadavky zpracovávat pomalejš, ne? Nebo se to prostě řeší limitem, kolik se jich může zpracovávat současně?
-
Hodim sem takovou otázku ohledně Node.JS. Pokud vim, zpracovávaj se všechny požadavky v jednom vlákně. Co se tedy stane, když najednou server dostane obrovský množství požadavků. Moje představa je taková, že u prvního požadavku zpracuje např. jeden příkaz, pak jde k druhýmu.. a postupně je všechny obejde a jde zpracovávat druhej příkaz u všech. když bude takhle obsluhovat třeba X požadavků - OK, ale až jich bude 100× víc, v tu chvíli se to musí všechny požadavky zpracovávat pomalejš, ne? Nebo se to prostě řeší limitem, kolik se jich může zpracovávat současně?
Ne, vždy se jede až k dalšímu callbacku. Typicky jsou u spojení timeouty, když se server přetíží, nevyřídí všechny požadavky. Většina zde moc nechápe, jak node.js funguje. Muliplexování na jedno vlákno je hovadina, správně by se mělo použít něco jako GCD ve spojení s NIO.
-
Hodim sem takovou otázku ohledně Node.JS. Pokud vim, zpracovávaj se všechny požadavky v jednom vlákně. Co se tedy stane, když najednou server dostane obrovský množství požadavků. Moje představa je taková, že u prvního požadavku zpracuje např. jeden příkaz, pak jde k druhýmu.. a postupně je všechny obejde a jde zpracovávat druhej příkaz u všech. když bude takhle obsluhovat třeba X požadavků - OK, ale až jich bude 100× víc, v tu chvíli se to musí všechny požadavky zpracovávat pomalejš, ne? Nebo se to prostě řeší limitem, kolik se jich může zpracovávat současně?
Node.js přerušuje provádění požadavků jen pokud čekají na výsledek IO operace. Go přerušuje nepředvídatelně, přesně tak jak popisujete.
-
Ne, vždy se jede až k dalšímu callbacku. Typicky jsou u spojení timeouty, když se server přetíží, nevyřídí všechny požadavky. Většina zde moc nechápe, jak node.js funguje. Muliplexování na jedno vlákno je hovadina, správně by se mělo použít něco jako GCD ve spojení s NIO.
Co je GCD?
-
However, in the case of multi-threaded implementations, many browsers implement a structured cloning algorithm to copy the message into the receiving thread’s context (http://nickwritesablog.com/the-state-of-concurrent-javascript/#webworkersapi)
JS runtime musi predavane objekty serializovat a deserializovat. Je s tym spojeny overhead a nedokaze passnut referenciu na priamo.
JS runtime musi predavane objekty serializovat a deserializovat. Je s tym spojeny overhead a nedokaze passnut referenciu na priamo.
Aha, takze uplne stejna zoufalost jako v R :)
Pre upresnenie aktualneho stavu, situacia sa zmenila s uvedenim Shared memory and atomics (http://'http://2ality.com/2017/01/shared-array-buffer.html') do ECMAScript 2017. Clanok je z januara tohto roka.
Pribudol lahky nastrel pamatovych barier, CompareAndSwap a shareovatelny region pamate medzi Webworkermi. Passovanie referencii na objekty stale nie je mozne.
-
However, in the case of multi-threaded implementations, many browsers implement a structured cloning algorithm to copy the message into the receiving thread’s context (http://nickwritesablog.com/the-state-of-concurrent-javascript/#webworkersapi)
JS runtime musi predavane objekty serializovat a deserializovat. Je s tym spojeny overhead a nedokaze passnut referenciu na priamo.
JS runtime musi predavane objekty serializovat a deserializovat. Je s tym spojeny overhead a nedokaze passnut referenciu na priamo.
Aha, takze uplne stejna zoufalost jako v R :)
Pre upresnenie aktualneho stavu, situacia sa zmenila s uvedenim Shared memory and atomics (http://'http://2ality.com/2017/01/shared-array-buffer.html') do ECMAScript 2017. Clanok je z januara tohto roka.
Pribudol lahky nastrel pamatovych barier, CompareAndSwap a shareovatelny region pamate medzi Webworkermi. Passovanie referencii na objekty stale nie je mozne.
Takže pořád to je prakticky nepoužitelné...
-
Takže pořád to je prakticky nepoužitelné...
Situace se zásadně změnila, dřív to bylo nepoužitelné, pak jsme dodělali spostu zajímavých věcí a pořád je to nepoužitelné.
Jo a ještě je potřeba dodat, že těch spoustu zajímavých věcí podporují jen některé prohlížeče. Mají penetraci 10%. Ale to nevadí, protože existuje knihovna, která tu funkcionalitu obaluje a má fallback pro ostatní prohlížeče.
Jo ale počítejte s tím, že ta knihovna je použitelná jenom s webpackem. Integrace s Gruntem není. Teda je, ale musí se do něj nainstalovat plugin.
Jo a ten plugin občas způsobuje memory leaky. Ale nevíme komu a proč.
-
Jo a ještě je potřeba dodat, že těch spoustu zajímavých věcí podporují jen některé prohlížeče. Mají penetraci 10%. Ale to nevadí, protože existuje knihovna, která tu funkcionalitu obaluje a má fallback pro ostatní prohlížeče.
Jo ale počítejte s tím, že ta knihovna je použitelná jenom s webpackem. Integrace s Gruntem není. Teda je, ale musí se do něj nainstalovat plugin.
Jo a ten plugin občas způsobuje memory leaky. Ale nevíme komu a proč.
Měl jsem pocit (alespoň podle nadpisu), že se mluví o node.js. Výstřel do tmy.
A je to nepoužitelné, ale všichni to používají.
-
A je to nepoužitelné, ale všichni to používají.
Všichni používají Node? Aha :)
Spíš všichni si s tím hrají, protože je to cool. ...a pak s tím mají takovéhle zkušenosti:
I spent a year trying to make Javascript and more specifically Node work for our team. Unfortunately during that time we spent more hours chasing docs, coming up with standards, arguing about libraries and debugging trivial code more than anything.
Would I recommend it for large-scale products? Absolutely not. Do people do that anyway? Of course they do. I tried to.
https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a
:)
-
A je to nepoužitelné, ale všichni to používají.
Všichni používají Node? Aha :)
Spíš všichni si s tím hrají, protože je to cool. ...a pak s tím mají takovéhle zkušenosti:
I spent a year trying to make Javascript and more specifically Node work for our team. Unfortunately during that time we spent more hours chasing docs, coming up with standards, arguing about libraries and debugging trivial code more than anything.
Would I recommend it for large-scale products? Absolutely not. Do people do that anyway? Of course they do. I tried to.
https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a
:)
To je nefér srovnání. Django je určené pro jeden konkrétní typ aplikací. V tom je asi lepší. Node.js je univerzálnější.
-
OMG, proč jsem to vlákno vůbec četl. Což o to, JS má slabá místa, to je pravda. Nechcete si ovšem nejdřív doplnit elementární znalosti, než něco začnete kritizovat? Jak kdyby vám přečtení pár řádků specifikace mělo vykloubit mozek. Když vás někdo, kdo tu specifikaci evidentně četl, na vaší neznalost upozorní, tak z něj ještě děláte blbce. Nechci si ani představovat, co v tom plodíte za prasárny. Chyťte se spolu za monády a běžte ... do knihovny.
-
A je to nepoužitelné, ale všichni to používají.
Všichni používají Node? Aha :)
Spíš všichni si s tím hrají, protože je to cool. ...a pak s tím mají takovéhle zkušenosti:
I spent a year trying to make Javascript and more specifically Node work for our team. Unfortunately during that time we spent more hours chasing docs, coming up with standards, arguing about libraries and debugging trivial code more than anything.
Would I recommend it for large-scale products? Absolutely not. Do people do that anyway? Of course they do. I tried to.
https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a
:)
Tak ono to NIO je super nápad a funguje skvěle, jen se to nesmí míchat s Javascriptem, že... Aneb slovy klasika: "ECMAScript (sic!) on the backend sucks donkey bollocks. No developer capable of writing decent code who's well in his mind would touch it with a ten-foot pole."
-
What? Pokud lidi s tvejma znalostma delaj v nodu, tak buh s nama. Ty nemas nejmenci paru o jeho funkci natoz jak obvykle funguje async kod nezavysle na jazyku...
Udelal bys my laskavost? Skus implementovat to cos tady navrh a pak si dej facku. Uz jenom to jakej bordel v side efektech te mel varovat ze je to picovyna.
Prosim trosku mozku omg
-
Hodim sem takovou otázku ohledně Node.JS. Pokud vim, zpracovávaj se všechny požadavky v jednom vlákně. Co se tedy stane, když najednou server dostane obrovský množství požadavků. Moje představa je taková, že u prvního požadavku zpracuje např. jeden příkaz, pak jde k druhýmu.. a postupně je všechny obejde a jde zpracovávat druhej příkaz u všech. když bude takhle obsluhovat třeba X požadavků - OK, ale až jich bude 100× víc, v tu chvíli se to musí všechny požadavky zpracovávat pomalejš, ne? Nebo se to prostě řeší limitem, kolik se jich může zpracovávat současně?
Btw reaguju na tebe...
-
https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a
:)
S prvním bodem souhlasím. Také mi vadí zbytečné používání různých preprocesorů - Babelu, Elmu, Purescritu a podobně. Rychlý vývoj je problém, ale nebude trvat věčně.
Špatné zkušenosti se dají vygooglit o všech techologiích.
https://code.mixpanel.com/2011/08/05/how-and-why-we-switched-from-erlang-to-python/
-
A je to nepoužitelné, ale všichni to používají.
Všichni používají Node? Aha :)
Spíš všichni si s tím hrají, protože je to cool. ...a pak s tím mají takovéhle zkušenosti:
I spent a year trying to make Javascript and more specifically Node work for our team. Unfortunately during that time we spent more hours chasing docs, coming up with standards, arguing about libraries and debugging trivial code more than anything.
Would I recommend it for large-scale products? Absolutely not. Do people do that anyway? Of course they do. I tried to.
https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a
:)
Nemám pocit že si s tím všichni jenom hrají. Z tvých předchozích příspěvků vím, že Google používat umíš. Stačí si vyjet, kdo všechno a kde to používá na produkci. (Stačí jen ti největší, abys procházením nestrávil dva dny.)
Předsudky často zaslepí oči i rozumným lidem. Nemusí mi vše vyhovovat, ale vykládat nesmysly jen proto, že se mi něco nelíbí je směšné...
-
Špatné zkušenosti se dají vygooglit o všech techologiích.
https://code.mixpanel.com/2011/08/05/how-and-why-we-switched-from-erlang-to-python/
To je zjevně pravda, ale tenhle link není úplně dobrý příklad, páč tam proti Erlangu není nic jinýho než "neměli jsme na něj lidi" :)
No one on our team is an Erlang expert, and we have had trouble debugging downtime and performance problems.
(Tohle je legitimní důvod opustit nějakou technologii, ale není to argument pro to, že ta technologie je špatná)
...nicméně když se kouknu, do jakých zoufalostí je Python zavedl ( https://code.mixpanel.com/2015/02/24/building-a-simple-expression-language/ ), tak si nejsem úplně jistý, jestli opustit jazyk s kvalitním makrosystémem byl úplně dobrý krok ;)
-
No one on our team is an Erlang expert, and we have had trouble debugging downtime and performance problems.
(Tohle je legitimní důvod opustit nějakou technologii, ale není to argument pro to, že ta technologie je špatná)
Celkově jak tak pozoruju, tak na jedné straně jsou články tohoto typu (nevíme, neznáme, nemáme lidi) a na druhé ty články ve stylu "měli jsme X, ale drhlo to, tak jsme přešli na Y, díky čemuž jsme z dvaceti serverů na dvou, z nichž polovina je jen záložních". A teď chybí jen statistika, co je X a co Y.
-
Celkově jak tak pozoruju, tak na jedné straně jsou články tohoto typu (nevíme, neznáme, nemáme lidi) a na druhé ty články ve stylu "měli jsme X, ale drhlo to, tak jsme přešli na Y, díky čemuž jsme z dvaceti serverů na dvou, z nichž polovina je jen záložních". A teď chybí jen statistika, co je X a co Y.
Nevěřím tomu, že by se kvalita technologie dala jakkoli rozumně měřit. Každý projekt je tak specifický (svým předmětem, personáliemi, financemi, řízením, ...), že ti s volbou technologie beztak nepomůže nic jinýho než intuice.
...a mně intuice říká, že když mi kuna způsobila neuvěřitelnej bordel na půdě, třikrát bych si rozmyslel než bych ji pustil do kurníku ;)
-
Celkově jak tak pozoruju, tak na jedné straně jsou články tohoto typu (nevíme, neznáme, nemáme lidi) a na druhé ty články ve stylu "měli jsme X, ale drhlo to, tak jsme přešli na Y, díky čemuž jsme z dvaceti serverů na dvou, z nichž polovina je jen záložních". A teď chybí jen statistika, co je X a co Y.
Nevěřím tomu, že by se kvalita technologie dala jakkoli rozumně měřit. Každý projekt je tak specifický (svým předmětem, personáliemi, financemi, řízením, ...), že ti s volbou technologie beztak nepomůže nic jinýho než intuice.
...a mně intuice říká, že když mi kuna způsobila neuvěřitelnej bordel na půdě, třikrát bych si rozmyslel než bych ji pustil do kurníku ;)
Spolehlivou intuicí se ale může chlubit málokdo, přece jen to vyžaduje značné zkušenosti.
-
Spolehlivou intuicí se ale může chlubit málokdo, přece jen to vyžaduje značné zkušenosti.
Anebo smíření s tím, že se člověk prostě občas splete ;)
-
Špatné zkušenosti se dají vygooglit o všech techologiích.
https://code.mixpanel.com/2011/08/05/how-and-why-we-switched-from-erlang-to-python/
To je zjevně pravda, ale tenhle link není úplně dobrý příklad, páč tam proti Erlangu není nic jinýho než "neměli jsme na něj lidi" :)
No one on our team is an Erlang expert, and we have had trouble debugging downtime and performance problems.
(Tohle je legitimní důvod opustit nějakou technologii, ale není to argument pro to, že ta technologie je špatná)
...nicméně když se kouknu, do jakých zoufalostí je Python zavedl ( https://code.mixpanel.com/2015/02/24/building-a-simple-expression-language/ ), tak si nejsem úplně jistý, jestli opustit jazyk s kvalitním makrosystémem byl úplně dobrý krok ;)
Zoufalosti jim fungují. Co byste jim jako Erlang expert poradil? Ukládat všechna sdílená data do databáze, jak se píše v diskuzi pod článkem?
-
Zoufalosti jim fungují.
Samozřejmě. Špagety fungují. Na čas.
Co byste jim jako Erlang expert poradil? Ukládat všechna sdílená data do databáze, jak se píše v diskuzi pod článkem?
Nejsem Erlang expert. A nevím, proč bych měl něco radit na situaci, kterou vůbec neznám, co to je za nesmyslný dotaz?!