9 ms·

The piece reads like a Unix pastor's pulpit preaching "Great nutritious technologies to use: Make, Emacs, Lisp, CLI" "Bad unwholesome technologies to use: Jav

by umvi 7y ago

The piece reads like a Unix pastor's pulpit preaching "Great nutritious technologies to use: Make, Emacs, Lisp, CLI" "Bad unwholesome technologies to use: JavaScript, Ruby, IDEs, Graphical User Interfaces" I personally hate Make, it's burned me too many times. Now I use CMake, and I haven't been burned in years. And is it candy or an olive that I like VSCode and not Emacs (not that I've ever tried Emacs, I just don't feel like investing in that ecosystem)? I agree the front end web framework churn is out of control; hopefully it will stabilize over time. But come on, don't just rip on random scripting languages that have been around for 25 years

vinceguidry 7y ago
Rake, the Ruby version of Make, is rock-solid, dependable, and crazy-powerful. Don't want a Turing-complete language in your build automation? Don't use it, the rule syntax works just fine. But it's there if you want it, and oh god is it great.
- cjfd 7y ago
  There is something extremely weird about the idea of having a build system for a particular language. It is not uncommon for a project to have multiple languages and it is also possible that some of the source code in one language is generated by an executable in another language. Because of this and because of compatibility issues the correct number of build systems to exist is 1. If there is more than 1 in a single project it will be the case that sometimes more is rebuilt than necessary.
  - vinceguidry 7y ago
    Yes I wouldn't ever want more than one build system. I use Rake to build Crystal, and haven't even bothered to investigate Crystal's offering.
  - regularfry 7y ago
    Rake isn't for Ruby any more than Make is for C. It comes from that ecosystem, but you can use it for anything. If you've got a system ruby installed, you've probably also got rake.
    - davidjnelson 7y ago
      Exactly. Remember in 2010 before grunt a lot of us were using maven to build single page JavaScript apps? That was pretty funny in retrospect :-) The creator of angular created the precursor to the karma test runner, called jstestdriver, which was a maven plugin ;-) It worked though! We built a single page app with tdd using it at Autodesk.
- nathell 7y ago
  > Rake, the Ruby version of Make That's a common misconception, but people often don't understand what make is. Contrary to the intuition, make is _not_ a build system (like, say, cmake), although build systems can be (and often are) implemented on top of make; nor is it a task runner (like rake). At its core, make is a declarative expert system (with a very sane design and a very quirky rule syntax). Its area of expertise is updating files. I urge every user of make who hasn't read "Recursive Make Considered Harmful"[1] to do so. [1]: http://aegis.sourceforge.net/auug97.pdf http://aegis.sourceforge.net/auug97.pdf
  - ummonk 7y ago
    Yup, and a common modern use case of make is to call in to other language specific build systems.
kd5bjo 7y ago
>I personally hate Make, it's burned me too many times. I’d be interested in hearing about the problems Make has caused you— Whenever I’ve needed to write or edit a makefile, it’s been a pain looking up the relevant details in the manual, but nothing as severe as what you seem to be implying. Have I just been lucky, working with less complicated projects, or something else?
- leggomylibro 7y ago
  Sometimes you can make mistakes which delete files, but you should keep development files backed up in some capacity. Still, spot the bug here: AS_SRC = main.S util.s OBJ = $(AS_SRC: .S=.o) [...] clean: rm -f $(OBJ)
  - rootlocus 7y ago
    Whatever the bug, git reset is the solution.
  - kd5bjo 7y ago
    The source files with a lower-case extension aren’t getting their file names translated and are passed straight through into OBJ unchanged. Granted, knowing that there’s an error here helped greatly in spotting it; there’s a good chance I would have run the incorrect makefile at least once before investigating.
- umvi 7y ago
  > I’d be interested in hearing about the problems Make has caused you The main problem that kept burning me was that I'd have a "dirty" build when I thought I had a clean one or an incorrect one when I thought I had a correct one. It was super hard to get the dependency graph correct because developers were creating files left and right but would only update the Makefile just enough to get it building (and forget to add new header files to the list of headers, etc) so I had little confidence in incremental builds and was always building from the ground up. CMake's generated build systems always have correct dependency graphs (i.e. it will only rebuild the bare minimum when you touch a given file) and I've always had complete confidence that my build is clean (since I just created a fresh directory) and that my incremental builds are correct.
