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

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

#861

Post by plugnburn » Fri, Mar 25, 2016, 7:49 AM UTC

runin2k1 wrote: 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…

Sure, because just writing

  isPositive = (x) => +x === x && x > 0

is boring. Need more requires to require the requires...

Keep in mind though that absolutely not all JS programmers are like that. Not everyone wants to be an aforementioned Dick-from-a-mountain.

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

#862

Post by plugnburn » Fri, Mar 25, 2016, 7:58 AM UTC

augustl wrote: post #529

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…

That's interesting. JavaScript has enough quirks to warrant an is-positive-integer module.

See:

  isPositive = (x) => +x === x && x > 0

In which conditions does it return a wrong value? I haven't found any.

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

#863

Post by lmm » Fri, Mar 25, 2016, 8:07 AM UTC

BinaryIdiot wrote: post #859

lmm wrote: post #845

Earlier quoted context omitted.

> 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 minut…

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

If writing it would take minutes and adding the dependency would take seconds, add the dependency. And how long it takes to look for is beside the point - code is read more than it's written, so how long it takes to read is much more important.

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

No, look, if you have some kind of problem where dependencies maker your builds unreproducible or break your deployments, you need to fix that problem. If you have that problem when you have 100 dependencies, you're still going to have that problem when you have 90 dependencies. Unless you're going to cut every dependency, cutting dependencies is not the way to fix that problem.

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

for and while probably should be ordinary functions (smalltalk style) and probably should be in a library somewhere rather than having everyone reimplement them, yes. Almost all languages have a for or while in their standard library so I don't know what you're really saying?

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

#864

Post by vicx » Fri, Mar 25, 2016, 8:23 AM UTC

lotsoflumens wrote: post #802

rantanplan wrote: post #743

Earlier quoted context omitted.

Worry not my friend. I'll take the risk of being wrong. Up to now, it seems that there's consensus on the fact that the JS/frontend world is the worst offender when it comes to engineering robust software. At least there are JS programmers that seem aware of it and agree that this has to change. So there's still hope I guess.

> JS/frontend world is the worst offender when it comes to engineering robust software I completely agree. I still can't understand why the language that we depend on for increasingly large-scale front-end work still works like this: [1, 10, 2, 21].sort() // returns: [1, 10, 2, 21] It's 2016, software engineering is purported to be a profession, and we still have the worst tools imaginable.

Yep. And very large software developers have created languages that compile to javascript ... it is madness but it solves their problems.

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

#865

Post by nikki93 » Fri, Mar 25, 2016, 8:46 AM UTC

pjlegato wrote: post #204

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…

The thing is, it actually doesn't matter. No one needs to be a certain way. Cool things will be done by people that can and will do those cool things. In the end the prescriptivity of this whole space is only ascribed by people internal to the whole system: externally nothing is 'supposed' to be done. This is just a symptom of more people programming.

The thing that will speak the loudest is actions and results. If people don't like depending on modules, don't. If you do, do. Eventually everything will be lost and forgotten like teardrops in the rain.

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

#866

Post by nailer » Fri, Mar 25, 2016, 10:20 AM UTC

lotsoflumens wrote: post #802

rantanplan wrote: post #743

Earlier quoted context omitted.

Worry not my friend. I'll take the risk of being wrong. Up to now, it seems that there's consensus on the fact that the JS/frontend world is the worst offender when it comes to engineering robust software. At least there are JS programmers that seem aware of it and agree that this has to change. So there's still hope I guess.

> JS/frontend world is the worst offender when it comes to engineering robust software I completely agree. I still can't understand why the language that we depend on for increasingly large-scale front-end work still works like this: [1, 10, 2, 21].sort() // returns: [1, 10, 2, 21] It's 2016, software engineering is purported to be a profession, and we still have the worst tools imaginable.

Try

.sort(sorts.numerical)

Using npms 'sorts' module

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

#867

Post by EvanPlaice » Fri, Mar 25, 2016, 10:42 AM UTC

