I'm doing my small part by paying for websites that respect me in the way TFA describes. I have annual subscriptions to Defector, Brand New, and DIELINE, and I'll add more as other websites follow their lead. Maybe it'll become too much to manage one day, but it might be for other readers too, and then maybe that will pressure our card companies and banks to start providing some more useful consumer services. We need enough people to actually subscribe to these websites to make that future happen though.
The divergence between users and programmers became more pronounced over time. When command line interfaces were dominant they naturally made programmers out of users, even if they didn't realize it. CLIs made “using the computer” and “programming the computer” effectively the same activity in a lot of cases. A command someone entered to run a program was itself a program. Entering the previous command again and modifying it, for instance to pipe the output of the first program into another program, was also a program. Once the desired result was achieved, that final command could be saved and used again later. Or shared with someone to be used as-is, or to be tweaked a little bit for their own use case.
Each interaction with a CLI results in a valid program that can be saved, studied, shared, and remixed. That's a powerful model for the same reasons the spreadsheet model is powerful: it's immediate, not modal, and successful interactions can be saved as an artifact and resumed later. Can we do the same things for GUIs? What is the GUI equivalent of pressing the up arrow key in a shell, where I can recall my previous interaction with the system and then modify it? Can I generate artifacts as byproducts from my interactions with a GUI system that I can save for later and share with others?
Stamp collecting is a good outlet for research as leisure. If you're the type of person who falls into wiki holes and likes talking about what you learn with other people, it might be for you.
Many stamp collectors follow the research-as-leisure framework naturally as part of their hobby. The article outlines cultivating curiosity, developing questions, gathering evidence, developing answers, and building communities around that process, which is basically what collectors are doing when they're talking about stamps and other philatelic material. They're sharing discoveries they find interesting, often only after identifying the material, looking up its historical context, drawing parallels to current events, and then formulating some kind of answer or conclusion that makes it worthwhile to share what they've found.
I think the experts in a lot of hobbies engage in this sort of recreational research for the joy of it, but it's closer to the norm for casual collectors. There is a whole wide spectrum of collectors though, ranging from aesthetics-driven folks who spend more time on thematic album pages than on researching anything, over to experts in narrow areas like Transylvanian hotel stamps who publish whole books on about how they weren't valid for postal use but were used by hospitality workers nestled up in the Carpathians to get mail from guests back into the official mail stream because the state couldn't be bothered to service up there. If you get into it you'll find there are a lot of curious and motivated people in the middle who are happy to share what they've been reading about (or listening to, or watching) lately.
Nice work with the guide, the bevy of examples makes it easy to digest.
The colon being used in multiple contexts is tricky. As I was scanning the examples I found postfix `:` doing type conversion like in `(%)\. {%/Apple/}{`3:}` and then I was wondering what it does when it has nothing on its left-hand side, like in `[(+)|0 [:1"x]`. Then I noticed that the [ were unbalanced in the latter example, and eventually figured out that `[:` is its own operator separate from `:` and the middle `[` had nothing to do with function syntax.
A big use case for them was using them as scriptable editors in pipelines, and a lot of vim's commands are inherited from them. The diff(1) utility actually has an option to emit ed script, allowing files to be patched in ed pipelines: http://www.gnu.org/software/diffutils/manual/html_node/ed-Sc...
I wouldn't consider the industry backing of Heroku and a collective 4,500+ GitHub stars between the tools particularly niche or obscure. Crank it up to ~20k stars if you want to count deploy tools that can use them, like Dokku or Flynn. Anyway, the other great thing about Procfile is that it's just a declarative format. Lots of tools can leverage them, and they are an important part of my and many others' workflows.
I also don't think the article is too keen on "standards", judging by it referring to make a "task launcher" and the suggested usage completely diverging from the expected behavior of the program.
I like the ideas here, but for long-running processes like file watching, dev servers, hot reloading, etc. a better format is Procfile (https://devcenter.heroku.com/articles/procfile). The ideas from this article could be nicely applied to it.
Procfil is a format that declares a named list of processes to be run that can be controlled by tools like Foreman (http://ddollar.github.io/foreman/) and Honcho (https://pypi.python.org/pypi/honcho). The advantage is being able to start and stop them concurrently as a group, useful for things that otherwise take a tmux session or multiple windows/tabs, like dev server + file watching + live reload: they become a simple `foreman start`. Processes can also be started individually. Procfiles can also be exported to other formats, like systemd, upstart, inittab, etc.
Here's an example Procfile from a web project I've been working on. Since it uses node I went with node tools like http-server and watch, but it could just as easily use any other web server or file watcher. The way it works is it starts a web server serving public/; starts a live reload server for public/; and watches the src/ directory for changes and re-runs make. The makefile has a few rules for compiling JS and CSS from src/ to public/.
web: ./node_modules/.bin/http-server
livereload: ./node_modules/.bin/livereload public
watch: ./node_modules/.bin/watch make src
ffmpeg can utilize streams, in both input and output. The trouble comes from different codecs and containers, especially on output. Some formats aren't append-only—the prime example being MP4 + h.264—and so ffmpeg needs to be able to write to a seekable output device, ruling out streaming output in those cases.
In systems like Flake you are able to get a useful roughly-ordered property which is good for generating ID's and organizing things like activity feeds. Things will be mostly sorted by time by encoding the time in the most significant bits, but they will be fuzzy because of machine and sequence ID's in the LSB's. You will get monotonically increasing ID's per-process because each one spinlocks locally against backwards drift, but you're not guaranteed to get monotonically increasing ID's globally across all processes. One process' time might drift forward, or you might have two ID's at the same time but the instance with the higher machine ID responded first.
As others have noted, there is a semantic difference between Markdown and roff. But if you really want to write them in Markdown, you can with ronn: http://rtomayko.github.io/ronn/ Ronn also supports outputting to HTML.
I wouldn't use make for file watching and live reloading. I would express the Sass and CSS dependencies in a Makefile, and then describe the dev server, file watching[1], and live reloading[2] processes in a Procfile, using something like foreman[0].
> Make is for executing shell commands on file patterns with dependency rules.
Yep absolutely. Make is a system for generating files from other files, it is that simple. Compiling templates and code, generating source maps, concatenating, minifying -- many of these tasks all fall under that umbrella.
> It's not designed to use an ecosystem of plugins or have long running processes (eg. to run a local server or watch for file changes).
You're right, I wouldn't advocate that either. Procfiles and tools like foreman (and it's various reimplementations, like honcho) are for managing those processes: development servers, file watchers, etc. That's actually my own personal approach, I go for the Makefile/Procfile combo and run `foreman start` to boot up the a server and any other processes that project might need. Works pretty well for me.
> Make isn't a bad tool; for very doing some specific things. Specifically building c code on unix-ish systems.
That's a pretty narrow view, like I said earlier, it's good for any application where you're generating files from other files. Building an ebook, managing unwieldy SSH configurations (smdh at lack of include directive in SSH config), etc.
So yeah I agree make is no good at being an all-in-one everything-and-the-kitchen-sink suite. And that's great. It has one job and does it well enough, and is even better complemented by other tools. Some people like the suite approach better, but I wouldn't disparage make for something it wasn't intended to do to begin with.
The "horrific syntax and semantics" claim seems pretty drive-by, the variables and some function names might be arcane, but newer releases have nicer aliases for those who care for them. I don't know what is so horrific about the semantics though, they are pretty straightforward. A Makefile is a set of rules, each rule being a target file, its dependencies, and the recipe to turn the dependencies into the target. Make can figure out which steps need to actually run based on the states of the targets and dependencies (prereqs in Make terms). It's a really powerful way to describe the relationships and transformation steps for files, and you get partial builds for free! Not that make is without problems (the initiative behind DJB's redo addresses them at length) but unsubstantiated FUD isn't necessary.
I think these languages for generating data are really useful. There is one called Protodata (https://github.com/evincarofautumn/protodata) for generating binary data. From the README: "Protodata is a language for describing binary data, originally written for prototyping and reverse engineering binary file formats. It is particularly useful for generating annotated data in a custom format, without having to write custom editing tools."