<div class="gmail_quote"><br><br>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. <div>

<br></div><div>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.<br>

<br><div class="gmail_quote">2010/7/5 Ertugrul Soeylemez <span dir="ltr">&lt;<a href="mailto:es@ertes.de" target="_blank">es@ertes.de</a>&gt;</span><div><div></div><div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>Felipe Lessa &lt;<a href="mailto:felipe.lessa@gmail.com" target="_blank">felipe.lessa@gmail.com</a>&gt; wrote:<br>
<br>
&gt; On Sat, Jul 3, 2010 at 9:25 AM, Ertugrul Soeylemez &lt;<a href="mailto:es@ertes.de" target="_blank">es@ertes.de</a>&gt; wrote:<br>
&gt; &gt; Haskell provides a lot of low level glue like laziness, currying and<br>
&gt; &gt; other very helpful language features.  But what is different in<br>
&gt; &gt; Haskell is that it doesn&#39;t seem to provide any high level glue like<br>
&gt; &gt; other languages do, especially when it comes to the IO world.  There<br>
&gt; &gt; is a somewhat powerful module system, but nothing to bring modules<br>
&gt; &gt; and the objects they define together in a consistent way.<br>
&gt;<br>
&gt; When I first read this paragraph, I thought: &quot;STM to the rescue!&quot;.<br>
&gt; STM is one of the best concurrent world glues, IMHO.<br>
<br>
</div>I found that I get along with the basic concurrency constructs.  STM may<br>
be handy in a few applications, but in none that I write.<br>
<div><br>
<br>
&gt; If you want, you may use Haskell just as you as PHP or C: just put<br>
&gt; everything in IO.  Your code will get uglier and the type system won&#39;t<br>
&gt; catch many bugs, but that&#39;s what we get when doing C or PHP, right?<br>
<br>
</div>Not really.  Even when programming in such a style, Haskell is much<br>
safer than PHP with its braindead type system, and still somewhat safer<br>
than C.<br>
<div><br>
<br>
&gt; &gt; The problem with that approach is:  This makes my code harder to<br>
&gt; &gt; understand for beginners.  Usually they can tell /what/ my code is<br>
&gt; &gt; doing, because it&#39;s written in natural language as much as possible,<br>
&gt; &gt; but they couldn&#39;t reproduce it.  And when they try to learn it, they<br>
&gt; &gt; give up fast, because you need quite some background for that.  Also<br>
&gt; &gt; sometimes when I write Haskell, my friend sits beside me and<br>
&gt; &gt; watches.  When he asks (as a PHP programmer with some C background),<br>
&gt; &gt; say, about my types, I can&#39;t give a brief explanation like I could<br>
&gt; &gt; in other languages.<br>
&gt;<br>
&gt; I agree that it gets harder to reason about the code.  In fact,<br>
&gt; sometimes I stack monad transformers in the wrong order.  However, as<br>
&gt; Ivan says, if the feature is useful for you, don&#39;t be afraid of using<br>
&gt; it.  Beginners may have a hard time grasping the concepts for the<br>
&gt; first time, but that&#39;s only until they &quot;get it&quot;.<br>
<br>
</div>I find monad transformers easy to reason about, and in most cases the<br>
stacking order doesn&#39;t make a difference at all.  Just remember to<br>
change the running function, too.  The problem with them is that<br>
beginners learn them very late.<br>
<div><br>
<br>
&gt; &gt; Yesterday I was writing a toy texture handler for OpenGL (for<br>
&gt; &gt; loading and selecting textures).  He asked about my TextureT<br>
&gt; &gt; type.  I couldn&#39;t explain it, because you couldn&#39;t even express such<br>
&gt; &gt; a thing in PHP or C.<br>
&gt; &gt;<br>
&gt; &gt;  type TextureT = StateT Config<br>
&gt; &gt;<br>
&gt; &gt;  -- Note that this is MonadLib.<br>
&gt; &gt;  -- BaseM m IO corresponds to MonadIO m.<br>
&gt; &gt;  selectTexture :: BaseM m IO =&gt; B.ByteString -&gt; TextureT m ()<br>
&gt;<br>
&gt; &quot;It is the type of functions that may access and modify a state of<br>
&gt; type Config.&quot;<br>
<br>
</div>Then you need to explain &quot;type of functions&quot; and this explicitly<br>
implicit &quot;state&quot; and why you have to do it that way in Haskell.<br>
<div><br>
<br>
Greets,<br>
Ertugrul<br>
<br>
<br>
--<br>
nightmare = unsafePerformIO (getWrongWife &gt;&gt;= sex)<br>
<a href="http://ertes.de/" target="_blank">http://ertes.de/</a><br>
<br>
<br>
_______________________________________________<br>
</div><div><div></div><div>Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div></div></div><br></div>
</div><br>