31–40 of 71 posts
Earlier quoted context omitted.
Well, the browser implementation I guess. The point being the correct mindset.
"Mindset" is not a property of programming languages. "Semantics" is. And JavaScript's semantics is, by any reasonable assessment, a huge pile of crap.
Not trying to be flamy, but, once again... why people insist on pushing on projects based on a... renownedly flawed programming language? ..Yea JS. Today it's clear that the "only" reason for it being used is its widespread availability in browser, but that started in a time when you needed a way to change the mouse pointer from default to a rainbow colored one. But still js it's the programming language we build fra…
The last thing we need is for everyone to be writing iOS and Android apps and calling it a day.
Come up with a better language that runs anywhere, instantly, so I don't have to give Apple a cent or Google an iota of data on me, and we'll talk!
Earlier quoted context omitted.
[edit spelling] I think that the reason you find so much negativity regarding javascript is that many people come to javascript from some other language which offers features which javascript doesn't yet offer. Having cut their teeth on a language tends to leave the programmer with a worldview where any language which doesn't have the same features which are present in their beloved language is an inferior language.…
Yes, I am so trapped in my Haskell blub that I cannot possibly understand why JavaScript is so amazing.
Earlier quoted context omitted.
[edit spelling] I think that the reason you find so much negativity regarding javascript is that many people come to javascript from some other language which offers features which javascript doesn't yet offer. Having cut their teeth on a language tends to leave the programmer with a worldview where any language which doesn't have the same features which are present in their beloved language is an inferior language.…
Yes, I am so trapped in my Haskell blub that I cannot possibly understand why JavaScript is so amazing.
Earlier quoted context omitted.
"Mindset" is not a property of programming languages. "Semantics" is. And JavaScript's semantics is, by any reasonable assessment, a huge pile of crap.
Meh, whatever. I can’t believe people still have flamewars about programming languages on the Internet like it was still 1996.
In any case, the real issue at stake is whether there is anything about Node.js that makes it particularly good for writing server-side applications. As far as I can tell, the only thing Node.js brings to the table is an event loop. Event loops are not a particularly earth-shattering concept: Anyone who has written a graphical Win32 application by directly using the WinAPI has written an event loop (message loop in Win32 parlance). I do appreciate not having to write the loop myself, but:
1. An event loop can only handle concurrent I/O. Furthermore, because the event loop is hardcoded into every single Node.js instance, there are two legitimate choices that are nevertheless unavailable to a Node.js programmer: a) disabling the loop, if he does not need it, b) spawning multiple event loops as separate threads within a single Node.js instance.
2. Node.js offers no support whatsoever for concurrent computation. I know, I know, all your Web application does is move data between a database and a client. But, if the only use case of Node.js is going to be making Web applications, would it not have been better to make a Web application framework, and provide it as a library?
Languages that actually provide concurrency support (Erlang, Haskell and Rust, to name a few) make writing event loops as easy as it used to be in the 1990s. On top of that, they can be used to write server-side applications that scale.
Earlier quoted context omitted.
Meh, whatever. I can’t believe people still have flamewars about programming languages on the Internet like it was still 1996.
I was not trying to ignite a flamewar. I was just correcting the mistaken idea that JavaScript's "relative absence of blocking IO calls" is somehow a property of the language itself. In any case, the real issue at stake is whether there is anything about Node.js that makes it particularly good for writing server-side applications. As far as I can tell, the only thing Node.js brings to the table is an event loop. Even…
Earlier quoted context omitted.
Meh, whatever. I can’t believe people still have flamewars about programming languages on the Internet like it was still 1996.
I was not trying to ignite a flamewar. I was just correcting the mistaken idea that JavaScript's "relative absence of blocking IO calls" is somehow a property of the language itself. In any case, the real issue at stake is whether there is anything about Node.js that makes it particularly good for writing server-side applications. As far as I can tell, the only thing Node.js brings to the table is an event loop. Even…
History of Node.js: http://www.youtube.com/watch?v=SAc0vQCC6UQ
Earlier quoted context omitted.
I was not trying to ignite a flamewar. I was just correcting the mistaken idea that JavaScript's "relative absence of blocking IO calls" is somehow a property of the language itself. In any case, the real issue at stake is whether there is anything about Node.js that makes it particularly good for writing server-side applications. As far as I can tell, the only thing Node.js brings to the table is an event loop. Even…
Node was created to make scripting fast servers easy. Nothing more, nothing less. Because JS (as implemented in the browser and known by many programmers) didn't carry the baggage of blocking IO calls, Ryan thought it would be a good language for an event-loop based server. History of Node.js: http://www.youtube.com/watch?v=SAc0vQCC6UQ
Earlier quoted context omitted.
No, Javascript has no notion of threads. Rather than true concurrency and a synchronization mechanism, it has callbacks (upon callbacks upon callbacks).
Technically speaking, HTML 5 introduced web-workers which allows javascript to have multiple threads (see 1). However, it's still useful to think about them as being single threaded since workers are sandboxed, meaning they don't have access to the global namespace. This avoids issues commonly found in concurrent programming. E.g., separate threads cannot read and write to the same variable since they don't have acce…