Re:Computer History Museum 2018 Fellow: Guido van Rossum
by detaro on Thursday February 22, 2018 @08:04AM
(#16437245)
What's totally missing from this comparison is that languages allow multiple styles. E.g. the Python variant is for some reason not recursive, and you could write a Python version that looks a lot more like the Go or Lua versions than this Python version. (Which also can be seen as a weakness of Python from a readability point of view: freedom to choose a style also means you can pick the wrong one or a reader can be surprised by more uncommon one)
[ Parent
| on HN ]
Re:Computer History Museum 2018 Fellow: Guido van Rossum
by shakna on Thursday February 22, 2018 @08:10AM
(#16437272)
For the most part, I tried to choose styles that match the language, but yes, just a taste of the languages.
> E.g. the Python variant is for some reason not recursive
Because of the recursion limit in Python, really, as Python doesn't do tail-call elimination. That limit can make recursive code a real pain point, so iterative styles tend to work better.
Re:Computer History Museum 2018 Fellow: Guido van Rossum
by dom96 on Thursday February 22, 2018 @08:30AM
(#16437380)
Where did you find the Nim example? It's by far the strangest fibonacci implementation I have seen (and I am a Nim developer).
Anyway, I translated the Go example to Nim for a better comparison:
proc fib(a: int): int =
if a < 2:
return a
return fib(a - 1) + fib(a - 2)
Re:Computer History Museum 2018 Fellow: Guido van Rossum
by detaro on Thursday February 22, 2018 @08:27AM
(#16437363)
Many of these programs do not get tail-call elimination (e.g. I think most languages can not automatically optimize the equivalent of "return f(n-1) + f(n-2)", if they do tail-call elimination at all). The nicest ones do not bother with negative n, some others don't. IMHO not a very useful set of comparisons.
Re:Computer History Museum 2018 Fellow: Guido van Rossum
by joshuamorton on Thursday February 22, 2018 @12:16PM
(#16439205)
As I mentioned elsewhere, in python the correct way would be to add the @functools.lru_cache decorator. That way you get the caching behavior of the tricky to write methods, with the clarity of the obvious recursive solution.