Monads are red herrings, if what you're interested in is getting started with functional programming (or even Haskell specifically). It's an unfortunate flaw in the Haskell literature that makes it seem like you have to grok monads to learn Haskell; you don't.

Monads enable syntactic sugar. If you're getting started with Haskell, you'll notice that when you write code that does I/O, you use a weird imperative-looking syntax ("do notation") that looks different to the normal functional style:

    main :: IO ()
    main = do
      putStrLn "Please enter your name"
      name <- getLine
      putStrLn ("Hello " ++ name ++ "!")

'putStrLn "Hello"' doesn't actually print anything; it returns an IO value that, when interpreted by the Haskell runtime, prints something: that interpretation takes place when 'main' is run. The do notation is syntactic sugar for creating a sort of compound IO value that interprets as a bunch of actions rather than just one. The reason you can use do notation for IO but not for (all) other Haskell code is that IO values are monadic (which is another and possibly more useful way of saying "IO is a monad"): that just means that they behave in a certain way when combined (to produce that compound value) and obey certain laws to make the do notation well behaved.

Monads are a design pattern to abstract away repetitive functional code. For example, if you write a lot of pure-functional code you sometimes end up having to pass around a 'state' parameter. If a function reads or writes from the state, then any function that calls it has to pass in the state, and so on. This leads to a lot of functions with an extra state parameter, many of which don't even care about the state except to pass it down the call tree. An improvement would be to write a higher-order function which took a function which didn't care about state and wrapped it to produce one that just passed the state through. The State monad encapsulates this wrapping and lets you clean up the rest of your code.

Monads are what's between the lines of an imperative program. Bourne shell scripts have the default error-handling rule that they ignore failing commands unless it's the last one executed, or put another way, they run in a monad that ignores errors:

    cat nonexistent.txt   # prints an error message
    echo Done.            # still executes, prints "Done."
    # script returns success

But you can tell it to run instead in a monad which stops after the first error:

    set -e                # change the monad, i.e. the error-handling rule
    cat nonexistent.txt   # prints an error message
    echo Done.            # never runs
    # script returns failure

Old-school Visual Basic has the opposite default, but you can make it behave like a shell script with "ON ERROR RESUME NEXT". Yes, VB had monads.

Monads are a specific example of higher-kinded polymorphism, which is a very powerful and useful concept that's starting to enter the programming mainstream (examples are template concepts in C++ and LINQ in C# and .NET). Parametric polymorphism (List<String> in Java and C#, etc) means you don't have to write a 'reverse' function that works on lists of strings, and another 'reverse' function for lists of ints, etc; you can just write a generic reverse function that works on lists of any kind, because it doesn't need to know the details of the contained type, just how to iterate over a list. However, if you want to reverse an array, you still have to write a new 'reverse'. If your language supports higher-kinded polymorphism, you can write a generic reverse function that works on any kind of container, because all it needs to know is that the container has some well-behaved method of iteration.

(The LINQ example is a bit more subtle, because C# doesn't support higher-kinded polymorphism, but LINQ is a hard-coded exception to that rule. The cool LINQ syntax works for any type which provides certain operations and behaves in a certain way - which just happen to coincide with the requirements for the type to be monadic.)

Um... I disagree. I worked for a large company that does just that: hire liberal arts majors with high gpas and teach them to program. It works, well, horribly. Ask any former employee about the code quality at epic systems.

"Fortunately, [...] a SpyHunter fan [...] had extracted the sound effects himself and put up WAV files on his web page."

"I wanted to give the guy a game credit [...]. The publisher refused....their legal team were already writing up a cease-and-desist letter ordering him to remove the assets from his fan page."

Guy saves the day and instead of a cookie he gets a CnD letter. Do things really have to work this way?

"But you have to defend your trademarks or they become worthless!" Right, because the publisher would have been so much better off if those WAVs wouldn't have been out on the Internet in the first place.

It's because "every startup" is lazy and afraid to take risks. In the programming world, for example, everyone wants to hire someone who has 150 years of experience with each of C, C++, Java, C#, Perl, Python, Ruby, OCaml, Haskell, and node.js. Problem is, that is not possible. So the position goes unfilled.

If programming shops were willing to hire people fresh out of college with English degrees and teach them programming, they would probably do really, really well. But nobody is willing to do that, so college grads go without jobs and startups go without employees.

(Also, startups expect you to really drink that Kool-Aid. They want you to work 12 hour days, skip weekends, not take vacation, and "be loyal" to the company. Why would anyone do that when they can work 9-5 for 4x as much money at an investment bank?

Ironically, even the investment banks can't hire anyone, but that is for other reasons.)

I hope that's the case, honestly, and I hope that it does go to court. I'm frankly sick and tired of the 'unlimited' advertising model, wherein unlimited really means limited to some arbitrary amount that is not disclosed.

As a customer who has been kicked off of a number of unlimited hosting services for a site that only does ~30Gb or so in traffic in a month, I'd love to see hard limits advertised rather than 'unlimited'.

I know that Dreamhost oversells on purpose, and that's fine, but I think they can still do that (though perhaps not quite as effectively) by just stating their upper limit. Of course, this means that more people are likely to hit or approach that upper limit, but at least they'll know when they need to grow into another 'slice' as it were, or whether or not to relocate from Dreamhost altogether.

This reminds me of what my electrical engineering friend once did when his washing mashine stopped working. He got out his multimeter, opened up the back panel, and finally traced everything to an open circuit: the lid was open.

Perhaps the reason startups are struggling to hire in NYC is not because there are too few hackers but because there are too many startups. Most hackers simply do not have aspirations to work 80 hours a week to make some MBA jackass rich off of his website which promises to revolutionize the world for apartment brokers, attempt to make print media relevant online, or sell last year's handbags at a discount.

MAME saved my ass too.

I was working on a coin-op game for a mid-level manufacturer in Chicago. Let's just say they were the last dinosaur in the tar pit and they didn't have a stellar hardware engineering team. They tended to copy other people's designs and not really understand the architectures, so things like in-circuit emulators and IDEs were scarce or non-existant. You debugged via trial-and-error and, if you were lucky, printf().

So I was working on this title and started working from home a couple of days a week to take care of a family member. That made things hard, and even harder since you tend to have the physical machine next to you while coding. It was frustrating to code for a day, get to work, then find half of it wasn't working.

Then I discovered that the MAME kids had already supported the platform. With a small amount of work I could develop on the emulated platform. I could work remotely and I had access to things the in-house guys didn't even have: hardware breakpoints, live RAM viewing, scripted testing for example.

Without MAME I would have seriously been suffering on this project.