[clean-list] Clean in the Real World

[Tomasz Zielonka]

On Wed, Jan 07, 2004 at 07:35:50PM +0100, Marco Kesseler wrote:
> Seriously now: You are right Ronny: I do not find monads "difficult" to
> use, in principle, assuming that one one planned to use them from the
> start... The "inelegance" issue needs some refinement. Irrespective of
> elegance, I am not fundamentally against using monads as a technique. I
> am against using monads as a fundamental solution.

I have some experience using Clean's Uniqueness Typing and more with
Haskell's monads and I think both have cons and pros.

What other solution would you propose? I would happily learn about it.

> Erik already pointed out that monads are not essential for parsing in
> general.  You can write perfectly elegant, well-designed, parsers
> without them.

I already admitted that. I only say that a monadic interface can be
easier to use... for someone who has mastered monads.

> Similarly, I am not convinced that they are essential exception
> handling either.

There are arguments for handling different computational effects within
the same framework. Monads give you the ability to combine different
effects in the way you want (see monads transformers).

Example: Suppose you want to maintain some global mutable state and you
also want to be able to throw and catch exceptions. Should the thrown
exception roll back all state changes up to the point of catch? With
monad transformers you can choose the right semantics. That's because
both effects - State and Exceptions - were placed in the same well
thought out framework.

> Would an elegant monadic Haskell program be just as elegant in say C?

Why should it be?

> And how about C++, or Java? or Erlang, Eiffel, SmallTalk, OCaml or...
> Lisp?

I don't understand you here. 

Would an elegant program massively using Erlang's concurrency mechanisms
be elegant in C? Or in FORTRAN?

Or take a LISP program using lisp macros to elegantly model some domain
language be still elegant if translated to C and CPP macros?

> If I am to do _impure_ functional programming anyway, wouldn't it
> be better to use the full power of one of these languages, than be
> dealing with some "do" notation?

Full power? You make it sound like those languages where better suited
for imperative programming than Haskell ;)

When I program imperative parts of my programs in Haskell, I rarely (if
ever) miss any features of conventional programming languages. I really
don't feel that I have to "deal" with do-notation, I just use it or
not.

If you are curious, I have written a considerable amount of code in
Haskell for dealing with real world problems, like a multi-threaded DNS
resolver library, various networking apps, programs that process huge
binary data files, scripts controlling other external programs, CGI
applications, etc.

> And, as libraries and useful functions were mentioned: take a look at
> sourceforge.net. I'd rather just take some of it and extend it with some
> purely functional code, than that I have to redevelop the whole lot
> using monads.

It's happening already. There are projects like wxHaskell that give a
Haskellish interface to some foreign language libraries (wxWindows
here).

> No. Most features in a functional programming language do _not_ force
> you into an imperative style of programming. Uniqueness typing and
> monads restrict the way in which expressions can be used.

Yes, but there are always some restrictions, especially in statically
typed languages like Haskell and Clean.

> Ever tried to convert a truly elegant functional program without any IO
> into one that writes "ouch!" to a file somewhere "deep inside" its
> computation?

Yes, something like this happened to me a couple of times, but it wasn't
really difficult to refactor the code. And if you just want to make some
diagnostic prints, there are tracing libraries.

> One of the points I am trying to make is that software developers hardly
> ever develop a whole new program from scratch. There is always _some_
> existing code base. If there isn't, look again.

That's what FFI is for. A couple of weeks ago I needed to use zlib's
decompress in my program - creating a raw interface took about 2
minutes, wrapping it in a more pleasant function took another 30.

Right now I am working on extending PostgreSQL with Haskell code - see,
I don't plan writing the entire RDBMS from scratch.

> regards,
> Marco

Best regards,
Tom

-- 
.signature: Too many levels of symbolic links