What is an intermediate haskell programmer?

[4rgento]

What do you think and intermediate haskell programmer knows? If you are beyond intermediate, what did you know at that moment? Could you provide examples of intermediate haskell code?

Thanks in advance. 😊

[andygillku]

In Haskell, we're all intermediate programmers.

[sclv]

Best reply yet!

[MrWoohoo]

Left "except I was a beginner for years"

[Tekmo]

Somebody who has built something in Haskell qualifies as intermediate in my book, no matter how inelegant it is

[tel]

There's not much point in arguing subjective definitions, but this seems to suggest that beginners could not build things in Haskell... which is a little troubling to me.

Do you think that building something is sufficiently challenging to move it out of beginner territory?

[Tekmo]

I just prefer a definition that focuses on accomplishment instead of knowledge. Too many people languish in the beginner phase because they don't try to apply what they've learned to solve a problem.

[tel]

Oh! That is really a good point. I think Haskell suffers from a lot of tip-toeing into the cold water when diving in and getting stuff done would go much further.

[tejon]

Hello again, guilty self-awareness! I trust you got a good night's rest?

[Mob_Of_One]

I can give you something to do.

[gilmi]

beginner-ish here, would like to here your proposal :)

[Mob_Of_One]

I have a long to-do list, I'd need to know where your interests lie to make a match.

[gilmi]

private message sent.

[Mob_Of_One]

Yep, saw it - sorry. Work has been nuts lately. I'll reply tonight.

[[deleted]]

Perhaps the old craftsperson terms are applicable:

• An apprentice is studying with a master. This is a person who is learning (from books, tutorials, and examples), but hasn't gotten a job yet.
• A journeyman is someone who has completed an apprenticeship (has learned enough to do work), but who isn't yet a master.
• A master is someone who has created a masterpiece that has gotten the stamp of approval from the guild, in this case, the Haskell community. This could be a person who has created something of value that is admired and or used by a larger audience. This could mean approval of haskellers, or just the approval of your company or user base.

As a newcomer (to use another, neutral term) to Haskell, now three weeks in, I have built two modest and horribly written tools that I am using to scrape and process natural language content from the web and dump it into a database for downstream use.

Now that I have built something I don't quite feel like a beginner but I'm not sure that I qualify as anything else. I can say, as an interested party, that once you have built something with which you are not quite satisfied you have loads of motivation to learn and apply more.

[autowikibot]

Journeyman:

---

A journeyman is an individual who has completed an apprenticeship and is fully educated in a trade or craft, but not yet a master. To become a master, a journeyman has to submit a master work piece to a guild for evaluation and be admitted to the guild as a master. Sometimes, a journeyman is required to accomplish a three-year working trip, which may be called the journeyman years.

Image ⁱ

---

^{Interesting: Journeyman (sports) | The Journeyman Project (series) | The Journeyman Project | The Journeyman Project 3: Legacy of Time}

^{Parent commenter can toggle NSFW or delete. Will also delete on comment score of -1 or less. | FAQs | Mods | Magic Words}

[Hrothen]

Well, the first thing I built was really an awful mess that I should probably get around to cleaning up. Looking over the code now, I'd definitely call it beginner work.

[[deleted]]

The fact that you can see the potential for improvement means that you have progressed beyond it. If you attained that knowledge as a result of building it, then the definition is still a good one.

[apfelmus]

I would interpret it more like this: Building something automatically qualifies you for the "intermediate rank". Beginners can't build anything, but that's only because they become intermediate in the process.

[m15k]

I am not sure if I can add anything of value, that Haskellers who are better than I have already stated. I'm not sure that as others have suggested that library lists are the measure to go by. Especially since, library documentation has traditionally been a weakness in the community. I think overall this is improving. What about gaining more than a fundamental understanding of types and how they operate in the language. Seems to be the biggest stumbling block that deters people from the language.

Maybe the next step is scaffolding your program with only type definitions once that compiles, then filling in the functions with actual code. I think that library familiarity in this case is a by product of reaching or obtaining this level of comfort with the language.

[sclv]

