Re: client-side Ruby on iPad/iPhone?

On Sat, Jul 17, 2010 at 9:41 PM, David Masover <[e-mail]> wrote:

> Those are all pretty weird, though I could mention similar oddities in
> Ruby,
> like the use of === in case statements


Of all of the examples of "weirdness" in Ruby, I wanted to single this one
out.  The === operator is the closest thing Ruby has to pattern matching,
and for what it's worth I think using === as the basis of case is one of the
more brilliant things Matz did.

True pattern matching is nicer, no doubt, but failing that, I'm a big fan of
the === approach.


>  > the need for a JQuery jock strap to even make the language tolerable by
>
> masking away all the bizarre gymnastics you'd otherwise have to do to get
>
> basic functionality out of the language, etc etc.
>
> In other words, Ruby has a better standard library.


Not the standard library, but rather core types.  Ruby's core types are
simply beyond compare, as are the core functions of Object which due to
Ruby's everything-is-an-object nature are inherited by all the core types.

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 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.  JavaScript is
missing core functionality which libraries like JQuery and Prototype
provide, and the way this core functionality is implemented is a complete
hack, because JavaScript's built-in operators for providing the same
functionality are fundamentally broken.  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.  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.  And this is what they've
settled on... a string comparison of the "toString" result.  Really?  That's
the best they can do?  Yes, yes it is.

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.  I think it's completely necessary to provide
useful errors, among other things.  You get that "for free" in statically
types languages, granted, and in dynamic languages people either type check
function arguments or entirely resent the notion of doing so and 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.

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, and...

It also seems especially bizarre to mention jQuery here, when jQuery
does nothing
> 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.

JavaScript is ugly and broken by default.  Ruby is not.

-- 
Tony Arcieri
Medioh! A Kudelski Brand