More seriously though, I find these particular choices interesting. For one thing, they're indicative of his experience as a "greybeard" programmer [1]: Someone who was still active until very recently but started programming 50 years ago. He was always try to bring forwards some computer science ideas from the 60s that never really made it into the modern zeitgeist. His tool choices seemed to represent that. Old tools that had some foundational flexibility that allowed them to stay relevant through the decades.
[1] and not the curmudgeonly kind who will only use what they learned so many decades ago, as demonstrated by his selection of more modern tools for other tasks
Make, particularly, stands out for me. As an embedded/firmware programmer, it's a core tool of mine that I've had to begrudgingly learn. Make is awful, but it's irreplaceable.
At it's core, it's really a mix of three things:
1. A language to define a dependency graph ("target: dependencies") and how the nodes are connected ("rules")
2. a functional scripting language to be able to factorize the declaration of the graph
3. and finally a graph traversal worker to dispatch and perform those rules that are required (including a sophisticated "job server" to maintain the concurrent job limit across child make processes with no developer intervention!)
I haven't encountered a good replacement tool that properly tackles all 3 of these feature sets. (Granted, I haven't done an in-depth analysis of the field...)
I used it on a project with many thousands of files and hundreds of (mostly dynamic) build rules. This was a literate program, and most build steps required the extraction of code from the source docs --- including build rules themselves --- and I still maintained sub-second updates.
I have! Tup was high on my list of potential replacement candidates (despite being initially put-off by the cheekiness of its homepage).
In my experiments though, Tup failed hard on point 2, lacking a good language to factorize the dependency graph declaration. (and to be clear, I think Make's is pretty terrible by itself, before GMSL or Guile extensions come into the picture)
Edit: I see tup supports Lua extensions, which may cancel my complaint above.
What language and/or system were you writing in? I discovered literate programming in 2003 and was excited by it (still am). But it never took off and the tooling was poor (Leo, the Literate Programming Editor, is the one I remember - and shudder thinking about)
Edit: some dead links there. This "bootstrap" directory contains the custom tangler and the custom rule processor. This 10K, plus the tiny configs in the root, are the only code in the project not in documents.
Have you considered just writing your own? The dependency graph should be a DAG - finding dependencies in a DAG is not hard. If you use a language like Python, This will easily give you point 2) - you can express abstractions in a much saner language than make.
Frankly, I have much better things to do than writing my own ad-hoc, bug-ridden implementation of Lisp^h^h Make.
I did look at SCons years ago, which is a Python-based build-system, but as I recall it ended up being the worse of both worlds by attempting a declarative syntax that was marred by its imperative warts.
I doubt it (if we're talking about the same thing since I see no mention of SLIME nor distel in the article). SLIME was developed as a replacement for ilisp which got a little long in the tooth.
ilisp was developed for Emacs to get a similar experience as developing on Lisp machines and now we're so far back in the past that I do not think that way of working was inspired by Erlang.
Agreed. I've used Vim as my editor for as long as I can remember, and combine it with make if a project needs some kind of compilation or post-processing step. The flexibility of using it alongside a powerful general-purpose text editor means you can basically do anything, without the need for an IDE. Even writing mobile apps, and you get a better understanding of what's going on "under the hood" as well.
It's amazing how many of those product links are dead just 6yrs later.
Electronics (or any "hardware") companies suck at maintaining links. Which is bad for SEO and bad for potential customers. Even if the products are old, at least mark the page as older.
It's not like people stopped using those old products and I can still find almost all of them for sale on craigslist. Particularly the audio equipment.
As the person who runs usesthis.com, let me tell you it's a massive pain in the ass (I have a JSON file for every item I link to, and so many just... die.)
Have you considered automatically submitting the links to the archive.org save API? Unfortunately it doesn't support HEAD anymore, only GET but basically just request this URL:
You could have a service that runs in the background (say once a week) on all outbound links that checks for 404s and then automatically updates the outbound link to the archive.org link. That or have both links.
Joe did talk about wanting a web where addresses are directly associated with an exact piece of content (i.e. addressable via a hash) and be able to live forever through some sort of distributed web.
I really hope that one day that vision becomes a true reality, I know there are lots of projects trying to tackle it !
Not a direct answer to your request, but you may also be interested in this book called “Dreaming in Code” [1] which documents the reasons and the whys of why the Chandler project failed, a book written by some of the people directly involved (if I remember right) and a book that I’ve also heard that is quite excellent (I’ve personally didn’t read it yet even though it has been on my to-read list for quite some tome, I did read though in real time the blog posts of some of the developers working on the project).
I love how his wishlist is basically “I want more fault-tolerance in my life.” It must have been supremely frustrating having built Erlang to see so much brittleness in the rest of the world.
Also, +1 for Emacs. :) It’s nice to know that some really smart people like the same tools I do.
It would cache data off-machine into fault-tolerant storage.
If the machine broke I would like to go to any other machine and resume work within a few seconds without losing any data.
If my machine was stolen I would like it to be totally unusable after a short time - so nobody would bother to steal it.
I would like the machine to recognize me, through some mechanism (fingerprints, retina scan, DNA - who knows) so I don't need passwords.
This seems to be a combination of what‘s possible with chromebooks + smartphone (not stolen much anymore because of Find My iPhone etc.) + Touch ID on the macbooks.
I have the first 3 points covered with resilio sync, wireguard, and running ZFS on a Linux district with full disk encryption. I would have all 4 if Linux supported newer fingerprint readers
Surprised he hasn't mentioned TiddlyWiki on that list, he was pretty enthousiastic about it the last couple of months on Twitter. I feel like I owe it to him to start using it and get my shit organized finally :/
Yes, the iPhone has it but it sucks. You can't reinstall anything without unlocking the phone (thanks to the closed ecosystem) and because pretty much all the hardware is integrated in a board it doesn't make economic sense to replace parts to circumvent this.
aw man, that 2013 hardware list is still state-of-the-art. my mbp of that vintage is still running strong and im terrified of what i will do when it dies (i use my ports all the time!)
In Erlang that makes a lot of sense since most of your calls into other processes are done with a timeout of (by default) 5s, so breaking for longer time puts the system in a very non-standard state, which doesn't help in finding errors :)
I have no idea what this means, or what relationship it has to the construct after it. Where does the result of ‘2a+sqrt(a)’ go? I thought ... was just a separator in the text, but now maybe it’s some sort of functional syntax?
This is exactly the problem I have with most of the articles I’ve read that extol the virtues of functional programming. They say something like ‘in a functional language all you do is X’, without explanation, where X frankly just looks like gibberish.
To be fair this isn’t an article about functional programming, or an introduction to it. Fair enough, but it’s still a bit exasperating.
EDIT Ok. I should have said this isn’t an introduction to functional programming.
I'm validated!
More seriously though, I find these particular choices interesting. For one thing, they're indicative of his experience as a "greybeard" programmer [1]: Someone who was still active until very recently but started programming 50 years ago. He was always try to bring forwards some computer science ideas from the 60s that never really made it into the modern zeitgeist. His tool choices seemed to represent that. Old tools that had some foundational flexibility that allowed them to stay relevant through the decades.
[1] and not the curmudgeonly kind who will only use what they learned so many decades ago, as demonstrated by his selection of more modern tools for other tasks