what is basic Haskell?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

what is basic Haskell?

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what is basic Haskell?

Wojciech Danilo
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 <[hidden email]>:
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what is basic Haskell?

Alexander Vieth
I'm curious to know why you have included functional dependencies under basics. I'd call that an advanced concept, since a Haskell programmer could be effective even without understanding it. Although, if your company makes heavy use of these, then I suppose you ought to consider it basic for new recruits.

Alex

On 2014-07-24, 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

  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 <[hidden email]>:
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what is basic Haskell?

Andrew Gibiansky
In reply to this post by Wojciech Danilo
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 <[hidden email]> 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 <[hidden email]>:

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what is basic Haskell?

Wojciech Danilo
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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what is basic Haskell?

Andrew Gibiansky
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe





_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what is basic Haskell?

Alexander Solla
In reply to this post by Johan Larson
On Thu, Jul 24, 2014 at 3:44 PM, Johan Larson <[hidden email]> wrote:
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.

I won't try to categorize.  Here's a very handy reference:

http://dev.stephendiehl.com/hask/ (What I wish I knew when learning Haskell)


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what is basic Haskell?

Donn Cave-4
In reply to this post by Andrew Gibiansky

> Oh, that makes sense. If you regularly do stuff with OverlappingInstances,

... which you wouldn't, at a basic level?

Rather than split off a whole set of basic categories like
- basic Haskell
- really basic Haskell
- really, really basic Haskell

... it makes sense to me to distinguish "basic" from "what we use
all the time at our shop."

Basic would be, as Johan Larson proposed, the things you'd really need
to write in Haskell, with fundamental properties of the language that
contribute to reusability, type safety etc.  We could reasonably put
type classes at that level, for example, if for no other reason than
it's hard to make any sense out of the platform libraries without knowing
about classes and instances etc.  But language features that aren't
even supported by default?  Is that even Haskell, as opposed to GHC?

        Donn
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: what is basic Haskell?

Johan Larson
In reply to this post by Wojciech Danilo
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
<[hidden email]> 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 <[hidden email]>:
>>
>> 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
>> [hidden email]
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>



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