[Haskell-beginners] do Haskell programs have fewer bugs?

[Kyle Murphy]

>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 <nadirsampaoli at gmail.com>wrote:

> Hello,
>
> Il 19/mar/2014 18:09 "Dennis Raddle" <dennis.raddle at gmail.com> 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
> Beginners at haskell.org
> 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.html>