Try Haskell (tryhaskell.org)

I'd like to be able to tell those jokes without it being like making sounds in a foreign language—that's what I mean by "knowing" Haskell. You can't speak a language until you can make a witty retort in it ;)

  is the purpose of the Maybe monad to abstract the concept of "evaluate to Nothing if the previous expression evaluated to nothing?

  Also, is 'build'/'return' being used implicity somewhere?

In real code, it's mostly used when the exact monad being used isn't specified. For example, here's a function which runs a monadic computation until it returns `False'. The result is `()', sort of a Haskell void type.

  runUntil :: Monad m => m Bool -> m ()
  runUntil comp = loop where loop = do
    x <- comp
    if x then loop else return ()

C# and Python can, sort of, but their syntax and object-oriented semantics make it somewhat difficult. I don't know C# well, and Python needs a lot of magic[1] to get reasonable-looking code.

Here's a Python example. It's not a direct translation, but is close enough that you should be able to figure out the original. I've included the Haskell code in comments.

  import abc
  
  # class Monad m where
  #   build :: a -> m a
  #   bind :: m a -> (a -> m b) -> m b
  class Monad (metaclass = abc.ABCMeta):
  	@classmethod
  	def build (cls, x):
  		raise NotImplementedError
  
  	def bind (self, f):
  		raise NotImplementedError
  
  # data Maybe a = Just a | Nothing
  #   deriving (Show)
  class Maybe (Monad):
  	def __init__ (self, x):
  		self.__x = x
  
  	def __repr__ (self):
  		if self is Nothing:
  			return "Nothing"
  		return ("Just %r" % self.__x)
  
  # instance Monad Maybe where
  #   build x = Just x
  #
  #   bind Nothing  _ = Nothing
  #   bind (Just x) f = f x
  	@classmethod
  	def build (cls, x):
  		return Just (x)
  
  	def bind (self, f):
  		if self is Nothing:
  			return Nothing
  		return f (self.__x)
  
  def Just (x):
  	return Maybe (x)
  
  Nothing = Maybe (None)
  
  # clamp limit x = if x > limit then Nothing else Just x
  def clamp (limit, x):
  	if x > limit:
  		return Nothing
  	return Just (x)
  
  # multiclamp2 lim1 lim2 x = bind
  #   (clamp lim1 x)
  #   (\x' -> clamp lim2 x')
  def multiclamp2 (lim1, lim2, x):
  	return clamp (lim1, x).bind (lambda x2: clamp (lim2, x2))

  multiclamp = clamp >=> return clamp

  allclamp lims x = foldM (flip clamp) x lims

Writing an extension for XMonad may be worthwhile, though. Or learning about its inner workings. (There are some good introductions floating around the net. They put a lot of thought into the types in XMonad.)

tl;dr version:

1) It's a pretty language.

2) It's fast.

3) Static typing (and its optional companion "formal verification") rock.

4) Higher-order functions, Algebraic Data Types, Polymorphism and currying are our friends.

5) Exceptions are evil[1], explicit error handling is safer. Finally a language that hands me more convenient way of explicit error handling then:

  int result = someCLibraryCall();
  if (result == -1) {
    fprintf(stderr, "Ach, mein leben!");
    exit(EXIT_FAILURE);
  }

Arbitrarily changing prefix into infix functions or vice versa:

  elem foo list == foo `elem` list
  1 + 2 == (+) 1 2

2) For a language as high-level as Haskell, it's FAST. Most of the benchmarks show it pretty consistently in the C/Java performance regions (depending on what you're doing of course).

3) I used to hate static typing and think dynamic typing was the "end all, be all" of typing solutions until I start learning Haskell and suddenly realized I don't hate static typing, but that I hate crappy static typing implementations (Java, C, I'm looking at you).

A bonus of this is that it makes program verification of Haskell programs A LOT easier. During my class on protocol validation the mu-calculus we used for verifying programs was almost trivial to translate to Haskell (and vice versa).

I'm a firm believer in "formal verification" as a means to detect/prevent bugs. And while it might not be an issue for the programming world at large right now[2] (who cares if a word processor or browser crashes), it is important for mission critical software on things like cars, train, airplanes and space shuttles...

As a side note, I still like and use dynamic systems like python, but only for "trivial" code. i.e. quick scripts and stuff where I don't care if it breaks.

4) I find that with Haskell I'm usually working on a much higher level of abstraction then otherwise. Which means I'm spending more time thinking and scribbling on my white board and less time writing code and fixing stupid mistakes.

5) Monads like Maybe and Either allow for various convenient ways to do explicit error handling (there's probably a gazillion more ways to do explicit error handling with monads, but I don't grok them enough yet).

While Haskell still has exceptions they're far more limited and more sparsely used then in other languages.

EDIT: Removed very verbose and vague description of the Maybe monad, examine the example posted by jmillikin below instead.

In conclusion, what's Haskell good for? Well, I find it lends itself pretty well for high-level, abstract, meta sort of programming. The type a lot of people advertise Lisp for. And while Lisp macro's might be a tad more expressive[3], Haskell is most certainly prettier. And as behoofs any (ex-)python programmer I'm convinced readability matters.

All this while still being fast, reasonably good at stopping you from writing bugs and relatively easy to debug. Sounds like good enough reasons to use it, for me.

[1] - I'm not gonna argue "why" here, if you want to know I recommend Googling "Exceptions considered harmful" or "why exceptions suck" and you'll find plenty of in-depth explanations.

[2] - Actually, I do think it is relevant to ALL programmers. But that's more of a personal opinion which not a lot of people seem to share.

[3] - This is a hunch, learning Lisp/Scheme/Clojure is still on my todo list, so I'm not entirely sure if Lisp macro's can do things which are impossible in Haskell or not.