It's all very well to say your lisp is clear and unambiguous, how long did it take you to realise it's wrong? It took me a good 20-30 minutes of writing a reply

It's all very well to say your lisp is clear and unambiguous, how long did it take you to realise it's wrong? It took me a good 20-30 minutes of writing a reply about character count, before I tried to format your lisp onto three lines and then noticed. I think the Python code is very clearly a correct Fibonacci, it looks at a glance like the layout of a procedural language doing a recursive call with a base case and a recursive case. The APL is not as clear in that sense, but knowing the diamond is a statement separator it breaks down into small pieces and is fairly easy to read because there's so little of it to read. The Lisp with 8 pairs of parens, 5 levels of nesting, and use of function names instead of "n - 2", while still being a long run of code where there are almost no symbols except alphabet letters and parens to make anything stand out, makes it difficult for me to parse by eye to see what the intended nesting is, and to make sure the parens are nested as intended. You have it returning fib ((n-1) + (n-2)) instead of ((fib (n-1))+(fib (n-2))), and I think you might have the condition the wrong way around, if N is positive then the recursive calls should happen. That's not to say you or Lisp can't write a correct Fib, it's to say that I think I would spot errors in the Python much more easily, thus making it "more clear". Which his another way of saying that I'm not convinced that counting characters is automatically worse than counting tokens - characters are what we type, what we have to read, they are what take up screen space and push other code off screen, they push related bits of code further apart even when it's all on-screen, and they are places bugs can hide. If they're not helping, what are they doing? Characters are the reason the APL could fit 3x in a single 80 character wide line, and the Lisp code 1.3x in the same line, and the Python code 0.2x in the same line. Not that I desperately want to read 80 characters of uncommented APL, but that adds up quickly. The APL tends to be high level and more declarative, which doesn't show up in Fibonacci, but makes a difference in character count. ---- APL functions in the dfn style (curly braces) can only take an argument on the left and an argument on the right, both optional. The left one becomes alpha ⍺ and the right one becomes omega ⍵. That is to say, because you see omega in the code, you know it too expects exactly one argument, that argument goes on the right, and it has a name. The name is no less meaningful than "n", although no more meaningful either. The steep learning curve about APL code isn't "what does the code say, those symbols are unreadable", they stop being scary quite quickly and just stay dense, instead it's "how on Earth does that manipulation of arrays solve the problem??"