NPM and Left-Pad: Have We Forgotten How to Program? • Hacker News Board

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

#851

Post by wtbob » Fri, Mar 25, 2016, 2:25 AM UTC

mreiland wrote: post #780

wtbob wrote: post #671

Earlier quoted context omitted.

> ye ole Lines of Code paradigm Little-known fact: the *y in old signs is actually a 'þ', which is an Old English letter named 'thorn' and pronounced like modern 'th.' Thus, the old books & signs were really just saying, 'the.' Incidentally, þ is still used in modern Icelandic. Completely off-topic, but I þought you might be interested.

holy shit, I had no idea. That's cool. edit: and I double checked, because the internet :) http://www.etymonline.com/index.php?term=ye it's true! that's awesome.

I really þink ðat we ought to use þ and ð in modern English, but oddly enough no-one agrees wiþ me:-)

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

#852

Post by paulddraper » Fri, Mar 25, 2016, 2:43 AM UTC

Retric wrote: post #765

geetee wrote: post #736

Earlier quoted context omitted.

You can't republish with the same version number, so you would be protected if you're pinned to a specific release.

At which point you don't get bug fixes. This is an old problem and there is no good solution.

You get bug fixes when you upgrade, deliberately.

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

#853

Post by MaulingMonkey » Fri, Mar 25, 2016, 3:25 AM UTC

nradov wrote: post #786

MaulingMonkey wrote: post #543

Earlier quoted context omitted.

> #include #include #include #include I've written worse - at least those cover multiple variations each (or overloads in C++ for float/double/std::complex?/...) While I'm not a fan of the enforced java route of 1 file = 1 class, I do trend towards 1 file ~ 1 (main, public) thing - which might be a single function with no overloads. #include ? Better than #include , which I see far too often... I don't have to figure…

Java doesn't enforce 1 file = 1 class but rather 1 file = 1 public class, which is exactly what you asked for. You can put as many private classes in the file as you want.

Not exactly - I didn't ask for enforcement, and the irritation usually arises from wanting the occasional secondary type - such as an enum - to be part of the public interface (thus forcing the type itself to be public, naturally) without either:

1) moving it into a separate file, for the simplest two value one liner

or

2) making it interior to the other class, with all the verbose lengthy names (and semantic implications) that this might entail.

I want clear and concise names, so I lean towards #1. And if an enumeration gets more shared between multiple classes, or collects enough values and comments to merit it, sure, I'll move it into it's own file. But forcing me to shove it in a separate file before I've even decided on the best name (meaning I need to rename the file repeatedly as well), and before I'm even certain I'll keep that specific enumeration, is just meaningless friction.

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

#854

Post by fieryeagle » Fri, Mar 25, 2016, 4:03 AM UTC

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…

I would give those candidates the FizzBuzz problem just to see if they can actually code from scratch or `require('fizz-buzz-solver');`. I care more about their competence than what 1 or 10-liner packages they maintain.

On the contrary, I would certainly mark "maintains moderately popular open source project" as a calculated career move, just like how prostitutes would dress up right for the cliente. Sorry for the crude example but I am not placing the blame on the devs here but the absurd notion of employers considering a GitHub repo the 'in' thing before actual capability. Candidate - Brah I got 10 of those packages with 10mil downloads in total but I can't code for shit. Hiring manager - Since we are suckers who look at stats, you're hired!

The problem with this nanomodules approach is that it results in complacent and naive developers that eschew the basics and just publish random crap. Anything can make it to be a NPM package and be judged by...popularity? Since when is code turning into pop music :)?

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

#855

Post by jdd » Fri, Mar 25, 2016, 5:12 AM UTC

zbuttram wrote: post #274

zbuttram wrote: post #23

Earlier quoted context omitted.

Some of the libraries people were mentioning broke yesterday already have lodash as dependencies, I have no idea why they wouldn't have just been using this...

Someone mentioned below that lodash had some breaking changes related to the padding functions a couple times, which could be a totally valid reason to avoid using those. I was under the impression that the lodash API was more stable than to have that kind of thing happening.

Lodash renamed padding on a major version bump (which requires opting into) to better align with the ES7 proposal.

Nothing was done in a way to pull the rug out from underneath folks.

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

#856

Post by tedmiston » Fri, Mar 25, 2016, 5:51 AM UTC

gizmo385 wrote: post #451

tjmehta wrote: post #339

Earlier quoted context omitted.

Author of "is-positive-integer" here. I will admit the implementation is pretty funny, but I move-out all single-purpose utils out of projects to modules for a bunch of reasons. DRY is the most obvious one, but one that may be less obvious is for better testing. I move out modules so I can write really nice tests for the independent of the projects I am using them in. Also, I tend to write projects w/ 100% test cover…

"DRY is the most obvious one, but one that may be less obvious is for better testing." Isn't that why we just write functions? Turning simple functions into entire modules just adds an unnecessary level of abstraction that helps nobody.

