Ciao!
I hope I didn't just break your email client with the Polish subject.
We Italians are not well-known for our language-speaking skills. Super Mario, anybody?
Statistically, we are not doing great. However, I believe anybody can learn anything, modulo some hard work. Hell, I managed to do something useful with Haskell myself!
When I was sixteen, I spent a couple of weeks in Poland. During the trip, I asked people to teach me sentences until, one evening in a pub, I made a shocking discovery.
I was taught to say jedno piwo for one beer. Then dwa piwa for two. But when I attempted to order five with pięć piwa, everything collapsed: they corrected me with pięć piw.
I knew Polish was a mess, but two different plurals?!
Luckily, at that point, we had eight beers of wisdom circulating in our blood. We reversed-engineered the rule: in Polish, to form the plural, you must use the nominative case with a numeral ending in 2, 3, or 4 and the genitive case otherwise.
You say two beers and five of beers. That's why they sell t-shirts that say "I speak Polish, what's your superpower?"
I've been lucky I learned Latin in high school. As soon as I heard nominative and genitive, I felt at home and could apply the Polish rule without a sweat.
In other words, Latin informed my Polish. Also, I'm sure, it would work the other way around should I wish to pick up some dusty books from Rome.
This week's article is all about that. From Ruby, to Haskell, and back to Ruby:
How would I do it in Haskell? — Here's a couple of examples where I contaminated Ruby with functional intuitions.
Making Impossible States Impossible by Richard Feldman
Among the most time-consuming bugs to track down are the ones where we look at our application state and say "this shouldn’t be possible."
We can use Elm’s compiler to rule out many of these bugs in the first place—but only if we design our Models using the right techniques! This talk explores how.
(Riccardo: This is a classic, so probably you've already watched it. But it introduces zippers, which is used in the next article. Plus, Richard is always a pleasure to watch. And he has a great name too!)
JSON Parsing from Scratch in Haskell: Error Reporting by Abhinav Sarkar
In the previous post we wrote a simple but correct JSON parser in Haskell. The parser was written very naively: if it failed, it returned nothing. You couldn’t tell what the failure was or where it happened. That’s OK for a toy parser but error reporting is an absolute must requirement for all good parsers. So in this post and next post, we’ll add simple but useful error reporting capability to our JSON parser.
(Riccardo: This is a dense one, but there are a ton of goodies: zippers, backtracking, predictive parsing with lookaheads, and more.)
Refactoring Recursion by Harold Carr
Recursion is the fundamental looping mechanism in functional programming. This talk shows patterns of recursion using Haskell. It shows those patterns for list structure only. This makes it easier for beginners to understand recursion schemes by focusing on their operation with lists. We start by writing explicit recursive versions of sum, product, and length of lists, then factor them into fold functions. We proceed in a similar manner with other folds, unfolds, and refolds with many examples of the patterns in operation. We end by mentioning factoring recursion out of data.
(Riccardo: From the comments sections: "Most accessible talk about recursion schemes that I have encountered so far. Thank you." I agree, but I suspect it's going to take me a long time to get to the bottom of it.)
Have you ever used the how would I do it in ___? trick to inform your decisions? Maybe to contaminate object-oriented code with functional tricks? Or the other way around?
I'd be super curious to know! Please, hit reply and drop me a line!