Chattered

Point being that plagiarism/copying might be easier to spot via mistakes. I understand that this is how scholars do it for ancient texts.

It's not the same 23 word sentence. It's the same 23 word run-on. The first comma should be either a semi-colon, colon or stop.

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.

Dejavu Sans Mono.

For some reason, I've typed it out in a few files, such as my Emacs init and .Xresources.

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.

Which book is that? I'd love to read.

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.

I kept my office machine as an additional remote for when I was working at home, pushing over ssh to save an extra pull when I got in.

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.

Proof assistants are frequently used to prove the correctness of computer programs. And since a proof assistant is a computer program, and often quite a complex one that could contain bugs that render everything it does useless, you might want to use your proof assistant to prove that its code does what you hope it does.

Goedel's second incompleteness theorem says you can't do that. Ever. And more generally, it says that you will hit a roadblock as you try to prove what it is that your proof assistant does. This is really annoying.

But you can get pretty damn close. HOL Light has something of a self-consistency proof that is so close to the real thing that it's worth taking seriously.

But incompleteness, by itself, isn't a big deal for theorem provers. Russell himself worked as if the existence of infinities wasn't provable, which is why Goedel had little relevance to Russell. Hilbert on the other hand....

Maps should do whatever ArrayList does when your index is out of bounds. And so long as null is a value that could be in the collection, lookup should definitely not return null.

If a lookup fails, it is often a bug or a violation of a constraint that you shouldn't be handling. Throw an exception. If a lookup is expected to fail in normal execution, you can use an Optional to mash together a check and lookup in a typesafe way. Lookup failures should not be allowed to propagate as nulls only to be caught as NullPointerExceptions in disparate parts of the code.

Your first sentence is very close to something I've said to others. NixOS is the first time I've been excited about an OS since first discovering Linux back in 2003.

The OP mentions "the ability to do controlled per-user changes in an ad-hoc fashion". I assume they are referring to the use of "nix-env", which some members of the community frown upon. I've adopted the policy of not using it. My system is defined entirely by various ".nix" files, and for launching simple applications, such as firefox, I just have my xmonad configuration bind "C-SHIFT-F" to "nix-shell -p firefox --run firefox".

For programs where I have more complicated environments, I have a "shell.nix" file in $HOME which contains a bunch of derivations that I commonly use, and I use "nix-shell -A" to enter them.

For development, all of my projects now include a "default.nix" file. Typing "nix-shell" in the project directory then brings in my project's dependencies as well as the tools I want when developing on that project, such as a suitable Emacs with the appropriate packages already installed.

I find I move these move ".nix" files frequently between different machines, and I really appreciate that I am put into reproducible development environments wherever they are.

To reiterate what others have said below: the Nix package manager makes sure to share build inputs. If I start a new project and include a bunch of stuff in my "default.nix" that I use elsewhere, it costs nothing to enter the new environment.

I see this frequently in Edinburgh. I join a group at the pelican crossing and after waiting too long, realise that the button hasn't been pressed.

Many of our crossings do nothing if you don't press the button. And if the light has been green for road traffic for a while, pressing the button /immediately/ sets the traffic sequence towards red. I often let the odd car pass so the traffic looks clear before pressing, rather than force a poor driver to a stop.

You sure? I was playing with Unity back in 2009 and you scripted both game and IDE atop mono. The .NET flavour of JS was being pushed, with code examples additionally in C# and Boo (!). I preferred to use F#.

We know Haskell variants or maybe scalaz. I don't get why these now represent pure functional programming. Scala isn't even close to pure. This is just jargon for languages that can represent very abstract mathematical concepts.

I am happy to see these ideas work their way into any language. I just question the utility here. So there are potentially abstract things going on in my code? Great. So what? I can maybe notice it and get back to work.

Haskell gives me more. It says I can define some of the abstractions and write code against them. More realistically, it allows someone smarter than me to define the abstractions which I can then code against. For better or worse, this is expected now of even beginner Haskell programmers, where "monad" rears its head as an inbuilt type class, in inbuilt functions and some of the earliest type errors.

In Haskell, a monad isn't just an abstract concept that you can see if you squint hard enough at your code. A monad is code. It has an implementation as a typeclass, in Ocaml as a module type. How is it implemented in JS?

I am also sceptical that these abstractions are useful outside statically typed languages. Haskellers habitually ride towers of these constructs and I for one couldn't do it without a type inferencer. I already find scalaz too painful for me personally.

Kay has also suggested that late binding or dynamic dispatch is a massive deal, and in most statically typed oop languages, dynamic dispatch is typed according to the inheritance hierarchy.

The upshot is that to teach OOP in Java, say, you need to talk about significant parts of the inheritance machinery just to get dynamic dispatch, perhaps later cautioning against implementation inheritance and even interface inheritance.

In Smalltalk, you can talk dynamic dispatch without messing around with inheritance at all.

For a statically typed language where dynamic dispatch is free from inheritance graphs (sometimes described by saying that subtyping is not inheritance) see Ocaml's structural subtyping via row polymorphic records (bit of a mouthful --- but I need to differentiate from Ocaml's module system which is structurally subtyped and supports inheritance!)

Camus would tell you that by killing yourself, you have utterly failed to embrace the absurd. I would say the same for anyone chasing scientific techno utopias.

Please explain how to lift the constructors of Maybe to typeclass instances where its use can be monomorphised.

I disagree, and since we are talking about the expression problem, we should not be conflating dynamic dispatching code which could be statically resolved from dynamic dispatching code which is necessarily dynamic.

A standard use-case of dynamic dispatch is for representing different types of term in a parse tree, where we want to dispatch on nodes according to type. This sort of dispatch cannot be monomorphised, since the the exact callee depends on the shape of the trees being traversed and this almost certainly cannot be figured out statically.

In Haskell, you do not do this sort of dispatch with typeclasses, but instead use ADTs.

When it comes to the expression problem, the tradeoff is that ADTs allow you to easily write new sorts of traversal but do not allow you to extend the tree type in a modular way. By contrast, single dispatch OO allows you to easily extend the tree type by providing new classes to implement the traversal methods, at the cost that you cannot easily define new traversals.

They can be implemented via method dictionaries but, sans type system extensions, polymorphic recursion and separate compilation, all uses of a type variable constrained by a type class could, in principle, be monomorphised and the dictionaries eliminated. This is not true of dynamic dispatch.

And ensime for Scala.

The idea is at least as old as SLIME, which has been the defacto common lisp mode for Emacs for ages. When I was using it nearly fifteen years back it was easily the most comfortable development environment I had used in any language.

I recently had a paper published written in org mode and I have another in review. I don't plan to write straight LaTeX again.

For me, babel is the killer feature. I can write code snippets in the buffer, highlighted and indented according to the corresponding emacs mode, with paredit for lisp, and beautifully exported via pygments. A single key combo lets me evaluate my code in persistent repls associated with my buffer, and I can choose what combo of code/result I want to export. I had some of my snippets generate raw LaTeX that I could include in the document.

Org links make section references trivial, and I have it hooked up to ebib so my citations are pure org. In the emacs buffer, clicking a citation link takes me straight to the bibtex entry.

I don't much use the organiser, but I do use org heavily for writing cross referenced notes about other people's code.

I have this library:

https://github.com/Chattered/ocaml-monad

and use it regularly when writing Ocaml. I'd like to get back to it and try to implement some MTL style interfaces (MonadState etc...). Edward Kmett says this is not likely to work, but that sounded like a wager to me.

Most BBC Micro games loaded like this: game data would spill into memory mapped video and then dealt with after.