Macro examples are often poor, and my advice is to always favour functions, since then you are working with actual values. For instance, with-open-file should be a higher order function, not a macro as it is in CL.
That leaves a few other uses: macros as compiler extensions for generating fast code (see "Paradigms in Common LISP" for a lovely example of a parser generator). But heed warnings about premature optimisation.
It leaves macros for novel binding strategies. List comprehensions, do-notation, destructuring-bind, pattern matching, CL's LOOP and macros that anonymously bind a pronoun like "it".
I have no shame in using macros for really succinct control structures where delaying evaluation with a lambda would just look gross (see "or" and "and" macros), but maybe that's just a cry for lazy evaluation :P
Wadler's introductory Haskell course at Edinburgh doesn't cover monads, but it's great. I don't want to use scheme because I want students exposed to a decent static type system. There's an argument to be made for using standard ml, maybe.
I think the fact that strings are linked lists is great for beginners. One of their assignments is on web scraping, where they can reuse all their list based functions to solve the problem.
I am not too keen on Haskell's polymorphism for teaching beginners, and error messages are mostly useless for them. If I were teaching again, I would be recommending custom preludes with simpler types.
I spent my twenties running long distance, but gave up four years ago. The frequent injuries were just too much. A bad injury once had me off training for four months. Going from feeling like a machine to someone who can't manage a jog in the space of an afternoon seriously messed with my emotional state.
I'm writing this on a recumbent bike. I've averaged ninety minutes a day for four years without injury. I've also read a ton of books on my kindle.
I want to give urbit a try. I have a planet, but last time I fired it up the latency was so bad that I wasn't having fun. I'll try again sometime.
I can even get behind runes, and I set up abbreviations in Emacs to learn their names. And generally, I like the philosophy of language where short, one syllable, old/middle English words are used in place of the less familiar Latin/Greek derived words. I don't have a problem with revising our existing vocabulary in this way.
But the attitude to type theory strikes me as anti intellectual, precisely because we get nonsense claims about Hindley Milner requiring category theory. This sort of misinformation does no good for anyone.
Yes, but are most games mostly static scenes because the tech is limited? Getting a decent looking scene which can be rendered quickly has historically relied on precomputed light maps, light volumes and space partitioning, which massively restrict the sort of game you can make if you want scenes to look nice. If more could be done in realtime, we would see games which were not mostly static scenes.
I compare the situation to the 90s games. Machines did hardware scrolling and were optimised for blitting sprite sets. And so, lo and behold, most games are scrolling shooters and beat em ups. I always felt gpus have put similar constraints on our imaginations, hence most games are mostly static scenes.
It's a pretty poor REPL. Every time you update your code, you have to reload, and you lose all your previous bindings. And, no, I don't simply want to rerun my interactive session. I want a persistent session.
When doing theorem proving in Ocaml (which was both ML's and Lisp's MOs), my REPL session could last months. I sadly didn't have Lisp's great (save-lisp-and-die) in Ocaml, but I was able to snapshot the process state to get semiway there.
Common Lisp is built around the idea that your runtime is a persistent live system that you stay in and modify and introspect. Your tool-chain should consist entirely of Lisp objects that are part of your runtime, and should themselves be modifiable. Everything is programmable. The Art of the Metaobject Protocol is still one of the coolest things I've ever read.
I'm a Haskeller now, through and through, but Haskell's REPL and runtime isn't comparable to Lisp's.
So far, Incandescence is the toughest of his novels that I've read, and the main world is an extreme and beautiful conception where the ambient forces are all peculiar and the inhabitants are figuring out their cosmology as the novel goes on.
That said, I really could have used more diagrams while I was reading. I only found out after finishing that Egan has a whole bunch of Java applets on his website explaining the experiments that the main characters in the novel carry out, and why they give the results they do.
I'd love to see IPFS video (https://ipfstube.erindachtler.me/ ) get used for this sort of thing. For static, high-bandwidth content like video, that is created by users and for public domain, it makes more sense to be than a fat centralised pipe that's extremely expensive to maintain.
This is pretty much my setup but I still use the terminal a lot. What are you using instead? eshell? ansi-term? Or do you find you don't need terminals much generally?
Since discovering paredit-mode, I have found a whole new love for Lisp syntax, and now I won't write Lisp without it.
I have tried a structure editor for Haskell but I found it pretty counterintuitive. I wonder if structure editing just assumes a language with very little syntax.
NixOS gets my vote too. I started on Gentoo back in 04, played with Arch for a year or so, then went to Nix a few years ago. I have never had so much love for an operating system.
The Nix language is cute, very powerful, and as you say, is capable of cool tricks. I personally find it very easy to read too.
For every project I work on, I define a .nix file describing its build environment. It is then just a matter of cloning the repo, typing nix-shell, and then all build dependencies will be downloaded and I'm ready to go. These nix files also specify which emacs I want to use and with which modes: I don't use Emacs' package manager.
I use nix-shell for pretty much everything. My basic environment contains only core utilities. I launch firefox with "nix-shell -p firefox --run firefox" (bound to a shortcut defined in my xmonad config).
Nix is easy to customize. The override infrastructure makes it easy to modify package definitions from your user config file, and I find I am much happier doing this in a programming language rather than a bespoke config file format.
Other pros: you don't need to be root to install stuff. And there isn't much more satisfying than getting a new laptop, git cloning the repo containing your intended system configuration, and being back up with your old OS with one or two commands.
As you say, if Arch turns you off, Nix may horrify. Despite the vote, I'm pretty discriminating about who I recommend it to.