[Haskell-cafe] what is basic Haskell?

Thu Jul 24 23:19:01 UTC 2014

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 <andrew.gibiansky at gmail.com>:

> 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 at 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 <johan.g.larson at gmail.com>:
>>
>> 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 at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140725/a2fffd07/attachment.html>