[mechanical_fish]

Haskell is compiled. As I understand it, much of the point of Maybe is that it provides a formal language for expressing and manipulating unhandled edge cases. Then the compiler can spot those unhandled edge cases at compile time and make sure you handle them at one level of scope or another.

In Ruby the concept seems less useful because there is no compiler.

[leif]

That's not the point, the point is that Maybe is the right way to handle what nil (or None or null) fails to handle properly. Scala gets it right too, IIRC, with Nullable.

1. A "null" instance of one type should not be conflated with a "null" instance of a separate type. 2. By type-wrapping in a Maybe, you declare where you need to be able to handle nulls and where you are free to ignore them (but can never pass them in). You confine the null to specific regions of your code. 3. You force your code's clients to think about the null case wherever you make it visible.

[Locke1689]

Maybe is really just a special case of Either, where it optimizes for the situation where the second return type is "failure." The type of Either is necessary because proper type theory requires a container type to wrap two types. This is immediately obvious if you try to write the type signature for any function which has a return arity of one.

[andolanra]

Maybe is still useful outside of compiled language because it is also a way of composing and combining operations that might fail. The catch is that a great deal of its usefulness (in Haskell &al) comes from static typing, because any function which could return nil would return Maybe<SomeType> instead of SomeType, so you are forced to check against Nothing in order to have a valid program, thereby eliminating any possible NullPointerExceptions from your program. (The monadic syntax Haskell/Scala/&c provide makes this less tedious than it sounds.)

However, you could still make use of the composition operations in dynamic, untyped languages, and simply use them as a toolkit for chaining together operations which could possibly return nil. You don't actually have any static guarantees like you have in a typed case, but it's possible to imagine use-cases where the combining operations are useful enough to reimplement in a dynamically typed language. I suspect that a dynamically typed language that somehow lets you use some kind of monadic notation would benefit from this (e.g. perhaps through the use of Lisp macros), but without extra language support, it probably would just be tedious and verbose (e.g. in Ruby.) I'd be happy to be proved wrong, though.

[rntz]

It has nothing to do with compilation. It has to do with static typing -- that, before ever evaluating something, you typecheck it. It is perfectly feasible to interpret a statically typed language -- SML/NJ for example, includes an interpreter for SML. However, statically typed languages are generally easier to fully compile than dynamic languages; SML/NJ also includes a compiler for SML.

[jvoorhis]

Exactly. You can pass Maybe objects in Ruby as a convention, but the extra layers of indirection probably aren't buying you much. There is no way to enforce the contract.

[eru]

There are also interpreters for Haskell. Like hugs. And Maybe stays useful.