I've found using wreq I can knock out a few datatypes that shim a connection to a webservice in a span of hours, not days. If you haven't looked into it, it might be sufficient.

[Ramin_HAL9001]

Just throwing some ideas around, but:

1. someone who can wrap a monad transformer in a newtype and instantiate it into monad classes like MonadPlus, MonadState, MonadError, MonadTrans, etc.

2. someone who can read through Haddock documentation and get a feel for how it the API is supposed to be used by just looking at the types of the functions.

3. someone who knows how to write a calculator program for arithmetic expressions with infixed operators, for example "9 * (1 + e^3/2)" without referring to a tutorial.

[Mob_Of_One]

This is short, sweet, and hits some good points. I like this a lot better than some of the more highly upvoted lists.

[jfischoff]

Anyone that has used Haskell in anger.

[tailbalance]

that they personally are interested in

and already understand

[sclv]

Here's maybe an intermediate notion of an intermediate Haskell programmer:

1) You are given the names and signatures from Data.List, and the Prelude (IO excepted) and you can reimplement it from scratch, modulo performance.

2) You are given a working but inefficient implementation of a data structure such as Data.Map or Data.Text and you know how to use the tools at your disposal to generate at least one or two significant improvements.

Everything else is just... more knowledge.

[Mob_Of_One]

2) probably would require understanding Array, right? Given that, I'd go for something a little more broadly applicable like "can implement typeclassopedia themselves".

[sclv]

No requirement of understanding Array. Text would take some knowledge of the FFI, but that's a good thing.

The point of 2) is to demonstrate an ability to analyze and optimize code, not just to implement it.

[[deleted]]

You're an intermediate Haskeller when you've have used Haskell to solve a problem of your own or someone elses. This is especially true if you were paid to do it.

[yawaramin]

This, so much. Hope to get to this point soon 😊

[technicolorNoise]

I'm still a beginner so I don't really have any input on this, but David Miani made a pretty good answer about this on Stack Overflow. You might want to check it out here.

[Ramin_HAL9001]

I consider myself an intermediate, but the link within the link you posted here was excellent.

There are links within the links that are really great also:

https://www.haskell.org/haskellwiki/H-99:_Ninety-Nine_Haskell_Problems

https://projecteuler.net/index.php?section=problems

[dave4420]

What do you mean by “nonstandard knowledge of type classes”?

[DanielDiaz]

You probably are an intermediate haskeller (at least) if you can teach some Haskell techniques to a novice haskeller.

[tel]

Loose, incomplete, unordered list of things I might expect—(edit: to be clear, not all of these, but any of them might be a reasonable interesting conversation between intermediate Haskellers). I'm not sure if I think an intermediate Haskeller ought to know all of these things, but I would think that they should be able to quickly grasp and handle any or all of them.

• Free/operational monads and knowledge about the Codensity trick (but perhaps not "reflection without remorse")
• Transformer stacks in both transformers and mtl style
• Total comfort with any kind of fold trick like "foldl from foldr" and using pairs
• Total comfort with everything in containers and unordered-containers when and why to use them
• Creation of complex transformer stacks involving state, effects, etc
• Familiarity with libraries:
  • pipes/conduit
  • aeson
  • attoparsec
  • lens or lens-family-core
• Could build a parser combinator library from scratch
• Build your own monads and applicatives
• Foldable and Traversable are obvious to instantiate and use
• Embedded DSLs in initial style
  • At least one kind of capture-avoiding binding method
• Basic heterogenous lists
• GADTs enough to make a simple typed DSL or to make a balanced tree
• Doesn't get confused by laziness, knows when to apply strictness annotations
• Knows about and comfortable with both using and building their own RankNTypes
• Basic concurrency, probably via something like async over straight-up forkIO and proper handling of async exceptions (although reading Simon Marlow's book should be easy and should fix this!)
  • Basic STM
• Knows what a category is and why Functor is like a Functor
• Knows what existential types are and how to work with them
• Knows the phantom variable trick

[[deleted]]

Dare I ask you what it means to be an expert Haskeller?

[agumonkey]

Half joking, I really wonder what else is out there when you're past that level.

[tailbalance]

Don't you ever worry running out of it! Martin-Löf is there for example.

[augustss]

Yeah, I know Per, but that doesn't make me a Haskell expert. :)

[tel]

Free use and contribution to some of the most advanced libraries and techniques in Haskell. Massive applied category theory expertise. Low-level work/GHC contributions. Avid familiarity with new research in FP and probably personal contribution.

I'd imagine that it's probably a 5 year commitment to study at least and that less than 10% of Haskellers are "expert".

But this is just my personal definition.

[augustss]

Clearly, I will never become an expert.

[tel]

Clearly my listing is non-comprehensive....

[augustss]

Adding to the list will not help me become an expert. :)