Crinus 7y ago
You may hate Make and it is certainly far from ideal (tab-based syntax was a mistake) but the thing is, Make has very simple rules that haven't changed for decades and Makefiles generally keep working (and when they break it isn't the fault of Make itself but of something else that isn't as stable/backwards compatible as Make).
- kabdib 7y ago
  Common make fail #1 The project you landed on has been using some souped-up supermake with a ton of features (which were used with wild abandon) and some subtly different semantics for (say) macro expansion and variable assignment (and these are really difficult to determine the dependency scope of). The build system has grown to a recursively gnarly Turing-complete mess. So when you go to update the tooling, you find out that this supermake is (a) a commercial project, (b) the company has gone out of business, or adopted a predatory per-seat licensing scheme, or no longer supports your platform, or has changed the product so significantly that you might as well port everything to a different version of make anyway. Never happened to me. Common make fail #2 I was regularly dealing with bugs in multi-million-line makefiles. Make, you see, has no debugger; you can't step through things to find out what's going on. To debug an issue you insert print (echo) statements and look at output, and/or gronk through many, many lines of make's internal structures. Why didn't file A compile, and why file B compile twice? It could take a long time to figure out. Common make fail #3 "Builds are too slow, we need to speed them up." So you go parallel. Hey, this is easy. Except for those libraries there (they need to be done first). And those headers are generated, so those need to come first, but first first. And everything depends on these libraries getting built, so need to wait for the linker here, here and here. Pretty soon you have a dependency hairball that nobody understands and that people are afraid to change because things always break. Eventually you get to a point where "yeah, building twice usually seems to fix that issue..." and that's when you know the project has grown too damned big for its shell again. Common make fail #4 You die a little each time that you get screwed by tab-versus-space. And cross-platform . . . umm, what year is it? Then someone smugly mentions some XML-based tool to you, and you snap because that tool is worse in every single measurable dimension and a few more besides but the developer in question doesn't question things because the tool uses Holy XML and Blessed Java (well, some version of Java, anyway, you can probably still download it from somewhere) and who cares if it's just the same set problems with a different color paint slapped on top and the usual Reddit community dedicated to the elimination of all heretical views. Support? Who needs that, just read the source. Seriously, I haven't seen any build tools in the past 30 years that have done a great job and that were a joy to use. CMake, Ant, Gradle, make-of-the-month-club, whizzy vendor-locked tools, bespoke in-house constructions, they have all been terrible. I see little hope, entropy has won this one.
