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.
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).
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.
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.
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).
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.
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).
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.
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.
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.
43 comments
[ 2.3 ms ] story [ 97.5 ms ] threadScheme 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.
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.
https://people.eecs.berkeley.edu/~fateman/papers/factorial.p...
Also: It's more fun to use the name `fact` in benchmarks...
https://en.wikipedia.org/wiki/Factorial#Computation
B&W ()
B&W and optional bold ()
B&W and optional bold/larger ()
Full color rainbow parentheses.
B&W ()
One or two of the Lisp editors I use also support rainbow parentheses, but after an initial phase of experimentation, I have disabled that feature.
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).
Rainbow colors are extremely distracting and overloading to me.
> There should be one-- and preferably only one --obvious way to do it.
> Although that way may not be obvious at first unless you're Dutch.
def factorial(n):
The recursive version would be fine as well, but I would say it's less idiomatic in Python, and less efficient.def factorial(n):
Beyond that, I cannot think of any obvious way to do this (without getting unreasonably convoluted).In my opinion, it's great that there are such few options to express this operation, and that both cases are eminently readable.
There are lots of ways to do this in Python. That's not only fine, it's inevitable.
Here's a burnt-out PhD level one using highly pythonic paradigms:
Of course there are more ways, but I would definitely qualify this as "unreasonably convoluted".
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.
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.
This is exactly why I asked the question!
Edit: prod(range(1, n+1)) does work
let factorial n = [1..n] |> List.reduce (*)