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

NPM and Left-Pad: Have We Forgotten How to Program?

haneycodes.net

Post reply on HN
Print view View original

741–750 of 887 posts

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#741

Post by adrusi »

jessaustin wrote: post #647
adrusi wrote: post #318

Earlier quoted context omitted.

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…

Is Node.js itself appropriate for packaging? I think maybe not. It changes really quickly, and has done for some time. Anyone coding in Node installs the particular versions she needs without regard to the distro. Most Node modules are just libraries installed in and for particular projects. There are tools written in node, but for the most part they focus on coding-related tasks that also tie them to particular proj…

I'm not talking about packaging node libraries for developers. No node developers are going to use system packages to install their libraries. What I mean is packaging applications written in node for end users.

For example, you can install Wordpress on Arch with `pacman -S wordpress' and you'll have a managed wordpress installation in /usr/share/webapps/wordpress. Then you just edit some wordpress config files, set up your http server to serve php from that directory, and you have a wordpress blog.

It would be nice to be able to do the same with Ghost.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#742

Post by Jtsummers »

TickleSteve wrote: post #666
lmm wrote: post #640

Earlier quoted context omitted.

Straight-up C is not at all suitable for safety-critical software. C plus various bolt-on tools for static analysis and the like can be usable, but is always going to be less effective (IMO) than a unified language where every tool is working according to the same rules. There might be a few legitimate use cases for C, but I've seen people pick it for the wrong reason so often (and using C because "it would be perfor…

You would have to argue with the overwhelming majority of safety-critical software that is and has been for decades, written in C... Of course, static analysis is always used in combination with proper coding style... but that is just the normal (professional) C development environment.

> You would have to argue with the overwhelming majority of safety-critical software that is and has been for decades, written in C...

> Of course, static analysis is always used in combination with proper coding style... but that is just the normal (professional) C development environment.

>> Straight-up C is not at all suitable for safety-critical software. C plus various bolt-on tools for static analysis and the like can be usable, but is always going to be less effective (IMO) than a unified language where every tool is working according to the same rules.

Pretty sure you've just restated GP's point in your second paragraph.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#743

Post by rantanplan »

nailer wrote: post #732
rantanplan wrote: post #729

Earlier quoted context omitted.

A 1-line of code module matches your needs exactly just for today . When you have 100 such modules which don't quite work and don't quite need after a month(quite a long time for a JS project to exist untouched), then your dependency hell shows its ugly head. If you had years of experience in a wide array of technologies and languages, you'd be aware of that which is, and has been, obvious to the rest of us for the p…

> A 1-line of code module matches your needs exactly just for today. Nothing about function length determines utility. There are many one lines that match many people's needs repeatedly. > When you have 100 such modules which don't quite work This is worrying. How are you picking the modules you use? 100x popular modules from npm - with git repos, unit tests, READMEs, and hundreds of other users - beat 100x functions…

Worry not my friend. I'll take the risk of being wrong. Up to now, it seems that there's consensus on the fact that the JS/frontend world is the worst offender when it comes to engineering robust software.

At least there are JS programmers that seem aware of it and agree that this has to change. So there's still hope I guess.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#744

Post by jmtd »

nailer wrote: post #578
saurik wrote: post #442

Earlier quoted context omitted.

> By relying on these small rigorously tested libraries they are avoiding the need to test their own code, and thus avoiding basic null check or conversion errors. In practice, many, if not most, of these one-line modules don't even work correctly, and it is difficult to get people to care to collaborate on fixing them instead of just replacing them with a new one-line module that works slightly better as the concept…

Odd, the ones I use all have tests, thousands of downloads, and active bug trackers. If I reinvented the wheel, or copy pasted, I wouldn't get those things.

The OP's example ( is-positive-integer) has tests, and is only three lines long, and is on major release version 3.X, because despite all that, it had serious problems in versions 1 and 2.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#745

Post by Bahamut »

nailer wrote: post #585
spion wrote: post #562

Earlier quoted context omitted.

Promise was clearly necessary, because without it we had hundreds of other less principled ways to implement async control flow :)

We had, and still prefer (looking at npm stats) the async module. Eg: promise.then(function(){}).then(function(){}) is not substantially different than: async.waterfall([function(){}, function(){}]) Promise advocates kept pretending async didn't exist though, and everybody was using callback hell.

There's a lot of old cruft using async (my current workplace being one of them) - bluebird also has 4x the downloads of async.

async is pretty terrible though, you cannot pass the results from one execution to another, i.e. passing results from one function in async.series to another, which results in developers tending to pollute variable scope by defining above and filling it in inside each callback. This prevents the ability to write clean isolated testable functions.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#746

Post by golergka »

gvdp wrote: post #680
golergka wrote: post #624

Earlier quoted context omitted.

> var isCapital function(s) { return s[0] === s[0].toUpperCase(); }; > isCapital("שלום"); true > isCapital("1"); true > isCapital('\uD83D\uDE00'); // Smiling emoji true > isCapital(\u279B); // Right-facing arrow true > isCapital("\u061Casd"); //Bidirectional control character true > isCapital(" "); true

If "true" is not a valid answer, what would've been one? Similar code in C# returns the same. E.g. Console.WriteLine("שלום".ToUpperInvariant()=="שלום") returns true.

Hebrew doesn't have upper and lower case, so the question "is this hebrew character capital" is meaningless. So, the function in question should not return just a boolean value; it should have a way to return a third option. (Whether it's nil, a C-style return code, an exception, an enum or something else is irrelevant here.)

Actually, it just means that if you're wondering "if this word starts with a capital", you're asking a wrong question. Instead, you should be asking "if this word is a valid generic name", or "is this word a start of a new sentence", and implement these semantic queries in a language-specific way.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#747

Post by spenuke »

usrusr wrote: post #675
fieryeagle wrote: post #335

Earlier quoted context omitted.

Just sugar-coated kool aid I'm hearing. Community benefits? First of all, I'm coding to get paid and this recent madness proved that JS ecosystem is semi-garbage. Back to the original question - do people really can't program that they need packages like left-pad or is-integer which had their own dependencies? Before writing those cool toolchains (which would likely work in a specific machine with a specific setting…

People need modules like leftpad to tick the "maintains moderately popular open source project" checkbox. Instant hirability. I don't want to claim that it would be a directly calculated career move, more like starting a blog: you admire a good blog, you want to be more like the blogger, you start your own one. On the dim chance that it will become both good and not abandoned after the third post. Nanomodules can be…

Yep, I think this is a huge, HUGE part of it.

Step 1: Create a culture in which "having open source contributions" is a requirement to entering said culture.

Step 2: Remove all friction from introducing open source contributions into the culture.

Step 3: Watch the Cambrian explosion.

Step 4: (Two years later) Point to the Cambrian collapse and how the new hot thing will solve everything.

I don't know what sort of shit show Step 4 will turn into, but it will also definitely be the result of folks taking a simple and good rule of thumb (this time, it won't be "small and composable"), and implementing it without ever stopping to think what problems it solves and doesn't solve.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#748

Post by kungtotte »

haberman wrote: post #198

> In my opinion, if you cannot write a left-pad, is-positive-integer, or isArray function in 5 minutes flat (including the time you spend Googling), then you don’t actually know how to code. Spoken like someone who writes functions in 5 minutes that I find bugs in later. Just because a problem is simple to describe informally doesn't mean it is simple to implement without bugs.

It would be trivial if the language lent itself to trivial solutions and there wasn't a culture of trying to anticipate and catch really messed up error cases that results largely from user errors.

In Python I would write ´if num > 0´, if it matters that it is an integer I would cast it to int, and that handles everything you should be handling at that level. If your user passes in a list instead of a number type, the code should crash because then there's probably an input error somewhere. If a user has monkeypatched a base class to make a number into something else the code should also fail and you deserve whatever happens to you.

Catching every possible error is a mistake.

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#749

Post by [deleted] »

chukye wrote: post #681

Man, I have to quote: `In my opinion, if you cannot write a left-pad, is-positive-integer, or isArray function in 5 minutes flat (including the time you spend Googling), then you don’t actually know how to code.` You would be surprised of how many developer these days have 'afraid' to write such functions, or how lazy they are, they found this thing and just add to a project, then push to some google list and the pro…

[deleted]

Re: NPM and Left-Pad: Have We Forgotten How to Program?

#750

Post by yAnonymous »

lewisl9029 wrote: post #206
runin2k1 wrote: post #7

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

The reasoning makes sense for small modules that might change in the future, but as he says himself, most of his modules are finished and will never change. That makes many arguments in his post moot and the modules should probably be snippets instead that are implemented directly.
Post reply on HN