Live data from Hacker News

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

haneycodes.net

441–450 of 887 posts

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

#441
post #420

Earlier quoted context omitted.

Perhaps another reason for this is that Javascript is inherently unsafe. 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. Other languages handle this with compilers, may be strongly typed, and/or have features that don't allow nulls. Javascript doesn't exactly have that luxury. So maybe it makes sense in J…

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.

Oh, but javascript is dynamically typed, so it doesn't matter if your sin-module works with a different kind of arbitrary-precision decimal number module than your geolocation module, your cosine module or your openg-draw-triangle or opengl-draw-circle modules... /sarcasm

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

#442

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…

Perhaps another reason for this is that Javascript is inherently unsafe. 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. Other languages handle this with compilers, may be strongly typed, and/or have features that don't allow nulls. Javascript doesn't exactly have that luxury. So maybe it makes sense in J…

> 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 of complex collaboration to perfect one line of code is so foreign to a generation of developers who would rather just throw code to the world and never look back (an issue made all the worse as tiny bugs in these one-liners can almost seem dangerous to fix when you aren't really sure how they are being used: maybe it actually is better to not fix anything and just have people rely on the replacement better module :/).

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

#443
post #223

Earlier quoted context omitted.

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

How does storing integers in 32-bit values help the issue of integers being truncated to 53 bits?

Clearly 2^32+2^32 < 2*53, so there is no problem ;-)

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

#444
post #134

Nobody has forgotten. These people never knew to begin with. NPM/JS has subsumed the class of programmer who would have previously felt at home inside PHPs battery-included ecosystem. Before that, a similar set of devs would have felt at home with Visual Basic. Seriously, go visit the comments section on archived copies of the PHP documentation. You'll find code of a similar nature. If PHP had had a module system 10+…

The huge difference is that PHP package manager support namespaces and dependencies ARE FLAT. You cannot import 2 versions of the same package under the same namespace. Which

1/ forces package authors to write stable libraries

2/ forces dependencies to narrow the versions of their dependencies

3/ prevents name squatting to some extent. You cannot have a package named "forms" and then sell the name for real money, like seen on NPM. your package needs to be "namespace"/"name". NPM made a huge mistake with its gems like global namespace and it explains half the problems it is having today.

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

#445

Earlier quoted context omitted.

Every once in a while, I come to HN, and inevitably find a post about some new JavaScript technology on the front page, wherein I find some comment that gives me a new appreciation for the web app language I use at work, which fortunately is not JavaScript.

What is the web app language you use at work? I assume you're talking about something that runs on the client -- a web browser -- so it probably compiles down to JavaScript, right? JS literally has no numeric type that isn't a float, so how does your language escape this fundamental limitation?

Not OP, but I used Google's Long.js (among other things) in a project[0] to get around the limitation of not being able to do as in Python:

    import fractions
    print str(fractions.Fraction.from_float(0.3333).limit_denominator(10))
Almost anything that compiles to JS would be better than by-hand JS; I'd love to use ClojureScript with re-frame at work...

[0] http://www.thejach.com/pseudo-public/webgl_coursera/assignme...

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

#446
post #377

Earlier quoted context omitted.

We could have something similar with full dependent types a la Idris: you could write a proof and search for a function that satisfies it. If such a thing were popular and huge amounts of Idris code were written, you could write only proofs for your program and the Idris system could go download and piece together your program! That would be very cool, but I'm not sure how much easier it would actually turn out to be…

Similar idea but what if you were to write your tests first and then upload them to a site that pieces together the required modules to pass them and generates an API against the modules.

Because finding code that passes arbitrary tests is undecidable in the general case.

(Same reason the pseudo-Idris language would have to be non-Turing-complete)

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

#447
post #210

What would happen to all those NPM projects if GitHub is destroyed? I don't think it will close anytime soon, but lets say, a meteor shower hits GitHub data center or something along the lines of this.

I still find it hilarious that, upon the bulk of SCM use shifting to a DVCS, the first[1] thing people did is run out to build a central hub. [1] For the pedantic, it probably was not literally the first thing; I'm sure some folks went to the rest room, others ate something, still others took a nap.

The thing with DCVS is not that central hub does not exist. It is that you do not need specific central hub. That means if github dies, I can take any of my git repos I checked from github and continue working with them, and create a local git server that would allow others to work with it. Of course, there is a convenience value in having central hub. The point is not denying that, the point is turning it from necessity to option.

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

#449

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…

What would you recommend to a junior CS major to avoid falling into this pattern?

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

#450

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…

You're just trading in the complexity of the code you'd have to write for the delayed complexity of dealing with dependency issues down the line. It's a waste of a trade off for tiny things like this.
Post reply on HN