I love this! I have done a lot of CS research lately, and some of these I haven’t come across yet.<p>Let me share some of my favourites not listed here, off the top of my head:<p>- Ian Piumarta’s “Open, Extensible Object Models” (<a href="https://www.piumarta.com/software/id-objmodel/objmodel2.pdf" rel="nofollow">https://www.piumarta.com/software/id-objmodel/objmodel2.pdf</a>) is about creating the most minimal object-oriented metaobject system that allows the maximum amount of freedom for the programmer. It basically only defines a message send operation, everything else can be changed at runtime. The practical counterpart to the dense “Art of the Metaobject Protocol” book.<p>- John Ousterhout “Scripting: Higher-Level Programming for the 21st Century” (<a href="https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pdf" rel="nofollow">https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pd...</a>) - not really a paper, but an article from the creator of Tcl about the dichotomy between systems programming languages and scripting languages. Obvious at first sight, the lessons therein have wide ramifications IMO. We always seek the perfect multi-paradigm language that can do anything at high performance with the most productivity, while perhaps it is best to have compiled, fast, clunky systems languages paired with ergonomic, flexible interpreted frontend. Often all you need is C+Tcl in the same app. A must-read for anyone writing <i>yet</i> another programming language.<p>- Niklaus Wirth's Project Oberon (<a href="https://people.inf.ethz.ch/wirth/ProjectOberon/" rel="nofollow">https://people.inf.ethz.ch/wirth/ProjectOberon/</a>) is the implementation of an entire computer system, from the high-level UI down to kernel, compiler, and a RISC-like CPU architecture. He wrote the seminal "plea for lean software" and actually walked the walk. A long lost art in the era of dependency hell and towering abstractions from mediocre coders.
Love this post. Writing on programming languages has changed how I think about _programming_ in general.<p>I often think about this quote from TAPL. This framing of “safety” changed how I design systems.<p>> Informally, though, safe languages can be defined as ones that make it impossible to shoot yourself in the foot while programming.<p>> Refining this intuition a little, we could say that a safe language _is one that protects its own abstractions_.<p>> Safety refers to the language's ability to guarantee the integrity of these abstractions and of higher-level abstractions introduced by the programmer using the definitional facilities of the language. For example, a language may provide arrays, with access and update operations, as an abstraction of the underlying memory. A programmer using this language then expects that an array can be changed only by using the update operation on it explicitly—and not, for example, by writing past the end of some other data structure.<p><a href="https://www.cis.upenn.edu/~bcpierce/tapl/" rel="nofollow">https://www.cis.upenn.edu/~bcpierce/tapl/</a>
Regarding weird development methods of interest...Aaron Hsu of APL fame writes a lot of code in calligraphy with fountain pens when trying to organize his thoughts. I do something kind of similar, but in print with a crummy bic pen and a flow chart of Python objects (kind of like poor man's UML).
I would also highly recommend watching one of Rich Hickey's talks (especially the earlier ones). Watching those certainly changed how I thought about programming in general.
It's a shame that Abdulaziz went quiet after moving back to Kuwait. He was our intern on Maxine VM back in 2009. A super nice guy and that paper is a gem!
There was a nice post here recently about speeding up interpreters via closure-based interpreter:<p><a href="https://news.ycombinator.com/item?id=43595283">https://news.ycombinator.com/item?id=43595283</a><p>I hacked up a toy brainfuck interpreter using that technique and it was pretty fast. Not sure I'd get the chance to use it elsewhere, but experimenting with it was useful regardless:<p><a href="https://github.com/skx/closure-based-brainfuck-vm">https://github.com/skx/closure-based-brainfuck-vm</a>
I like this guy, so nothing against him, but none of these are about PL and all about these are about compilers (except for the one about GC). Which is fine (I like compilers) but they're just not in any way about PL.
I wish someone would write this for higher-level languages: JavaScript or .NET. I'm sure this person is brilliant, but they're operating at a much lower (higher?) level than most of us.
pytype is based in part upon byterun <a href="https://github.com/google/pytype/blob/main/docs/developers/index.md">https://github.com/google/pytype/blob/main/docs/developers/i...</a><p>I learnt a lot about bytecode interpreters from working on it, and it helped me understand the cpython source code a lot more easily from having played with a python translation of it first.
don't you mean bernstainbear?<p><a href="https://www.cosmopolitan.com/lifestyle/a7664693/mandela-effect-examples/" rel="nofollow">https://www.cosmopolitan.com/lifestyle/a7664693/mandela-effe...</a>