From: Brian Mitchell <binary42@...>
Date: 2005-10-01T02:20:29+09:00
Subject: Re: In your opinion....

On 9/30/05, Karl von Laudermann <doodpants@mailinator.com> wrote:
> Christophe Grandsire wrote:
> >
> > You'll find out Haskell is quite a different beast. It has interesting
> > features, but it doesn't have much in common with imperative languages
> > like Ruby. Its IO model is �bercool though (completely functional, which
> > is quite a feat, and basically making IO actions into objects rather
> > than actions. But if you really want to understand how it works, you
> > need to understand the monad, which is quite an esoteric mathematical
> > notion - and I'm someone who used to eat distributions for breakfast, so
> > abstract mathematical notions normally don't frighten me ;) -).
>
> I certainly don't understand the monad. I read some introductory
> material re: Haskell just a couple of weeks ago, out of curiosity about
> the language. My understanding of the monad concept and Haskell's use
> thereof is basically this:
>
> - Haskell is a purely functional language
> - Purely functional languages cannot have side effects
> - A language that can't do I/O is useless, so we need a way to put side
> effects into a purely functional language
> Therefore:
> - We'll put I/O subroutines into Haskell, *but* we'll call them
> "monads", and that magically fixes the problem somehow
>
> I'm sure that my understanding is wrong, but that's what I came away
> with.
>

Monads are something that seem to be made over complicated. This is
usually caused by the fact that monads can be used to do so many
different things. Here [1] is an excellent introduction to monads for
those already familiar with very basic Haskell. Basic Haskell skills,
for those interested, can be learned from a large collection of
material, much of which is listed on the haskell.org learning page
[2].

To try to answer the original question:

I think it is up to the programmer or the team. I've seen amazing
things done in just about every language. What made these particular
things a success? The effort that the project was given. It is key to
remember that you are the one who will be lifting each finger to
compose each symbol used in your program.

Now, that might sound far fetched, but it isn't. I've seen many
projects fail, some of my own in fact, all because the energies to use
a particular tool (that may or may not have suited the problem)
diminished. I think Ruby's high flexibility lends to the ability to
maintain the original mental picture had when starting the project.

What about things that require absolute speed, parallelism, or
unavailable library support? Take what I just said into your focus.
Now ask yourself, would I get burnt out on this project using Ruby?
All of those things ruby can't do _actually_ can be done. It is just
something that might inhibit your enthusiasm as Ruby will slow you
down. It will require extra effort whether it be in binding a library,
speeding up the interpreter, or building a special framework.

In the end a completed but not perfected project is better than
something half done and perfect to that point. Maybe by the time you
complete the project, you will have found that things can be fixed or
that things aren't how you original thought them to be. Someone else
might have even solved your problem for you by then which also happens
in the Ruby community more often than not.

All I said really boils down to: Choose the tools that will keep *you*
going. The project will stay around as long as you do.

Brian.

[1] http://www.nomaware.com/monads/html/
[2] http://www.haskell.org/learning.html