Check out the work on Morte for a more reasoned approach for how to take micro-modularization to it's natural (or insane) conclusion.
NPM and Left-Pad: Have We Forgotten How to Program?
541–550 of 887 posts
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#542> if you cannot write a left-pad, is-positive-integer, or isArray function in 5 minutes flat (including the time you spend Googling), then you don’t actually know how to code.
I'd probably get 2 of those wrong in some weird way, but I blame javascript. I mean without Google of course.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#543Earlier 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.
> #include #include #include #include
I've written worse - at least those cover multiple variations each (or overloads in C++ for float/double/std::complex?/...)
While I'm not a fan of the enforced java route of 1 file = 1 class, I do trend towards 1 file ~ 1 (main, public) thing - which might be a single function with no overloads. #include ? Better than #include , which I see far too often...
I don't have to figure out which grouping of things my coworkers decided to throw something into if I can just #include by name - whereas aggregation headers more often than not will trigger a full project file-system search.
Unnecessary #include s don't accumulate nearly so much when you don't have to audit 100 functions to see if any of them use features from said header.
I don't trigger a rebuild of everything when the only things that #include stuff actually need it.
Lots of benefits!
> and "-lsin -lcos -ltan -lsinh …"
Or sin.o, cos.o, tan.o, sinh.o... which suddenly sounds a lot more reasonable. I wouldn't bat an eye at string_left_pad.o either.
Sure, I want to use tools to simplify the use of those micro-modules by aggregating them into libraries for convenience. But that's not a knock against micro-modules - just their packaging and tooling. Rewind time back far enough and I would've been manually specifying .o files on the command line and kvetching too...
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#544This is why one guy can now compete with say Google or Microsoft, because that guy uses code written and managed by more engineers then both Google and Microsoft have combined. Instead of paying hundreds of dollars to said companies, you can just NPM install "what you need".
Libraries/modules should help to solve complex problems where writing your own version is not optimal. Single line functions as modules, on the other hand, won't help you compete with Google or Microsoft and result in more problems than they solve. If a simple padding or "is this int positive?" is a complex problem, well, there are different professions than programmer's..
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#545JavaScript was a mistake.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#546Re: NPM and Left-Pad: Have We Forgotten How to Program?
#547Earlier quoted context omitted.
Small modules are easy to reason about They really aren't, when I'm reading is-positive-integer(x) and wonder if 0 is positive I need to hunt down the definition of positive through two packages and as many files. And it gets wrose if both your code and one of your dependencies required 'is-positive-integer' and I have to also figure out which version each part of the code base is using. If you had written (x > 0) I…
JS does not have an Integer type, so (x > 0) does not work. Now if you add all those checks necessary to see whether you're actually dealing with an integer here, you get to a point where you cannot be sure anymore whether there aren't any weird type coercion issues there and need to start writing tests. Suddenly your whole positive integer check took 1h to write and you still cannot be sure whether there's something…
A module doesn’t solve that kind of type confusion, though. Static typing does. The next best thing in JavaScript is passing consistent types of values to your functions, so just write
function isPositiveInteger(x) {
return x > 0 && Number.isInteger(x);
}
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#548I think this is the fundamental thing people don't understand about NPM and JavaScript, and the web in general: Nothing is included. And that's a feature. The web is not trying to be the kitchen sink. That's iOS. They provide high level APIs for everything . And as a result, the platform is architecturally only as vibrant as Apple can make it. Now maybe you're happy with Apple, maybe you love the iOS APIs. But if you…
You are talking about extremes here, but there are nice place somewhere in the middle, where open source libraries/modules exist to help you solving complex problems and you are free to write whatever you want.
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#549On DigitalOcean instance I cannot even use browserify+minify+babel6 cause npm process is killed by host (it consumes > 512Mb of RAM). So I have to manually run browserify + babel then minify. Still it produces 500kb of bundle.js :D
Re: NPM and Left-Pad: Have We Forgotten How to Program?
#550Earlier quoted context omitted.
If you want to build is-bigger-than-5 yourself, I recommend pulling in fivejs[1] as a dependency. [1] https://github.com/jackdcrawford/five
five.js was missing something. I fixed it. https://github.com/jackdcrawford/five/pull/234
Did you add dist/five.js to commit by mistake?