Very often the type system assures safety to a point where some coding is done trough trial and error: -I think that this composition is right, let´s try it-... -oh, some missing type here, Let´s put it here and here-...-go on-... -The typechecker say t´s OK. I run it and, well it works. Later when I look at the code, I have to think twice to understand it. Sometimes I mix transactions, threading, IO and some other abstractions in the same line, things that I would fear much to work with in any other language. This playing thig is fine, because the typechecking cut a lot of dead branches in the entrophic tendency of humans to commit mistakes. For this matter I praise math as the hidden god that handles reality and haskell its prophet. but the resulting code is not a product of my intended design, but something made together with the compiler, and sometimes it needs more than a look to understand it, even to myself. 2010/7/5 Ertugrul Soeylemez Felipe Lessa wrote:

...

On Sat, Jul 3, 2010 at 9:25 AM, Ertugrul Soeylemez wrote:

...

Haskell provides a lot of low level glue like laziness, currying and other very helpful language features. But what is different in Haskell is that it doesn't seem to provide any high level glue like other languages do, especially when it comes to the IO world. There is a somewhat powerful module system, but nothing to bring modules and the objects they define together in a consistent way.

When I first read this paragraph, I thought: "STM to the rescue!". STM is one of the best concurrent world glues, IMHO.

I found that I get along with the basic concurrency constructs. STM may be handy in a few applications, but in none that I write.

...

If you want, you may use Haskell just as you as PHP or C: just put everything in IO. Your code will get uglier and the type system won't catch many bugs, but that's what we get when doing C or PHP, right?

Not really. Even when programming in such a style, Haskell is much safer than PHP with its braindead type system, and still somewhat safer than C.

...

...

The problem with that approach is: This makes my code harder to understand for beginners. Usually they can tell /what/ my code is doing, because it's written in natural language as much as possible, but they couldn't reproduce it. And when they try to learn it, they give up fast, because you need quite some background for that. Also sometimes when I write Haskell, my friend sits beside me and watches. When he asks (as a PHP programmer with some C background), say, about my types, I can't give a brief explanation like I could in other languages.

I agree that it gets harder to reason about the code. In fact, sometimes I stack monad transformers in the wrong order. However, as Ivan says, if the feature is useful for you, don't be afraid of using it. Beginners may have a hard time grasping the concepts for the first time, but that's only until they "get it".

I find monad transformers easy to reason about, and in most cases the stacking order doesn't make a difference at all. Just remember to change the running function, too. The problem with them is that beginners learn them very late.

...

...

Yesterday I was writing a toy texture handler for OpenGL (for loading and selecting textures). He asked about my TextureT type. I couldn't explain it, because you couldn't even express such a thing in PHP or C.

type TextureT = StateT Config

-- Note that this is MonadLib. -- BaseM m IO corresponds to MonadIO m. selectTexture :: BaseM m IO => B.ByteString -> TextureT m ()

"It is the type of functions that may access and modify a state of type Config."

Then you need to explain "type of functions" and this explicitly implicit "state" and why you have to do it that way in Haskell.

Greets, Ertugrul

-- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe