Live data from Hacker News

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

haneycodes.net

651–660 of 887 posts

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

#651

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…

Completely agree.

Combining this with isomorphic code, cross-browser development and micro-services.

I even wrote a blog post couple of days ago about it [1].

1 : http://www.drinchev.com/blog/increase-your-dependencies/

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

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

> They've already taken it to an entirely different level of insanity.

Why is this insane? What alternatives would be better?

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

#653

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

In the compiled artifact there might not be a difference. But developers tend to ignore the issues outside their scope. So yes, for a developer it might not make much difference. For people who need to make sure that you can compile and deploy, it's much more complexity.

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

#654
post #571

Earlier quoted context omitted.

> Maybe some people have so little to do that they can author or find a relevant package for every single ~10 line function they need to use in their code and then spend countless commits bumping project-versions and updating package.json files. I have no idea how they get work done though... Rather than copy paste someone else's unmaintained thing and handle all the bugs, or write their own code and unit tests, they…

If you don't know how to write a function to left-pad a string without copy & pasting, you have other problems..

What makes you think people who don't write their own left pad function can't write a left pad function?

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

#655

Going down the "lots of tiny modules" route is about these three things: a) No standard lib in JS b) JS is delivered over the internet to web pages in a time sensitive manner ... so we don't want to bundle huge "do everything" libs. Sometimes its convenient to just grab a tiny module that does one thing well. There isn't the same restriction on any other platform c) Npm makes it really easy to publish/consume modules…

Note for b): If you include libraries such as jQuery on you website via CDN, I believe browsers will be able to use the cached version even if they never visited your website before (given that they've cached this version from the same CDN before).

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

#656

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.

If you've called it with an empty string there's probably a bug in your calling code which you'll want to test for anyway.

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

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

> Not that I agree with micro modules (I would rather see a set of js core libs)

Why not both? If you just want one part of a module, you can just import the dependency directly, if you want a whole core lib, you can do that.

Some people really like underscore and import that. I use ES6/7 functions for the most part, but underscore has some useful things I can import on their own.

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

#658

Earlier quoted context omitted.

Small modules are easy to reason about Yes they are, in the same way that a book in which every page consists of a single word is easier to understand than one with more content per page. By focusing on the small-scale complexity to such an extreme, you've managed to make the whole system much harder to understand, and understanding the big picture is vital to things like debugging and making systems which are effici…

Sorry for the nitpick, but "hyperabstraction"? left-pad isn't even slightly abstract.

It's not.

The hyperabstraction is in how even tiny functions like this, isPositive, isArray, etc. are being abstracted and turned into individual modules.

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

#659
post #515

Earlier quoted context omitted.

He described not Link Time Optimization (-flto), but the very basic linker functionality: to only include required functions. C/C++ has a weird compilation model where each source file is translated to machine code separately, with placeholders for unknown function addresses. Thus it is trivial to take only required functions. -flto, on the other hand, allows to reverse this process to allow interprocedural optimizat…

@TickleSteve below me: "without this, removal is only performed within the compilation-unit" Not quite. When you link to a static library ( .a) with lots of .o object files in it, only those object files will be linked that are actually used by your program. I first learned about this when I looked at the source of dietlibc, and wondered about every function being in a separate file. That enables the aforementioned t…

Thanks for the correction. Didn't know that.

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

#660

Earlier quoted context omitted.

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

Write a damn unit test for your padding function. We should share unit tests, not one-line libs. Libs with unit tests can be one-liners and be as fine-grained as we like, since it's something your users don't have to download

> We should share unit tests, not one-line libs.

Most of the small libs I've shared are mainly sharing unit tests.

Here's a function I've shared on npm:

  var kind = function(item) {
    var getPrototype = function(item) {
      return Object.prototype.toString.call(item).slice(8, -1);
    };
    var kind, Undefined;
    if (item === null ) {
      kind = 'null';
    } else {
      if ( item === Undefined ) {
        kind = 'undefined';
      } else {
        var prototype = getPrototype(item);
        if ( ( prototype === 'Number' ) && isNaN(item) ) {
          kind = 'NaN';
        } else {
          kind = prototype;
        }
      }
    }
    return kind;
  };
The tests:

  suite('kind', function(){
    test('shows number-like things as numbers', function(){
      assert(avkind(37) === 'Number');
      assert(avkind(3.14) === 'Number');
      assert(avkind(Math.LN2) === 'Number');
      assert(avkind(Infinity) === 'Number');
      assert(avkind(Number(1)) === 'Number');
      assert(avkind(new Number(1)) === 'Number');
    });
    test('shows NaN as NaN', function(){
      assert(avkind(NaN) === 'NaN');
    });
    test('Shows strings as strings', function(){
      assert(avkind('') === 'String');
      assert(avkind('bla') === 'String');
      assert(avkind(String("abc")) === 'String');
      assert(avkind(new String("abc")) === 'String');
    });
    test('shows strings accurately', function(){
      assert(avkind(true) === 'Boolean');
      assert(avkind(false) === 'Boolean');
      assert(avkind(new Boolean(true)) === 'Boolean');
    });
    test('shows arrays accurately', function(){
      assert(avkind([1, 2, 4]) === 'Array');
      assert(avkind(new Array(1, 2, 3)) === 'Array');
    });
    test('shows objects accurately', function(){
      assert(avkind({a:1}) === 'Object');
      assert(avkind(new Object()) === 'Object');
    });
    test('shows dates accurately', function(){
      assert(avkind(new Date()) === 'Date');
    });
    test('loves Functions too', function(){
      assert(avkind(function(){}) === 'Function');
      assert(avkind(new Function("console.log(arguments)")) === 'Function');
      assert(avkind(Math.sin) === 'Function');
    });
    test('shows undefined accurately', function(){
      assert(avkind(undefined) === 'undefined');
    });
    test('shows null accurately', function(){
      assert(avkind(null) === 'null');
    });
  });
Post reply on HN