SomeOldThrow 7y ago
> don't just rip on random scripting languages that have been around for 25 years Where do you see that? My point being: I imagine you could avoid this just fine with javascript. I don’t see this as a technical issue so much as a cultural one—we gave up on vetting our dep trees.
rxhernandez 7y ago
I mean I haven't been a professional for multiple decades but I've written professionally in a very wide range of fields in C, Matlab, Java, Python, Verilog, Assembly, Fortran, and Javascript, and, there is no language that I've seen that has more hair pulling, braindead I just learned to program yesterday type programming nearly as much as I've seen in Javascript. (I've worked intimately with decades old scientific programming codebases where the scientists didn't give a single damn about writing cleanly and even that was an order of magnitude more readable than the willy nilly, consistency be damned crap I've been seeing in Javascript) (I feel like I could describe a small portion of hell for me and it would include Javascript)
- deleted 7y ago
  [deleted]
- tomgp 7y ago
  I have a similar set of experiences but have a feeling that it's at least partly down to the sheer number of people writing Javascript and the very public nature of much of that code that so much of it is a mess. I don't think there's anything inherent in JS that make is produce messy code other than the fact that it's easy for amateurs to get results (thanks to the fact it runs in a browser and there's lots of easily available code samples).
  - tenaciousDaniel 7y ago
    I'm a JS dev and I love it, but JavaScript is to programming languages what the electric guitar is to musical instruments. It's the thing that attracts a lot of new beginners who may or may not be interested in the more serious theory that makes programming what it is.
    - rxhernandez 7y ago
      Have you worked in other languages for substantial amounts of time?
      - 7y ago
yogthos 7y ago
You don't have to throw the baby out with the bath water to have sanity. Clojure targets both the JVM and Js runtimes, and you can leverage all the existing ecosystem while using a much better language and tooling. You can even use VS Code for Clojure development, it works great. Here's what this all looks like in practice https://github.com/ClojureTO/JS-Workshop https://github.com/ClojureTO/JS-Workshop
meuk 7y ago
Hm, I'm not a fan of Cmake. I like how simple and clean Make is. In my experience it works more often than Cmake, and if not, I can usually debug it. Cmake seems like an overengineered beast to me. But I probably haven't 'grokked' it yet.
- umvi 7y ago
  I'm not a huge fan of CMake's syntax, but the thing that sold me (i.e. the "killer feature") was how easy it was to setup out-of-source builds[1]. The ability to have the entire build/build artifacts in a directory completely standalone from the source directories was a huge win. Because for me, that meant I could have 3 separate build directories - one for my optimized ARM builds, one for my debug (-g -O0) ARM builds, and one for my x86 unit test/coverage builds. If I modified one file, I didn't need to re-spin 3 clean builds - I just could hop into the one or more build directory I was interested in and incrementally update the builds. Plus, out-of-source builds make building clean as easy as `rm -rf build/` instead of hoping that `make clean` has all the right pattern matching and subdirectory listings to truly scrub the build artifacts. [1] https://cgold.readthedocs.io/en/latest/tutorials/out-of-source.html https://cgold.readthedocs.io/en/latest/tutorials/out-of-sour...
mighty_bander 7y ago
Having started with the MS stack way back in the old days of their Hegemony, I always felt like make was doing something that I shouldn't have to think about. I'm curious about VSCode - why that, and not Visual Studio or another full-featured IDE? I've gone from IDE to vim and back, and I have to admit with great sadness that the various little gimmicks an IDE provides (without hand-configuring the damn thing!) make it worth it, particularly since they all allow for vim keybindings to one degree or another.
- galangalalgol 7y ago
  I have developed c++ with vim and visual studio for a couple decades. I recently made the switch to vscode from vim and i like it even better than studio. Its snappier and it integrates with my vim workflow well so i dont have to do either or.
  - wolco 7y ago
    I don't see the benefit of switch from sublime to vscode. What am I missing? Does vscode offer something different?
    - mighty_bander 7y ago
      I'm not a sublime user, so I can't say why, but a couple of JS devs in my office switched from sublime to VS Code. I'm a little surprised by this to be honest, and I haven't interrogated them too thoroughly about why, since I'm not especially interested in either; you might want to give it a try, however.
    - umvi 7y ago
      Better git and debugging integration, mainly. I use VSCode with the Sublime Text extension[1] and honestly it feels almost exactly like sublime, but with better git and debugging integration. [1] https://marketplace.visualstudio.com/items?itemName=ms-vscode.sublime-keybindings https://marketplace.visualstudio.com/items?itemName=ms-vscod...
mijoharas 7y ago
> I personally hate Make, it's burned me too many times. Now I use CMake, and I haven't been burned in years. Could you elaborate on how you've been burned by make? Because my experience is the exact opposite of yours. I shudder to remember some of the cmake I've had to deal with.
babyloneleven 7y ago
VSCode (and Atom) feels like an Emacs with Javascript instead of Lisp anyway

by umvi 7y ago

vinceguidry 7y ago

Rake, the Ruby version of Make, is rock-solid, dependable, and crazy-powerful. Don't want a Turing-complete language in your build automation? Don't use it, the rule syntax works just fine. But it's there if you want it, and oh god is it great.

cjfd 7y ago
There is something extremely weird about the idea of having a build system for a particular language. It is not uncommon for a project to have multiple languages and it is also possible that some of the source code in one language is generated by an executable in another language. Because of this and because of compatibility issues the correct number of build systems to exist is 1. If there is more than 1 in a single project it will be the case that sometimes more is rebuilt than necessary.
- vinceguidry 7y ago
  Yes I wouldn't ever want more than one build system. I use Rake to build Crystal, and haven't even bothered to investigate Crystal's offering.
- regularfry 7y ago
  Rake isn't for Ruby any more than Make is for C. It comes from that ecosystem, but you can use it for anything. If you've got a system ruby installed, you've probably also got rake.
  - davidjnelson 7y ago
    Exactly. Remember in 2010 before grunt a lot of us were using maven to build single page JavaScript apps? That was pretty funny in retrospect :-) The creator of angular created the precursor to the karma test runner, called jstestdriver, which was a maven plugin ;-) It worked though! We built a single page app with tdd using it at Autodesk.
nathell 7y ago
> Rake, the Ruby version of Make That's a common misconception, but people often don't understand what make is. Contrary to the intuition, make is _not_ a build system (like, say, cmake), although build systems can be (and often are) implemented on top of make; nor is it a task runner (like rake). At its core, make is a declarative expert system (with a very sane design and a very quirky rule syntax). Its area of expertise is updating files. I urge every user of make who hasn't read "Recursive Make Considered Harmful"[1] to do so. [1]: http://aegis.sourceforge.net/auug97.pdf http://aegis.sourceforge.net/auug97.pdf
- ummonk 7y ago
  Yup, and a common modern use case of make is to call in to other language specific build systems.

