Ok good info :-)<br><br>&gt; btw, are you read Hoar&#39;s book &quot;Communicating Sequential Processes&quot;? i<br>think that his model is very FPish and reading his book should allow<br>to switch your look at concurrency in right direction
<br><br>No, I&#39;ll check it out.<br><br><div><span class="gmail_quote">On 7/1/07, <b class="gmail_sendername">Bulat Ziganshin</b> &lt;<a href="mailto:bulat.ziganshin@gmail.com">bulat.ziganshin@gmail.com</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hello Hugh,<br><br>Sunday, July 1, 2007, 8:56:05 PM, you wrote:<br><br>&gt; Genuine question: please could you tell me what are the truly powerful features of Haskell?
<br><br>&gt; Anyway, getting back to my question, there&#39;s a whole slew of<br>&gt; articles around saying that no-one uses Haskell because they&#39;re too<br>&gt; stupid. That&#39;s certainly an argument, but it possibly lacks a certain objectivity ;-)
<br><br>i agree with it. haskell represents new programming paradigm and most<br>programmers are unable to learn it without help of college<br><br>in other words, there is not yet enough learning infrastructure for FP<br>
languages. the same situation was in 80s for OOP languages. this means<br>that learning FP require much more work, or, spending the same time,<br>one will learn FP much worse than OOP<br><br>&gt; So... what do you see as the &quot;Killer Advantages&quot; that make Haskell stand out from the pack?
<br><br>i&#39;ve written 8kloc &quot;real world&quot; program in haskell and can say what<br>was killer features for me:<br><br>- natural data structures and easiness of defining algorithms<br>- rich set of list operations
<br>- easiness of use of higher-level functions<br>- type inference (dropping almost all declarations)<br>- strong type checking detects many errors just at compile time<br>- non-updateable data simplifies algorithms development
<br><br>for concurrent programming:<br>- it&#39;s easy to split algorithm to several parts that are run<br>concurrently and exchange data<br>- channels allows to organize data streams (like Unix pipes) between<br>threads, non-updatability of data significantly simplifies usage of
<br>these data<br>- MVar allows to implement shared updateable variables which<br>automatically locks on their use<br><br>shortly said, non-updatability of data significantly simplifies<br>both usual programming and concurrency, especially later. you can do
<br>the same with C#<br><br>it&#39;s an example how i use concurrency for data archiving and<br>compression:<br>- first thread scans disk and finds files to compress. it sends<br>filenames to its output stream<br>- second thread reads contents of these files and sends memory buffers
<br>filled with data read to its output stream. it also runs background<br>decompression stream which decompress data from old archive<br>- third thread runs one or several C streams which compress its input<br>buffers and sends buffers with compressed data to output stream. it
<br>may be several threads that do it, making a pipe<br>- fourth thread writes compressed data to output archive<br><br>all four threads are started by line<br><br>runP$ scanning |&gt; reading |&gt; compression |&gt; writing
<br><br>where each thread represented by a function which has additional<br>argument for exchanging data with previous and next thread in list:<br><br>reading pipe = do<br>&nbsp;&nbsp;nextFile &lt;- readP pipe<br>&nbsp;&nbsp;....<br>&nbsp;&nbsp;writeP pipe buffer
<br><br>running additional background thread and exchanging information with<br>it is also trivial:<br><br>&nbsp;&nbsp;decompressor &lt;- runAsyncP decompressor<br>&nbsp;&nbsp;writeP decompressor request<br>&nbsp;&nbsp;buffer &lt;- readP decompressor<br>
<br>you can see module which implements this as Process.hs from<br><a href="http://www.haskell.org/bz/FreeArc-sources.tar.gz">http://www.haskell.org/bz/FreeArc-sources.tar.gz</a> although it&#39;s<br>actually only a thin layer around forkIO/Chan/MVar features
<br><br>you can do the same in C# although i guess that syntax overhead will<br>be a bit more and allocating a lot of small non-updateable values may<br>be less efficient because its GC isn&#39;t aimed to such usage<br><br>
btw, are you read Hoar&#39;s book &quot;Communicating Sequential Processes&quot;? i<br>think that his model is very FPish and reading his book should allow<br>to switch your look at concurrency in right direction<br><br><br>
--<br>Best regards,<br> Bulat&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mailto:<a href="mailto:Bulat.Ziganshin@gmail.com">Bulat.Ziganshin@gmail.com</a><br><br></blockquote></div><br>