im from tumblr and what is this
Shipping Culture Is Hurting Us
121–130 of 169 posts
Re: Shipping Culture Is Hurting Us
#122Earlier 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,…
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 :)
Re: Shipping Culture Is Hurting Us
#123This 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…
I don't understand your complaint against the article. I think it exactly discusses the harms arising from path-dependence and how we need a lot of focus, dedication, and hard work to overcome this path-dependent inertia, to build better tools, and to get them adopted.
Re: Shipping Culture Is Hurting Us
#124Earlier quoted context omitted.
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.
There is another option: work for a salary, live frugally, and stockpile savings. Then later (maybe 5-10 years later), work on the tech you really want to work on that has no obvious & immediate business need. The upside is that because no one invested or hired you to work on it, you own 100% of that work.
Also, make sure you are (a). young (Yea, if you have met all those conditions, then that approach may work for you.
Re: Shipping Culture Is Hurting Us
#125The 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":…
I think many people confuse "ship it" culture with just doing crap work. I've seen too many ship it projects die because the biggest feedback from the customers was "This thing doesn't actually seem to work" or "This is useless". Ship it can apply to hard problems as much as easy ones, it's more about not doing extra work before you know what your customers want. But if you MVP it to the point where it barely works and has no real functionality then customers will often view it as trivial and useless and you'll likely confuse missing product market fit with under delivering.
Re: Shipping Culture Is Hurting Us
#126The first two comments in the linked article are gold.
Re: Shipping Culture Is Hurting Us
#127> 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 law of identity shouldn't apply to NaN because it isn't a single value. NaN represents a set of values that get mapped to NaN. But information is lost along the way. Since we can't recover that information, we can't know for certain what value this NaN represents or whether this NaN represents the same thing as that NaN.
Re: Shipping Culture Is Hurting Us
#128Earlier quoted context omitted.
Fixing the warts of the web is not the hard part, the hard part in designing a "better" platform is achieving adoption, that would require an act of god as there is no coalition powerful enough to make it happen through human volition alone. I don't know, I remember when Flash was viewed the same way, ran everywhere and nothing would unseat it. Although I am not a huge Apple fan, I think Job's started the snowball wh…
Flash always had its drawbacks, such as: 1. it was not a web standard, 2. it was not indexable by search bots + was not accessible, 3. needed a plug-in to run. Therefore, I don't think it was ever being seen as unseatable. It was actually quite hated in the community of web standards & accessibility-aware web developers very early on.
Don't get me wrong, I hated Flash as much as anyone else. And yes it required a plugin, but it was ubiquitous, and did run everywhere. Plus it allowed people to make rich games and apps. I even remember someone developed a DB connector that used Flash's protocols (it wasn't using Flash) to allow universal web based access to DBs (my google-fu is failing me, can't find the project now).
So regarding your points: 1: Flash everywhere made it a de facto standard 2: You win there - except in my opinion most real world examples of 5/3/JS are not accessible (which is condemnation of us devs, we have to tools to make our sites accessible but we don't (are too lazy to?) do it. 3: Fair point again, but I glimpsed a headline here on HN that said Firefox was using something else to play flash videos...
But to your main point which was drawbacks and dev hate, I think we are also starting to see that happening now with JS. There are drawbacks to JS, and some are starting to hate it. Wether or not it is enough to start a Che Guevara movement against JS I guess will unfold in the coming years.
My money is on the fact that JS is here to stay (but I am personally still hesitant to dive deep into it)- but I think that it is in the realm of possibility to remove JS and move to something 'better'. Just what that 'better' is I don't know.
Re: Shipping Culture Is Hurting Us
#129Earlier quoted context omitted.
Given that the ECMAScript community has (for good reason; "don't break the web") decided to avoid backwards-incompatible changes, that necessarily places a limit on the amount of "fixing" they can do to the language. New or enhanced features are okay, rectifying mistakes is harder. (This isn't just a JS thing; go talk to any random Python developer and ask them what they think of Python 2 vs 3. There are tradeoffs to…
"don't break the web" I know it's not your fault but this statement doesn't make any sense. Web is made of hyper-linked content not jQuery animations and AJAX.
No one cares what the Web was originally intended to be, frankly.
Re: Shipping Culture Is Hurting Us
#130People use mongo and node because they want to get a site up really really fast and see if it gets traction. When they actually get somewhere they'll rewrite it in a better language. If you want to set yourself up with really slick tooling and a great language you can code in Scala with Intellij. You can even avoid touching any ugly dynamically typed stuff by coding your JS in scala.js. If you're doing it better than…
> When they actually get somewhere they'll rewrite it in a better language. Anecdata for you: Not necessairly. I'm working for a company which has "actually gotten somewhere", and our development team is still writing in Node with Mongo. Of course, there is a reason for it, the front end development team has spare cycles, and the backend team does not. Ergo, Node!
I'm inclined to repurpose a cliche, and say that now your backend team has two problems!