Of course that's why we write functions. But we can't share a function with others and across projects... so we make it into a module to do that.

It's like (micro)crowdsourcing (the smallest components of) the standard library that JavaScript never had.

Some bit of logic could go from being DRY in one project, to DRY in all of my projects, ... to eventually be DRY in all projects. It's globally DRY.

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

#857

Post by tkxxx7 » Fri, Mar 25, 2016, 5:53 AM UTC

paulddraper wrote: post #852

Retric wrote: post #765

Earlier quoted context omitted.

At which point you don't get bug fixes. This is an old problem and there is no good solution.

You get bug fixes when you upgrade, deliberately.

This is what everyone should do ideally, but that means your solution is conscientiousness, and good luck spreading that across all your dependencies.

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

#858

Post by nnq » Fri, Mar 25, 2016, 6:03 AM UTC

Ciantic wrote: post #580

nnq wrote: post #503

...maybe it's time a committee of really smart people sit and sip through all the most used modules below N lines of code or smth, and just write an opensource JS-stdlib, hopefully merging in top 30% most used methods of Lodash too? Node/NPM is a great example of why too much democracy and decentralization is bad . Just gather some experts and have them centrally plan a "standard library" then impose it as "industry…

There is also a big programmer efficiency to be gained by having batteries included library: The new person coming to a project has learned the same batteries already, and it need not to re-learn new set of minipackages the last person working on a project has used. In fact this should be the key selling point for stdlib to JavaScript. It actually saves money from their employers if trivial functions are mostly in th…

> there is a lot of hate for Python's "kitchen sink" library in JavaScript world

Is there? Most "js people" have never had the pleasureful experience of working with a "pleasantly opinionated" language like Python and the similar feel of its libraries, even the 3rd party ones.

Really, there's something really awesome in the Python ecosystem that should be spread to others before node takes over the world: If done right, being opinionated ("one way to do it") and centrally planned (a BDFL or smth like that) is A GOOD THING for an open-source language/infrastructure project! And it's also good if you extend the philosophy to the libraries and frameworks. Don't ditch the baby with the bathwater!

But I have a really hard time translating this message to "node-speak" unfortunately... Thanks for the "saves money" tip though, never thought of that, will try it ;)

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

#859

Post by BinaryIdiot » Fri, Mar 25, 2016, 6:13 AM UTC

lmm wrote: post #845

BinaryIdiot wrote: post #813

Earlier quoted context omitted.

> Every line is another line that maintainers have to read and understand. Seriously? This is what you're going with? We're talking about very simple, elementary programming. To be worried about maintaining code that you learn how to do in the first few classes of any programming 101 class is absolute insanity. > Disagree. If there are issues with npm shrinking not working then you absolutely need to resolve them Can…

> Seriously? This is what you're going with? We're talking about very simple, elementary programming. To be worried about maintaining code that you learn how to do in the first few classes of any programming 101 class is absolute insanity. Every line is a maintenance burden - just reading and understanding the code is what takes most of the time. Lines of code (and notably not any measure of "complexity" of those lin…

> Every line is a maintenance burden - just reading and understanding the code is what takes most of the time. Lines of code (and notably not any measure of "complexity" of those lines that's been tried) is the one thing that correlates with bug rates.

I'm sorry but that is just a horrible way to look at programming.

You shouldn't NEED to go out and look for an already done solution if it's elementary and takes minutes, if that, to write. Ever.

This is just sloppy.

> So figure out a process and resolve that, once and for all.

Tell yourself that; that was simply a counter argument to your false claim. Regardless it's fixable.

> There's no point just cutting 10% (say) of your dependencies and hoping that you won't encounter the problem on your more important dependencies.

This doesn't even make sense. What are you trying to convey here? The more dependencies you can cut out the more reproducible your builds will be. Period. Which is important when you're dealing with code that gets rapidly deployed to many production boxes.

> That's exactly why people were depending on this library.

If using left pad gave them time back because the original author could do it better, faster and cheaper...I'm not sure programming is the right type of work for these people.

What's next, are you going to outsource all your for and while loops to a module? You know, so you have less things to "maintain"?

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

#860

Post by Too » Fri, Mar 25, 2016, 7:38 AM UTC

nbzklr wrote: post #223

lsiebert wrote: post #130

Earlier quoted context omitted.

You know what's worse? Javascript numbers are all floating point numbers, which means integers are 53 bits long. So, you might think this library would try to address issues this can cause, but nope, this is the average statement you'd write if you didn't know was a mantissa was and had never heard of big.js, bignumber.js, decimal.js, crunch.js or even strint (which represents integers as strings because wtf not).

That's not true. In most javascript implementations, integers will be represented by real 32 bit integers.

Source? I find this very hard to believe. 1. How does the engine know of it should be an integer or not? 2. Why would they have a special case for this, it won't benefit accuracy and treating them in a special way probably hurts performance more than just always keeping it as doubles.