The list there you have roughly corresponds to my intuitions, except for a few minor things: 1. Functional dependencies. --- I personally have used functional dependencies and wrestled with things like the coverage condition, and while I know I could easily look it up and would have no trouble understanding it, I doubt I could tell you what each of those is without looking it up. But I've never felt that knowing that is really worthwhile - they're just things the compiler will complain about if I run into them accidentally, and most programmers who have written enough of their own instances probably get them right anyways. So I'm not really sure that understanding those is necessary for being productive on a day-to-day basis, and they seem a bit out of place on that list. Do you have a particular reason they're there? 2. Arrows -- I've been programming Haskell for a few years now, and only run in to arrows *in practice* a few times. I've definitely seen a few libraries migrating away from arrows towards applicative or monadic interfaces instead. Do you use them often? I definitely feel like they're a bit more on the esoteric side, while GADTs, free monads, lenses, type families, and existential data types are things I encounter fairly frequently. On the other hand, they seem to be a good model for FRP and such, so maybe not. (Same goes for church encodings, but that's just a nice bit of CS that people should know a bit :) ) On the whole, looks like a pretty good list that I agree with. Of course, the "basic" list really includes a bunch more - knowledge of data types, syntax, functions, laziness, etc. -- Andrew On Thu, Jul 24, 2014 at 4:01 PM, Wojciech Danilo wrote:

This is **very** interesting question! When we recruit people to our company (we are working in Haskell everyday), we are basing on some classification between basic, intermediate and advanced stuff. These sections are shown below. I would love to hear what others are thinking about it and what from the below stuff would be widely considered as "basic Haskell knowledge", which would allow for full-time basic Haskell work.

Basics

1. type classes 2. instances 3. functors, applicatives, monads, etc ( http://www.haskell.org/haskellwiki/Typeclassopedia) 4. functional dependencies 1. Patterson condition 2. Coverage condition 3. Liberal coverage condition 5. monad transformers

Intermidiate

1. lens 2. arrows 3. free monads 4. GADTs 5. Type families 1. closed type families 6. existential datatypes 7. RankNTypes 8. church encoding

Advanced

1. templateHaskell 2. generics 3. continuations 4. delimited continuations

2014-07-25 0:44 GMT+02:00 Johan Larson :

What does a programmer need to know to be proficient in "basic Haskell"?

...

For my money, basic programming skills are those that are required to write programs for simple tasks in the common idioms of the language. This means the practitioner should be able to read input from the terminal or files, select/combine/reformat data, and output a result. At this point, efficiency isn't really the point; only getting to a correct answer without writing anything really weird matters.

In LYAH, I'd put the boundary at the end of chapter 9, which covers the IO monad. At that point the reader has studied functions, lists, tuples, types, recursion, higher order functions, four major modules, and algebraic data types. Actually, some of the later topics in chapter 8 (functors, kinds, recursive data structures) seem more like intermediate material.

Thoughts?

-- Johan Larson -- Toronto, Canada _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Oh, that makes sense. If you regularly do stuff with OverlappingInstances, that can definitely bite you :) I did not think about that since I tend to avoid OverlappingInstances in my own work whenever possible. Makes sense, then! I think it might make sense to have a list like this on a wiki somewhere, honestly. Of course a lot of bikeshedding could go into the exact division of topics, but it'd still be useful for something like this to exist somewhere. On Thu, Jul 24, 2014 at 4:19 PM, Wojciech Danilo wrote:

Alex - we are making a very havy use of them (we are creating our own language, compiler and domain specific libraries) - but you are right - in other scenarios, they would be intermidiate (not advanced in my opinion).

Andrew - I would disagree with point 1. If you are using OverlappingInstances and you are defining self-recursive instances, compiler will complain giving you no hints unless you know what you are doing (again, we are making ahvy use out of it, so I'm a little biased) Ad. 2) - you are right - they are in the intermediate section, because they are not hard to follow and understand. Additional, they are used a lot in reactive programming - but here I agree, they could go elsewhere.

And of course you are right - there is a bunch of very busic stuff not covered by the list - maybe I should just add it there, to make this list more pure! :D

2014-07-25 1:14 GMT+02:00 Andrew Gibiansky :

The list there you have roughly corresponds to my intuitions, except for a

...

few minor things:

1. Functional dependencies. --- I personally have used functional dependencies and wrestled with things like the coverage condition, and while I know I could easily look it up and would have no trouble understanding it, I doubt I could tell you what each of those is without looking it up. But I've never felt that knowing that is really worthwhile - they're just things the compiler will complain about if I run into them accidentally, and most programmers who have written enough of their own instances probably get them right anyways. So I'm not really sure that understanding those is necessary for being productive on a day-to-day basis, and they seem a bit out of place on that list. Do you have a particular reason they're there?

2. Arrows -- I've been programming Haskell for a few years now, and only run in to arrows *in practice* a few times. I've definitely seen a few libraries migrating away from arrows towards applicative or monadic interfaces instead. Do you use them often? I definitely feel like they're a bit more on the esoteric side, while GADTs, free monads, lenses, type families, and existential data types are things I encounter fairly frequently. On the other hand, they seem to be a good model for FRP and such, so maybe not. (Same goes for church encodings, but that's just a nice bit of CS that people should know a bit :) )

