7 ms·

Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools

by s_kilk 10y ago

Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. 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.

collyw 10y ago
There are far more developers who will jump on the latest new shiny with no good reason.
- sangnoir 10y ago
  Which is why I don't pity them when they scream "Javascript fatigue!". Put down the shiny new tool and back away slowly: you might hurt yourself and others.
  - nemild 10y ago
    I think they don't know better - as any relatively new web-ish dev has grown up in a server-side javascript ecosystem that's maturing rapidly in the last 6-7 years, and so has led to a lot of churn (frontend frameworks, js build systems). 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.
- JdeBP 10y ago
  In counterpoint, remember that there was a time when some of the things mentioned on this page, such as autotools, were themselves the "latest new shiny".
philh 10y ago
I think Make is also broadly associated with autotools, which surely can't help its public image.
- gkya 10y ago
  Autotools is smoking shit, but the make man page is a few pages and very comprehensive. Also the includable make libs that come with bmake allows many makefiles to be a few or one lines. Also, the best makefile I've ever seen is that of Linux, if someone considers to use make, must see that to convince himself, yes, it is possible to write a comprehensible, cross-platform and editable makefile for a big, deep project with configurables w/o the atrocious madness that is gnu autotools.
  - snuxoll 10y ago
    The concept of autotools is fine for the most part, it's just M4 that has a really bad rap (and rightfully so, it's a huge pain in the butt!). I have a couple toy vala and C++ projects I've written and autotools "just works" without much effort, but when I've needed to do something outside of the standard functionality the need to write M4 macros makes me quickly switch it out for CMake instead.
    - gkya 10y ago
      The problem with autotools is that it is an abstraction over a thing that's already simple and easy at it's heart, resulting in ultimately something more complex than it should've (and would've) been. 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.
nailer 10y ago
> Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. 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...
- coldtea 10y ago
  >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.
  - nailer 10y ago
    Totally agreed, that's why most npm modules are focused on specific tasks, and we use github and npm to track how active projects are before installing them. 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.
    - coldtea 10y ago
      >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.
gerbilly 10y ago
I think it also has to do with the stackoverflow effect. 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#Introduction https://www.gnu.org/software/make/manual/make.html#Introduct... [2] Cellphones.
- spinlock 10y ago
  this is an interesting thought. the Linux Documentation Project was full of full length books on every aspect of administering a Linux system. I printed out many of them, put them in a spiral binder and they lived on my bookshelf next to my O'Riely collection. Now, I've only got one book on my desk and it's more of a coffee-table thing about html and css
draw_down 10y ago
By the same token, old shit isn't good by dint of its age.
WayneBro 10y ago
Please show me the makefile for your Javascript project that will run perfectly on Linux, Windows and Mac with little to no setup. 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.
- spinlock 10y ago
  I can't even get `npm install` to run perfectly on my mac. It _always_ fails and needs to be re-run a few times to get everything installed. Anyway, the point is, everyone likes the smell of their own farts. But, they still stink.
- ori_b 10y ago
  I tend not to do much with Javascript, but if you have a project that I can take a shot at converting, I'd be curious to see what trouble you're running into. Windows is the only real challenge there, but with mingw, I can't imagine that it's a serious one.
- Someone 10y ago
  "Please show me the makefile for your Javascript project that will run perfectly on Linux, Windows and Mac with little to no setup." 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.
- nwmcsween 10y ago
  Sure github.com/nwmcsween/asm.css/Makefile
  - WayneBro 10y ago
    "that will run perfectly on Linux, Windows and Mac with little to no setup"? No. 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.

by s_kilk 10y ago

collyw 10y ago

There are far more developers who will jump on the latest new shiny with no good reason.

sangnoir 10y ago
Which is why I don't pity them when they scream "Javascript fatigue!". Put down the shiny new tool and back away slowly: you might hurt yourself and others.
- nemild 10y ago
  I think they don't know better - as any relatively new web-ish dev has grown up in a server-side javascript ecosystem that's maturing rapidly in the last 6-7 years, and so has led to a lot of churn (frontend frameworks, js build systems). 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.
JdeBP 10y ago
In counterpoint, remember that there was a time when some of the things mentioned on this page, such as autotools, were themselves the "latest new shiny".

philh 10y ago

I think Make is also broadly associated with autotools, which surely can't help its public image.

gkya 10y ago
Autotools is smoking shit, but the make man page is a few pages and very comprehensive. Also the includable make libs that come with bmake allows many makefiles to be a few or one lines. Also, the best makefile I've ever seen is that of Linux, if someone considers to use make, must see that to convince himself, yes, it is possible to write a comprehensible, cross-platform and editable makefile for a big, deep project with configurables w/o the atrocious madness that is gnu autotools.
- snuxoll 10y ago
  The concept of autotools is fine for the most part, it's just M4 that has a really bad rap (and rightfully so, it's a huge pain in the butt!). I have a couple toy vala and C++ projects I've written and autotools "just works" without much effort, but when I've needed to do something outside of the standard functionality the need to write M4 macros makes me quickly switch it out for CMake instead.
  - gkya 10y ago
    The problem with autotools is that it is an abstraction over a thing that's already simple and easy at it's heart, resulting in ultimately something more complex than it should've (and would've) been. 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.

nailer 10y ago

> Unfortunately, many developers have a mortal fear of anything from before the year 2000. They've grown up with this tribal wisdom of unix and it's various tools being a beardy wilderness of byzantine hacks and toxic waste dumps. 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...

coldtea 10y ago
>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.
- nailer 10y ago
  Totally agreed, that's why most npm modules are focused on specific tasks, and we use github and npm to track how active projects are before installing them. 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.
  - coldtea 10y ago
    >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.

gerbilly 10y ago

I think it also has to do with the stackoverflow effect. 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#Introduction https://www.gnu.org/software/make/manual/make.html#Introduct... [2] Cellphones.

spinlock 10y ago
this is an interesting thought. the Linux Documentation Project was full of full length books on every aspect of administering a Linux system. I printed out many of them, put them in a spiral binder and they lived on my bookshelf next to my O'Riely collection. Now, I've only got one book on my desk and it's more of a coffee-table thing about html and css

draw_down 10y ago

By the same token, old shit isn't good by dint of its age.

WayneBro 10y ago

Please show me the makefile for your Javascript project that will run perfectly on Linux, Windows and Mac with little to no setup. 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.

spinlock 10y ago
I can't even get `npm install` to run perfectly on my mac. It _always_ fails and needs to be re-run a few times to get everything installed. Anyway, the point is, everyone likes the smell of their own farts. But, they still stink.
ori_b 10y ago
I tend not to do much with Javascript, but if you have a project that I can take a shot at converting, I'd be curious to see what trouble you're running into. Windows is the only real challenge there, but with mingw, I can't imagine that it's a serious one.
Someone 10y ago
"Please show me the makefile for your Javascript project that will run perfectly on Linux, Windows and Mac with little to no setup." 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.
nwmcsween 10y ago
Sure github.com/nwmcsween/asm.css/Makefile
- WayneBro 10y ago
  "that will run perfectly on Linux, Windows and Mac with little to no setup"? No. 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.