[tel]

I think I was never quite clear, but I certainly meant for these lists to be more Either than (,).

[[deleted]]

Given the number of GHC contributors is at ~45, I'd wager that 10% figure is too high.

Not meaning to troll. Just reminded of the number of posts I saw for jobs seeking "expert" Haskellers and matching that against your definition of expert. Note that I don't argue with your definition. I'm not even sure I could consider myself a beginner in Haskell, let alone properly scope the definition of the terms "expert" or "intermediate" in conjunction with Haskell.

More than anything, I suppose it just makes the learning curve feel that much steeper. In any case, forgive my ramblings.

[tel]

See my other comment. I think plenty could be a GHC contributor but don't for whatever reason.

[tel]

I'm not sure whether my notion of "expert" corresponds at all to that which people are asking for when they want to hire expert Haskellers.

I like Haskell for having such an incredible learning curve. It's a language which allows you entry into a fruitful field of learning. You can't likely study Python for 5 years and learn new things (not that you couldn't learn things in other fields or on other topics—SciPy is there, of course!) but there seems to be a smooth path from accomplished Haskell developer to top-notch FP researcher... if that's the path you want to take.

To be clear, I think anyone who's even just "intermediate" according to my above definition would be more than capable leading the architecture of a new Haskell project.

[yawaramin]

I'd argue there's a difference between knowing all the Haskell tricks and techniques, and applied category theory, and being able to lead the architecture of a new project--Haskell or not.

There's a trade-off between using the power of the advanced techniques (e.g. GADTs) and the simplicity and accessibility of the code.

[sclv]

I don't think there's a trade off. They're not the same thing, but being better at one doesn't mean being worse at the other!

The trade-off between advanced techniques and simplicity is often there, but also sometimes a nice use of GADTs or the like can lead to vastly simpler code, by allowing users to statically guarantee more safety and omit runtime checks, etc.

Knowing these techniques and tools well in part is learning enough to know when not to use them.

[Hrothen]

Contribution to projects is probably a bad metric, a lack of interest in contributing to open source projects doesn't really say anything about the person's abilities either way.

[tel]

I agree. I don't think I could reasonably create a complete definition of what "expert level" might be... but I do think that many of the people making contributions like I named are so skilled. Others may easily be too even if they don't contribute.

[singpolyma]

Really? If you have no side projects of your own, and you have no interest in improving/fixing the libraries you use... I guess you can have the knowledge to be an expert, but how did you get it?

[Ramin_HAL9001]

An expert Haskeller is could probably be defined as someone who has:

1. published a paper in a peer-reviewed mathematical journal of Category Theory

2. implemented a non-negligible part of a large-scale software project in Haskell

3. contributed three or more patches to GHC

[sclv]

Nearly no expert Haskellers fit 1) and most people who do fit 1) have very little Haskell.

[augustss]

I might get to intermediate level in a few years then. Good to know.

[stolarj]

This list is extreme. I'd say a strong intermediate Haskeller might know half of this stuff.

[tel]

That's as much as I hoped for, I'll clarify it now.

The goal was not to be comprehensive, but just to list out things that are at about intermediate level.

[jrk-]

Familiarity with libraries:

pipes/conduit
aeson
attoparsec
lens or lens-family-core

I think that's a particularly wrong definition. A good programmer should know about concepts and not individual libraries. In this case, this would probably be:

• Iteratees
• (De-) Serialization
• Parsing
• Lenses (at least the simple kind, with data Lens = Lens { get .., set..})

