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" wrote:

Hello,

Il 19/mar/2014 18:09 "Dennis Raddle" 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@haskell.org http://www.haskell.org/mailman/listinfo/beginners

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 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 wrote:

...

Hello,

Il 19/mar/2014 18:09 "Dennis Raddle" 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@haskell.org http://www.haskell.org/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Il 19/mar/2014 23:51 "Kim-Ee Yeoh" ha scritto:

There's a lot of low-lying fruit that's easily plucked leveraging

...

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?

Don't sweat them monads. The codebase for GHC doesn't even use monad

functional programming. Thanks for the insight. The "don't"s are most helpful. I have to constantly take myself from code golfing and overcomplicating things for the sake of cleverness (especially in a language that enables you so much). transformers iirc. My point was that when you're arranging new data types you'd probably benefit from understanding/recognizing behavioral patterns (e.g a Reader, a State-carrying data structure, etc.). Nonetheless I think I understand your point in which keeping things flat simple does come a long way to solving problems.

Not at all. Haskell mailing lists used to have long, discursive

discussions, but somehow this one turned into some kind of rapid-fire Q&A. Most of the interesting knowledge can't be unpacked in that format. Eh, that would imply a certain level of knowledge on both side. The fact that I'm stubborn and keep writing mails on a phone while train-commuting doesn't help either.

-- Kim-Ee

Thanks again, Regards Nadir