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

591–600 of 887 posts

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

#591

Post by lmm »

ksenzee wrote: post #75
atjoslin wrote: post #11

Counter-argument: A good micro-module removes complexity. It has one simple purpose, is tested, and you can read the code yourself in less than 30 seconds to know what's happening. Take left-pad, for example. Super simple function, 1 minute to write, right? Yes. But check out this PR that fixes an edge case: https://github.com/azer/left-pad/pull/1 The fact of the matter is: every line of code I write myself is a comm…

> every line of code I write myself is a commitment That's true. However: Every dependency you add to your project is also a commitment. When you add a dependency, you're committing to deal with the fallout if the library you're pulling in gets stale, or gets taken over by an incompetent dev, or conflicts with something else you're using, or just plain disappears. If you add a dependency for just a few lines of code,…

Maintaining a dependency on a library should be much less effort than maintaining 17 lines of code. If it isn't that's a deficiency in your dependency infrastructure.

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

#592

Post by joantune »

ksenzee wrote: post #107
joantune wrote: post #87

Earlier quoted context omitted.

OR: you depend on a specific version of the library, that you know that works, and you have none of those problems.

You can't escape problems by bundling specific library versions. You just get a different set of problems. When you require a specific version of a library, you're making your code incompatible with anything that requires a higher or lower version of that library. You're also assuming there will never be a security fix that requires you to update your dependency.

You just get a different set of problems. When you require a specific version of a library, you're making your code incompatible with anything that requires a higher or lower version of that library. You're also assuming there will never be a security fix that requires you to update your dependency.

