Fwd: [Haskell-cafe] Re: Is my code too complicated?

Alberto G. Corona agocorona at gmail.com
Mon Jul 5 08:32:24 EDT 2010


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 <es at ertes.de>

Felipe Lessa <felipe.lessa at gmail.com> wrote:
>
> > On Sat, Jul 3, 2010 at 9:25 AM, Ertugrul Soeylemez <es at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100705/bd72fe66/attachment.html


More information about the Haskell-Cafe mailing list