On the other hand, Lua syntax is much simpler

(slightly out of date: http://programmingisterrible.com/post/42432568185/how-to-par...)

> slightly out of date: http://programmingisterrible.com/post/42432568185/how-to-par...

Ouch.... Perhaps a lesson in making your language's grammar too complex: if you do, you'll eventually have to pre-compile.

So has Ruby joined the ranks of languages that formally cannot be parsed due to the halting problem?

I know Perl is in that category.

I don't think so. There are a few things that looks distinctly iffy in that respect on the surface, but they are resolved.

e.g. is "foo" a method call or an instance variable? You can't know in isolation, but it doesn't matter at parse time, as if it's part of a larger construct that is only valid as a method call, such as if there's an argument list after "foo", it is parsed as a method call. E.g:

    foo = 1
    foo(42)

will result in:

    test.rb:4:in `<main>': undefined method `foo' for main:Object (NoMethodError)

I think all of the potential cases that might have otherwise made Ruby impossible to formally parse are resolved in similar ways.

Now, there are certainly layering violations. The aforementioned example of "foo" by itself can only be resolved by determining whether or not "foo" is in scope as a local variable at the point it is referenced, for example, but you can opt to defer the decision until after parsing.

> So has Ruby joined the ranks of languages that formally cannot be parsed due to the halting problem?

No I don't think anyone has suggested that, have they?

ruby has a parse.y yacc grammar source file (linked to from the post I linked), and yes it can be parsed separately from being executed.

However, IIRC, no one has been able to re-implement parse.y; jruby and the other ruby re-implementations copied it and made what adaptations were necessary.

I've seen similar results with perl bytecode.

Our syntax probably isn't simpler :)

I wrote a benchmark that measures just CPU impacts, and it finds that loading source code takes 25x longer: http://blog.reverberate.org/2014/10/the-speed-of-python-ruby...

A few things:

  - you don't drop the disk cache; so you're loading from RAM (echo 3 > /proc/sys/vm/drop_caches)
  - you don't have very complex code
  - you timing includes starting/loading the intepreter itself.

> you don't drop the disk cache

Yes that is why I said the benchmark measures "just CPU impacts."

I don't think dropping cache alone would be sufficient to simulate loading of a large project -- I think the benchmark would also need to split the input across many files to recreate the seek time effects.

> you don't have very complex code

Given what I know about parsers, I highly doubt that the performance profile of parsing real code differs from my benchmark very much (ie. >30%). But I'm happy to be proven wrong on this, if anyone wants to try.

> you timing includes starting/loading the intepreter itself

That is why the benchmark makes the files pretty big, so the constant interpreter startup overhead is not a significant factor. Again, I don't think that you're going to be able to significantly change the shape of the results by adjusting for this.