Open tomjaguarpaw opened 3 years ago
willjgould
commented
3 years ago Do we know what we're looking to address as a result of this issue, or are we just looking for suggestions/discussion around this? I'm asking because this is a topic I find quite interesting.
tomjaguarpaw
commented
3 years ago I wanted to record the summary but I don't have a clear idea for what to do about it. Please use this issue as a place to discuss though. I'd be interested in your ideas.
willjgould
commented
3 years ago It seems like this really splits into two different problems.
Problem one is teaching people who are either new to programming or juniors. They're learning to put programs together in their heads whilst also learning a language. So, if you take a language like Python, JavaScript, Java, C#, there are TONS of resources for really basic things. That's a huge wealth of information which feels, to me, difficult to achieve without a large community. It seems to me that trying to solve this problem would be an inefficient use of time, at the present moment.
Problem two is teaching more senior people. This ties into the other issue about having so many ways of doing things to a degree. I suspect that this might be more suited to being tackled right now, so my points rely on this assumption.
Code reviews would be exceptionally useful. Problem is, people aren't going to be queueing up to do full-on code reviews. The only way I can see code reviews being a valid method of learning is through people submitting to open source projects. Of course, people are willing to review small snippets on Reddit, but a full overview of the architecture of a web-app backend or something probably isn't reasonable.
What is perhaps doable is taking a bunch of example projects (relatively mundane ones like web-app backends), possibly with intentionally good or bad parts, and having people produce public reviews with suggestions of what's good, what could be better and why. It could also involve the reviewers showing how they'd improve things. It'd have to involve multiple reviewers though, in my opinion, because I think that getting different, possibly conflicting, points of view is important. It'd give people an angle to begin to agree with; the beginnings of a path to discover their own style and form opinions.
Another idea is building a small project in three "levels" of Haskell, with explanations of what's changing between each level, why it's useful, what language features are used and how it all slots together. I actually think that this, and the point above, are probably really important and I'll explain why. In more common languages you can often just search things like "how to do x in C#" and get a full answer (or dozens of full answers) explaining why the thing the asker was trying to do was bad and how they should do it instead. It gives context and structure to the learning experience. If the answer to a question was "typeclasses" or "free monad" or whatever, it helps to shape the mental model of Haskell for the reader, and that'll continue to build the more they see a given language feature or technique used in different contexts. They can go and look up the language feature or technique that was recommended to find out more, then after reading a simple (more on that later) tutorial they can come back and look at the answer through a clearer lens. There simply aren't enough people answering Haskell questions on StackOverflow for that to be the case here for all except the most common things, so that'd be the goal of this idea.
Demonstrations of common practical problems being solved by different language features are useful for tutorials. I think the goal with explaining a language feature isn't necessarily for a person to go away with a full understanding of the abstract power of the thing, it's just to begin to get a grasp of why it might be useful. I think that, often, we're more willing to dedicate time and effort to learning things that are demonstrably practically useful. A perfect example of such a demonstration would be something like solving form validation with applicatives. Easy to see, understand and extrapolate.
Also, in general, I see learning resources for languages as fulfilling a dual role. They're there to teach, but they're also marketing for the language. "Look at this cool feature, here's how you use it, here's why you'd want to use it". I don't see learning material for Haskell doing that very often. To see more clearly what I mean, if you search for "C# interface example" you'll get some super basic examples which do literally nothing but show you how to create and use an interface; it won't intersperse the visitor pattern or something into the example. This simplicity is desirable. On the contrary, if you look up "Haskell typeclass example" you get some very in-depth, partially theoretical explanations which, while useful for certain readers, aren't the kind of thing someone who's looking up typeclass tutorials is likely to want. What they ARE likely to want is something like "Hey, you know interfaces, right? Well, this can be used similarly, here's a full example!" and then you can have the "But wait, there's more!" section at the end which explains that, actually, they're much more than that and gives the reader the lead to follow if they so desire.
On the topic of theory, I'm strongly of the opinion that any tutorial on how to use something should have as little theory in it as possible. It could have links to relevant theory, it could have collapsible boxes explaining theory, but it most definitely shouldn't break up the flow of the tutorial with expositions on theory. I think this is a bit of a culture thing, as is evidenced by the frequency with which people reply to questions with a link to a paper.
Finally, the fact that 50% of people, from a sample willing to fill in a survey mind you, aren't willing to ask questions smells like a problem. I'm not sure what that number would be for other languages, but given how useful StackOverflow answers are for learning, the more answers existing for future learners to cargo-cult from the better. Not sure how that could be fixed, but I think fixing it is important.
That was waaaaay longer than I intended, sorry.
tomjaguarpaw
commented
3 years ago Great analysis, thanks. It was long (which is why I only just got round to reading it) but it was also very thorough!
Given the limited resources at our disposal what do you think is the right thing to tackle so that we get the most benefit?
willjgould
commented
3 years ago Alright, I've had a think about this.
I suspect writing ultra-simple (w3schools style) language feature tutorials would probably rank highest in value-to-effort. Nothing like that currently exists, as far as I can tell. There are tons of great books and book-like resources (like LYAH and Stephen Diehl's What I Wish I Knew When Learning Haskell) currently out there, but they don't fill the same role.
I'd certainly be up for writing some.
Once we've got a few that we like the format of, we could raise a call-to-arms for people to contribute.
Also, if you fancied it, there's probably no-one better placed to write one for arrows than you.
https://docs.google.com/forms/d/e/1FAIpQLSf9EwXjwR5_ondG_HLhqJtrqPZdeB2NZYQWKBXC9_j7tpjYDg/viewanalytics
(I have rounded a lot of the figures here for simplicity)
The most popular language to learn was Haskell with 35%. The second most popular was Scala with 10%
What learning material did you find useful?
Where did you start asking questions when learning?
If you have the time, if there was anything that could have improved your learning of FP language, what would it have been? Or what did you find was helpful?