Re: client-side Ruby on iPad/iPhone?

On Sunday, July 18, 2010 09:30:37 pm Tony Arcieri wrote:
> On Sat, Jul 17, 2010 at 9:41 PM, David Masover <[e-mail]> wrote:
> > In other words, Ruby has a better standard library.
> 
> Not the standard library, but rather core types.

I don't see much of a difference, except where there are artificial 
limitations -- "primitive" types - but you weren't talking about that, were 
you?

And your mention of jQuery (and _still_ not Prototype) suggests it's not the 
primitive types you care about, it's the DOM types. Really? Is it worse than 
REXML?

An ugly API can be wrapped. This one is ugly, but not terribly poorly 
designed, so it can be dealt with. I much prefer it to an ugly language, or a 
poorly-designed API that's more difficult to wrap.

> Ruby's core types are
> simply beyond compare,

Really?

> as are the core functions of Object

I mean, really? BlankSlate had to strip those out, in a not entirely intuitive 
way. We needed 1.9 to adopt BasicObject instead for this kind of thing to work 
properly.

We also needed 1.9 to fix the encoding issue, and we still have libraries that 
assume strings are sequences of bytes. This is something Java got a lot closer 
to right the first time around -- UTF-16 may be limited, but it's a hell of a 
lot better than ASCII.

And why the distinction between methods, blocks, and lambdas?

> I am constantly surprised and disillusioned by Rubyists who look a gift
> horse in the mouth and go "nah, fuck that, let's use prototype-based object
> orientation"

So... now you don't like prototypes?

> > So what? I could just as easily claim that Ruby needs a "Rack jock strap"
> > before it's a useful Web development language.
> 
> If that's what you think you completely missed my point.

Apparently. I still am.

> JavaScript is
> missing core functionality

What functionality?

> which libraries like JQuery and Prototype
> provide,

Again, what functionality? JQuery and Prototype are huge libraries.

> For example, consider basic type
> checking, which can certainly incite a bit of a holy war in the dynamic
> language community so I'm a bit lax to bring it up.

As well you should be. If I don't check types often in Ruby, it seems even 
less likely I'd want to in JavaScript.

> But JavaScript's
> instanceof operator is fundamentally fucked and completely broken, some
> examples of which I provided earlier.  So how does JQuery implement basic
> type checks, like isArray?
> 
> From http://code.jquery.com/jquery-1.4.2.js
> 
> isArray: function( obj ) {
> 	return toString.call(obj) === "[object Array]";
> }
> 
> JQuery has bounced around on the implementation of this particular function
> considerably.  Why?  Because it's so hard to provide consistent semantics
> across multiple JavaScript implementations.

So, aside from the semantics which are actually spelled out in ECMA-262, what 
about actually checking the prototype tree via __proto__?

> As a language implementer perhaps I'm a bit of a snob about these things. 
> I don't buy into the school of thought which believes type checking in a
> dynamic language is bad.

Maybe not "bad", but depending on it is probably not a good idea. It's also 
really, really difficult to see when I'd need it, or need it to absolutely 
work reliably -- for example, Ruby's kind_of? can be overridden.

By contrast, it's actually quite easy to see cases where duck typing can be 
really useful, and where I'm going to resent it if you force me to override 
#kind_of? or something similar to convince your method to take my object 
seriously.

> I think it's completely necessary to provide
> useful errors, among other things.

Don't you get that for free anyway, by providing a useful toString() method?

> leave the matter of debugging unexpected objects passed as arguments to a
> function not designed to receive them as an exercise to the end user.

To be fair, this is a common pattern in Ruby -- again, duck typing.

> I make the decision as to whether I should type check the arguments to a
> particular function on a case-by-case basis.  Without a JavaScript "jock
> strap" like JQuery or Prototype, this isn't particularly doable in
> JavaScript, since the built-in facilities for doing so are fundamentally
> broken to the point no one ever uses them.
> 
> Bottom line, JavaScript comes broken by default...

You haven't provided a refutation of any sort to my point about a "Rack jock 
strap", or maybe an extlib or activesupport jock strap?

I just don't have a problem with a language which requires libraries to be 
useful. In fact, I consider that a plus -- if it's something a library can do 
well, I'd rather have it in a library than in the core language.

> > to make the language itself more or less tolerable -- it wraps itself
> > around the DOM, though it comes with a few easily-duplicated utility
> > functions.
> 
> ...I must strongly disagree here, what you deem "a few easily-duplicated
> utility functions" are extremely difficult and controversial to write, to
> the point they fluctuate frequently, and provide essential functionality
> which is missing from the core language.

I'll concede that they may be difficult, and I'm sure I'm underestimating the 
instanceof problem above. I just don't agree that verifying the type of 
something is essential functionality. It seems like I'm reaching for 
Activesupport to give me 5.minutes.ago far more often than I'm reaching for 
jQuery to tell me whether something's an array or not.

What else is broken by default? I'll give you a skin-deep ugliness, sure.