Lecture 7A | MIT 6.001 Structure and Interpretation, 1986

(I like _why and I don't have any problem with the attention he receives or anything. But I did kind of agree with some of the "that's rubbish" responses to the "first" stuff.) I'm reasonably sure I won't agree with you on any definition of art. But, uh, here's some stuff. I may-or-may-not think of some of it as art. I do think it's stuff that keeps the coding world from being some dreadful place of "craftsmanship" and "professionalism" and things. The miniKanren presentations are wonderful. They're all "and now let's run this stuff backwards. Because because." [LINK] Meta-circular evaluators. Page 13 of [LINK] [VIDEO] [LINK] ("After completing the preceding exercise, use the interpreter to run a copy of the interpreter, and use the copy to run another copy of the interpreter. Repeat this process to see how many levels deep it will go before the system grinds to a halt." :D) SICP opens with this: [LINK] I think it's lovely. [LINK] "One of Dijkstra's sidelines was serving as Chairman of the Board of the fictional Mathematics Inc., a company that he imagined having commercialized the production of mathematical theorems in the same way that software companies had commercialized the production of computer programs. He invented a number of activities and challenges of Mathematics Inc. and documented them in several papers in the EWD series." Also obfuscated code and some esolang stuff, I guess. I remember some competition that was about creating and hiding some bug that did some p

My favorite is the FLAC algorithm. It's fairly simple to explain - take a signal input, pattern match a generative signal that closely matches the original or part of it, and the output is a combination of that generative code and the difference between it and it and the input. Second favorite is the LISP REPL. Specifically the Eval function, thanks to this classic video of Sussman [VIDEO]

The self-definition comment is a reference to the common LISP exercise of writing a "meta-circular evaluator"[1] - that is, writing a LISP interpreter in LISP. This is famously done[3] in "Structure and Interpretation of Computer Programs", which is a very popular textbook and MIT course which uses LISP as a teaching language[2]. This can be found for example, in lecture 7 of the SICP lecture series on Youtube[4]. Dijkstra's comment on this is quite acerbic, isn't it? Here is the full quote for easy reference: > [LISP's] promotion of the idea that a programming language should be able to formulate its own interpreter (which then could be used as the language’s definition) has caused a lot of confusion because the incestuous idea of self-definition was fundamentally flawed. I agree to the extent that the exercise of writing a LISP interpreter in LISP is indeed often a very confusing exercise for beginner, partly because writing any interpreter (or compiler) is fairly arcane for a beginner, and partly because keeping track of which parts are in implementation and which parts are in the target language can be made more difficult; also because it's easy to "cheat" and rely on outside language in inappropriate ways. I would recommend using a language you already know well and implementing a moderately simple language as a first exercise to a student. But on the whole the exercise of writing an interpreter in its own language - or alternatively writing a self-hosting compiler[5] -