Comparing Implementations of the Monkey Language VIII: Ruby, Python and Lua | Hacker News Reader

Comparing Implementations of the Monkey Language VIII: Ruby, Python and Lua

medium.com

37 pointsthunderbong17 comments

Having used both Python and Ruby professionally and Lua in a hobby setting, they all have their place.

To me, Python feels rooted in procedural programming (as imo evidenced by how many of the built-in base functions behave, statements vs expressions and everything mapping to magic eventually), reminds more of 90s object pascal with syntax-magic than lisp or self.

Then ruby feels like a coherent mix of self/Smalltalk-style "pure" OO and Lisp functional programming, though it's a little "weird" at first when coming from python or c-like langs/java (e.g. iteration is just a method on a collection with the equivalent of a lambda passed in, oh, and that block vs proc vs lambda distinction). So it's not as easy to pick up for mainstream programmers. And since it's often mostly used with rails, that's another whole bag of worms - especially again at first.

Lua is just this special, minimal thing. The whole codebase (including VM internals, lang parser and table) can be studied in an afternoon, the single built-in data structure is actually neat once you're used to it and the c ffi is neat and easy to pick up.

I think python has the familiarity for those coming from mainstream languages, nicely readable syntax and easy uptake going for it. Though I don't like that many new features feel "bolted on" and make the language more complex.

Ruby is just a joy to use once you get into it, although that can take longer than py. Imo, it's combining the best of OO with really practical functional programming.

Lua is to a large extent (and within limits) what you make of it, but a joy to study.

This is a shockingly fair and, in my opinion, correct comparison of these three languages. Kudos!

I really wish Lua had taken over the Python space. It's so much better as a language. At this point, though, the Python ecosystem is so huge it's very hard for me to justify investing in Lua.

It's one of those weird path-dependent things, I guess.

Lua has chosen a minimalistic 'batteries-excluded' strategy to ease the integration into host platforms. That strategy worked wonderfully - Lua was always a popular choice for embedding into various platforms (Roblox, Ngnix, Neovim, VLC, Wireshark...).

Python made interfacing just about anything a simple job, which is why it succeeded as "glue" language and automation tool. It is a completely different area than what Lua was designed for even though they are both called a scripting language.

In an alternate timeline Lua could have been used in JavaScript's place though. The web would have benefited from Lua's simplicity and speed.

> Python feels rooted in procedural programming

Yes it does, and its OOP features feel sloppily bolted and taped on. It seems everyone really wants to use Python in a very OOPy way, so that means using all the awkward features and decorators to try to accomplish what is elegantly simple and clear in Ruby.

Worse even, the functional aspect of Python is a schizophrenic mess, with a mix of functools, builtins, and comprehensions. Meanwhile, in Ruby the structure and patterns of function features is consistent and arguably very sensible.

The only good argument for using Python is, "The people before us used it, and now we continue using it." Even so, there's a good chance that a rewrite in a better language would be worthwhile.

I can’t figure out whether Medium is bad at providing navigation for long-running content, the author is bad at providing metadata to support whatever Medium can do with it, or I’m bad at finding the necessary UI bits, but it turns out the last several entries are also the author’s most recent posts, so you can see the full series here:

https://medium.com/@mario.arias.c

When I went through these books (https://interpreterbook.com/ and its sequel https://compilerbook.com/), I did them in Typescript, which was a great exercise. I felt like this is the sort of program that really gives TS its time to shine.

Ironically, I didn't get _any_ speed up using the interpreter vs the compiler in my TS implementations. I'm not sure if that's because I wasn't careful enough with memory allocation in the compiler or V8 had already sped up the interpreter as fast as it was going to go. It's been on my list to dig in and try to fix that, but I've since moved onto other projects.

> Ironically, I didn't get _any_ speed up using the interpreter vs the compiler in my TS implementations. I'm not sure if that's because I wasn't careful enough with memory allocation in the compiler or V8 had already sped up the interpreter as fast as it was going to go. It's been on my list to dig in and try to fix that, but I've since moved onto other projects.

What were your benchmark programs?

I used the recursive fibonacci implementation from the book. You can see the whole bookmarking script here: https://github.com/xavdid/monkey-ts/blob/a3d1789cbb80e33316a...

I've also got the node profiler results here: https://github.com/xavdid/monkey-ts/tree/a3d1789cbb80e33316a...

I guess that most likely it is not due to v8 magic optimizing the interpreter as much as it can be. The end result of v8 optimizing an AST interpreter is not the same as the end result of v8 optimizing a bytecode interpreter.

That makes sense, but I thought it was odd that the two implementations had _identical_ timing results. I should really dig more into it, I just haven't.

I linked the benchmarking script and results in this comment if you're curious: https://news.ycombinator.com/item?id=31643006

For Lua documentation, I recommend the Programming in Lua book, from Roberto Ierusalimschy (lead Lua dev). The most recent edition is from 2016, after 5.3 came out, but that's ok because the language hasn't changed much since then.

http://www.lua.org/pil/

Another helpful reference is the reference manual. As far as reference manuals go, Lua's is fairly easy to follow and not as dense. (I still have nightmares from reading the Javascript reference manual)

https://www.lua.org/manual/5.4/manual.html

The performance of the Ruby YJIT version is interesting:

  5.73 ± 0.34 times faster than 'ruby --yjit'
  11.17 ± 0.67 times faster than '#ruby'

which is approximately twice as fast as the standard Ruby.

This is probably explained by the nature of the benchmark used, "Running a recursive fibonacci(35) inside the Monkey interpreter", which is very simple and repetitive, making it ideal for JITs.

On the other hand, if that's the benchmark used for assessing the performance (as it seems), it's not representative of the performance of the tested languages at all.

To author/submitter: code snippets in the article contain different-width spaces for some reason, which makes them look badly indented.

I have no idea what Monkey Language is and after reading first few paragraphs it looks like the author does not plan to explain it either. So unless you know what Moneky Language is, do not bother to open.

Considering this is explicitly part 8 of a series, I would recommend starting with part 1, where this is explained.

https://medium.com/@mario.arias.c/comparing-kotlin-and-golan...

The language website is here: https://monkeylang.org

It's a toy language created for, and used by, the book "Writing An Interpreter In Go"¹ (presumably, also by the subsequent book, "Writing A Compiler In Go")

It's a good book, very easy to follow, so I think it had a large following of people writing their own dialects, in many languages.

¹=https://interpreterbook.com

Reply on news.ycombinator.com