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. Re: do Haskell programs have fewer bugs? (Darren Grant)
2. Re: do Haskell programs have fewer bugs? (Kyle Murphy)
3. Re: do Haskell programs have fewer bugs? (Ryan Trinkle)
4. Re: do Haskell programs have fewer bugs? (Dan Krol)
----------------------------------------------------------------------
Message: 1
Date: Wed, 19 Mar 2014 11:29:58 -0700
From: Darren Grant <[email protected]>
To: Haskell Beginners <[email protected]>
Subject: Re: [Haskell-beginners] do Haskell programs have fewer bugs?
Message-ID:
<CA+9vpFeO8zmZk4OJLnqRE31=M_qCuXzy+E+g61HqF=njj2t...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
For better or worse depending on your POV I find that I spend a lot of time
looking at the implementations of many libraries I employ in larger
projects.
There are certainly some surprises when a program doesn't execute in the
time or memory that I expected, and having the library source available can
be invaluable for determining why.
Cheers,
Darren
On Mar 19, 2014 11:21 AM, "Nadir Sampaoli" <[email protected]> wrote:
> Hello,
>
> Il 19/mar/2014 18:09 "Dennis Raddle" <[email protected]> ha scritto:
> >
> > I was thinking about why it seems I can write Haskell code without bugs
> in a much easier way than imperative languages. Part of it is the strict
> type-checking, but I think there is something more.
>
> As a beginner I find that the type system is my best friend. I spend most
> of the time in the repl trying function compositions until GHCi likes them.
> At that point, like I often read from expert haskellers' conversations, "if
> it typechecks it's most likely correct".
>
> >
> > It's the potential for conciseness. I work hard when programming in
> Haskell to take advantage of language features that make my program concise.
>
> As the saying goes, less code means less potential for bugs :)
>
> >
> > Somehow this leads me to think about it in a certain way. I know I'm on
> track as it gets smaller and smaller. And as it gets smaller, it leads me
> to think about my logic's cases and things like that. Certain patterns show
> up and I think about what those patterns mean for the structure of my
> problem.
> >
> > By the time I'm done with all that, I've analyzed my problem much more
> thoroughly than I would ever do in an imperative language.
> >
> > Dennis
> >
>
> As someone who is still struggling to get past that learning phase where
> you only solve "simple" (usually one-liner) exercises, I'd like to ask you
> (and anyone reading this) how do you reason at a larger level?
> At the function level Haskell feels like piping shell commands (which I
> find nice): a chain of successive transformations.
> How do you work at a larger (module/project) level? Do you need to have
> mastered all the main monads (beyond list amd maybe) and monad transformers?
>
> Sorry for the long rant. And thanks for the interesting discussion.
>
> --
> Nadir
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140319/31c277a2/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 19 Mar 2014 14:47:12 -0400
From: Kyle Murphy <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] do Haskell programs have fewer bugs?
Message-ID:
<ca+y6jcwrc6l00psub6bscbsmgozakmijarhdn3i0le4losk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
>From my experience so far it's largely the same, but you start to try to
take advantage of some of the more advanced types to handle of lot of the
plumbing type tasks. Things like Applicative and Monad make it simpler to
shuffle data and context between (or around) functions. In general picking
the right abstraction over your data goes a long way towards making your
code easier to work with and more succinct. Aside from that it's really
much like the case with individual functions, it's about composing larger
operations from smaller ones until eventually you reach the program level
where you're composing a handful of very coarse functions that comprise the
totality of the program.
-R. Kyle Murphy
--
Curiosity was framed, Ignorance killed the cat.
On Wed, Mar 19, 2014 at 2:21 PM, Nadir Sampaoli <[email protected]>wrote:
> Hello,
>
> Il 19/mar/2014 18:09 "Dennis Raddle" <[email protected]> ha scritto:
>
> >
> > I was thinking about why it seems I can write Haskell code without bugs
> in a much easier way than imperative languages. Part of it is the strict
> type-checking, but I think there is something more.
>
> As a beginner I find that the type system is my best friend. I spend most
> of the time in the repl trying function compositions until GHCi likes them.
> At that point, like I often read from expert haskellers' conversations, "if
> it typechecks it's most likely correct".
>
> >
> > It's the potential for conciseness. I work hard when programming in
> Haskell to take advantage of language features that make my program concise.
>
> As the saying goes, less code means less potential for bugs :)
>
> >
> > Somehow this leads me to think about it in a certain way. I know I'm on
> track as it gets smaller and smaller. And as it gets smaller, it leads me
> to think about my logic's cases and things like that. Certain patterns show
> up and I think about what those patterns mean for the structure of my
> problem.
> >
> > By the time I'm done with all that, I've analyzed my problem much more
> thoroughly than I would ever do in an imperative language.
> >
> > Dennis
> >
>
> As someone who is still struggling to get past that learning phase where
> you only solve "simple" (usually one-liner) exercises, I'd like to ask you
> (and anyone reading this) how do you reason at a larger level?
> At the function level Haskell feels like piping shell commands (which I
> find nice): a chain of successive transformations.
> How do you work at a larger (module/project) level? Do you need to have
> mastered all the main monads (beyond list amd maybe) and monad transformers?
>
> Sorry for the long rant. And thanks for the interesting discussion.
>
> --
> Nadir
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140319/bcc67c8f/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 19 Mar 2014 14:52:32 -0400
From: Ryan Trinkle <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] do Haskell programs have fewer bugs?
Message-ID:
<cahnepizs27xogdq4ic4pohl8v4z8oog7j6naocvm_ntef-b...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Dennis,
At skedge.me, our platform is Haskell on the backend and JavaScript on the
frontend, and we've definitely found that we have far fewer bugs coming out
of the backend than the frontend. I think Haskell's language features
(including the type system and sum types, most prominently) are responsible
for much of this difference.
We've also been able to completely eliminate certain kinds of bugs, such as
accidentally performing side effects during a database transaction (which
might be rolled back), by using monads to enforce our application's layer
architecture.
It's certainly possible to write very buggy code in Haskell, but Haskell
gives you a lot of tools that you can use to prevent yourself from writing
bugs. In my experience, it is much more efficient than achieving the same
level of quality using only testing.
Ryan
On Wed, Mar 19, 2014 at 1:09 PM, Dennis Raddle <[email protected]>wrote:
> I was thinking about why it seems I can write Haskell code without bugs in
> a much easier way than imperative languages. Part of it is the strict
> type-checking, but I think there is something more. It's the potential for
> conciseness. I work hard when programming in Haskell to take advantage of
> language features that make my program concise. Somehow this leads me to
> think about it in a certain way. I know I'm on track as it gets smaller and
> smaller. And as it gets smaller, it leads me to think about my logic's
> cases and things like that. Certain patterns show up and I think about what
> those patterns mean for the structure of my problem.
>
> By the time I'm done with all that, I've analyzed my problem much more
> thoroughly than I would ever do in an imperative language.
>
> Dennis
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140319/9217d49c/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 19 Mar 2014 11:58:37 -0700
From: Dan Krol <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] do Haskell programs have fewer bugs?
Message-ID:
<CAAWRcS93Ve7_zkj_yy=-qaeybb+bktoqih+qh940rvqm4ya...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Perhaps a bit tangential to the general question of "fewer bugs", but I'll
tell you that Haskell really clicked for me when I made a very nuanced
refactor of code that, while it took me a half day to sort out the type
errors, worked perfectly the first time I ran it. And this was for audio
generation stuff, something that's rather hard to debug in a usual way, so
I'm grateful that I didn't have to. There's no way it would work so
smoothly in, say, C++. Granted, I threw a whole lot of types at it, because
I was working with transformations between and operations within different
sorts of domains that I didn't want to get mixed up. So, you sometimes have
to deliberately leverage the tools to get it to do the magic for you.
On Wed, Mar 19, 2014 at 11:47 AM, Kyle Murphy <[email protected]> wrote:
> From my experience so far it's largely the same, but you start to try to
> take advantage of some of the more advanced types to handle of lot of the
> plumbing type tasks. Things like Applicative and Monad make it simpler to
> shuffle data and context between (or around) functions. In general picking
> the right abstraction over your data goes a long way towards making your
> code easier to work with and more succinct. Aside from that it's really
> much like the case with individual functions, it's about composing larger
> operations from smaller ones until eventually you reach the program level
> where you're composing a handful of very coarse functions that comprise the
> totality of the program.
>
> -R. Kyle Murphy
> --
> Curiosity was framed, Ignorance killed the cat.
>
>
> On Wed, Mar 19, 2014 at 2:21 PM, Nadir Sampaoli
> <[email protected]>wrote:
>
>> Hello,
>>
>> Il 19/mar/2014 18:09 "Dennis Raddle" <[email protected]> ha
>> scritto:
>>
>> >
>> > I was thinking about why it seems I can write Haskell code without bugs
>> in a much easier way than imperative languages. Part of it is the strict
>> type-checking, but I think there is something more.
>>
>> As a beginner I find that the type system is my best friend. I spend most
>> of the time in the repl trying function compositions until GHCi likes them.
>> At that point, like I often read from expert haskellers' conversations, "if
>> it typechecks it's most likely correct".
>>
>> >
>> > It's the potential for conciseness. I work hard when programming in
>> Haskell to take advantage of language features that make my program concise.
>>
>> As the saying goes, less code means less potential for bugs :)
>>
>> >
>> > Somehow this leads me to think about it in a certain way. I know I'm on
>> track as it gets smaller and smaller. And as it gets smaller, it leads me
>> to think about my logic's cases and things like that. Certain patterns show
>> up and I think about what those patterns mean for the structure of my
>> problem.
>> >
>> > By the time I'm done with all that, I've analyzed my problem much more
>> thoroughly than I would ever do in an imperative language.
>> >
>> > Dennis
>> >
>>
>> As someone who is still struggling to get past that learning phase where
>> you only solve "simple" (usually one-liner) exercises, I'd like to ask you
>> (and anyone reading this) how do you reason at a larger level?
>> At the function level Haskell feels like piping shell commands (which I
>> find nice): a chain of successive transformations.
>> How do you work at a larger (module/project) level? Do you need to have
>> mastered all the main monads (beyond list amd maybe) and monad transformers?
>>
>> Sorry for the long rant. And thanks for the interesting discussion.
>>
>> --
>> Nadir
>>
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140319/370c04b3/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 69, Issue 27
*****************************************
