John Wiegley writes about Git internals, Haskell, Lisp, Emacs, and more recently his Claude Code setup.
HN commenters often recommend 'Git from the Bottom Up' as the best guide to how Git works, and read his Haskell and Lisp posts.
Git commands are not consistent. This is a result of it growing organically, and having a maintainer who strongly values backwards compatibility. But you know, having used git for years that doesn't bother me. Let me explain.
Git is conceptually straightforward[1]. It is difficult if not impossible to discern those concepts from its baroque CLI. So learning git from its built-in help and/or man pages is suboptimal if not a complete waste of time. Either read the Pro Git book[2] or pop the hood[3]. Then the inconsistent CLI is no longer a big deal. If it were, someone would have come up with a new porcelain (high-level CLI) that would have taken hold by now. And no one really has. There is Easy Git[4] but I don't know anyone who uses it.
And really, I see git as not much different than Unix in this regard. Unix commands vary widely in their usage. Does knowing awk help with sed? cpio and tar? wget vs curl? Eventually you understand concepts such as pipes, regular expressions, file descriptors, etc and you become familiar with the commands where you are able to apply these concepts, at which point does strict interface consistency between them matter? I dunno, but I started with both git and hg around the same time and ended up happier with git. Mercurial had the "better" CLI, but I found git was better at doing what I wanted. Before that I used clearcase, which has a very consistent CLI and yet I was constantly cursing at it.
Or maybe I just have stockholm syndrome and I'd…
It is not the language per se, but the tools around it that makes it amazing.
After years hearing about org-mode, three months ago I finally decided to try it out. Here is how it went.
I started simple. First I watched a short tutorial which gave me the overall idea [1]. Then, I created a simple todo.org file and started fiddling with it. You add lists with * and nests them with more *
* Project
** Code
*** TODO Email my co.
*** TODO Implement foo
** DONE Implement bar
As a side note, I think Markdown syntax is much better visually. org-mode has more clutter when formatting block code, inline code, and URLs. The good thing about * is that nesting is easy.
After that, I started trying out the keybindings: <tab>/<S-tab> folds lists; C-c C-t is a function to cycle between task states; C-c C-s schedules a task for a given day; C-c C-d sets a final deadline; C-c C-a shows the agenda (day/week/month); you can refile entire groups of tasks (C-c w), archive (C-c C-x C-a), move tasks around (M-ArrowUp/ArrowDown), increase depth (M-ArrowRight/Left). These are the main shortcuts I use. You don't need to memorize all, you can access most through M-x org- and hitting tab to see the functions available.
Another useful function: C-c C-l adds a link, which can be an URL, a file, a folder. Then, you can open that link with C-c C-o. It is great to add context to a task, like
* TODO read hacker news article…
If you use Emacs, it's particularly easy to learn them by experimenting with M-x re-builder.
Hey! I did not know about this, and it looks really useful. I've used http://www.newartisans.com/blog_files/regex.tool.for.emacs.php and it's good, but not as well integrated.
I wish I knew a better way to get a survey of what's available in the Emacs world - something that would have clued me in to this command, for example... any tips?
Edit: I want to comment on this as well:
learning a lexer/parser is the next step
Recently I've had occasion to write a few parsers. In the past, I'd always used parser generators (yacc and antlr) on the assumption that they made things easier. For this project that wasn't an option, so I bit the bullet and did the recursive descent thing. To my surprise, it turned out to be way, way easier than I expected. Moreover, in at least one case (a complex one), the hand-written parser code turned out shorter than the (cl-) yacc version, as well as handling more cases and reporting errors better.
The morals of the story are: (1) Don't assume something is hard without trying it; (2) It's not hard to write a classical recursive-descent parser and the skill is a lot more useful than you may realize. Wish I'd learned that a long time ago.
The first line of the abstract reminds me of some recent work allowing plain Haskell functions to be sent to the Z3 theorem prover/SMT program:
http://newartisans.com/2017/04/haskell-and-z3/
It leverages some cool work of Conal Elliott that develops (formulas in) cartesian closed categories into something like an "intermediate representation" for functional language compilation.
http://conal.net/blog/posts/haskell-to-hardware-via-cccs
http://conal.net/blog/posts/overloading-lambda
http://conal.net/papers/compiling-to-categories/ (the "LaTeX goals" ICFP 2017 paper)
--
Also, something I always like to link when this kind of thing comes up: the salamander lemma!
https://sbseminar.wordpress.com/2007/11/13/anton-geraschenko-the-salamander-lemma/
https://mathoverflow.net/questions/6749/a-proof-of-the-salamander-lemma-without-mitchells-embedding-theorem
I think this nails the challenge of getting started with Common Lisp:
'With Lisp, newbies say "How do I get started?" and instead of a URL, they get "Lisp is a family of languages, with the primary branches being Common Lisp and Scheme. But these are just language standards with a number of implementations. Which implementation is best for you depends on your platform and computing needs." Huh?'
I think SBCL is closest to being the default CL implementation, but the functionality on Mac/Windows still isn't quite caught up to the Linux version. Threading seems to be the biggest sticking point.
If you have a Mac, the best starting point I know of is ReadyLisp:
http://www.newartisans.com/software/readylisp.html
These posts can get your ball rolling. The first one is pretty detailed, I started with copy-pasting a large hunk of code from it and using as is.
Once you get the hang of it, the second one gives a gentle introduction to the entire process of capturing, refiling and prioritising.
http://doc.norang.ca/org-mode.html
http://www.newartisans.com/2007/08/using-org-mode-as-a-day-planner/
Also, this one on quickly capturing anything from the browser:
https://orgmode.org/manual/Protocols.html#Protocols