If there is a security fix, you should bump your dependency by hand, the other problems that you pointed out do not exist in Node (and it's about time they disappear in Java)

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

#593

Post by TickleSteve »

lmm wrote: post #589
TickleSteve wrote: post #486

Earlier quoted context omitted.

It already is on the server-side. Feel free to use C; at least it would be performant.

It's easy to write code that does the wrong thing quickly in any language, and IME that tends to be the usual result of choosing C.

ok, you are aware that the vast majority of the worlds software is written in C.... yes there are problems with it but it is still suitable for real-time, embedded, safety critical software of the sort I've been making quite successfully for close to 30 years.

Don't fall into the 'C is the devil' trap, any tool can be misused.

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

#594

Post by xorcist »

imron wrote: post #466
coldtea wrote: post #354

Earlier quoted context omitted.

> TL;DR: Small modules are easy to reason about, and encourage code reuse and sharing across the entire community. How does that even remotely applies to the "is positive integer" test, and even more so to "it's positive" and "it's integer"? What's next? is-bigger-than-5? word-starts-with-capital-letter? add-1-to-a-number?

Not defending javascript because I dislike it immensely, but with javascript being a dynamically typed language, and with the way it handles implicit conversions between types, and with trickiness around NaN, Infinity and null objects, there are sufficient edge cases that writing a correct function to test if some variable contains a positive integer is not as trivial as it is with more sane languages, and is likely…

(That's the whole point of using a dynamic language, what '>' actually does depends on the surrounding code. If you want '>' to type check you should be using a type safe language to begin with.)

The issue I have with this is readability. Type '>' and I know exactly what it does, I know what implicit conversions are involved, and how it would react to a null object. Type 'isPositiveInteger' and I need to check. I can not read your code fluently anymore.

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

#595

Post by eterm »

scrollaway wrote: post #247
meric wrote: post #236

NPM modules can be used on browsers. On browsers, space is a premium. Why would you want to install a 500kb dependency that has only one function you need, when you can install a 10kb dependency that has it? Would you want each of your five 20kb dependencies to re-implement the same 5kb function, increasing the code you must send to the client by 20%, or would it be more optimal for each of those dependency to use th…

It's quite ironic how you're lecturing people about dependencies and bandwidth when you yourself don't seem to have a good grasp in your mind of how immense even 5 kilobytes is (you talk about 5kb functions). 5 kilobytes (well, KiB) is 5120 bytes. That's about 200-300 lines of code. If you're talking about minimized code, maybe up to 500 lines.

While a 5kb function is immense, I work on a legacy code base and I have seen functions up to 2000 lines long. You possibly overestimate the quality of code that people in business actually write. I've worked in a few places and all have parts of the code which I would thought were made up if submitted to the dailywtf.

Also, have you ever seen a commercial library require >2MB of minified JS? Here's an example:

http://cdn.wijmo.com/jquery.wijmo-pro.all.3.20153.84.min.js

That file is almost 2MB minified (5.6MB unminified).

And that is is only 1 of the few different files required for our dependency on it, there is a bunch more javascript/css also required. Would I use that library on a new product? I'd probably advise against it due to the size, but a legacy product has dependencies and you don't have the freedom to rewrite everything all the time.

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

#596

Post by lmm »

Klathmon wrote: post #239
AgentME wrote: post #201

Earlier quoted context omitted.

Wow, I feel like I could have written this. Back when I used Python, I had a folder full of functions I would copy-paste between my projects. (And maybe some of the projects contained unit-tests for the function. I didn't always keep those tests in sync.) Updating them was a pain because inevitably each one would get slightly modified over time in each project separately. Eventually, I bundled all of them into a bund…

I feel exactly the same. There is something about JavaScript that makes people go a little crazy both for and against it. I've never seen so many programmers advocate copy/pasting code before... 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…

> 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.

If you ever get the chance I'd strongly recommend trying a small project in a strongly-typed functional language - PureScript if you're targeting the browser, otherwise Haskell or Scala, or maybe F# or OCaml. (Scala and OCaml also have compile-to-JS options). If you find you don't like that style then fair enough, but it's well worth trying one language in that space and getting a sense of the techniques that it enables - it will make you a better programmer even if you end up going back to JavaScript or another language from your list.

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

#597

Post by TickleSteve »

serge2k wrote: post #554
TickleSteve wrote: post #483

Earlier quoted context omitted.

Two points: - Breaking out is-positive-integer hasn't reduced the number of paths to test. You have not gained anything, you've added overhead. - 100% test coverage is rarely a good thing. It is required for safety critical areas like avionics. I can guarantee that your JS code is not making into any safety critical environment!

> 100% test coverage is rarely a good thing Do you mean rarely useful, or actively harmful?

Both in a way.

What happens when you have a "100% test coverage" requirement is that people don't think about the tests, they simply make tests to force the code down every path without thinking whether it was intended to operate like that.

For example if the is-positive-integer had a silly test for "if(value==23) return false", a requirement for "100% test coverage" would simply result in someone creating a test for that condition instead of considering if it was actually a fault.

100% test coverage != no faults.

What you have done by generating 100% test coverage is effectively 'frozen' your code and made it harder to implement any changes.

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

#598

Post by majewsky »

Fiaxhs wrote: post #566
golergka wrote: post #492

Earlier quoted context omitted.

Do you seriously think that "word starts with a capital letter" is an easy function to write? I feel like you haven't spent enough time with Unicode.

return string[0] === string[0].toUpperCase(); You're welcome!

This will give

  startsWithCapitalLetter("!") == true
which is not what you want.

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

#599

Post by lmm »

nv-vn wrote: post #186
chipotle_coyote wrote: post #51

Earlier quoted context omitted.

I think the article's thesis is essentially that every dependency your project pulls in -- which includes all the dependencies your dependencies pull in -- is a point of potential failure. I understand the "don't re-invent the wheel" defense, but the Node/JavaScript ecosystem tacitly encourages its users to build vehicles by chaining together dozens of pre-made wheels, all of which depend on more wheels, and each and…

Worse yet, a backdoor or legitimate bug in any of these module could leave huge exploits in the entire Node.js ecosystem.

A backdoor or legitimate bug in any line of custom code could leave huge exploits in your system. A widely-used published module is likely to be much more reliable, at least on average.

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

#600

Post by lmm »

BinaryIdiot wrote: post #73
NathanKP wrote: post #6

I don't see anything wrong with using a pre-made left pad function. Why waste time and lines of code implementing something so trivial when there is already a solution available? However, I agree it is ridiculous to have a dedicated module for that one function. For most nontrivial projects I just include lodash, which contains tons and tons of handy utility functions that save time and provide efficient, fast implem…

> Why waste time and lines of code implementing something so trivial when there is already a solution available? Because it's so trivial? I can't wrap my head around why this is an argument in the first place. 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 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 custom code.

> People should be trying to limit dependencies where possible. Reproducible builds are really important if it costs you almost no time you should have it in your code base IMO.

That's a non sequitur. Reproducible builds are important, but unless you write code with 0 external dependencies you already have a system in place for handling library dependencies in a reproducible way. So why not use it?

> People taking the DRY principle to the most extreme degree always makes for the worst code to debug and maintain.

This is the opposite of my experience.

Post reply on HN