Live data from Hacker News

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

haneycodes.net

611–620 of 887 posts

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

#611
post #570
post #420

Earlier 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?

> What's not to like?

That depends; in the case of mathematics libraries they have to be bundled together because of functional dependencies. It's either that or ignoring DRY principles -- which if you do that, you're ignoring the entire point of what breaking things into submodules is intended to do.

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

#612
post #583
post #566

Earlier quoted context omitted.

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

Not that I agree with micro modules (I would rather see a set of js core libs), but your code fails with empty strings.

Maybe F1axs knows that at this particular spot the string will never be empty? There are two philosophies in libraries; one is to check for every possible error in the lib function, the other is to state the pre-conditions in the documentation.

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

#613
post #570

Earlier quoted context omitted.

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?

Having a full set of math functions isn't kitchen sink, it's the right level of granularity for a module. If I want math functions I really want them to all be written by the same author and kept in lock-step as a unit. Why don't you want the whole module? Because it's bloat? Surely it's far less bloat than one submodule per function?

A lot of javascript is going to be deployed to a website.

Every line of code that isn't used is bytes you're sending to every user unnecessarily

> Surely it's far less bloat than one submodule per function?

How is that bloat? It's the same LoC whether it's 1000 modules or 1 after it's been compiled/minified

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

#614
post #382

The Python community has a proper response: https://pypi.python.org/pypi/left-pad/ /s

Then you can do variants.

A Java left pad implementing a Padder class instanciated by a PadderFactory that you can get by a PadderInjector from a PadderRegistry all that accepting an AbstractPaddingString.

Then one in Ruby where you monkey patch the string to that it pads, then add an AUTO_PAD settings set to True by default and a fluent API to chain padding.

Then one version PHP version containing pad_string, then real_pad_string that deals with unicode, then real_pad_string_i_swear_this_time that that call str() on parameters automatically.

Then a Haskell one with a monad and a trampolin and some |=> giberrish to mix it all.

Then a Go one that creates a string padding microservice. With a docker file, just in case.

And the last trend in Python, an aio_string_pad which gives you an asyncronous padding coroutine, but under the wood calling run_in_executor, and optionally auto start an event loop.

This is 99 bottles of beer all over again.

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

#615

Yes, or more accurately a large new generation of coders is entering the workforce who know how to code only in a superficial sense and think this is a good thing. Programming, and especially startup programming, is being taken over by people who are primarily technicians rather than engineers. They want to assemble prefab components in standardized ways rather than invent new things. They are plumbers who know how t…

an engineer is more like a plumber than an inventor though.

you don't need to design a new type of screw to make a one off aquaduct, you don't need to design new bearings to make a gear box, you don't need to design a new opamp to make an amplifier, nor do you need to design a new MVC framework to make a one off CRUD app.

You use off the shelf parts and combine them with your knowledge and skills to produce and effective solution for your constraints. If you can't do it with existing stuff, then you design something new that can do it.

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

#616

Earlier quoted context omitted.

Edge cases for a padding function? Your comments make me think that the author's point is valid.

Edge case for left padding - when you provide empty string as padding filler. It can go into infinite loop if not written correctly.

[deleted]

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

#617
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…

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.

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

#618
post #344

Earlier quoted context omitted.

That recursive node_modules or whatever it is called was what made me hate this whole npm thing, specially because it is not centralized somewhere in my computer. And that means the same files a few times repeated on my drive just eating space. Being a Java developer I don't understand why the approach was not more like maven.

npm does a decent enough job deduping shared packages. The reason is different packages consume different versions of things. Java only lets you have a single version of a package. If the API changes, it can be a pain when your dependencies were written for different versions. That slows adoption since you have to wait until everyone you depend on has updated first.

Are you thinking of the new flat-tree npm? Because in my 1.3.10 installation, I see this:

    $ find node_modules/ -type f | wc -l
    56278
    $ find node_modules/ -type f | xargs md5sum | gawk '{print $1}' | sort | uniq | wc -l
    8545