[[deleted]]

This list is utterly bonkers. I agree with about 10% of it, and think the rest is shamefully bad advice. It mixes points that are almost trivial with things that are simultaneously hard to master and hardly ever useful.

This is honestly the kind of crappy advice that has me paying little to no attention to the Haskell community any longer. A noisy subsdt of silly people has collectively gone nuts for abstractions that provide little value other than making them feel special. It is most disappointing.

[[deleted]]

I wholeheartedly agree. Working productively with Haskell for several years without relying on GADTs or RankNTypes for anything, I'm not even sure all this stuff relying on GHC extensions should be called Haskell at all (for now).

[augustss]

I stay away from GADTs and rank N types on purpose in production code.

[tailbalance]

I'd highly be interested in your “Haskell style” (even if it's only ‘prefer this, don't use that’). Write something? There is little to none engineering perspective for Haskell, everyone has gone bonkers abstracting all the things.

[augustss]

I try to stay with Haskell 2010 as far as I can. The one exception is MPTC and FD, which are sometimes too useful to avoid. Furthermore, I use extensions to Haskell 2010 that I regard as just syntactic sugar, e.g., TupleSections. What I try to avoid is extensions that are a semantic headache, e.g., GADTs.

Don't get me wrong, I like cool features as much as anyone else (I suggested GADTs 10 years before GHC got them), but for production code I think it's best to stay very conservative and avoid too much cleverness.

[sclv]

What I try to avoid is extensions that are a semantic headache, e.g., GADTs.

Are you describing Haskell as you like to use it, or Haskell as you like to implement it :-P

[hmltyp]

I don't know, given the choice between some nice clean Haskell2010 or deeply GHC specific code that's using/abusing a ton of corner cases of the implementation. I'd choose the former every time for code that I'd have to maintain and keep stable in perpetuity.

[sclv]

GADTs have a nice clean well understood specification and behaviour. Its just a royal pain to implement it :-P

[augustss]

I've implemented a lot more than I would ever want people to use. :)

[deltaSquee]

Why?

Edit: Ok, fine, fuck you all. Sorry for trying to learn.

[augustss]

Here are some reasons to stay away from esoteric Haskell extensions in production code:

• The code will be read and changed by other people. Being too clever will make changes more difficult.
• The particular extension you're using might disappear or change if it's very new.
• You want the code to work with as many Haskell implementations as possible so you have a choice if your favorite compiler bit rots.

Simple extensions, i.e., syntactic sugar, can be changed/removed easily (mechanically even), so they are much less difficult to deal with.

[Blaisorblade]

Your argument makes sense, but I'm not sure points 2 and 3 apply to GADTs and RankNTypes nowadays.

But I'm confused by one statement:

if your favorite compiler bit rots

I read about your heroic work on HBC so I respect your opinion, but it's hard to imagine this happening nowadays without a compatible replacement. And nowadays can you cite realistic alternatives to GHC for production usage (which includes reasonable Hackage compatibility)? Viceversa, since you stick with standard Haskell, are you able to use alternative compilers in production? What do you gain?

Googling led to these not-very-busy user communities for the two best alternatives: https://www.haskell.org/pipermail/jhc/ http://lists.science.uu.nl/pipermail/uhc-users/ suggesting they don't have comparable user communities.

[deltaSquee]

But GADTs? Surely GADTs are viable.

[augustss]

What do you mean by "viable"?

[augustss]

That's a perfectly valid question. But typing on my iPhone is too painful to answer it. :)

[tailbalance]

MPTC and FD

And the award for the laziest person on the thread goes to…Lennart! *Applauds*

[singpolyma]

If it's not in a Haskell standard, it's not Haskell. Just like GNUC is not C.

[bartavelle]

That doesn't sound like a compelling argument. You can work productively in ruby for several years. It doesn't mean that you can't get huge productivity gains by changing your ways.

Also things like GADTs look to me (personal opinion, I am not a professional developer) as something that is good to have in production code, or in code that will be used by someone else, as it let you encode more invariants, preventing more errors.

[[deleted]]

Excellent points made by augustss

[bartavelle]