kd5bjo 7y ago

>I personally hate Make, it's burned me too many times. I’d be interested in hearing about the problems Make has caused you— Whenever I’ve needed to write or edit a makefile, it’s been a pain looking up the relevant details in the manual, but nothing as severe as what you seem to be implying. Have I just been lucky, working with less complicated projects, or something else?

leggomylibro 7y ago
Sometimes you can make mistakes which delete files, but you should keep development files backed up in some capacity. Still, spot the bug here: AS_SRC = main.S util.s OBJ = $(AS_SRC: .S=.o) [...] clean: rm -f $(OBJ)
- rootlocus 7y ago
  Whatever the bug, git reset is the solution.
- kd5bjo 7y ago
  The source files with a lower-case extension aren’t getting their file names translated and are passed straight through into OBJ unchanged. Granted, knowing that there’s an error here helped greatly in spotting it; there’s a good chance I would have run the incorrect makefile at least once before investigating.
umvi 7y ago
> I’d be interested in hearing about the problems Make has caused you The main problem that kept burning me was that I'd have a "dirty" build when I thought I had a clean one or an incorrect one when I thought I had a correct one. It was super hard to get the dependency graph correct because developers were creating files left and right but would only update the Makefile just enough to get it building (and forget to add new header files to the list of headers, etc) so I had little confidence in incremental builds and was always building from the ground up. CMake's generated build systems always have correct dependency graphs (i.e. it will only rebuild the bare minimum when you touch a given file) and I've always had complete confidence that my build is clean (since I just created a fresh directory) and that my incremental builds are correct.

Crinus 7y ago

You may hate Make and it is certainly far from ideal (tab-based syntax was a mistake) but the thing is, Make has very simple rules that haven't changed for decades and Makefiles generally keep working (and when they break it isn't the fault of Make itself but of something else that isn't as stable/backwards compatible as Make).

kabdib 7y ago
Common make fail #1 The project you landed on has been using some souped-up supermake with a ton of features (which were used with wild abandon) and some subtly different semantics for (say) macro expansion and variable assignment (and these are really difficult to determine the dependency scope of). The build system has grown to a recursively gnarly Turing-complete mess. So when you go to update the tooling, you find out that this supermake is (a) a commercial project, (b) the company has gone out of business, or adopted a predatory per-seat licensing scheme, or no longer supports your platform, or has changed the product so significantly that you might as well port everything to a different version of make anyway. Never happened to me. Common make fail #2 I was regularly dealing with bugs in multi-million-line makefiles. Make, you see, has no debugger; you can't step through things to find out what's going on. To debug an issue you insert print (echo) statements and look at output, and/or gronk through many, many lines of make's internal structures. Why didn't file A compile, and why file B compile twice? It could take a long time to figure out. Common make fail #3 "Builds are too slow, we need to speed them up." So you go parallel. Hey, this is easy. Except for those libraries there (they need to be done first). And those headers are generated, so those need to come first, but first first. And everything depends on these libraries getting built, so need to wait for the linker here, here and here. Pretty soon you have a dependency hairball that nobody understands and that people are afraid to change because things always break. Eventually you get to a point where "yeah, building twice usually seems to fix that issue..." and that's when you know the project has grown too damned big for its shell again. Common make fail #4 You die a little each time that you get screwed by tab-versus-space. And cross-platform . . . umm, what year is it? Then someone smugly mentions some XML-based tool to you, and you snap because that tool is worse in every single measurable dimension and a few more besides but the developer in question doesn't question things because the tool uses Holy XML and Blessed Java (well, some version of Java, anyway, you can probably still download it from somewhere) and who cares if it's just the same set problems with a different color paint slapped on top and the usual Reddit community dedicated to the elimination of all heretical views. Support? Who needs that, just read the source. Seriously, I haven't seen any build tools in the past 30 years that have done a great job and that were a joy to use. CMake, Ant, Gradle, make-of-the-month-club, whizzy vendor-locked tools, bespoke in-house constructions, they have all been terrible. I see little hope, entropy has won this one.

SomeOldThrow 7y ago

> don't just rip on random scripting languages that have been around for 25 years Where do you see that? My point being: I imagine you could avoid this just fine with javascript. I don’t see this as a technical issue so much as a cultural one—we gave up on vetting our dep trees.

rxhernandez 7y ago

