"I'll pick a few, simple, perfectly ordinary inputs at random, and work out what I think the output should be. This is a pretty trivial problem so I'm expecting that all the implementations will match my output. [narrator: He is is expecting no such thing] I'm also expecting that, even if for some reason I've made a mistake, all the implementations will at least match each other. [narrator: More lies] They've all been proved correct, right?"
" Not all of the implementations were that easy to run. In fact, many of them didn't take any kind of "string" as input, but vectors or lists or such things, and it wasn't obvious to me how to pass strings in. So I discounted them. For the ones I could run, I attempted to do so by embedding the test inputs directly in the program, if possible."
A tester selected simple inputs and computed expected outputs, padding to length 10 using '-' and using a monospace font to align output columns. One entry represented 'e acute' differently from another. Several implementations did not accept plain strings and used vectors, lists, or Vec<Thingy>, so those implementations were set aside. Runnable implementations required embedding test inputs directly in programs. Haskell sources produced lexical errors for embedded characters, prompting a small driver that read from a file. A provided leftpad required char[] input, resolved via .toCharArray(). An online playground with an editable #eval helped run examples.
Read at Luke Plant's home page
Unable to calculate read time
Collection
[
|
...
]