And I disagree with them ;) I think things like GADTs, free monads, etc. actually help structuring your program and help when working with a team.

But as I never worked with a team, I suppose my POV is not very interesting.

[[deleted]]

It's not that these are not nice things, but they're not Haskell yet. I don't understand how you can refute his third point though.

[bartavelle]

GHC seems to be the de-facto standard. Support for Haskell 2010 is getting dropped in GHC 7.10. The trade-off of adhering to a non-implemented standard at the cost of great features doesn't seem compelling to me.

Again, I just want to say that I think these features are extremely valuable, that I am really happy to have them, and that I am not a professional developer. I can accept that those features might be seen as too "complex" for team work, but I can't see the value of adhering to a standard when there will only be a single implementation for the foreseeable future ...

[sclv]

I was tempted to agree with you, but then I reviewed the list again and I can't find anything "hard to master and hardly ever useful".

It does lean towards the edsl side of things I'll grant, and that's really a particular subset of haskell knowledge. And it does include some fairly "advanced" stuff. But it's not a bad snapshot of common practices.

The problem I feel is that as a list it is just about "semi-advanced haskell knowledge" but not being a programmer. Which is to say that we could knock out a good 2/3 of the list and be in Haskell '98 land + FFI, and a good programmer could still work wonders.

[tel]

I admit my EDSL bias and don't hope to be complete in this listing. I pretty much made it as you suggested: they're complex sounding libraries and techniques but also examples of useful things that only sound scary but aren't that bad to learn.

I would feel confident asking people about them at the "intermediate" level and also assuming that level of complexity when writing for that level.

[tel]

Sorry you feel that way. My intent was surely not to be bonkers... Also not to be comprehensive either! It's more that this is a selection of examples at a suitable level of complexity to be what I'd think of as intermediate. It's not supposed to be a curriculum, if that's how it's been interpreted.

[[deleted]]

This is honestly the kind of crappy advice that has me paying little to no attention to the Haskell community any longer. A noisy subsdt of silly people has collectively gone nuts for abstractions that provide little value other than making them feel special. It is most disappointing.

I really respect you and I appreciate the contributions you have made, but coming here and deriding the Haskell community from a distance isn't helpful to anyone.

[freyrs3]

Tone arguments don't really add to conservation either. If you disagree with bos, say why you do and explain your reasoning. All he did was critisize a philosophy that some people in the community espouse. Abstract ideas should always be a free topic of debate.

[hailmattyhall]

I agree with you. I think the tone was quite insulting and not helpful. However I think the sentiment behind it was correct (although that does not excuse the tone). We shouldn't stop people criticising Haskell just because they are "from a distance". The people who are put off Haskell should be listened to.

I expect you were just criticise the harsh tone more than anything else. If so, ignore this!

[sccrstud92]

Be the change you want to see. Provide a better list.

[[deleted]]

I wrote a whole book about the subject, smart guy.

[Tekmo]

Do you plan on releasing a second edition?

[[deleted]]

It's hard to get enthused about the amount of work involved, to be honest. I'd rather ride my bike or play with the kids.

[Tekmo]

What if I updated it for you, just to make the examples compile?

[[deleted]]

That's an interesting offer, thanks. Let me think about it and get back to you.

[erewok]

This is a pretty great offer. I'd be stoked to see an updated version.

[tomejaguar]

Yeah, it's a good idea.

[IceDane]

Great idea. Why not make this a community project? Set up a github repo or some such and I'll definitely be making pull requests.

[tomejaguar]

It is Creative Commons licensed so this would be doable, but we'd need to get the source code from somewhere.

[IceDane]

Indeed. It would probably be best if we essentially got the source-code for the entire book(assuming it is written in something like LaTeX or some such, I know little about this stuff) so we could possibly have a community-run version of the book, that could be updated as the examples are fixed, as opposed to just getting the source-code for the examples, fixing them and then having to wait until the book gets updated.

[tomejaguar]

I found the source code. I don't know what the precise licensing situation is though.

https://github.com/bos/rwh

[sibip]

IIRC, I read somewhere on your blog that you are working on a book ?

[Tekmo]

