This whole article makes me want to scream, if only because the author seems to have never heard of the concept of Path Dependence[1]. I could utter a similar rant, on how terrible it is that we're stuck with awful legacy dumb AC lightbulb sockets everywhere, and wouldn't it be nice if the entropy fairy just waved a magic wand and we all had 'net-connected DC smart sockets for our wonderful Future Bulbs. But that kin…
Javascript has become the defacto browser programming language, even though it's objectively awful for complex software. The only reason it's achieved it's high status is because browser developers refused to cooperate and develop something better. Microsoft and Apple view software lockin as a competitive advantage and have actively undermined technologies they thought were threatening(java and flash amongst others).…
Shipping Culture Is Hurting Us
41–50 of 169 posts
Re: Shipping Culture Is Hurting Us
#42All things in moderation.. To me, "ship it" as a philosophy means the most important thing we do as developers is deliver working code to customers. On my team, when we encounter a concept that is just too complicated to ship right away, we try to branch-by-abstraction and keep shipping changes, even if the feature isn't "ready" yet. To me, the marginal returns on trying to be right diminish more rapidly than the ret…
The history of software development is littered with companies that failed because they spent so long polishing the beautiful crystal tower they were developing that someone released a concrete one instead and everyone bought that, and then no one needed a crystal one any more.
Unfortunately, it can be really hard to find out about these companies because of how hard they've been trodden into the ground by their successors, but Xerox and Netscape would be two high profile examples.
Shipping constantly may not be the best thing for technology, it may not be the best thing for quality and it may not, at times, even be the best thing for your users. But if you don't, someone else will.
Re: Shipping Culture Is Hurting Us
#43This whole article makes me want to scream, if only because the author seems to have never heard of the concept of Path Dependence[1]. I could utter a similar rant, on how terrible it is that we're stuck with awful legacy dumb AC lightbulb sockets everywhere, and wouldn't it be nice if the entropy fairy just waved a magic wand and we all had 'net-connected DC smart sockets for our wonderful Future Bulbs. But that kin…
Javascript has become the defacto browser programming language, even though it's objectively awful for complex software. The only reason it's achieved it's high status is because browser developers refused to cooperate and develop something better. Microsoft and Apple view software lockin as a competitive advantage and have actively undermined technologies they thought were threatening(java and flash amongst others).…
Who's the "we" in your comment and the original article? HN readers? The programming community at large? You and anyone else reading this article are free to write a compiler for a much better language than Javascript. There is no guarantee that Microsoft or Apple or Google will not actively undermine you too if it looks like your application is becoming a threat. More likely, such a language wouldn't serve the needs of most developers, and it'd be ignored like many other brilliant research languages that cannot get popular adoption.
Re: Shipping Culture Is Hurting Us
#44Uh, no. For instance, Unix kernels have been traditionally cooperative---at least when executing kernel code. That is to say, user space can be preempted but not the execution of kernel code. The introduction of SMP brings concurrency into the kernel, though, and with that, preemption can follow. Linux development followed this path.
Still today, you don't have to turn on CONFIG_PREEMPT when building your kernel. If you don't have SMP either, then you have a cooperative kernel: one task is in there at a time, and it has the CPU until it voluntarily calls into the scheduler.
Cooperative tasking has the enormous advantage that it makes a whackload of potential race conditions go away, and that could be a possible reason why Node.js is the way it is.
Unix might not have been successful had Ken Thompson decided to make the kernel preemptive, and then spent 1973-1987 debugging it. :)
Re: Shipping Culture Is Hurting Us
#45This whole article makes me want to scream, if only because the author seems to have never heard of the concept of Path Dependence[1]. I could utter a similar rant, on how terrible it is that we're stuck with awful legacy dumb AC lightbulb sockets everywhere, and wouldn't it be nice if the entropy fairy just waved a magic wand and we all had 'net-connected DC smart sockets for our wonderful Future Bulbs. But that kin…
Javascript has become the defacto browser programming language, even though it's objectively awful for complex software. The only reason it's achieved it's high status is because browser developers refused to cooperate and develop something better. Microsoft and Apple view software lockin as a competitive advantage and have actively undermined technologies they thought were threatening(java and flash amongst others).…
Yes, and it's so damn obvious now that you'd better have something salient to add. To wit: this has been done much better by others. C'mon, the book is called Javascript: The Good Parts (cough, 2008 vintage) This post is just chock full of bizarre straw-men in the guise of actual argument:
Systems stopped using cooperative multitasking at least 20 years ago because it sucked compared to the alternative of automatic, preemptive multitasking. And yet Node.js harks back to those dark days with its callback-based concurrency, all running in a single thread.
What the heck? No comprehension of evented systems? Reactive programming, anyone? No acknowledgement of the use cases when these systems do (or do not), in fact, kick total ass? Yes, the vanilla JS nested callback thing is a bit annoying. So don't do it. Use some of those FP chops and unwind it. Maybe a fold or a monad or some categorical pocket lint. Just please let cooperative multitasking have a nice rest.
Re: Shipping Culture Is Hurting Us
#46Re: Shipping Culture Is Hurting Us
#47Earlier quoted context omitted.
The stupid thing about IEEE NaN is that it's not equal to itself! If variable x holds a NaN, then (x == x) is false. This violates: http://en.wikipedia.org/wiki/Law_of_identity If (x == x) tests false, then it asserts that x is not itself, which is logically preposterous. ANSI Common Lisp has a bit of this problem in it too, but it's not required ; it is there for some weird historic implementations. That is to say,…
NaN literally means "not a number." Lots of things aren't numbers. The letter a is not a number. The square root of negative 1 is not a number (at least, not one representable in floating point math). a is not equal to the square root of negative 1.
char *p = "abc";
Yet, this yields true: p == p
The square root of -1 is easily representable in floating math. You just need two floats to make a complex.Re: Shipping Culture Is Hurting Us
#48> Instead we get some bizarro-world where where the type of NaN (“Not a Number”) is number, where NaN !== NaN*, and a chart like this exists for something as simple as comparing two values. That's the definition of NaN in virtually any programming language with floating point numbers. And the comparison table makes sense with the rule "when types are incompatible, both are casted to strings". Just use === instead of…
The stupid thing about IEEE NaN is that it's not equal to itself! If variable x holds a NaN, then (x == x) is false. This violates: http://en.wikipedia.org/wiki/Law_of_identity If (x == x) tests false, then it asserts that x is not itself, which is logically preposterous. ANSI Common Lisp has a bit of this problem in it too, but it's not required ; it is there for some weird historic implementations. That is to say,…
Not saying it's the perfect way to handle things, but it's pretty reasonable in world where people write code that generates NaN almost every time they use division. I worry more about writing code that generates NaNs than NaNs themselves anyway.
Re: Shipping Culture Is Hurting Us
#49Earlier quoted context omitted.
Don't quote me on this, but I recall the rational for NaN is because NaN is typically the result of a division by 0. Divisions by 0 can be thought of as infinity (for the sake of this explanation, but mathematicians will cringe), but it is not any particular infinity. In the sense that x / 0 does not necessarily have to equal y / 0. For that definition, the result of a division by 0, NaN, must not equal itself. You c…
IEEE division by zero gives positive (or negative) infinity (with the sign determined by the sign of the zero). NaN crops up with e.g. sqrt(-1) and infinity - infinity for which there is no way to define a sane answer.
To drive the point home, this is somewhat like making 0xF different from 15.
Re: Shipping Culture Is Hurting Us
#50AS for Javscript, there are worser languages out there, and the debuggers are good enough now, so it can be perceived as a "normal" language.