wren

to just say, "well, it's written in C so it's probably great." It's using ref-counting and linear scanning or hash table lookup for property look-up. Perf is likely not great. Just as a point of comparison, my little hobby language[2] is also written in very simple C, but it's carefully designed to be fast too. Property look-up and method calls are just pointer + known offset. GC is tracing. Because of this (and other stuff), perf actually is good[3], typically better than Python and Lua and on par with Ruby. (With the usual caveat that all benchmarks are bad. :) ) [1]: http://duktape.org/guide.html#performance [2]: https://github.com/munificent/wren [3]: https://github.com/munificent/wren/blob/master/doc/site/perf...

walk(self, callback): """Traverse the tree in order, invoking `callback` on each node.""" if self.left: self.left.walk(callback) callback(self.data) if self.right: self.right.walk(callback) We can create a little tree and then print the data items in order like so: tree = Tree(Tree(Tree(None, 1, None), 2, Tree(None, 3, None)), 4, None) tree.walk(print) (This works in Python 3, in Python 2, you'll have to make a little fn for print.) Swell, right? Later, we decide we want to iterate over the items in a tree. Easy-peasy, Python has generators! We can just make a function that takes a Tree and returns a generator. We already have a method to walk the nodes, so we just need to call that and then yield the items, like so: def iterateTree(tree): def callback(data): yield data tree.walk(callback) Then you can just use it like so: for x in iterateTree(tree): print(x) Perfect, right? Actually, no. This doesn't work at all. You can't yield from the callback passed to walk. That's because walk() itself doesn't know that the callback is a generator. This is the problem with generators: they divide all functions into two categories: regular functions and generators. You run a regular function by calling it. You run a generator by iterating over it. The caller must use it in the correct way. At its simplest level it means you have to be careful when refactoring. If you have a generator function that gets too big and you want to split it up, you have to remember that the functions you split out are also special generator functions if they contain a yield. You have to remember to flatten it when you "invoke it". It's more than just annoying though: it means it's impossible to write code that works generically with both kinds of functions. In other words, all of your higher-order functions like map, filter, etc. now only work with some of your functions. (Or, I suppose, you could explicitly implement them to support both but that's more work and I don't think most languages do.) In languages like Lua, the above code just works. You can yield from anywhere in the callstack and the entire stack is suspended. It's fantastic. (If I can be forgiven a bit of self-promotion, I'll note that my programming language Wren[1] can not only express full coroutines like Lua, but also supports symmetric coroutines which can express some things Lua cannot. They are roughly like the equivalent of tail call elimination for coroutines.) [1]: https://github.com/munificent/wren

e design decision I made was to make the set of fields in an object statically-determinable. Like Ruby, it uses a distinct syntax for fields, so we can tell just by parsing the full set a class uses. My implementation is less than 5k lines of not-very-advanced C code, and it runs the DeltaBlue[2] benchmark about three times faster than CPython. People think you need static types for efficiency, but I've found you can get quite far just having static shape. You can still be fully dynamically-dispatched and dynamically type your variables, but locking down the fields and methods of an object simplifies a lot of things. You lose some metaprogramming flexibility, but I'm interesting in seeing how much of a trade-off that really is in practice. [1] https://github.com/munificent/wren [2] https://github.com/munificent/wren/blob/master/benchmark/del...

binary_trees - wren 3193 0.31s binary_trees - lua 1366 0.73s 233.72% binary_trees - luajit 6256 0.16s 51.04% binary_trees - python 1376 0.73s 231.96% binary_trees - ruby 3003 0.33s 106.34% fib - wren 3078 0.32s fib - lua 2785 0.36s 110.52% fib - luajit 6900 0.14s 44.62% fib - python 1331 0.75s 231.37% fib - ruby 3548 0.28s 86.77% for - wren 6080 0.16s for - lua 1990 0.08s 50.71% for - luajit 5914 0.02s 13.24% for - python 2825 0.35s 215.25% for - ruby 6595 0.15s 92.19% method_call - wren 4707 0.21s method_call - lua 1674 0.60s 281.17% method_call - luajit 4221 0.24s 111.53% method_call - python 767 1.30s 613.69% method_call - ruby 3061 0.33s 153.77% As you can see, Ruby fares quite well.