Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shipping Culture Is Hurting Us

bitbashing.io

Post reply on HN
Print view View original

61–70 of 169 posts

Re: Shipping Culture Is Hurting Us

#61

Post by pjmlp »

nulltype wrote: post #41
soup10 wrote: 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).…

If you think Javascript is bad for complex software, you should try C++.

It is not that bad without the C parts.

Re: Shipping Culture Is Hurting Us

#62

Post by aidenn0 »

kazinator wrote: post #21
DiThi wrote: 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…

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

You are missing a lot of nuance here.

First of all it is debatable over whether or not the spec allows (eq x x) to be false. eq is required to return true if the arguments are the same identical object. It would be a twisted interpretation of that to allow (eq x x) to ever return false.

Now (eq 1 1) is specifically not required to return true, as, for example an implementation that boxes all numbers could create two separate objects for that expression, and the arguments are now in fact not the same identical object.

This is something that exposes implementation details to the user, so using eq is discouraged (and in fact it can only portably be used to compare symbols). There are times when the best way to accomplish what you are doing is to (ab)use implementation specific behavior, and this is particularly true of Lisp which was a dynamically typed garbage collected language in the 70s (yes, predating the VT100 terminal referenced in this article).

Re: Shipping Culture Is Hurting Us

#63

Post by pjmlp »

kazinator wrote: post #44

> 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. Uh, no. For instance, Unix kernels have been traditionally cooperative---at least when executing kernel code. That is to say, user space can be preem…

>Unix might not have been successful had Ken Thompson decided to make the kernel preemptive, and then spent 1973-1987 debugging it. :)

Sadly that didn't happen, UNIX was adopted by 80's hipsters into their startups, became adopted by the industry at large, thus spreading C into the industry.

Now we have patch .

Re: Shipping Culture Is Hurting Us

#64

Post by pjmlp »

digi_owl wrote: post #12
didgeoridoo wrote: post #2

The author talks about languages and technologies (JS, Mongo), but he's really getting at something deeper. The real danger of the "ship it" culture is that things that can't be "shipped" right away — things that require solving really hard problems — tend to fall off our collective radar because there is just SO MUCH cool and (relatively) easy stuff to do right now. PG has a great term for this: "schlep blindness":…

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

I agree. Almost 30 years into this and I still don't see the point.

It is almost as when cleaning became health assistance.

Re: Shipping Culture Is Hurting Us

#65

Post by computmaxer »

McUsr wrote: post #50

I haven't tried Mongo.db, but Node.js takes up a lot of resources in a browser, Node.js apps feels a bit like the widest book strategy in the bookstore, you have to shove other stuff out of your browser, in order to use stuff that uses Node.js, and I feel that as a rather arrogant approach to deliver software, especially, when the functionality of Node.js apps doesn't really dictate the necessity. AS for Javscript, t…

> but Node.js takes up a lot of resources in a browser

You must be confused. Node.js is used to run JavaScript on the server, not in a browser (the client).

Re: Shipping Culture Is Hurting Us

#66

Post by hackuser »

didgeoridoo wrote: post #2

The author talks about languages and technologies (JS, Mongo), but he's really getting at something deeper. The real danger of the "ship it" culture is that things that can't be "shipped" right away — things that require solving really hard problems — tend to fall off our collective radar because there is just SO MUCH cool and (relatively) easy stuff to do right now. PG has a great term for this: "schlep blindness":…

Perhaps ship-it-now is the right answer for the times. With so many rapid changes in technology there should be 1) a lot of low-hanging fruit (i.e., quick, high-value solutions), making short-term project more valuable and 2) a shorter shelf-life for any solution (i.e., a new tech will make it obsolete), making long-term projects less valuable.

Re: Shipping Culture Is Hurting Us

#67

Post by fijal »

didgeoridoo wrote: post #2

The author talks about languages and technologies (JS, Mongo), but he's really getting at something deeper. The real danger of the "ship it" culture is that things that can't be "shipped" right away — things that require solving really hard problems — tend to fall off our collective radar because there is just SO MUCH cool and (relatively) easy stuff to do right now. PG has a great term for this: "schlep blindness":…

The problem runs deeper than that even. Even if you like doing stuff that requires more effort, it's shockingly difficult to find places/people who want to invest/hire you to work on such technology. You have essentially a choice between academia (which is, well, sometimes very academic) and large corpos which have their own share of problems and not everyone fits.

Re: Shipping Culture Is Hurting Us

#68

Post by nemothekid »

kazinator wrote: post #21
DiThi wrote: 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…

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

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.

Re: Shipping Culture Is Hurting Us

#69

Post by makeitsuckless »

dkarapetyan wrote: post #37
digi_owl wrote: post #12

Earlier quoted context omitted.

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

How about "full-stack developer"?

That's the one. That's basically short hand for "you don't need to do anything really well, you just need to do everything barely good enough to ship it now".

Re: Shipping Culture Is Hurting Us

#70

Post by jks »

kazinator wrote: post #21
DiThi wrote: 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…

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.
Post reply on HN