That's a lot of duplicate files.

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

#619

Earlier quoted context omitted.

Having a full set of math functions isn't kitchen sink, it's the right level of granularity for a module. If I want math functions I really want them to all be written by the same author and kept in lock-step as a unit. Why don't you want the whole module? Because it's bloat? Surely it's far less bloat than one submodule per function?

A lot of javascript is going to be deployed to a website. Every line of code that isn't used is bytes you're sending to every user unnecessarily > Surely it's far less bloat than one submodule per function? How is that bloat? It's the same LoC whether it's 1000 modules or 1 after it's been compiled/minified

Bloat in the source code, build system, dependency management, overheads per submodule, complexity.

I'm not arguing that there shouldn't be a math module but that you shouldn't split it up into such (imho) crazy small parts.

Closure Compiler can remove any unused functions.

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

#620

Earlier quoted context omitted.

I'm going to keep writing stuff in JS, and I'm going to keep loving it. Why do you like it? Serious question.

I'm very hesitant to answer this, as i know it will bring on angry comments and people telling me i'm wrong, but i'll give it a shot (this is all literally off the top of my head right now, so if you are going to poke holes in it, cut me some slack) This got a lot bigger than i thought, so strap in! * The lack of "private" anything. This sounds like a bad idea, but I firmly believe it was a major reason for JS's succ…

Not sure I agree with some of your points but you most likely have used Javascript more than I since most of my professional experience is with enterprise Java. Let me try to show you how I see the programming world through my Java-colored glasses :P

"The lack of 'private' anything" - Just hearing this caused immediate revulsion and I am sorry to say that. Where I come from, the best practice is to try to keep everything closed from modification but still open enough for extension: http://www.cs.utexas.edu/users/downing/papers/OCP.pdf

"The debugging" - The features you mentioned are all available in the Java ecosystem as well. It is a very mature ecosystem with great IDEs, debuggers, performance testers, etc. The step-back and edit feature of debugging has been around for awhile now. Heck, you can even write your own debugger fairly easily due to good support of other tools in the ecosystem.

"async programming" - Not sure what you mean by "first-class citizen", but asynchronous programming can also be done with Java as well. Callbacks and futures are used widely (at least where I work). But even better: Java is multi-threaded. What happens to the Node.js server if a thread is getting bogged down?

"the mix of functional and OOP" - I admit I have no experience with functional programming so I can't say anything about mixing the two paradigms together. But I have seen OOP with Javascript and frankly, it is confusing and unwieldy. I don't even think the concept of class as an object blueprint exists. How do you even create a class that inherits the properties of another Javascript class? It is one of the basic ideas of OOP but I don't think Javascript supports it. From my brief time with it, it really looks like you only have simple objects with properties and methods which can be set up off of a prototype but that's it.

"it's fast" - Not sure where you got this idea. Looking at various benchmarks on the internet, they show that Javascript is significantly slower (sometimes by an order of magnitude) compared to Java, Go, and C++. I did notice that it looks to be faster than Python and Ruby. https://www.techempower.com/benchmarks/#section=data-r12 https://benchmarksgame.alioth.debian.org/u64q/javascript.htm...

"the compilation options" - I'm assuming you're are talking about transpilers and yes, I've been noticing more transpilers that target Javascript. I honestly don't know why one would want to do that though. It just seems an unnecessary layer. Why not just directly write Javascript code? Is the Javascript syntax so bad that you want to code in pseudo-Ruby (Coffeescript)? :)

"the tooling" - Hot swapping, test frameworks, linting, optimizing, ...these are also available in the Java ecosystem and have been for quite some time now. Notice I didn't mention auto-refresh, minifying, and compressing since I am not sure what exactly those are and I don't think they apply to compiled languages.

"npm" - The available libraries in the Java ecosystem is vast and a great number of them have been developed and iterated upon by some of the best engineers and computer scientists in the past ~20 years. And the Java libraries do not seem to have the problems that npm is suffering at the moment :P

Post reply on HN