As someone who is rapidly becoming an old-timer, I have to say I miss the old days of Make. It was everywhere and had weird quirks. But you didn't need to spend too much thought on it. These days, I see projects using Gradle, Maven, Ant, Ivy, ... and it makes me feel like yet another tool I have to to learn in order to use X. As a technophile, I'm not against the new new thing. Newness in language is fantastic .. lets us express ideas or concepts that were previously hard to do. The explosion in tools that do somewhat similar things makes me feel like we're doing the wrong thing as a community. I have an equal disdain for devops solutions like Chef, Puppet, CFEngine, Ansible, whatever. Is software not mature enough to just standardize on a few and get on with it? Surely there is not much in it for the winners (maybe I am deluded about this). Anyways, rant over.
P.S. I was being facetious about missing Make. Point stands.
It might be accurate to say that we're doing the wrong things but iterating fast. That's why we have this tumult of tools. Software is definitely not mature enough to just standardise on a few of them.
I feel confident in saying that because the thought of permanently standardising on any existing build or configuration management tool fills me with horror. In the JVM world, ant is inadequate, Maven is diabolical, Gradle is a huge step forward but has many warts and one or two fundamental mistakes, and sbt is just vile. Gradle is good enough to be getting on with, but i'm looking forward to the next step.
Provided, that is, that the next step is taken after learning from previous steps. Sometimes that happens - Ansible and Salt are clearly attemps to improve on the overcomplexity of Puppet and Chef. Sometimes it doesn't - i'm not sure that Gulp or Leiningen do anything to help.
> Gradle is good enough to be getting on with, but i'm looking forward to the next step.
Check out Buck. It's fast, the codebase and general complexity is a tiny fraction compared to Maven or Gradle, and it's more sound in at least one fundamental way. (It uses file hashes instead of modtimes to figure out if a task has to be rerun.)
I agree with the rest of your post. Most build systems suck. Here's an off-hand idea:
All build systems I know work share the same core concept, a directed acyclic graph of tasks. Each task has inputs (which might be the output of another task) and if the inputs are changed then the task is rerun. That same idea also covers a lot of systems for data processing.
Why can't we have a simple, minimal tool for doing only that? Then, we could plug in different task definitions for different uses (eg building a Go project, a Java project, or running a data pipeline).
This seems preferable to a bunch of different application-specific build systems that each roll their own DAG, and their own DSL for defining tasks.
> The explosion in tools that do somewhat similar things makes me feel like we're doing the wrong thing as a community.
Yes. And, that thing is forgetting to teach history to people. There was a story a few days ago about a father pushing his son to play video games in chronological order [1]. Perhaps we need to do something similar in software development.
In my experience, two of the most important attributes of a good developer are awareness of historical context (understanding important lessons that have been learned, and how those lessons influenced major decisions) and knowledge of common idioms of the technologies/tools/languages they use.
I really like your idea. Imagine a book, class or structured tutorial that sliced up the history of web development (or UI design, Windows app development, parallel programming, game development, network communication, systems administration, mobile development, or any other kind technical topic) into a handful of important "eras" and spent a couple hours or days on each one doing a technical deep dive. Boot up a VM, install the dev tools of the day, have your hand held through some characteristic tasks so you could see first hand how people were thinking during that era, what kinds of things were easy to do, and what was hard. As you move to the next era, you get to see the results of the lessons that were learned (or not learned!) in the previous one.
The more I think about it, the more I like this idea.
Mixing a progression though programming language/machine/tooling history and nand2tetris, and perhaps a companion tetris2nand [1], would make for an amazing foundation for future programmers. You would just have to make sure the high school students still pass the AP exams, to justify the multiple courses.
[1] Tetris2nand does not exist. The idea would be to build the "ideal programming language" and then work your way down to the hardware, exploring things like GCs, parallelism, and more along the way.
I've been trying (and failing) to go through Peter Norton's Assembly book to start learning x86 assembler. The plan was to then do some DOS VGA programming and work my way through Turbo Pascal and C. I'd love to take a course that's historically focused as you described.
Sidenote: If anyone knows someone at Penguin, can you help me get permission to put Peter Norton's book on GitHub and update it?
i've done exactly that when i was in school. you can still do it. i believe turbo pascal/c is available even today and supports asm blocks directly, so you can do assembly programming in pascal/c.
How can the people who maintain these projects be satisfied with this experience? I can't imagine ever starting to setup a project like this and saying to myself "this is a good idea, we should keep going this way, and not start over from scratch." Especially in more established projects, stuff that lots of people have already been working on for a while. It's been a serious impediment for my own attempts to get involved with open source software.
I just looked up this project Domenic_S mentioned. It says why it does what it does right in the first line of the README:
> This project uses Opal to transcompile Asciidoctor—a modern implementation of AsciiDoc—from Ruby to JavaScript to produce asciidoctor.js, bringing AsciiDoc to the browser!
The whole point is to not rewrite it in JavaScript but to piggyback on the original Ruby implementation and just compile it to JavaScript so it can run in a browser.
P.S. I was being facetious about missing Make. Point stands.