bbcbasic wrote: post #355

EvanPlaice wrote: post #326

Earlier quoted context omitted.

Use the null object pattern. If you're checking a value to see if it's set by testing for null/undefined, you're doing it wrong. This is good advice for any language, not just JS. Besides, using null as the default for an undefined value is a mistake. Null should indicate a non-value not the absence of a value. Maybe one day the static OOP languages will die so devs have a chance to learn the difference.

My point is more that the compiler* can't detect these mistakes but in other languages you can. E.g. in Haskell you only allow Null on types when you want it (you do this by using the Maybe type). Objects where you probe for values that could be undefined or could be defined but null doesn't exist as a concept but if you badly wanted it you could use a dictionary. In Haskell if you use Maybe and you process a Maybe o…

Maybe/Nothing is a perfect example of the null object pattern. Either provide a sane default or a typed instance with empty values rather than checking for null/undefined. Ie the 'null object' in 'null object pattern' doesn't mean using null to indicate the absence of a value.

Null isn't used in JS to mark undefined variables, that's what 'undefined' is for. Unlike static/OOP languages, null is specifically reserved for use cases where a null value is necessary. Which was the point of my comment.

If you try to access an undefined variable in 'strict mode' it throws an undefined runtime error.

JSLint does, in fact, check for undefined variables and/or globals that are accessed before they're defined in the local source (ie unspecified external globals).

So... There's that...

-----

Did you happen to notice how I didn't even remotely mention Haskell or anything related to functional programming but, please, I'd love to hear for the thousandth time how Haskell's purity is going to cure the world of all it's ills. As if the Haskell community hasn't been over-promising and failing to deliver production-ready applications for the past decade.

Unlike Haskell, JS source can be actively linted while you write it rather than requiring a separate compile/build step.

With ES6 on the client-side, modules can be hot reloaded as changes are made for instant feedback. The obvious downside being, fewer coffe breaks that can blamed on the compiler.

Have fun implementing trampolines once Haskell's 'recursion all the things' default approach to lazy-loading inevitably overflows the stack and crashes your app in production. Static type checking can't save you from logic errors. See also 'memory profiling' the phrase that shall not be uttered.

Source: http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...

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

#868

Post by nailer » Fri, Mar 25, 2016, 10:45 AM UTC

fieryeagle wrote: post #854

usrusr wrote: post #675

Earlier quoted context omitted.

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 cr…

I'd hire the people who use fizz-buzz-solver and spends time doing original work rather than rewriting something for the sake of ego.

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

#869

Post by ZeWaren » Fri, Mar 25, 2016, 10:46 AM UTC

Regardless of whether micro-modules are good or bad, I think that if you are the owner/manager of a project, you should be able, given its full flat list of dependencies, to explain why each one of them is useful for you.

Every project I've seen that uses npm always required 100s or 1000s of dependencies.

If building or running your project requires something and you can't explain why, I think there's a problem.

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

#870

Post by nailer » Fri, Mar 25, 2016, 12:30 PM UTC

spion wrote: post #800

nailer wrote: post #789

Earlier quoted context omitted.

If you solve callback hell for a series of sequential functions by using an actual series of sequential functions, you don't have nested callbacks and you didn't require Promises or composition - just a basic understanding of data structures and first class functions. It seems you're defining callback hell as 'whatever promises solves' rather than it's common definition of over-nesting.

Callback hell is a "loss of composition" problem. Most languages, including JavaScript, have things called expressions. Expressions rely on functions returning their output. They become useless when functions give their output through a callback passed as their input: they don't compose with that frankenstein. Node style callbacks are a prime example of how in the quest for "simplicity" and hate for abstractions its…

Hrm, it's always seemed natural (and not frankenstein) that a function would be input as much as a number or string is. 'My name is Steve, my age is 7, and here's what do to one the database has saved'.

That said I see how the inconsistency you're talking about with how expressions return values with callbacks and you've certainly put the point very well.