Should Programming Languages be Safe or Powerful?

2024-11-21T00:00:00+00:00

Should a programming language be powerful and let a programmer do a lot, or should it be safe and protect the programmer from bad mistakes? Contrary to what the title insinuates, these are not diametrically opposed attributes. Nevertheless, this is the mindset that underlies notions such as, “macros, manual memory management, etc. are power tools—they’re not supposed to be safe.” If safety and power are not necessarily opposed, why does this notion persist?

The problem—I think—is that historically you did have to trade safety for certain kinds of power: if you wanted to write a high-performance device driver, C—with all its unsafe behavior—was your only option. This founded the idea that the “power tools” of the industry were fundamentally dangerous.

There’s a few things wrong with this though:

Power is relative to the domain of interest. Both Haskell and C are powerful, but in completely different ways. So, when judging whether an aspect of a language is powerful or not, consider its application. </li>

Expressive languages get you power without sacrificing safety. New advances in programming language research have found ways to express problem domains more precisely. This means that we have less and less reason to breach safety and reach into the unsafe implementation details to get our work done. </li>

It’s good to add safety to power tools. A safe power tool is more trustworthy than an unsafe one. This holds for real-world tools: I will never use a table saw without a functioning saw stop. </li> </ol>
Specifically in the case of macros, there’s been an evolution from powerful-but-unsafe procedural macros in Lisp to safe-but-less-powerful pattern macros in Scheme, and finally to powerful-and-safe macros in Racket.
More safety means higher reliability—something that everyone wants. And with advances in making languages more expressive, you can have a language perfectly suited to a particular domain without sacrificing safety.
What makes a language powerful?</h2> A language that lets you do more of what you want to do is more powerful than a language where you can’t do what you want. But what does “what you want to do” encompass? If you want to write device drivers, then C is great for you. However, C is not as expressive in some of the ways that, say, Haskell is. For example, in Haskell, I can write lazy, recursive definitions. Here’s a list of all 1</a> the Fibonacci numbers:
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)</code></pre>
Before you tell me that that’s just a useless cute trick, I actually had to use this when I was building the balancing algorithm in my rope data structure for my text editor written in Haskell</a>. Haskell is incredibly powerful in an expressive sense: a single line of code can elegantly capture a complicated computation.

The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.

