[Haskell-cafe] XmlSerializer.deserialize?

[Bulat Ziganshin]

Hello Hugh,

Sunday, July 1, 2007, 8:56:05 PM, you wrote:

> Genuine question: please could you tell me what are the truly powerful features of Haskell?

> Anyway, getting back to my question, there's a whole slew of
> articles around saying that no-one uses Haskell because they're too
> stupid.  That's certainly an argument, but it possibly lacks a certain objectivity ;-)

i agree with it. haskell represents new programming paradigm and most
programmers are unable to learn it without help of college

in other words, there is not yet enough learning infrastructure for FP
languages. the same situation was in 80s for OOP languages. this means
that learning FP require much more work, or, spending the same time,
one will learn FP much worse than OOP

> So... what do you see as the "Killer Advantages" that make Haskell stand out from the pack?

i've written 8kloc "real world" program in haskell and can say what
was killer features for me:

- natural data structures and easiness of defining algorithms
- rich set of list operations
- easiness of use of higher-level functions
- type inference (dropping almost all declarations)
- strong type checking detects many errors just at compile time
- non-updateable data simplifies algorithms development

for concurrent programming:
- it's easy to split algorithm to several parts that are run
concurrently and exchange data
- channels allows to organize data streams (like Unix pipes) between
threads, non-updatability of data significantly simplifies usage of
these data
- MVar allows to implement shared updateable variables which
automatically locks on their use

shortly said, non-updatability of data significantly simplifies
both usual programming and concurrency, especially later. you can do
the same with C#

it's an example how i use concurrency for data archiving and
compression:
- first thread scans disk and finds files to compress. it sends
filenames to its output stream
- second thread reads contents of these files and sends memory buffers
filled with data read to its output stream. it also runs background
decompression stream which decompress data from old archive
- third thread runs one or several C streams which compress its input
buffers and sends buffers with compressed data to output stream. it
may be several threads that do it, making a pipe
- fourth thread writes compressed data to output archive

all four threads are started by line

runP$ scanning |> reading |> compression |> writing

where each thread represented by a function which has additional
argument for exchanging data with previous and next thread in list:

reading pipe = do
  nextFile <- readP pipe
  ....
  writeP pipe buffer

running additional background thread and exchanging information with
it is also trivial:

  decompressor <- runAsyncP decompressor
  writeP decompressor request
  buffer <- readP decompressor

you can see module which implements this as Process.hs from
http://www.haskell.org/bz/FreeArc-sources.tar.gz although it's
actually only a thin layer around forkIO/Chan/MVar features

you can do the same in C# although i guess that syntax overhead will
be a bit more and allocating a lot of small non-updateable values may
be less efficient because its GC isn't aimed to such usage

btw, are you read Hoar's book "Communicating Sequential Processes"? i
think that his model is very FPish and reading his book should allow
to switch your look at concurrency in right direction


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com