On the whole, looks like a pretty good list that I agree with. Of course, the "basic" list really includes a bunch more - knowledge of data types, syntax, functions, laziness, etc.

-- Andrew

On Thu, Jul 24, 2014 at 4:01 PM, Wojciech Danilo < wojciech.danilo@gmail.com> wrote:

...

This is **very** interesting question! When we recruit people to our company (we are working in Haskell everyday), we are basing on some classification between basic, intermediate and advanced stuff. These sections are shown below. I would love to hear what others are thinking about it and what from the below stuff would be widely considered as "basic Haskell knowledge", which would allow for full-time basic Haskell work.

Basics

1. type classes 2. instances 3. functors, applicatives, monads, etc ( http://www.haskell.org/haskellwiki/Typeclassopedia) 4. functional dependencies 1. Patterson condition 2. Coverage condition 3. Liberal coverage condition 5. monad transformers

Intermidiate

1. lens 2. arrows 3. free monads 4. GADTs 5. Type families 1. closed type families 6. existential datatypes 7. RankNTypes 8. church encoding

Advanced

1. templateHaskell 2. generics 3. continuations 4. delimited continuations

2014-07-25 0:44 GMT+02:00 Johan Larson :

What does a programmer need to know to be proficient in "basic Haskell"?

...

For my money, basic programming skills are those that are required to write programs for simple tasks in the common idioms of the language. This means the practitioner should be able to read input from the terminal or files, select/combine/reformat data, and output a result. At this point, efficiency isn't really the point; only getting to a correct answer without writing anything really weird matters.

In LYAH, I'd put the boundary at the end of chapter 9, which covers the IO monad. At that point the reader has studied functions, lists, tuples, types, recursion, higher order functions, four major modules, and algebraic data types. Actually, some of the later topics in chapter 8 (functors, kinds, recursive data structures) seem more like intermediate material.

Thoughts?

-- Johan Larson -- Toronto, Canada _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

That's setting the bar rather high, isn't it? I appreciate that you are talking about professionals, but working professionals whose domain is Haskell programming should have long since mastered basic Haskell, whatever we call "basic". Their daily work is intermediate Haskell, with occasional detours into the advanced. On Thu, Jul 24, 2014 at 7:01 PM, Wojciech Danilo wrote:

This is **very** interesting question! When we recruit people to our company (we are working in Haskell everyday), we are basing on some classification between basic, intermediate and advanced stuff. These sections are shown below. I would love to hear what others are thinking about it and what from the below stuff would be widely considered as "basic Haskell knowledge", which would allow for full-time basic Haskell work.

Basics

type classes instances functors, applicatives, monads, etc (http://www.haskell.org/haskellwiki/Typeclassopedia) functional dependencies

Patterson condition Coverage condition Liberal coverage condition

monad transformers

Intermidiate

lens arrows free monads GADTs Type families

closed type families

existential datatypes RankNTypes church encoding

Advanced

templateHaskell generics continuations delimited continuations

2014-07-25 0:44 GMT+02:00 Johan Larson :

...

What does a programmer need to know to be proficient in "basic Haskell"?

For my money, basic programming skills are those that are required to write programs for simple tasks in the common idioms of the language. This means the practitioner should be able to read input from the terminal or files, select/combine/reformat data, and output a result. At this point, efficiency isn't really the point; only getting to a correct answer without writing anything really weird matters.

In LYAH, I'd put the boundary at the end of chapter 9, which covers the IO monad. At that point the reader has studied functions, lists, tuples, types, recursion, higher order functions, four major modules, and algebraic data types. Actually, some of the later topics in chapter 8 (functors, kinds, recursive data structures) seem more like intermediate material.

Thoughts?

-- Johan Larson -- Toronto, Canada _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Johan Larson -- Toronto, Canada