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 <e...@ertes.de> Felipe Lessa <felipe.le...@gmail.com> wrote: > > > On Sat, Jul 3, 2010 at 9:25 AM, Ertugrul Soeylemez <e...@ertes.de> 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 >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
