5 ms·
Thank you. It's nice to know that I'm not alone in this dark, dark world. It's so depressing when people use arguments like "it's old", "it uses tabs", and "it
by dblotsky 9y ago
Thank you. It's nice to know that I'm not alone in this dark, dark world.
It's so depressing when people use arguments like "it's old", "it uses tabs", and "it's hard to learn". As described by one Peter Miller, "Make is an expert system". If a tool is the most powerful, standard, and expressive among its peers, its age or the fact that it uses tabs should be inconsequential.
If anything, the fact that it's decades old and used in every major software project is a testament to its effectiveness, not a drawback.
And if "learning Make" is a barrier, that to me is a sign that someone cares more about complaining than about their project. The same way people learn Git when it's clear that it's the best tool, people learn Make. It really isn't that hard. Even the basics are enough to reap huge benefits immediately.
- hungerstrike 9y agoThe tools are not the same on every platform. That’s reason enough for me to not use it with my JavaScript projects. The bigger reason though is that it’s not very idiomatic for JavaScript projects to use Make. It sounds like the only reason that some people go out of their way to use it is because they actually don’t want to learn something.
- dblotsky 9y ago> "The tools are not the same on every platform." Any common examples? > "It’s not very idiomatic for JavaScript projects to use Make." While I agree that popularity is a factor in picking a tool, it shouldn't be a deciding factor. Going by popularity is precisely how we end up with a new Build System of the Year(TM) every few years. The fact that we've gone through 4 fairly prominent tools (Gulp, Grunt, Broccoli, Webpack), all of which contending to "fix" the previous, and none of which have proper DAG or incremental builds (which Make has had for decades) is damning evidence. In other words, I think Make could be (and I wish it was) idiomatic for JS.
- hungerstrike 9y agoThis comment points out the kind of problems that can occur just on Unix systems - https://news.ycombinator.com/item?id=16485637 https://news.ycombinator.com/item?id=16485637 And then there’s Windows... Anyway, the fact that things change quickly in JS-land is more of a testament to how popular it is than anything else IMO. If C were used in the same environments as JS, I’m sure that you'd see just as much churn.
- gonvaled 9y agoC is used in a lot of platforms. Js only in the browser (thankfully mostly converged) and in node.
- hungerstrike 9y agoJavaScript is in the server, browser, mobile apps, desktop apps and embedded devices. Basically, it’s used everywhere that C is used and then some.
- gonvaled 9y agoWhat is the runtime? Always the same. More than C? Ha! The platform where your js is running is probably written in C!
- hungerstrike 9y agoPffffft. Nobody wants to touch C these days. That's why many, many, many, many, many more people are writing server, browser, desktop and mobile apps with JS and not C.
- dblotsky 9y agohttps://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
- 9y ago
- gonvaled 9y agoWhat is the build tool used in the javascript world this week? Broccoli? Grunt? Gulp? Talp? Just dealing with breaking changes in any one of those is a full time job!
- hungerstrike 9y agoPro-tip: you don’t have to switch tools the minute that something new comes out.
- btbuildem 9y agoHaha yes you do, because your manager does, every time
- gonvaled 9y agoYou do, since different communities use different build tools. And they even switch tools, for the new kid on the block.
- hungerstrike 9y agoBullshit. You're arguing as if every JS developer has to interact with every JS community. Stop presenting these ridiculous false dichotomies.
- dblotsky 9y agoYou often do though. For example if you want to do open source development on JS projects, this means that you might have to learn many different build systems.
- hungerstrike 9y agoYeah, where “often” is defined as “this one example that I just conjured up”.
- jjrh 9y ago> If anything, the fact that it's decades old and used in every major software project is a testament to its effectiveness, not a drawback. Part of the reason is because people see the superficial issues (like the discussion regarding spaces) before they see the value of years (or decades) of work. It doesn't help that when folks bring this up many times you get "you're holding it wrong" type responses. I sympathise with both sides of the argument. I don't know the solution but it's unfortunate seeing folks reinventing the wheel and struggling with problems solved in the past.
- dblotsky 9y agoI definitely think Gulp and Webpack have a place. Where you have to write a Makefile fresh every time for every type of project, Gulp and Webpack come prepared with JS-specific stuff. That's perfect for a throwaway project or a small codebase where build performance and maintenance really don't matter. My issue is that people who need serious solutions forgo Make because "tabs, man", or because Webpack has pretty console output.