This post is sad, and it hurts my eyes with all the words offensives. A big waste of time.
2 Likes
Not sure if satire…
Well, the angry young man has a point. But then again – what is the alternatives?
Yes, I know there are alternatives but things are moving fast and every day something “hot” is presented. Many many people are involved, individuals that might or might not work towards a common goal but they never meet, they are normally unaware of each other. But they are equals.
It’s not just NPM, there are similar problems with Linux, the meteor packages, the RequireJs and whatnots. Often it is lazyness, I once found a Meteor package that would save me 20 minutes and when adding it I saw it added a lot of other packages. Looking at the code, the functionality, of the package I wanted I saw just a few lines of code referencing other modules.
Laziness. We programmers are both lazy and ambitious, we want our stuff “out there” and we want to do as little as possible to achieve our goal. It’s human nature. We fuck up. Then we repair it. In the words of Laurie Anderson:
You’re walking. And you don’t always realize it,
but you’re always falling.
With each step you fall forward slightly.
And then catch yourself from falling.
Over and over, you’re falling.
And then catching yourself from falling.
1 Like
I had to get up and take a few steps across my kitchen floor to check for myself if this was actually true. Suspected it might have just been some clever sounding BS. But, no, it’s a good observation.
Does that image really suggest Ruby invented arrow functions?
Every now and then I forget what it’s like to develop non-meteor node applications.
So every now and then I give it a try and by the end of the day I’m suicidal. Crying, I go back to Meteor. If it was really bad, Meteor won’t do and I need go back to good old C# for a while (which is very awesome these days). From there I try to forget about the crazy node world that’s out there, until the next time I think I can handle it and make the same mistake again.
All of this to say I understand the mental state the guy must have been in when he wrote this blog post and for that I’m ready to forgive the huge exaggerations and half truths in there.
Node is just a very young project with huge growing pains. I’m an optimist so I hold on to what’s nice about it and believe the rest will get better. And it actually seems to get better quite fast.
4 Likes
You see the Node.js philosophy is to take the worst fucking language ever designed and put it on the server.
I think it was the universal prevalence of JavaScript in browsers that led to the choice to use it.
But I agree that JavaScript is a bad language, especially after having come from years of ASP.NET. We are spending so much time building things using a language that still to this day truly thinks 0.1 + 0.2 - 0.3 === 0 is false. I still sometimes try it in my browser console and shake my head at the insanity.
2 Likes
I think it was the universal prevalence of JavaScript in browsers that led to the choice to use it.
From what I’ve read/watched, Dahl created Node because of it’s asynchronous nature and event loop. Specifically he was inspired by how annoying it is to implement a real upload progress bar
Here’s an excerpt from an interesting article in which Ryan Dahl explains his motivation for making node
“Turns out, a lot of the frameworks were designed in a way that they made the assumption a request — response is something that happens instantaneously and that your entire web development experience should be abstracted as a function. You get a request, you return a response. That is the extent of your context.”
“Node was originally born out of this problem — how can you handle two things at the same time? Non-blocking sockets is one way. Node is more or less the idea, or exploring the idea: what if everything was non-blocking? What if you never waited for any IO to happen?”
For example, the non-blocking IO, what falls out of that? And pairing that with JavaScript, it turns out you can make a web upload progress bar with this, among other things
It’s not a bad language, it’s just misunderstood.
I think perhaps you don’t know enough about other languages, because floating point equality checks is insane in all languages, dotnet included, it invented decimals to make it a bit better.
see …
and google for more examples in nearly any language that support floating points . Some languages come up with their own ways of storing numbers that make things better, especially for storing things like money (never do that with a float)
So why would anyone use the insane floating point numbers? Because the CPU natively computes them and for many applications they work really well. If you ever try == with a native floating point, you are doing the wrong thing 
2 Likes
I’ve been programming since around 10 years of age and do know about other languages.
I use decimal in .NET and BigDecimal in Java for monetary calculations. They’ve been around for almost a decade. JavaScript has been around since 1995 (over 2 decades) yet we still don’t have a type other than floating point for non-integer numerical calculations, which is imprecise. I’d think it’s one reason to call it a bad language. Yet now here we are trying to build serious applications with it (or at least I am).
1 Like
I know, which is why I’ve been using BigNumber, for all monetary calculations, but it’s such a hassle and it’s not compatible with some other packages that I need.
Indeed, I don’t understand why people keep repeating the 0.1 + 0.2 != 0.3 problem. That’s the very basics of numerical analysis, which is included in about every CS program around the world.
I think it’s even worse if the language tries to help you. In php for example 0.1 + 0.2 will result in 0.3 (so it rounds from 0.30000000000000004, but ceil((0.1+0.2)*10) will give you 4, which IMO is more confusing, since you need to think of it only some of the times instead of all the time.
1 Like
But those are statically typed languages. Are there any dynamically typed languages that solve this?
Well, maybe those that have operator overloading make it easier…
But it’s often used to diss javascript, while it’s true for many languages.
Arguably the fact that JavaScript is dynamically typed may be a more general reason to why it’s bad. It may provide flexibility but that can come at later cost. See The Case Against Dynamic Typing.
Now we have Aldeed’s SimpleShema and Meteor’s ValidatedMethod that introduces some type checking functionality, but they would not have been necessary if JavaScript was statically typed.
ASP.NET or Java doesn’t try to “help you”. As long as you declare the variables using decimal or BigDecimal, any monetary calculations will automatically be precise. It saves the time and mental energy for other more important work.
So what is the “best-practice” solution to have accurate monetary and foreign currency exchange rate calculations using JavaScript?
I’m finding dynamic typing a very hard thing to come to terms with after having spent 15 years working in strongly typed languages, but when I look at the hoops I have to jump through in C# to get code fully testable (implementing interfaces that will only ever be used once just so you can mock something and do dependency injection for example) I do wonder whether strong typing, and even OO, might actually be the wrong solution altogether.
I haven’t got as far as testing in JS yet, but it seems like it should be simpler simpler to get tests round things in JS as you won’t need to create endless interfaces. Although, I guess you will potentially need a lot more tests to deal with what happens if your arguments don’t have the properties/methods expected.
Still, as far as strong typing goes, as was said earlier, the solution to that is probably TypeScript. If it’s good enough for Google…
1 Like
TypeScript introduces the “number” data type. The joke is that it’s just the same floating point type used by JavaScript, so inherits its imprecision.
The fact that TypeScript even exists with a growing user base and is now being used by Google for Angular 2 (when previously they just used JavaScript) adds weight to the notion that JavaScript itself is a bad language and needed a lot of fixing.
2 Likes
But you can’t just say a language is bad. You can say a language is bad for a specific use case. Many people forget the script in javascript. For the use cases it was designed, it does a pretty good job.
If you’re working with 20 developers on a huge financial business application, then yeah, javascript is bad for the job. But if you’re doing that, then it’s rather you who’s bad at making technology choices. Granted, in a web front-end you don’t have much choice.
1 Like
Oh that’s genius :facepalm:
And there in lies the problem I guess. Wrong tool for the job, but also the only one that can be used.
It was designed by Netscape for front-end web page scripting. Whether it did a good job is questionable. What can we expect from a language that was developed in just 10 days? Did you program in JavaScript in the dark ages when we had to always test using at least 2 different browsers? It was annoying to have to write code that would work on all of them. We had to often write workarounds just so it would work in a particular browser even if it worked fine in the others. I hated it. Yet now I’m deeply immersed in JavaScript for what it was not originally designed for - server-side scripting with high-frequency database access and monetary calculations.