[Haskell-beginners] clarity and complexity of Haskell code?

caseyh at istar.ca caseyh at istar.ca
Sun Sep 25 23:07:09 CEST 2011

Haskell is designed for heavy computational lifting; your example is  
not an example of major computational power.

So, of course, Haskell code will not be short in ALL cases. :)

Quoting Ozgur Akgun <ozgurakgun at gmail.com>:

> Hi.
> On 25 September 2011 18:10, Brent Yorgey <byorgey at seas.upenn.edu> wrote:
>> You must at least agree that it is short.
> Not trying to start language wars here, but it is not terribly short for
> what it does. The following code does the same thing in C#, and isn't far
> longer. And it has more or less a one-to-one correspondence to the given
> Haskell code; open a file for reading, open a file for writing, read some
> number of bytes, apply the transformation, write it to the output file.
> Flushing the input/output buffers and closing the files are handled by the
> using construct, similar to withFile in the Haskell example.
> int chunksize = 4096;
> using (var r = new BinaryReader(File.OpenRead("infile")))
>     using (var w = new BinaryWriter(File.OpenWrite("outfile")))
>         for (var buffer = r.ReadBytes(chunksize); buffer.Length > 0; buffer
> = r.ReadBytes(chunksize))
>             w.Write(Array.ConvertAll(buffer, p => (byte) ~p));
> I think the habit of using quite a few operators in Haskell does make the
> learning curve steeper.
> I am not trying to say that the C# code is *better. *Just that the Haskell
> code is not terribly short in this case and it can be a bit cryptic for a
> newbie.
> Best,
> Ozgur

More information about the Beginners mailing list