I mean I haven't been a professional for multiple decades but I've written professionally in a very wide range of fields in C, Matlab, Java, Python, Verilog, Assembly, Fortran, and Javascript, and, there is no language that I've seen that has more hair pulling, braindead I just learned to program yesterday type programming nearly as much as I've seen in Javascript. (I've worked intimately with decades old scientific programming codebases where the scientists didn't give a single damn about writing cleanly and even that was an order of magnitude more readable than the willy nilly, consistency be damned crap I've been seeing in Javascript) (I feel like I could describe a small portion of hell for me and it would include Javascript)

deleted 7y ago
[deleted]
tomgp 7y ago
I have a similar set of experiences but have a feeling that it's at least partly down to the sheer number of people writing Javascript and the very public nature of much of that code that so much of it is a mess. I don't think there's anything inherent in JS that make is produce messy code other than the fact that it's easy for amateurs to get results (thanks to the fact it runs in a browser and there's lots of easily available code samples).
- tenaciousDaniel 7y ago
  I'm a JS dev and I love it, but JavaScript is to programming languages what the electric guitar is to musical instruments. It's the thing that attracts a lot of new beginners who may or may not be interested in the more serious theory that makes programming what it is.
  - rxhernandez 7y ago
    Have you worked in other languages for substantial amounts of time?
    - 7y ago

yogthos 7y ago

You don't have to throw the baby out with the bath water to have sanity. Clojure targets both the JVM and Js runtimes, and you can leverage all the existing ecosystem while using a much better language and tooling. You can even use VS Code for Clojure development, it works great. Here's what this all looks like in practice https://github.com/ClojureTO/JS-Workshop https://github.com/ClojureTO/JS-Workshop

meuk 7y ago

Hm, I'm not a fan of Cmake. I like how simple and clean Make is. In my experience it works more often than Cmake, and if not, I can usually debug it. Cmake seems like an overengineered beast to me. But I probably haven't 'grokked' it yet.

umvi 7y ago
I'm not a huge fan of CMake's syntax, but the thing that sold me (i.e. the "killer feature") was how easy it was to setup out-of-source builds[1]. The ability to have the entire build/build artifacts in a directory completely standalone from the source directories was a huge win. Because for me, that meant I could have 3 separate build directories - one for my optimized ARM builds, one for my debug (-g -O0) ARM builds, and one for my x86 unit test/coverage builds. If I modified one file, I didn't need to re-spin 3 clean builds - I just could hop into the one or more build directory I was interested in and incrementally update the builds. Plus, out-of-source builds make building clean as easy as `rm -rf build/` instead of hoping that `make clean` has all the right pattern matching and subdirectory listings to truly scrub the build artifacts. [1] https://cgold.readthedocs.io/en/latest/tutorials/out-of-source.html https://cgold.readthedocs.io/en/latest/tutorials/out-of-sour...

mighty_bander 7y ago

Having started with the MS stack way back in the old days of their Hegemony, I always felt like make was doing something that I shouldn't have to think about. I'm curious about VSCode - why that, and not Visual Studio or another full-featured IDE? I've gone from IDE to vim and back, and I have to admit with great sadness that the various little gimmicks an IDE provides (without hand-configuring the damn thing!) make it worth it, particularly since they all allow for vim keybindings to one degree or another.

galangalalgol 7y ago
I have developed c++ with vim and visual studio for a couple decades. I recently made the switch to vscode from vim and i like it even better than studio. Its snappier and it integrates with my vim workflow well so i dont have to do either or.
- wolco 7y ago
  I don't see the benefit of switch from sublime to vscode. What am I missing? Does vscode offer something different?
  - mighty_bander 7y ago
    I'm not a sublime user, so I can't say why, but a couple of JS devs in my office switched from sublime to VS Code. I'm a little surprised by this to be honest, and I haven't interrogated them too thoroughly about why, since I'm not especially interested in either; you might want to give it a try, however.
  - umvi 7y ago
    Better git and debugging integration, mainly. I use VSCode with the Sublime Text extension[1] and honestly it feels almost exactly like sublime, but with better git and debugging integration. [1] https://marketplace.visualstudio.com/items?itemName=ms-vscode.sublime-keybindings https://marketplace.visualstudio.com/items?itemName=ms-vscod...

mijoharas 7y ago

> I personally hate Make, it's burned me too many times. Now I use CMake, and I haven't been burned in years. Could you elaborate on how you've been burned by make? Because my experience is the exact opposite of yours. I shudder to remember some of the cmake I've had to deal with.

babyloneleven 7y ago

VSCode (and Atom) feels like an Emacs with Javascript instead of Lisp anyway