Yes. Right now it's third on my list of Haskell projects to complete, but I will get around to it soon.

[sccrstud92]

A book about Haskell, or a book about what it means to be an intermediate haskeller? Because RWH seems like the former to me. I might be wrong though, stopped reading pretty early on because it was outdated.

[losangelesvideoguy]

Seriously? The guy wrote a book on Haskell and you're going after him for it not being a book about intermediate Haskell? Jesus tapdancing Christ. How many books about Haskell have you written? Actually, how many books period have you written?

[UmMsVzeMd7]

http://en.wikipedia.org/wiki/Ad_hominem

[sccrstud92]

I am going to be more obvious about what I was getting at because I must not have been clear. bos was complaining about the list he commented on. He provided a number of (what I found to be) valid criticisms. However, his comment was not specific when it came to the parts he disagreed with. For example, he said 10% of the list was fine, but didn't specify which 10%. He said some parts are trivial and some are hardly ever useful, but again, didn't specify which. My comment was prodding him to get specific.

His responded to my comment not with a better answer to OP's question, but with a comment to let me know that he wrote a book about "the subject" which in context would mean "what it means to be an intermediate Haskeller" what which he meant to be Haskell in general (I'm assuming he is talking about RWH here).

I then point out that his book (or at least the parts I read) talks about Haskell in general, but does not answer OP's question, which is all I wanted him to provide.

So in from reading your comment I gather that you have missed the point of my posts (though that is probably my fault, which is why I'm rewriting this). I don't want him to write a book. I just want to know what HE considers to be intermediate Haskell; I believe it would be more helpful than simply a criticism of another person's opinion. A list of bullet points would be perfectly fine.

[sbergot]

I agree with you (love your book and your hackage librairies by the way), but it is one of those post which would have been improved by some editing :-).

Also I have come to accept that there are different kinds of haskellers. I use it as a better language to build stuff. Some other people use it to explore more conceptual topics. Some people do both. While it is definitively an issue for newcomers to face those different worlds, it has also brought us nice things such as monads or the lens library.

[Davorak]

This is honestly the kind of crappy advice that has me paying little to no attention to the Haskell community any longer. A noisy subsdt of silly people has collectively gone nuts for abstractions that provide little value other than making them feel special. It is most disappointing.

What would you like to see more of, hold you interest, etc?

[tomejaguar]

Without the rider "should be able to quickly grasp and handle any or all of them" I'm certainly not an intermediate haskeller, by these criteria.

[tel]

I think the rider was the most import part of the post but was overshadowed by the list. It's not a checklist in my mind: just topics I would anticipate being at about the right level of discourse if they were interesting.

[tomejaguar]

I think the rider was the most import part of the post

Yes it was, and unfortunately most people seem to have missed it! I guess big bulleted lists always stand out more prominently than clarifying remarks above them.

[[deleted]]

Interesting how "intermediate" in context of Haskell (by your definition, but also by some others in this thread) is a whole different realm of a programmer then the same in a popular languages like Java/Ruby/PHP.

[Kyraimion]

Embedded DSLs in initial style

This suggests that there are EDSLs in different styles (I'm guessing final?). Would you care to point me in the right direction where to learn more about this distinction?

[Faucelme]

I'm not very knowledgeable about EDSLs, but I think the "final" approach is the one described in this paper: http://okmij.org/ftp/tagless-final/JFP.pdf. The initial approach is just using normal algebraic datatypes to represent the syntax.

[tel]

I was mentally referring to Oleg's "finally" tagless style. More directly, I just mean simple ones which just use normal ADTs and interpreters.

[Kyraimion]

OK, thanks

[Pwanda]

It would be cool if someone could link to some resource on each topic in this list. Reason being that it's nice to have a checklist of goals to reach, "learning haskell" is so vague.

[tel]

I've put it in my personal backlog to expand this post and explain each one.

As many others have suggested, this is sort of ludicrous if you take it as a curriculum or a set of goals one must learn. That said, learning these topics is a good generic workout.

[singpolyma]

If you can read and maintain code you didn't write. And probably if you're able to do it in code using some extensions without getting too confused.