Node.js vs jRuby vs Java (Nobody cares about your technology) ...(github.com)
github.com
Node.js vs jRuby vs Java (Nobody cares about your technology) ...
https://github.com/nddrylliog/blog/blob/master/nodejs-vs-jruby.md
5 comments
The problem I see with this premise is that for any reasonable language/environment and actual, real-life problem, n will hardly ever be n.
Most of the time, your productivity increase p will be equal to a slowdown s multiplied by a factor f.
So the big performance for lots of problems is: How large can f get for you? Sometimes you can't really pay the price (e.g. writing 3D engines in tcl), sometimes the money factor m will make more than up for it (i.e. more programmers, more instances on more servers etc.).
Never mind the actual size of p. Given the mentioned hodgepodge of dynamic languages, I'd expect it to be pretty small unless your environment isn't up to it, i.e. you have to write modules. Then even hyper-mega-insta-lisptalkscript will be much slower than CPAN.
I'd say that even for C/C++ vs. dynlang f will be pretty high, but again, it often doesn't matter that much…
Most of the time, your productivity increase p will be equal to a slowdown s multiplied by a factor f.
So the big performance for lots of problems is: How large can f get for you? Sometimes you can't really pay the price (e.g. writing 3D engines in tcl), sometimes the money factor m will make more than up for it (i.e. more programmers, more instances on more servers etc.).
Never mind the actual size of p. Given the mentioned hodgepodge of dynamic languages, I'd expect it to be pretty small unless your environment isn't up to it, i.e. you have to write modules. Then even hyper-mega-insta-lisptalkscript will be much slower than CPAN.
I'd say that even for C/C++ vs. dynlang f will be pretty high, but again, it often doesn't matter that much…
It also depends on how fast the app needs to be, and how far your computer is (e.g. the answer might have been different 20 years ago for the same task) - it would be nice to express the question differently, to make it invariant of these aspects.
For "interesting" tasks (in a research sense), speed is limited by combinatorial explosion. Finding an algorithm/approximation/heuristic that avoids or reduces that is the only real solution - because faster languages, like faster computers, can only give you linear speed up.
For "interesting" tasks (in a research sense), speed is limited by combinatorial explosion. Finding an algorithm/approximation/heuristic that avoids or reduces that is the only real solution - because faster languages, like faster computers, can only give you linear speed up.
>>"If you could choose n where your language is n times as slow and you are n times as productive with this language were both true which value of n would you choose?"
>>if I can build an app 5 times quicker than before, and the amount of time involved isn't trivial (i.e. a few hours) then then development time is vastly more important than the end speed of the code.
I would set n somewhere between 50 and 100. Then benchmark the resulting programs and rewrite bottlenecks in C. (Just think about it; years of productivity in a month! Then another few months to optimise the prototype.)
>>if I can build an app 5 times quicker than before, and the amount of time involved isn't trivial (i.e. a few hours) then then development time is vastly more important than the end speed of the code.
I would set n somewhere between 50 and 100. Then benchmark the resulting programs and rewrite bottlenecks in C. (Just think about it; years of productivity in a month! Then another few months to optimise the prototype.)
This is pretty good advice in an entrepreneurial forum where people are most interested in quickly prototyping an idea for the web, showing it to people and finding where to take it and how to change the idea, getting people to look at it who might throw some cash at it, and so on. You're not concerned about high performance or even really quality engineering yet, all the "soft" stuff is way more important.
I'd question its wisdom for engineering-heavy work.
Edit: Also, it makes a bit more sense to posit this:
If you could choose n where your language is n orders of magnitude slower and you are n times as productive with this language were both true which value of n would you choose?
I'd question its wisdom for engineering-heavy work.
Edit: Also, it makes a bit more sense to posit this:
If you could choose n where your language is n orders of magnitude slower and you are n times as productive with this language were both true which value of n would you choose?
For engineering-heavy work (I work in telecoms where a fair bit of work goes into reliability), the choice of language is still pretty low in the importance compared to other decisions.
The language can make things easier (and quicker) to do things the right way, but it'll always be possible to do the wrong thing.
The language can make things easier (and quicker) to do things the right way, but it'll always be possible to do the wrong thing.
What exactly is he talking about? I've read it, but got confused...
I've been console game developer for quite some time, and async stuff has always been around for us (but not so network oriented for the stuff I was doing - streaming sound, file I/O, DMA from one cpu to another, etc.)
But If I have to direct it, then precooking your data, so data once loaded only pointer mixup is needed was the basic to get streaming stuff in a game (Spiderman-2, Ultimate Spiderman, Spiderman 3).
Then comes stuff like ability to cancel async jobs, and off course start several at the same time, giving some more info to the underlying code - which should be done first. I can go on technical details in few pages.
What exactly is he talking about?
I've been console game developer for quite some time, and async stuff has always been around for us (but not so network oriented for the stuff I was doing - streaming sound, file I/O, DMA from one cpu to another, etc.)
But If I have to direct it, then precooking your data, so data once loaded only pointer mixup is needed was the basic to get streaming stuff in a game (Spiderman-2, Ultimate Spiderman, Spiderman 3).
Then comes stuff like ability to cancel async jobs, and off course start several at the same time, giving some more info to the underlying code - which should be done first. I can go on technical details in few pages.
What exactly is he talking about?
The whole thing came from "someone responding to node.js fanboys who pretend Node.js is faster at everything". Turns out his response contained a small, but ultimately flawed benchmark, which in turn provoked the reaction of other Node.js people. Some of it happened on Google+ and various blogs.
However, your perspective as a console game developer is highly interesting to me - care to write a bit more about it?
However, your perspective as a console game developer is highly interesting to me - care to write a bit more about it?
Not quite sure I would call people who question trivial benchmarks "fanboys". I would call people who post trivial one-sided benchmarks the fanboys, regardless of the language promoted. IMHO.
[deleted](1)
He should conclude with even more positive statements about developing and discussing good ideas in the context of use, not technology. I miss good discussions about ideas and more abstract concepts that go beyond technical terms and programming languages. Instead everybody is disrupting with his latest YA* that we had a thousand times.
*) KV stores, node.js hating or petting, the next big X, iPhools, Fezbook, little boyz anonymous - we are the rulerz of the world - hacking, "old tool" in a "new language" thing
(OK, I am enerved ...)
*) KV stores, node.js hating or petting, the next big X, iPhools, Fezbook, little boyz anonymous - we are the rulerz of the world - hacking, "old tool" in a "new language" thing
(OK, I am enerved ...)
This guy, it seems, still don't realize that there is no silver VM^Wbullet and never will be, and choosing appropriate tools for each particular task is still absolutely necessary. ^_^
And that clarity, readability and common idioms of a language matters more than its runtime, and that 100k of Java or Javascript code is not the same pile of crap as 100k of Python or Ruby code, assuming that it is not specially obfuscated. ^_^
Fast prototyping that some stacks (VM+frameworks) provide has no correlation with real production environments where you must consider a system in terms of data-flows, content types, separate storage for different types and flows of data, different levels of caching, and so on.
And, of course, in most cases, serving a content from a file on modern FS with help of a little C code is much faster end more efficient than serving the same content with some cool VM involved. ^_^
And that clarity, readability and common idioms of a language matters more than its runtime, and that 100k of Java or Javascript code is not the same pile of crap as 100k of Python or Ruby code, assuming that it is not specially obfuscated. ^_^
Fast prototyping that some stacks (VM+frameworks) provide has no correlation with real production environments where you must consider a system in terms of data-flows, content types, separate storage for different types and flows of data, different levels of caching, and so on.
And, of course, in most cases, serving a content from a file on modern FS with help of a little C code is much faster end more efficient than serving the same content with some cool VM involved. ^_^
I thunk his point is - he's wasting his breath talkin about it
"If you could choose n where your language is n times as slow and you are n times as productive with this language were both true which value of n would you choose?"
It's absolutely true - For me, if I can build an app 5 times quicker than before, and the amount of time involved isn't trivial (i.e. a few hours) then then development time is vastly more important than the end speed of the code.
Execution speed issues can always be solved - it might need more hardware, better coding, or even a complete rewrite, but it's fundamentally something that can be fixed.
That's not to say that your choice of stack and architecture isn't important, it's just that the language itself is only a small part of that decision, and most architectures (and most performance requirements) can be achieved in most languages.