Isn't this missing the joke? The Haskell article code ended with the "Tenured Professor" implementation (`fac n = product [1..n]`) as a nod to the old trope of not needing to implement anything. This article ends with `(define factorial (dynamic-require 'math/number-theory 'factorial (lambda () lambda (n) (error 'factorial "Cannot import library: ~a" 'math/number-theory)))))`.
Surely there is a lazier implementation than a define and 2x lambdas to use a library function. Although I did get a chuckle about not feeling a need to add brackets to the Scheme example.
It's not the best algorithm for computing factorials though.
A better strategy is to pair small and large factors together
in order to avoid bignum computations (or to reduce the size og bignum computations).
Normal Racketeers would just `(require math/number-theory)` and be done. No idea why they're loading the module at runtime like that instead, unless it's a deliberately over complicated joke solution like some of the others. Which would as you noted miss the point of the original.
I also came back to B&W because I’ve noticed that with structural editing I think more in terms of s-expressions than parentheses and distinguishing them isn’t that much of a problem anymore.
Not the parent but speaking for myself. I read Lisp code by looking at the indentations. Parens don't matter unless they're wrong, and they're rarely wrong because my editor matches them as I type, and then I just tell it to indent everything properly. If the indentation looks goofy after that step I notice it immediately and only then do I look for paren problems.
Lisp is by far my favorite language but if I had to write it with a "dumb" text editor it would quickly stop being my favorite. Most editors are smart these days, and this is why it's hard to explain to newbies that the parens don't get in your way: When you build lisp code your editor manages the parens for you and they become essentially invisible. So color solves a problem that doesn't exist (for me).
Using an actual rainbow seems a bad idea. I will try to set up a Viridis (or similar perceptually continuous) color scheme next time I dabble in lisps.
Golden opportunity to slip an "animated" option in there. I'm pretty sure there are editors with a little jump to the other side of a form to show where it is.
That was a tasty read! The Y-combinator implementation gave me a slight headache, but I averted my eyes and all was OK.
Scheme as a language and from a clean/simplicity point of view has always appealed to me, but I have mostly used Common Lisp because I have so much legacy code.
I use Scheme (these days more Racket or Shen) for doing 'language experiments' but if anything gets to production, it'll be CL. Like you said, legacy code, but also; it's just more practical. You give up some elegance, but in exchange you get something which you can build practically anything in, in modern times.
I don't know why I can use continuations all day long but I cannot wrap my head around the Y-combinator. My brain seems to fall into a well-bounded category: C^¬(YC).
Again I ask, considered by who? This is the kind of language that wikipedians would call "weasel words". Of course you shouldn't misuse eval or goto, and it's fine to have a rule of thumb to discourage it.
What's not fine, and strikes me as no better than superstition, is to make vague "everybody knows"-type statements that convey almost no information. If it's bad you should be able to say (or provide reference to) specifically how it's bad and what convinced you this was the case.
And yes, I deliberately wrote a perverse function because it was funny, but if you did a real fold instead of my fake one with strings then it wouldn't be so perverse. And wasn't it more pythonic to use a generator?
Not embracing Perl's tmtowtdi is fine, but until you solve the halting problem some people will write "x+x" and some will write "2*x" and some will write "x<<2" and those can't sensibly be unified.
I find both Haskell's `fac n = product [1..n]` and F# `let factorial n = [1..n] |> List.reduce ()` more readable and easier to comprehend. You could say using `product` is cheating, but `fac n = fold () [1..n]` definitely isn't!
Your idiomatic Python version uses three variables, two of which mutate. I'm a simple man - go easy on me please! The `n + 1` took me a while to figure out too.
Thanks for the heads-up. I was almost about to be misinformed by an outdated, no-longer-relevant article about a language that's been more or less the same for the last few decades.
Surely there is a lazier implementation than a define and 2x lambdas to use a library function. Although I did get a chuckle about not feeling a need to add brackets to the Scheme example.