On Sunday, January 16, 2011 07:33:04 am Joseph Lenton wrote:
> David Masover wrote in post #975191:
> > On Saturday, January 15, 2011 04:42:58 am Joseph Lenton wrote:
> >> > I actually feel are broken about Ruby as it is today.
> >> 
> >> I'm sorry to take this slightly off topic, but I just can't let this
> >> comment pass. I am currently building a language called Quby, which is a
> >> very Ruby-like language, that runs 100% in the browser (about 4,000
> >> lines of JS). There are differences (as it's Ruby-like not Ruby) with
> >> the main one being that it's tied to a canvas. But AFAIK it's the
> >> closest pure JS implementation of Ruby (although it's Quby, not Ruby).
> > 
> > There are two major issues I have with that:
> > 
> > First, why did you feel the need to fork Ruby syntax? I think I saw your
> > post
> > earlier, and I remember writing a long rant and then not sending it, but
> > that's really my main problem with it. Why create a new programming
> > language?
> 
> First lots of small things I don't such as nil, hash comments and Ruby's
> block comments.

This is _exactly_ what I'm talking about. I already know how to write Ruby 
with things like nil and hash comments. I don't see why I should have to learn 
an entirely new syntax, and teach my editor an entirely new syntax, for such 
trivialities as replacing nil with null.

This just shouldn't factor into it.

> Secondly one of my main motivations was that I really
> don't like that so many trivial compile time bugs in the static
> languages become runtime errors in dynamic ones, such as calling a
> function or method that doesn't exist anywhere in your code.

That's fair -- if this actually changes the language significantly, I guess I 
don't see a problem with tweaking the syntax somewhat, although I strongly 
disagree with some of your improvements. (For example, there's a good reason 
'initialize' is different than 'new'.)

I think the general consensus among Rubyists is that the only difference 
between stuff you catch statically and stuff you catch at runtime is what 
stage in your automated test run it will be caught. If you have code which 
calls a method that doesn't exist, for example, and it never gets run in your 
tests, that's a bug in your tests.

In any case, it sounds cool, but it also doesn't quite fit what I was asking 
for. The main reason I dislike being forced to use Javascript isn't that I 
don't like Javascript, it's the context switch between thinking in Ruby and 
thinking in Javascript. (I did seriously consider stuff like node.js...)