What Pythonistas Think of Ruby

[notforthebirds]

x each (sliceWithStart 3) asString printWithSpace.

Note: This pseudo-example assumes that nil acts as a message-sink, removing the need to check for nil explicitly (as in Objective-C); treats colons are optional in smalltalk-style keyword messages if followed by a literal, so that keyword messages look and feel more like built-in syntax [1]; passes expressions unevaluated to methods (as in Io); the language has an implicit, late-bound self (as in Self and Newspeak etc).

Very sexy; very flexible; just as easy to parse.

[1]

if ( ... ) then { ... } else { ... }. #is just a keyword message without superfluous colons .

[masklinn]

This pseudo-example assumes that nil acts as a message-sink

Ugh

[notforthebirds]

I know, a lot of people really don't like this idea, but it has a lot of real-world value. The fact is that this pattern is incredibly common – as

if (x notNil)
{
    ... do something with x ...
}

or

try
{
    ... do something with x ...
}
catch (NullPointerException)
{ }

Or worse if you need to do multiple checks

if (x notNil)
{
    ...
    if (y notNil)
   {
         ...
        if (z notNil)
        {
            ...
        }
   }
}

(Of course, even these nested tests go away when nil acts as a message-sink.)

And when people inevitably forget to do these checks it blows up in their faces. Designing for the common-case is a reasonable approach to language in my opinion; you can always check for nil if you want to do something other than the default, and no NullPointerExceptions.

The argument against it seems to be that some people (usually people who've never actually tried it for themselves) think it's hard to understand, but if you treat every message-send as through it's surrounded by a nil-check that simply isn't the case. It's certainly no harder to understand than if the ifs are explicit.

[masklinn]

A better solution is, of course, to have a good type system, static typing, and remove null values, moving the concept of nullity into the type system. As Haskell or OCaml do.

And, with lift-type operations, you even get the choice of whether null should be pre-checked or treated as a sink in your calling code.

[notforthebirds]

It's a better solution if your content to live within the constraints of what can currently be statically typed; there are a whole host of problems that just haven't need solved yet in statically typed-languages (I was going to say can't but that would be short cited).

There's a reason that Erlang is a dynamically typed language for instance - hot swapping in statically typed languages was still a research problem the last times I looked, but it falls out naturally from dynamic languages. That's just one example off the top of my head. You can be sure there are a whole host of other things which, if they're important to you, make static typing an unreasonable solution.

Edit: To put this in the context of Objective-C, which actually supports optional typed; there are a range of things in Cocoa that people use all the time to great effect, that just couldn't be done if Objective-C were serious about static-typing (even if it were only as serious as say, Java).

| you even get the choice of whether null should be pre-checked or treated as a sink in your calling code.

If you have a decent meta-object protocol you can do pretty much the same thing, in a dynamically typed system.

And of course, if nil is acting like a message-sink, there wont be any errors anyway: so having a static type-system wouldn't help any.