Meanwhile they'll merrily pile up a thousand node modules into a towering pillar of bad, just to run the equivalent of a shell one-liner, and call it a job well done.
Tools that gain traction today are those that can be learned incrementally by doing a google search and copy pasting a solution, one problem at a time.
Out are all those systems that have an underlying theory to them that has to be mastered first. As pointed out elsewhere, there is a perfectly good manual for make[1] that you can read.
My theory is that it has to do with shortened attention spans, and impatience perhaps bred by constant use of technologies with short stimulus response cycles [2].
[1] https://www.gnu.org/software/make/manual/make.html#Introduct... [2] Cellphones.
Now, I've only got one book on my desk and it's more of a coffee-table thing about html and css
Some stuff is genuinely awful.
- Sendmail was ubiquitous, but it was, according to anyone who'd had either fleeting or deep experience with it, a beardy wilderness of byzantine hacks and toxic waste dumps.
- All the WU apps had major exploits every few months.
- SysVinit sucked too, regardless of which replacement you prefer.
- RPM's macro-based .spec file format? Awful.
> pile up a thousand node modules to run the equivalent of a shell one-liner
If you don't like putting small modules together to achieve a task, I have some news for you about shell and Unix...
No, really. The "UNIX way" is not just "Use tons of small things to do a simple task, complexity of managing them be damned".
It is indeed "do one thing and do it well", but that "thing" is usually high level enough and ready to go -- not something you need a whole stack of dependencies, configuration, and lots of extra glue to use.
And of course those unix tools should be standard and evergreen -- not like npm module du jour that gets abandoned 2-3 years later or completely rewritten.
It really seems like you don't do a lot of node - which is fine obviously, but you seem to have very strong opinions about it.
The first part of this is a guess -- and it's wrong.
I can't speak for "most npm modules" (there are 200.000 or so -- i've only used around 1000, transitive dependencies included) but even those focused on specific high level tasks tend to depend on tons of lower level modules of varying utility and quality -- living them open to things like the "leftpad" fiasco.
And using "github and npm to track how active projects are before installing them" is not really an answer to the UNIX way described.
First because with UNIX you don't even need to check. You know all the basic tools, from grep and unique, to watch and make, are there for the long term (and have been for 3, 4 decades).
Second, because with npm, even checking for popularity doesn't tell you much. Even the most popular modules can be dropped by their authors, rewritten in just 1-2 years to behave differently, fall out of favor and languish etc. Heck that's true even for npm itself (e.g. the changes for version 3, like the flat sub-packages), gulp (see the way the new gulp handles dependent tasks and the new syntax required) and everything else.
Heck, 6 years ago Backbone was merely just released. And from then on we already went from it being most used and "hot", to Angular, React, React+Redux and who knows what's next.
Fair enough. Just saying that's the impression I get.
> even those focused on specific high level tasks tend to depend on tons of lower level modules
Yes. Good libraries do that. Smaller bits are made from bigger bits.
> living them open to things like the "leftpad" fiasco
I don't think you understand what the "leftpad fiasco" was. Small modules doesn't have anything to do with it - people who unpublish their modules on a whim does. And that's not been prevented.
> And using "github and npm to track how active projects are before installing them" is not really an answer to the UNIX way described.
Indeed. It's an answer to your concern about "npm module du jour that gets abandoned 2-3 years later or completely rewritten".
I'm not sure that npm, gulp changing significantly is a bad thing. Good software evolves over times. As long as the changes are clearly communicated I'm 100% down with that. Look how much better express got!
I think there's a marginal returns (or worse negative returns) border with this approach, where the overhead, over-generalization, and, finally, bloat, maintenance and management issues stemming from having too many small parts from disparate sources justify writing a specialized solution.
Leftpad would be an extreme case in point -- I'd put the bar even higher than that.
>Small modules doesn't have anything to do with it - people who unpublish their modules on a whim does. And that's not been prevented.
The "unpublish" thing just made the issue instantly apparent, but the core issue would still be there even if nobody could ever unpublish anything.
E.g. such small modules could get abandoned and neglected with bugs or security issues, could have extra bloat the parent library doesn't need (this might not hold with leftpad but would be true for anything a little larger that covers 10 things when you only need 2 and could code them yourself and be done with it), is now a dependency that has to be tracked and updated, it's not optimized for the particular use case it is used in, etc.
How well do you think a module with 1000 users is likely to be maintained, vs a create-your-own-wheel equivalent?
Do you think writing the latter is an adequate use of your time?
Do you think you'll discover all the edge cases?
How does writing your own wheel module rank when compared to working on features your customers want?
> - SysVinit sucked too, regardless of which replacement you prefer. > - RPM's macro-based .spec file format? Awful.
These are opinions, which is valid.
If you want to have some fun. install centos7 in a vm. Run yum update systemd. Reboot. Your vm is now bricked.
Rpm spec files can be annoying, but what is more annoying to me is the spec behavior changing between rhel/centos 5, 6 and 7.
Yeiks.
With that said, I agree about rpmspec's. They're simple to read and easy to maintain, it's part of the reason I chose CentOS and Fedora as our standard at work instead of Debian or Ubuntu.
In my current day-to-day, between work machines and my personal machines at home, I've only got to deal with init stuff occasionally, so picking up the Systemd way of doing things will take me a while.
I doubt it exists. Until then, I'll stick with my Node.js build tools, thank you very much.
Honestly, if anyone has an example of a makefile that can bundle my scripts, insert bundle links into my HTML which is compiled from jade and nunjucks templates, minify the JS, CSS and HTML and optimize my images...I'd love to see that.
Anyway, the point is, everyone likes the smell of their own farts. But, they still stink.
One can argue that it would be better to solve that problem, rather than requiring everybody to sort-of solve it well enough to run one's own build.
Having said that, minimizing .js, .css, .html or .png files conceptually is the same as turning a .c into a .o, and bundling is conceptually the same as tarring or zipping a set of files, so I don't see why it wouldn't be possible to write a makefile that does that.
Windows is the only real challenge there, but with mingw, I can't imagine that it's a serious one.
I see no reason at all to use a Makefile in that project other than it being your personal preference. It's completely non-standard for web projects and it will only serve to confuse and annoy the next developer who wants to work on your code.
Node.js, NPM, Gulp and Grunt are all orders of magnitude easier to get running on a wide variety of operating systems than your typical C/C++ build tools. Furthermore, you don't have to learn some cryptic syntax to use them. It's all Javascript and JSON.
Saying that gulp/grunt aren't real build systems because of one feature that you actually missed anyway is like saying that Javascript isn't a real programming language because it doesn't compile to assembly.
Practically nobody uses Make for JS outside of a few misguided folks. There are good reasons for that. One of them is that Make's craptic language is useless outside of that one single task. Another one is that Make sucks at cross-platform. It forces you to use OS tools that don't exist on every OS. Meanwhile, Node.js tools work everywhere.
Separately, on the information side, there just aren't as many articles on old, but stable technology - and so if you open up HN, all they're seeing is the latest; if your team doesn't have good experienced devs on it and if you haven't learnt it in college/bootcamp then you'll pick what is publicized.
M4 is nice for processing text, I do use it and like it for that, but for defining dependencies among files and processes to go from source to compiled files, make itself is second to none. Autotools is basically one of the biggest exaggerations in the computers' history.
Furthermore, bmake exists and its include files are simply better.
You'd be surprised. Especially if they work outside C/C++, and do e.g. mostly web development, they neither care much, not know much about makefiles. At best the know to configure, make and make install something on their Linux, but most haven't even tried that.
>Also why is it for hipsters? Or is the article for hipsters?
The article is (supposedly) for hipsters. You seem a little challenged keeping with the latest "culture" (ain't we all), so let me explain.
What he means is that the article is not for seasoned veterans, or unfashionable people who delve in the old-fashioned word of GNU-tools and Make, but for "hipsters", e.g. the new-ish, young-ish developers, usually working with hip languages (and especially web, scripting, etc.), that are not rooted and well versed in the UNIX traditions.
>Why does the author call his own published notes factually inaccurate? Why is it hacky to use a makefile?
It's just a funny wording for the author to convey:
"I'm not a complete authority on Make and Make best practices, I'll just tell you what I know from experience about it. And I expect some Make-gurus to try yell at me about my suggestions being inaccurate/hacky etc, so I try to pre-empt them with this warning".
(Lots of fond memories arguing about the term in europe, where the word seems to lack its snobby, negative feel)
Yes, but this isn't the generic term "hipster", it's applied to a specific context, that is hipster programmers.
>Lots of fond memories arguing about the term in europe, where the word seems to lack its snobby, negative feel
I guess depends on where in Europe. In the place I'm aware of (e.g. not sure about Germany or nordic countries), it is indeed negative. E.g. this is about hipsters from a UK perspective:
https://www.youtube.com/watch?v=lVmmYMwFj1I&feature=youtu.be
Then he should say hipster programmers. I think of a less-parodied version of these guys: https://www.youtube.com/watch?v=IGkuxk-LPww
Also, the people I argued with were German. Perhaps a broad brush...
I'm feeling cranky every day, but just today this post is at the top of hacker news, and that's frustrating.
I guess this article could be worse: the number of times I see people reimplement poorly thought out clones of make and present them as the new thing that everyone should use is just absurd.
That said, you can prize Make out of my cold dead hands. Still my favourite build tool, and damned powerful once you learn to tame it.
Bah, you just take things too literally, and can't process/appreciate some obvious and light-hearted cultural signs.
A post that makes a joke comment != a post that discredits itself.
A post that warns that its own makefiles might be hacky != a post that calls makefiles inherently hacky (in fact this is obvious, since the post's goal is the inverse: to promote Make to people).
A post that tries to introduce Make to a whole bunch of devs who don't know about it != a post that doesn't notice that Make is used by many people for native programming on unices
If we stopped attacking the authors of articles, then it would be easier for them to write openly and less defensively, but unfortunately if you write anything on the internet, people will call you an idiot.
There are plenty of valid reasons why an established developer would never use Make, namely integration with the rest of their 'ecosystem'. Also, there's plenty of reasons for everyone to get in and use Make where appropriate.
- you've got dependencies on some basic Unix commands (cp, rm etc.) in your tasks, so better rewrite that all to use your cross-platform language's facilities.
- XML, erm, no, JSON, shall be your only file format.
Java also pretty much brought the idea of dependency management (Maven) to mainstream programming languages (although I guess you could argue some of the early Linux did as well (RPM)). It is sort of interesting how Make is sort of like local dependency management.
And Maven is still the only "package manager" I don't end up wanting to beat my head after using. For all the flak that pom.xml gets for being wordy, I know that after installing the JDK and maven all it takes is running `mvn package` and all my build plugins plus dependencies will be downloaded, installed, project compiled, tests run with whatever test runner I decided to use that year, and, assuming they passed, the project packaged up in a .jar or .war ready to be deployed.
Some more recent tools like cargo also get this right, but I don't have much of a use case for rust since the majority of my time is spend in web and desktop apps. But EVERYTHING being in one file and one tool makes getting down to business easy, there's no "make sure you run npm install before you call grunt/gulp/brocc/whatever" because maven handles it all.
Oh, as an added benefit, I don't scream about dealing with proprietary libraries like I do with .Net. The .Net SDK for our document management system has to be installed on all systems that use it via an MSI, yet the Java one is just a .jar with a couple dependencies, I whipped up a pom.xml for it in 30 seconds, pushed it to an internal maven repo and boom, done. Hell, at that point getting it packaged into an RPM (because I don't do "sprawl shit over the filesystem" deployments) took me another 3 minutes.
The build tools in Rust are incredible (given the maturity of the language). OCaml is also rapidly evolving as well (after a brief period of stagnation). I think those two languages would and probably even now make for excellent enterprise/business programming languages.
As a tech decision maker I would love to build future projects with Rust or OCaml but the cognitive load and talent needed for both those languages is higher sadly. The Ocaml build tools were a disparate mess back when I used to use it in college and for pet projects but I can honestly say there has been unbelievable strides forward.... and OCaml compiles so damn fast. I still can't believe Go users brag about compilation speed when I swear OCaml has been and still is much faster (IMO/anecdotally of course. I don't have numbers).
I can understand that entirely, it's way too easy to get ostracized for having a positive view on Maven or Java these days.
Java as a language has warts, but thankfully there's a thriving community around the JVM and a wealth of alternate languages to pick up. Still, you can pull Maven out of my cold, dead hands.
> As a tech decision maker I would love to build future projects with Rust or OCaml
I would love to use OCaml but the lack of interfaces to a lot of tools we use really bites, so I've settled for F# (can't wait for .Net Core support). Until there's DB2 for i drivers plus Laserfiche by some miracle supporting any programming language not deemed "enterprise-grade" I'm stuck with .Net or JVM languages for a lot of things I do daily :(
It's also declarative, BTW, which is a big improvement over Ant.
Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters?
It's an improvement over pretty much anything else except for maybe cargo and whatever that haskell build tool is (name escapes me right now). Builds are not iterative/procedural tasks in my mental model, I simply have a list of inputs and desired outputs, so I agree that the declarative model of Maven is awesome.
I absolutely hate dealing with MSBuild files, Rakefiles, grunt/gulp/whatever because they all focus on a chain of tasks in a specific order. Why should I have to tell my build system how to do its job, I told you what I want done, just do it!
> Maybe somebody should re-skin maven with a yaml based front end to attract the hipsters?
A YAML to pom.xml converter would probably be a rather simple solution to this. Honestly, I wouldn't mind it either, there's a lot of noise in pom.xml that I could do without even as someone who likes Maven.
I guess you mean Shake.
With Maven everything is in ONE tool, and the ENTIRE configuration for the build is contained within your pom.xml. Custom maven repositories, what build plugins need to be installed, how the build plugins are configured, project dependencies, relationships between multi-module projects, what mojos run at what phases, it's all in a single easy to read, declarative XML file. MSBuild is a giant clusterfuck compared to Maven, and it's integration with NuGet is shoddy at best.
NuGet doesn't even allow me to specify repositories on a per-project basis to this day, everything has to be specified globally. There's a LOT more configuration required to get my build server set up to build .Net apps than anything compiled with Maven.
Solution level repositories might go some way to fixing your last issue, see https://github.com/voltagex/junkcode/blob/master/CSharp/zzCo...
As a personal machine maybe not, but even in the early heady days of Java, Unix deployment was the norm. I mean, what you're going to pick, one of those new-fangled NT servers or a proper IBM/Sun/HP-UX machine that has almost enough memory to run Oracle properly?
But given the "write once, run anywhere mantra", Java had something to prove, which lead to a lot ot NIH.
Or just install that Ubuntu on Windows thingy and be done with it.
I heard a legend that even the Windows developers run some flavour of unix.
And it's really easy, and there's tons of literature on it on the internet. And it has a manpage.
...That may be the source of your problems if your devs are that inexperienced!
Grunt came out in 2011 and Gulp came out 2 years later with a superior (IMHO) code-over-convention approach. They've kinda been doing their thing since then.
Statements like seem to be nothing but FUD.
The "bubble" is "most people that never used C/C++" (because outside of there, make is pretty rare despite its usefulness), and even if you've used C/C++ you are not necessarily familiar enough with it to know how to properly use it or to realize you can use it as a general tool.
Why would you expect people to magically know about (and prefer to others) a tool that's almost never used in the ecosystems they touch, or only behind the scenes?
So the problem with choice is the number of people who also know that tool who can help you.
For my part, as a Ruby developer, I detest rake and tend to write makefiles for my Ruby projects instead.
i use rake (very superficially) from time to time, and it seems fine. Any insights you have regarding its design after long-term or more indepth use?
And really, my experience with Gulp had been the opposite of the snide "hipster" dismissals. I wish I could find clean examples via googling that weren't useless due to APIs completely changing, or due to using a library that's been deprecated in favor of another library that's been deprecated...because, man, who still uses a library after a year? :P
Somehow, though, I don't see make being a great replacement for my purposes. At the very least, it's not going to be any faster running Babel over a pile of files.