Earlier quoted context omitted.
> But regardless of how many insults get thrown around, or how many people seem to think JS is useless or that it's a horrible language, its probably my favorite (and I've done professional work in non-trivial applications from C and C++, to Java and go, to python, Ruby, and PHP to BusinessBasic and even some lisp). I see one common thread between all those languages you list: none of them has a decent type system. I…
I've actually played with OCaml a bit, and Haskell a bit less. The problem is that I don't know what "problems to solve" with them, and there is no way I'm going to use something like that at work, so I kind of run out of steam before I really get into it. I might shoot for Scala next time. We don't use Java anywhere at my current job, but I might play around with it in a personal project for a while. I really like t…
NPM and Left-Pad: Have We Forgotten How to Program?
641–650 of 887 posts
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#642Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…
What I want to know is how many systems does the author of is-positive-integer have implicit root access to? Sounds to me like publishing oneliners on NPM is a trivial way to build a botnet.
> If npm was invoked with root privileges, then it will change the uid to the user account or uid specified by the user config, which defaults to nobody. Set the unsafe-perm flag to run scripts with root privileges.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#643Sure in some ways NPM has packages that don't deserve the title of a package, but isn't the convenience of not having to reinvent every code worth it?
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#644Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…
The majority of code I have ever seen is awful (20 years across large + small companies) but that is why I am hired to fix awful code so I am skewed. The amount of times I have seen people implement something simple, in a convoluted error prone was is unbelievable.
I know this seems ridiculous but when you see time and time again how people fail to do the simplest things it seems like a good idea.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#645Earlier quoted context omitted.
and it uses another 1LOC package. https://github.com/sindresorhus/number-epsilon/blob/master/i... and no, the edge cases argument does not apply to either of them. Wow.
Would you like to memorise that number yourself to use in your app?
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#646Earlier quoted context omitted.
The equivalent in C would then be replacing #include and "-lm" with #include #include #include #include … and "-lsin -lcos -ltan -lsinh …" Which is nuts no matter what language you are coding in.
So have libmath depend on libsin, libcos, libtan and libsinh. People who want the kitchen-sink version can get it. People who want just one specific submodule can depend on that. What's not to like?
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#647Earlier quoted context omitted.
Yeah I'm sure it sucks for distro packagers. Why are they using npm, though? It's not designed for their use case. Actually though you're just talking about some bugs in X, or possibly some design flaws in Y. Passing [EDIT, because bare objects are fine:] class instances around like that is the real code smell. So much coupling, so little cohesion. We call them "modules" because we like modularity.
It's not that packagers are using npm. It's that they might want to package a node application for their distro's package system, and now they have to sift through thousands of npm packages (already a nightmare). They can't just make a system package for every npm package, not just because that would violate packaging guidelines for any reasonable distro, but because one project can pull in multiple versions of a sin…
A distro that still packages python 2 (i.e. all of them) has a particular "velocity", and therefore it has no business packaging Node or anything written in it. Maybe a distro could package TJ's "n" tool (helpfully, that's written in bash rather than node), which would actually be handy for distro users who also use Node, but that's it.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#648Earlier quoted context omitted.
> It makes no sense to bring in a module from a third party adding yet another dependency and potential point of failure when reimplementing it yourself literally takes as long as it takes to find the module, add it to package.json and run npm install. Even if it does take the same amount of time (which it shouldn't), a 1-line call to a standard module imposes less of a future maintenance burden than 14 lines of cust…
> Even if it does take the same amount of time (which it shouldn't), a 1-line call to a standard module imposes less of a future maintenance burden than 14 lines of custom code. In my experience with using npm since it's release, module authors will spit out modules very quickly then, after some period of time, abandon them without passing them onto other people. At which point I have to assume all future maintenance…
Every line is another line that maintainers have to read and understand.
> The point being: where it's possible to mitigate and remove dependencies I think you'd be crazy not to. Every dependency you can lose is another potential build issue or attack surface you're removing from your project.
Disagree. If there are issues with npm shrinking not working then you absolutely need to resolve them - but resolving them is an O(1) problem no matter how many dependencies you have. Just like if you've already written a good general-purpose sorting function, there's no point writing a separate integer sort routine, even if the implementation could be simpler than the general-purpose one. You already depend on your packaging/dependency tools, so you might as well use them all the time.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#649Holy moly-- is-positive-integer/index.js: var passAll = require('101/pass-all') var isPositive = require('is-positive') var isInteger = require('is-integer') module.exports = passAll(isPositive, isInteger) I retract my previous statements that Javascript programmers are going down the same enterprise-y mess that Java programmers went down a decade ago. They've already taken it to an entirely different level of insani…
This comes up a lot when people discuss anything related to npm modules. It's easy to simply dismiss these trivial one-line modules as "insanity" and move on, but there's actually plenty of good reasons as to why many prefer to work with multiple small modules in this manner. This GitHub comment by Sindre Sorhus (author of over 600 modules on npm) is my favorite writeup on the topic: https://github.com/sindresorhus/a…
Anyone that has been around long enough has war stories about getting two relatively simple pieces of software working with each other. In my experience, integration problems are often the most difficult to deal with.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#650While in general I agree with the article I must admit that I also strongly DISAGREE with the overall message. Especially with this: "Finally, stringing APIs together and calling it programming doesn’t make it programming." Stringing APIs together is what actually programming is. This is building software and for instance when i use .toString() method I can easily forget how it is done, focus on other high level thin…
> Let's admit that the main problem here is with broken npm It is absurd to have packages suddenly retracted and important parts of the ecosystem stop functioning. This never happened with other languages I have used. Maybe we need a way to make sure the packages are always going to exist. Checksumming and adding the checksum to the version number would be useful too.