Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. clarity and complexity of Haskell code? (Gregory Guthrie)
2. Re: clarity and complexity of Haskell code? (Brent Yorgey)
3. Re: Functional programming principles at higher levels?
(Michael Xavier)
4. Re: clarity and complexity of Haskell code? (Ozgur Akgun)
5. Re: clarity and complexity of Haskell code? ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Sun, 25 Sep 2011 10:25:25 -0500
From: Gregory Guthrie <[email protected]>
Subject: [Haskell-beginners] clarity and complexity of Haskell code?
To: "[email protected]" <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I always enjoy and tout the clarity and simplicity of the declarative style of
functional programming, and with that also Haskell.
But it seems that although the wonderfully short and clear examples dominate
early learning and usage, the forums like this and caf? are dominated by
examples more like this:
import Data.Enumerator (run_, ($$), (=$))
import Data.Enumerator.Binary (enumHandle, iterHandle)
import Data.Enumerator.List as EL (map)
import Data.ByteString as B (map)
import Data.Bits (complement)
import System.IO (withFile, IOMode(..))
main = withFile "infile" ReadMode $ \inh -> withFile "outfile"
WriteMode $ \outh -> do
run_ (enumHandle 4096 inh $$ EL.map (B.map complement) =$ iterHandle
outh)
And many more - looks more like APL or Perl to me. :) Certainly not the
Python'ish model of "anyone can read this, and it is clear what it does".
Seems like the assertion that FP is easier and more clear is true at
introductory levels, but there are some subsequent big gradients in the
learning and usage curve. I use it only in very simple and small programs, so
wondered about the observations on this from more experienced experts.
I wonder if any studies have been done to quantify and measure the complexity
of programs in Haskell, as a way to assess this property.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20110925/75b3e695/attachment-0001.htm>
------------------------------
Message: 2
Date: Sun, 25 Sep 2011 13:10:27 -0400
From: Brent Yorgey <[email protected]>
Subject: Re: [Haskell-beginners] clarity and complexity of Haskell
code?
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Sun, Sep 25, 2011 at 10:25:25AM -0500, Gregory Guthrie wrote:
> I always enjoy and tout the clarity and simplicity of the declarative style
> of functional programming, and with that also Haskell.
>
> But it seems that although the wonderfully short and clear examples dominate
> early learning and usage, the forums like this and caf? are dominated by
> examples more like this:
>
>
> import Data.Enumerator (run_, ($$), (=$))
> import Data.Enumerator.Binary (enumHandle, iterHandle)
> import Data.Enumerator.List as EL (map)
>
> import Data.ByteString as B (map)
> import Data.Bits (complement)
> import System.IO (withFile, IOMode(..))
>
> main = withFile "infile" ReadMode $ \inh -> withFile "outfile"
> WriteMode $ \outh -> do
> run_ (enumHandle 4096 inh $$ EL.map (B.map complement) =$ iterHandle
> outh)
>
> And many more - looks more like APL or Perl to me. :) Certainly not
> the Python'ish model of "anyone can read this, and it is clear what
> it does".
The promise of FP is certainly not that "anyone can read this and it
is clear what it does". That's not really possible with any paradigm.
However, the above code to me does indeed seem wonderfully short and
clear: it opens an input and output files, then streams the contents
of the input file to the output file, while complemeting all the
bytes. You must at least agree that it is short. And clarity depends
a lot on your background. If you tried writing this program in most
mainstream languages I think you would find it to be longer and more
complex.
> Seems like the assertion that FP is easier and more clear is true at
> introductory levels, but there are some subsequent big gradients in
> the learning and usage curve. I use it only in very simple and small
> programs, so wondered about the observations on this from more
> experienced experts.
I think the perception of a big gradient in the learning and usage
curve is often due to the challenge of learning an entirely new
paradigm. The learning and usage curve was quite steep for the first
programming language each of us learned, but we have mostly forgotten
about it by now.
>
> I wonder if any studies have been done to quantify and measure the
> complexity of programs in Haskell, as a way to assess this property.
Not that I am aware of.
-Brent
------------------------------
Message: 3
Date: Sun, 25 Sep 2011 10:14:10 -0700
From: Michael Xavier <[email protected]>
Subject: Re: [Haskell-beginners] Functional programming principles at
higher levels?
To: Christopher Howard <[email protected]>
Cc: Haskell Beginners <[email protected]>
Message-ID:
<CANk=zmfvtnijgs8z0vxib8yvwvqazqa6c5fbehqsxd4nvzl...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I'm curious as to what it is about learnyouahaskell and other similar
tutorials that makes them "ridiculous". I found LYAH very helpful when I
wanted to actually learn how to get useful things done in Haskell without
taking a year off to read about theory. If that approach is ridiculous then
I think our definitions of that word differ.
On Sat, Sep 24, 2011 at 10:45 PM, Christopher Howard <
[email protected]> wrote:
> On 09/24/2011 09:12 PM, Mike Meyer wrote:
>
>
>> Actually, functional programming and the higher math are separate
>> things. Haskell (and I expect the similar languages) have a lot of
>> math in their documentation. But that's not true for other functional
>> languages, like Clojure or Scheme. With a background in those
>> languages, I didn't have much trouble with the functional nature of
>> haskell. But I'm still trying to recall the graduate math courses I
>> took long time ago in a state far, far different from today.
>>
>>
> Really? I'll confess I'm a bit surprised to hear that perspective. I don't
> know anything about Clojure or Scheme. But I found in trying to understand
> Haskell that it really is all about higher math. Once I finally gave up on
> "learnyouahaskell" and other ridiculous tutorials, I found the real
> functional programming textbooks, and discovered that it all starts with
> lambda calculus; all the explanations are given in set theory notation, with
> occasionally comparisons to integral and differential calculus for
> illustration, with very specific rules regarding substitution and reduction
> and normal forms. I'm still trying to figure out what all those combinators
> are about! And it is all rested on mathematical proofs, usually inductive.
>
> And that is just the lambda calculus aspect. Then we move on to type theory
> (!!!) plus the various types of polymorphism, and then on to a number of
> other topics that I don't know enough about to even mention intelligibly.
>
>
> --
> frigidcode.com
> theologia.indicium.us
>
> ______________________________**_________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/**mailman/listinfo/beginners<http://www.haskell.org/mailman/listinfo/beginners>
>
--
Michael Xavier
http://www.michaelxavier.net
LinkedIn <http://www.linkedin.com/pub/michael-xavier/13/b02/a26>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20110925/95e5dd22/attachment-0001.htm>
------------------------------
Message: 4
Date: Sun, 25 Sep 2011 21:05:04 +0100
From: Ozgur Akgun <[email protected]>
Subject: Re: [Haskell-beginners] clarity and complexity of Haskell
code?
To: Brent Yorgey <[email protected]>
Cc: [email protected]
Message-ID:
<calzazpd-ezsc5vd1vpeuy8fcvhe8aapn3vto-cv_ksl-pce...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi.
On 25 September 2011 18:10, Brent Yorgey <[email protected]> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20110925/583c1ab0/attachment-0001.htm>
------------------------------
Message: 5
Date: Sun, 25 Sep 2011 17:07:09 -0400
From: [email protected]
Subject: Re: [Haskell-beginners] clarity and complexity of Haskell
code?
To: Ozgur Akgun <[email protected]>, [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
format="flowed"
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 <[email protected]>:
> Hi.
>
> On 25 September 2011 18:10, Brent Yorgey <[email protected]> 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
>
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 39, Issue 31
*****************************************
