Live data from Hacker News

Shipping Culture Is Hurting Us

bitbashing.io

141–150 of 169 posts

Re: Shipping Culture Is Hurting Us

#141
post #38

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).…

> …browser developers refused to cooperate and develop something better. Microsoft and Apple…

Javascript was the language for nearly a decade before Apple shipped Safari.

Netscape shipped Javascript, but no one was necessarily locked in. When Microsoft shipped IE, they included an only somewhat compatible version of "JScript"/"DHTML" in it, with proprietary extensions added in. There wasn't even cooperation of Javascript per se, much less a "better" language to replace it.

Re: Shipping Culture Is Hurting Us

#142

Earlier quoted context omitted.

No one cares what the Web was originally intended to be, frankly.

Then why care about language designed for animating monkeys?

Because there are now God knows how many millions of applications built on top of it that would break if you made backwards-incompatible changes. But I don't think you're really unaware of that.

Re: Shipping Culture Is Hurting Us

#143

Earlier quoted context omitted.

The problem with that proposal is that we're currently waiting until all of the low hanging fruit got picked. I'm no masochist - if there are nice fruit on the bottom branches, I'm going to pick those. The problem is that the low hanging branches have been picked of all their nice fruit, just leaving the sour, the rotten, and the immature. We could start putting in the effort and climbing the tree for the nice, ripe…

To further the analogy.. as soon as the fruit on the low hanging branches becomes bad enough to justify the additional effort of climbing the tree for the better fruit, people will do it. Your argument makes it sound like you're saying no hard problems are being worked on currently, which is simply not true.

To continue the analogy even further - ... not if people instead invent ways to paint the crappy fruits so that customer buys them anyways. Happens all the time in every sector. As industries mature, products get crappier.

Re: Shipping Culture Is Hurting Us

#144

Earlier quoted context omitted.

Makes me wonder if this is why i find the whole "devops" concept to be raising my hackles.

DevOps is an integral part of Continuous Deployment. I am not sure why methods used to make deployment of software more frequent and less error prone should raise anyone's hackles. I guess it is not understanding what DevOps is and what it is trying to achieve.

You pretty much answered yourself right there in your comment. See how you capitalize "Continous Deployment" and "DevOps"? That's because they're recently invented feel-good buzzwords.

Re: Shipping Culture Is Hurting Us

#145
post #38

Earlier quoted context omitted.

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).…

> it's very reasonable to suggest that we could do a lot better. 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…

META: This is certainly the most divisive comment, vote-wise, that I've ever made. It was significantly positive last night, and is now currently hovering around zero. It's been up and down so much I really wish I could see the total vote volume.

To downvoters: now certainly this has a bit of ranty nature to it, but is it really so off the mark and off HN policy that it deserves only a downvote, and no rebuttal or reply-in-guidance? Or are some of you just using your downvotes as rebuttals? C'mon, speak up!

Re: Shipping Culture Is Hurting Us

#146

Earlier quoted context omitted.

How about "full-stack developer"?

Which really means "OUR stack developer, being a subset of the full-stack in our particular narrow domain, going as high as we go, and as low as we go".

I agree and that's exactly what job adverts should say. Spell out the stack and the amount of experience required. None of the nonsense with vague phrases like "full-stack developer".

Re: Shipping Culture Is Hurting Us

#147
post #70

Earlier 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,…

According to http://stackoverflow.com/a/1573715 the IEEE-754 committee decided to make NaN != NaN in order for programmers to have a simple way of detecting NaN before there was a standardized isnan function or macro.

I'm lacking sleep a bit here, but wouldn't NaN == NaN do the same trick?

Re: Shipping Culture Is Hurting Us

#148
The author's bit about how we forget about the problems and solutions of our forefathers - that resonates with me.

We do seem to keep re-inventing the wheel, and while part of that is out of joy of creation, I think a lot of that is that we're not writing down the problems, and we're not teaching the problems. We're only paying attention to solutions, and that's limiting.

Code is a solution to a problem, but it's not always apparent what that problem /was/ when you just look at it. So NodeJS (according to the authoer) is doing something that was thought of as a good idea at first, and then people learned why it wasn't, and /nobody wrote that down/. Or, at least, when they wrote it down, nobody taught it.

Solutions are /answers/, problems are /questions/. Here's a beautiful illustration of this dichotomy: http://dead-logic.blogspot.com/2012/09/a-collection-of-quest...

This is then part of why the TDD movement is in the right direction - you write down the problem you're going to solve, and later, someone can come read it. And maybe teach it.

(Not saying TDD has gotten "there", but it's in the right direction)

Re: Shipping Culture Is Hurting Us

#149
post #8

> 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…

Yes. The research culture that produced Haskell, for example, is far from the "shipping culture" that produced JavaScript 1.0, and yet: > let x = 0/0 > x NaN > x == x False > :type x x :: Double (and yes, Double is an instance of the Num type class) The author programs in C++ and D. I wonder if he knows the value of (NaN == NaN) in those languages?

NaN behavior might actually be appropriate in Haskell. I don't know enough about it to comment. But it is not helpful in JavaScript. Part of the problem is that in JS you can get NaN in a variety of different ways that do not involve mathematics. And that all numbers can be floats (whereas in other languages we have integers). And that NaN can be silently propagated and morphed in in a more complex expressions.

Re: Shipping Culture Is Hurting Us

#150

Earlier quoted context omitted.

The stupid thing about IEEE NaN is that it's not equal to itself! Why would it be? The rationale makes perfect sense. It would be unexpected to believe that 17/0 == 0^0. Both are NaN, and equally nonsense, but 2 very different statements. Secondly, IIRC, NaN is supposed to break assert(x==x), because if you use NaN in your program, then your program is undefined.

While your overall point is correct, your example is wrong: 17/0 == Infinity, and 0^0 == 1. Neither is NaN :)

Infinity is Not a Number, so 17/0 is NaN.
Post reply on HN