Hacker News Reader

Comment by Ericson2314 | Hacker News Reader

I dislike shitty languages and successfully avoid using them myself, but I do have to be a bit happy with NPM ecosystem teaching people to reuse more code.

View on HN

I think NPM has finally shown that you can, in fact, have too much code reuse. The representative example for me is this actual isPositiveInteger module:

  var passAll = require('101/pass-all')
  var isPositive = require('is-positive')
  var isInteger = require('is-integer')
  module.exports = passAll(isPositive, isInteger)

You don't even want to know what the is-positive and is-integer modules look like.

Software pundits have been saying how modern programming is just wiring together existing components for years; the node ecosystem has taken that to its illogical extreme.

Is this real or are you kidding?

Real. However, the same day the left-pad debacle stuff was on HN, this was changed to be self-contained: https://github.com/tjmehta/is-positive-integer/commits/maste...

Your information is out of date.

https://github.com/tjmehta/is-positive-integer/blob/master/i...

No discussion on Node.js and "overmodularisation" is complete without a mention of the left-pad debacle:

https://news.ycombinator.com/item?id=11348798

No matter how few dependencies you have, any of them can break you if your build system automatically moves you to an updated version without first testing it.

True.

And also, the more independent dependencies you have, the more that risk is compounded.

It seems to me that what other people call 'functions', npm calls 'modules'. There are so many 'modules' that are just a short function. Why not just make a 'standard library' with all these basic things in it?

One place I work at has a node app product with 500 (!!) modules like this, all of which have their own submodules. There are so many files that a server with a bog-standard 8GB EXT4 / drive cannot handle both the installed module, and a replacement during deployment, due to INODE exhaustion (solution: bigger EXT4 or use xfs).

The thing is, nobody is forcing you to use excessively small modules.

If you use an excessive amount of small modules, that's an error of the developer, not an inherent flaw in the platform/ecosystem.

The problem is that the ecosystem encourages small modules, and so the vast majority of existing modules in the ecosystem are small modules, or else are bigger modules that use many small modules. Basically, the only way to avoid depending on something this silly in your real-world Node project is to not use anything from npm. At which point you pretty much lose all the advantages of Node.

Nobody is forcing me to use node. If I use it, is that also an error of the developer?

My app does not use small modules... but its dependencies do, and the dependencies' dependencies, so in the end my node_modules folder has hundreds of packages and everything compiles slow like molasses :(

Compiles?

There is a "true" module, which returns true.

https://www.npmjs.com/package/true

From the usage:

> Usage

> Simply require the true module. The export is a function which returns the Boolean value true:

> var t = require('./true') , myTrueValue = t(); console.log(myTrueValue === true); // Logs 'true'

And it's not as easy as it seems: https://github.com/mde/true/issues/5

https://www.gnu.org/software/coreutils/manual/html_node/true...

I think the overall trend has been from no abstractions to bad abstractions. As a systems programmer, I like reading about the battle stories of e.g. console game developers from the 90s and earlier who practically wrote an OS, but I hope our current trajectory will eventually lead to good abstractions (in good languages).

The only way to avoid using shitty languages would be to stop programming altogether.

I have found in my experience a pattern that repeats itself.

1) I find a language (B) that I think is great because it solves X problem with the language (A) previously being used.

2) I use that new language long enough that eventually I learn it's pitfalls and hate it.

3) Switch to language (C) because it fixes problems found in language (B).

Eventually this loops.

I'm sorry that's been your experience. I've been using Haskell for 4 years, Rust for 2, happy with both. Anything I don't like other people usually don't like and is fixable.

For years I was stuck in a cycle: A->B->A->B ...

Where A was C++, and B was Python.

There are less shitty languages. I'd consider mine to be OCaml and Perl (and Rust is growing on me, but I might be in the first phase above).

I think, ultimately, this just boils down to “know a lot of tools and use the right tool for the job”.

I find that it doesn't loop for me, unless you count new versions of old languages (which fix old problems) same as old. The sequence is familiar, but in general, I find the tools that I use today better, in very specific ways, than tools that I've been using 5 years ago, which were better than those from 10 years ago etc.

So it's more of a spiral. A straight line would be better, but I'll take progress in whatever form.

While there is no arguing the pitfalls of dealing with Javascript. As a one man team, to build a product with the same language on the backend, that I've already been using on the front end. Is awesome. The ability to fire up a Node.js project on a server is even easier than a PHP one, which is arguably why PHP took off in the first place. And like you mentioned, I think the NPM system is awesome, super easy to use, and a voracious community.

Sure there is TONS of not nice things about JS, but it's slowly evolving to be better(ES6 + Promises), and it's not going anywhere anytime soon.

Reply on news.ycombinator.com