Edsgar Dijkstra </footer> </blockquote> </div>
Power is closely related to the domain of interest: a language is powerful in a particular realm of problems. C is powerful for working with memory directly. Conversely, Haskell or Racket is more powerful than C in pretty much every other domain because these languages give the user tremendous ability to match the program to the domain. This is a meta-power that sets high-level languages apart from lower-level ones.
Safe languages can be just as powerful as their unsafe counterparts—in many cases, they are more powerful because the abstractions they create better fit the domain. Whenever a tradeoff between power and safety must be made, that is a sign that the language is not the right fit for the domain.
Consider how immutability gives you local reasoning power. At one of my industry jobs, our codebase was a mixture of Ruby and Elixir. Both are safe languages, but Elixir is immutable. When I was working on some Elixir code, I could read:
user = get_user(session) name = get_user_name(user) do_something_else(user)</code></pre> and I didn’t have to worry about user</code> getting modified in the call to get_user_name</code>. To understand the output of this function, I didn’t have to worry too much about the implementation of get_user_name</code>. In contrast, if you did the same sort of thing in Ruby:
user = get_user(session) name = user.get_name() user.do_something_else()</code></pre>
the get_name</code> method could do something sneaky like set name to "blank"</code> if it didn’t exist.2</a> In this case, I did have to understand what every method call did to understand the function. This made it harder to track down errors because I had to account for all the side effects that could happen at every method call.
Certain things like immutability might seem constraining, but constraints can liberate you</a> by allowing you to rely on particular behaviors. Elixir doesn’t let you modify things in-place, but you can rely on this, which makes understanding and composing code easier. Haskell forces you to express side-effects in the type system, but this lets you know that calling a function with a signature like String → Int</code> won’t do any IO or throw an exception. Rust doesn’t have null</code> like in Java, but you know when you get a pointer, you can safely dereference it and you don’t have to do all the null checking that you have to do in Java.
Case study: macros in Lisp, Scheme, and Racket</h2> The evolution of syntax macros in Lisp, Scheme, and Racket provide an interesting real-world instance of how safety and power can start off as a trade-off, but with better language design, become complimentary. Lisp macros: unsafe but powerful</h3> I don’t have the space here to do a deep dive into Lisp macros, but here’s the short of it: Lisp macros are just functions that receive code as data. This code is represented as nested lists of symbols. All a macro needs to do is return a new list of symbols that will be spliced right into the call site. (defmacro my-or (thing1 thing2) `(let ((tmp ,thing1)) (if tmp tmp ,thing2))) ;; calling the macro (my-or 1 2) ;; expands to (let ((tmp 1)) (if tmp tmp 2)) ;=> 1</code></pre> The problem with this is that these macros are unhygienic: if I introduce a new variable, as I did with tmp</code> in my-or</code>, that is just a bare symbol that can be inadvertently captured producing unexpected output: (let ((tmp 99)) (my-or nil tmp)) ;; expands to (let ((tmp 99)) (let ((tmp nil)) (if tmp tmp tmp))) ;=> nil</code></pre> This is very bad! To use a macro safely, you need to be sure that it’s not introducing variables that you might accidentally capture. Lisp provides a mechanism3</a> to avoid some of the pitfalls with variable capture, but that’s not the end of the danger. If I have a macro that expands to a call to a function, e.g. printf</code>, I would expect this to be the printf</code> in scope at the time I defined the macro. However, this might not be the case—a user might inadvertently redefine a function, and then the macro would not behave in the expected way. Scheme macros: safe but less powerful</h3> Scheme has a faculty called syntax-rules</code>, which lets you define transformations between a pattern and a template: (define-syntax my-or (syntax-rules () ((_ thing1 thing2) (let ((tmp thing1)) (if tmp tmp thing2)))))</code></pre> Rust’s macro_rules!</code> form</a> is essentially syntax-rules</code> from Scheme, but a little fancier with some syntax classes like :expr</code> and such. </div> This is safe; the examples from the Lisp run as expected: (my-or 1 2) ;=> 1 (my-or #f 42) ;=> 42 (let ((tmp 99)) (my-or #f tmp)) ;=> 99</code></pre> However, we’ve lost some of the power because we can only define transformations between templates. We can’t, for example, write a macro that does some deep inspection of the code and makes decisions on how to expand. Furthermore, there’s no way for us to intentionally break hygiene when we really want to. Racket macros: the best of both worlds</h3> Racket resolves the dilemma between having to choose between powerful Lisp-like procedural macros, and safe Scheme-like hygienic macros by giving us fully hygienic procedural macros! I have another blog post discussing macros in Lisp, Scheme, and Racket</a> and I go into some detail about the evolution of those macro systems. And if you want to dive deep into macro hygiene, see Matthew Butterick’s excellent explainer on Hygiene</a> from his book Beautiful Racket</a>. </div> The upshot of it is that Racket uses a combination of features (scope sets, syntax objects, etc.) to give the user a richer way of specifying syntax than simple dumb lists of symbols. This avoids inadvertent variable capture as well as keeps function references lined up nicely. However, macros can still do arbitrary computation, which means that we’re not constrained in the way that the pattern-transformation macros in Scheme are. And just to prove that Racket is just as powerful as Common Lisp, here’s the classic aif</code> macro: #lang racket (require racket/stxparam syntax/parse/define) (define-syntax-parameter it (lambda (stx) (raise-syntax-error (syntax-e stx) "can only be used inside aif"))) (define-syntax (aif stx) (syntax-parse stx [(_ test tcase fcase) #'(let ([tmp test]) (if tmp (syntax-parameterize ([it (make-rename-transformer #'tmp)]) tcase) fcase))])) (aif 41 (+ it 1) 'whatever) ;=> 42 it ;error: it: can only be used inside aif</code></pre> This example is inspired by Greg Hendershott’s fabulous tutorial Fear of Macros</a>. The define-syntax-parameter</code> bit lets us introduce new bindings intentionally, whilst still keeping us from accidental breaches of macro hygiene. Consequentially, Racket’s macro system is far more useful than Lisp or Scheme’s systems, and this because of Racket’s safety and expressiveness. You can actually build trustworthy systems on top of Racket’s macro system because you’re not constantly foot-gunning yourself with hygiene malfunctions, and the macros are expressive enough to do some rather complicated things</a>. Towards greater safety and reliability</h2> Safe systems let us build software that is more capable and more reliable. Unsafe power is something to improve, not grudgingly accept—and much less defend as somehow desirable. Languages like Rust and Zig have made systems programming immune to whole hosts of errors by being more expressive than C, and languages like Racket are leading the way in making metaprogramming more useful reliable and less like dark magic. Further reading</h2> If you want to learn more about writing macros in Racket, check out Beautiful Racket</a> by Matthew Butterick and Fear of Macros</a> by Greg Hendershott. I highly recommend listening Runar Bjarnason’s talk at Scala World, Constraints Liberate, Liberties Constrain</a>, wherein he discusses how constraining one part of a system can open up freedoms of later components that build on that constrained part. Yes, all the Fibonacci numbers. Haskell is lazy; this will compute as many as you ask for. ↩</a> </li> You might think, “well, just document that behavior.” Now I need to read the documentation of every function I encounter—I might as well go read the code to be sure the documentation isn’t out of date. Local reasoning means to understand what do_something_else</code> is passed, I don’t have to worry in the first place if get_name</code> will do somethig to the result of get_user</code>. ↩</a> </li> Lisp has a function called gensym</code> which makes a fresh symbol for you to use. Some other languages such as Julia</a> have a gensym</code> function; gensym</code> is a poor substitute for proper hygiene. ↩</a> </li> </ol> </section>

How to Make Racket Go (Almost) As Fast As C

2024-10-15T00:00:00+00:00

I recently wrote about using first-class functions to help make a BF interpreter</a>. This is a follow-up post to describe a nifty solution to a tricky problem that made my program go 2–5× faster and put it about on-par with an interpreter written in pure C.

A basic interpreter works by walking down the AST and evaluating nodes recursively: when the interpreter encounters an expression, it dispatches on the type of expression to decide how to perform the evaluation. Here’s the key insight to get a massive speed bump with very little effort: that dispatch is expensive and can be performed ahead-of-time. We can walk through the code once and precompute all the dispatching work.

This is not a new idea. The first description that I’m aware of comes from Feeley and Lapalme [1</a>]. A name for this technique is making a threaded interpreter. It’s nowhere near as fast as a native code compiler, but interpreters are easy to write, and this is a very simple way to get a very big boost in performance.

A basic interpreter</h2>
Please see the appendix</a> for the full code for this interpreter. Tested to run with Racket v8.14 [cs]. </div>
Here’s a simple language and a (simplified) interpreter:
;; Syntax description (struct func (params body) #:transparent) (struct app (fn-expr args) #:transparent) (struct op (op-name arg1 arg2) #:transparent) (struct if-expr (test-expr t-case f-case) #:transparent) ;; Closure values (struct closure (params body env) #:transparent) ;; Core interpreter routine (define (interpret expr env) (match expr ;; Literal values: booleans and numbers evaluate to themselves [(or (? number?) (? boolean?)) expr] ;; Look up variables in the environment [(? symbol? var-name) (lookup-env env var-name)] ;; Evaluating a function expression yields a closure value [(func params body) (closure params body env)] ;; Application: evaluate the function expression to get a closure. ;; Next, evaluate the arguments, and then extend the environment ;; and evaluate the body of the closure. [(app fn-expr args) (let ([fn (interpret fn-expr env)] [eval-args (map (λ (e) (interpret e env)) args)]) (interpret (closure-body fn) (extend-env env (closure-params fn) eval-args)))] ;; Built-in operators [(op op-name a1 a2) (let ([arg1 (interpret a1 env)] [arg2 (interpret a2 env)]) (case op-name [(+) (+ arg1 arg2)] [else (error "Undefined operator!")]))] ;; Conditionals [(if-expr test tcase fcase) (if (interpret test env) (interpret tcase env) (interpret fcase env))]))</code></pre> We can now build and run simple programs:
(interpret (app (func '(x) (op '+ 'x 1)) (list 41)) '()) ;; => 42</code></pre> There is nothing particularly special about this interpreter: there’s a basic representation for programs, and the interpret</code> function walks the AST recursively to evaluate the program.
Threading the environment</h2> To make this interpreter go faster, we need bypass the match</code> statement by pre-computing the code to run. We can do this by building up a closure that calls the next thing to run in tail-position. Racket has a proper tail-call optimization, so function calls in tail position will be optimized to jump</code> instructions and they won’t grow the stack. Having known jump targets is also really good for modern CPUs which do speculative execution; known jump targets means no branch mis-predictions. We do this by breaking up the interpret</code> function: instead of taking an expression and an environment, we want a function that just takes an expression. This should return a function that we can give an environment, which will the compute the value of the program. We will call this new function compile</code>.
(define (compile expr) (match expr [(or (? number?) (? boolean?)) (λ (env) expr)] [(? symbol? var-name) (λ (env) (lookup-env env var-name))] [(func params body) (let ([comp-body (compile body)]) (λ (env) (closure params comp-body env)))] [(app fn-expr args) (let ([fn (compile fn-expr)] [comp-args (map compile args)]) (λ (env) (let ([c (fn env)]) ((closure-body c) (extend-env env (closure-params c) (map (λ (a) (a env)) comp-args))))))] [(op op-name a1 a2) (let ([arg1 (compile a1)] [arg2 (compile a2)]) (case op-name [(+) (λ (env) (+ (arg1 env) (arg2 env)))] [(-) (λ (env) (- (arg1 env) (arg2 env)))] [(*) (λ (env) (* (arg1 env) (arg2 env)))] [(/) (λ (env) (/ (arg1 env) (arg2 env)))] [(<) (λ (env) (< (arg1 env) (arg2 env)))] [(>) (λ (env) (> (arg1 env) (arg2 env)))] [(=) (λ (env) (= (arg1 env) (arg2 env)))] [else (error "Undefined operator!")]))] [(if-expr test tcase fcase) (let ([comp-test (compile test)] [comp-tcase (compile tcase)] [comp-fcase (compile fcase)]) (λ (env) (if (comp-test env) (comp-tcase env) (comp-fcase env))))]))</code></pre> Note how the code follows the same structure as the basic interpreter, but the return type has changed: instead of a value, you get a function in the form of (λ (env) …)</code>. Also, instead of calling interpret</code> on subexpressions, you call compile</code>, and pass the environment to those subexpressions to get the value out. There’s a lot more that we could here to improve things. The easiest thing would be to track where variables will be in the environment and optimize variable lookups with direct jumps into the environment structure. This saves us from having to walk the environment linearly on every variable lookup. I won’t implement that here, but that’s some pretty low-hanging fruit.
The tricky part of BF: mutual recursion</h2> So, we get a lot of oomph by turning everything into tail calls. But loops (which, in BF, are the only branching mechanism) present a tricky problem: you either need to call the function that encodes the loop body repeatedly or call the function that encodes whatever comes after the loop. Moreover, once the loop body is done, it needs to jump back to the first function that encodes the choice of whether to keep going in the loop or exit.Here’s my compile</code> function for my basic threaded interpreter</a> for BF: (define (compile program c-ip jmp-targets inst-cache) (if (< c-ip (vector-length program)) (match (vector-ref program c-ip) [#\+ (let ([rest-progn (compile program (+ 1 c-ip) jmp-targets inst-cache)]) (λ (state sp) (vector-set! state sp (+ (vector-ref state sp) 1)) (rest-progn state sp)))] [#\- (let ([rest-progn (compile program (+ 1 c-ip) jmp-targets inst-cache)]) (λ (state sp) (vector-set! state sp (- (vector-ref state sp) 1)) (rest-progn state sp)))] [#\> (let ([rest-progn (compile program (+ 1 c-ip) jmp-targets inst-cache)]) (λ (state sp) (rest-progn state (+ sp 1))))] [#\< (let ([rest-progn (compile program (+ 1 c-ip) jmp-targets inst-cache)]) (λ (state sp) (rest-progn state (- sp 1))))] [#\. (let ([rest-progn (compile program (+ 1 c-ip) jmp-targets inst-cache)]) (λ (state sp) (display (integer->char (vector-ref state sp))) (rest-progn state sp)))] [#\, (let ([rest-progn (compile program (+ 1 c-ip) jmp-targets inst-cache)]) (λ (state sp) (vector-set! state sp (char->integer (read-char))) (rest-progn state sp)))] [(jmp-forward target) (letrec ([loop-start (λ (state sp) (if (zero? (vector-ref state sp)) (loop-end state sp) (loop-body state sp)))] [loop-past-end (compile program (+ c-ip target 1) jmp-targets inst-cache)] [loop-end (compile program (+ c-ip target) (cons loop-start loop-past-end) inst-cache)] [loop-body (compile program (+ 1 c-ip) null inst-cache)]) loop-start)] [(jmp-backward _) (λ (state sp) (if (zero? (vector-ref state sp)) ((cdr jmp-targets) state sp) ((car jmp-targets) state sp)))]) (λ (_state _sp) ; finished compiling program void)))</code></pre> I match on each of the characters of the program. In my interpreter I do a little bit of preprocessing to turn [</code> and ]</code> into jmp-forward</code> and jmp-backward</code> structs respectively. That way, I don’t have to spend a ton of time scanning the program for matching brackets. The interesting bit is the clause for the jmp-forward</code> construct: to build the closure I need at a loop-start</code>, I need to be able to refer to the loop body (computed and stored in loop-body</code>) as well as the end of the loop (computed and stored in loop-end</code>). When I build the loop-end</code> closure, pass loop-start</code> and loop-past-end</code> (which is the rest of the program after the loop) into the compile</code> function as the jmp-targets</code> parameter. When the compiler encounters the matching jmp-backward</code> instruction, it uses the jmp-targets</code> parameter to get the loop-start</code> and loop-past-end</code> to decide whether or not to redo the loop or not. I’ve since improved this code, and now the zero?</code> check only happens once. I also parse the program so that every instruction gets turned into a struct—rather than left as a bare character. See interp_threaded_opt.rkt</a> in my Brainfreeze repo for the current version. </div> The loop-start</code> and loop-end</code> functions need to reference each other to be able to continue or abort the loop. letrec</code> lets me build functions that can reference each other in a clean, functional way. Let’s see some numbers!</h2> So how much faster does threading make the code go? Here</a> is a BF program that renders a Mandelbrot set. I can run this with my basic and my threaded interpreter on my M1 Pro MacBook Pro to get an idea: racket interp_basic.rkt bench/benches/mandel.b 43.25s user 0.77s system 93% cpu 47.138 total racket interp_threaded.rkt bench/benches/mandel.b 17.62s user 0.38s system 92% cpu 19.461 total</code></pre> 43.25 seconds</code> vs 17.62 seconds</code> is a big difference! That’s a solid 2× speedup! This actually put my threaded Racket interpreter on par with a C-based threaded interpreter that one of my classmates built and ran with the same benchmarks. If I recall, his was only about a second or two faster. The compile step opens up a big opportunity for optimizations. I’ve been working on some domain-specific optimizations for BF and my interpreter can run the same benchmark in a blazing 9.94 seconds</code>. racket runner.rkt bench/benches/mandel.b 9.94s user 0.18s system 94% cpu 10.707 total</code></pre> (And, of course, none of this really holds a candle to a proper compiler; I’ve to a compiler that takes the optimized code from the threaded interpreter and emits machine code. It can run mandel.b</code> in a mere 0.5 seconds</code>!) I hope you take away a few things from this post: Proper tail-calls make stuff go fast. If your language supports proper tail-call optimization, take advantage of it. </li> Racket is really good for writing interpreters and compilers! You can get very fast performance in the comfort of a high-level garbage-collected functional programming language. </li> </ol> Racket will never be able to match the best-written C code in terms of speed. But Racket is far easier to debug and a lot more fun to write—and for a lot of applications, Racket is still more than fast enough. A bad day writing code in Scheme is better than a good day writing code in C. David Stigant </footer> </blockquote> </div> Appendix: Full code for basic interpreter</h2> #lang racket ;; Syntax description (struct func (params body) #:transparent) (struct app (fn-expr args) #:transparent) (struct op (op-name arg1 arg2) #:transparent) (struct if-expr (test-expr t-case f-case) #:transparent) ;; Closure values (struct closure (params body env) #:transparent) ;; Environment helpers (define (extend-env base-env vars vals) (foldl (λ (var val env-acc) (cons (cons var val) env-acc)) base-env vars vals)) (define (lookup-env env var) (match (assoc var env) [(cons _ val) val] [#f (error "Undefined variable!")])) ;; Core interpreter routine (define (interpret expr env) (match expr [(or (? number?) (? boolean?)) expr] [(? symbol? var-name) (lookup-env env var-name)] [(func params body) (closure params body env)] [(app fn-expr args) (let ([fn (interpret fn-expr env)] [eval-args (map (λ (e) (interpret e env)) args)]) (interpret (closure-body fn) (extend-env env (closure-params fn) eval-args)))] [(op op-name a1 a2) (let ([arg1 (interpret a1 env)] [arg2 (interpret a2 env)]) (case op-name [(+) (+ arg1 arg2)] [(-) (- arg1 arg2)] [(*) (* arg1 arg2)] [(/) (/ arg1 arg2)] [(<) (< arg1 arg2)] [(>) (> arg1 arg2)] [(=) (= arg1 arg2)] [else (error "Undefined operator!")]))] [(if-expr test tcase fcase) (if (interpret test env) (interpret tcase env) (interpret fcase env))]))</code></pre>Appendix: Full code for threading interpreter</h2> #lang racket ;; Syntax description (struct func (params body) #:transparent) (struct app (fn-expr args) #:transparent) (struct op (op-name arg1 arg2) #:transparent) (struct if-expr (test-expr t-case f-case) #:transparent) ;; Closure values (struct closure (params body env) #:transparent) ;; Environment helpers (define (extend-env base-env vars vals) (foldl (λ (var val env-acc) (cons (cons var val) env-acc)) base-env vars vals)) (define (lookup-env env var) (match (assoc var env) [(cons _ val) val] [#f (error "Undefined variable!")])) ;; Threading interpreter (define (compile expr) (match expr [(or (? number?) (? boolean?)) (λ (env) expr)] [(? symbol? var-name) (λ (env) (lookup-env env var-name))] [(func params body) (let ([comp-body (compile body)]) (λ (env) (closure params comp-body env)))] [(app fn-expr args) (let ([fn (compile fn-expr)] [comp-args (map compile args)]) (λ (env) (let ([c (fn env)]) ((closure-body c) (extend-env env (closure-params c) (map (λ (a) (a env)) comp-args))))))] [(op op-name a1 a2) (let ([arg1 (compile a1)] [arg2 (compile a2)]) (case op-name [(+) (λ (env) (+ (arg1 env) (arg2 env)))] [(-) (λ (env) (- (arg1 env) (arg2 env)))] [(*) (λ (env) (* (arg1 env) (arg2 env)))] [(/) (λ (env) (/ (arg1 env) (arg2 env)))] [(<) (λ (env) (< (arg1 env) (arg2 env)))] [(>) (λ (env) (> (arg1 env) (arg2 env)))] [(=) (λ (env) (= (arg1 env) (arg2 env)))] [else (error "Undefined operator!")]))] [(if-expr test tcase fcase) (let ([comp-test (compile test)] [comp-tcase (compile tcase)] [comp-fcase (compile fcase)]) (λ (env) (if (comp-test env) (comp-tcase env) (comp-fcase env))))])) ;; compute 42 (define p1 (app (func '(a) (op '+ 'a 1)) '(41)))</code></pre>References</h2>

References</h2>

Explainer: Tree-sitter vs. LSP

Running

Typst for Your Code Blocks

Federate Away From GitHub

How I Organize the Papers I Read

Getting Started With Lock Picking

AI stands for “Artificial Inanity”

Bedrock Version 1.5.0 Released

How I Take Notes for Research

Programmers and Their Monospace Blogs

Real Programmers

TV Shows for Kids

A Quick Guide to LaTeX

What's New in Emacs: Last Decade Edition

Should Programming Languages be Safe or Powerful?

Towards the Fastest Brainf*** Implementation Ever

How to Make Racket Go (Almost) As Fast As C

Explainer: Tree-sitter vs. LSP

Running

Typst for Your Code Blocks

Federate Away From GitHub

How I Organize the Papers I Read

Getting Started With Lock Picking

TL;DR</h2> Start with these picks and locks:</p>

AI stands for “Artificial Inanity”

Bedrock Version 1.5.0 Released

How I Take Notes for Research

Programmers and Their Monospace Blogs

Real Programmers

TV Shows for Kids

A Quick Guide to LaTeX

What's New in Emacs: Last Decade Edition

Should Programming Languages be Safe or Powerful?

Towards the Fastest Brainf*** Implementation Ever

How to Make Racket Go (Almost) As Fast As C