The very same test, written in Haskell, wouldn’t compile!
That’s because the author used shouldBe, which (as they noted) is pure. If they wanted to do the same thing as the Python version, they could have used shouldReturn.
How is his conclusion not a point for Python as well? Because you can do it impurely in Python as well as purely? I’m not particularly impressed by this.
His point is that Haskell forced him to think about separation of concerns. With Python it was easy for him to mix them together.
In a sense, yet his case is so trivial he could risk invoking Zalgo and use grep for the correct result.
Python alls gets the job done, when purity isn’t always the main concern.
Which does not exclude writing more pure code in Python or refactoring hacks to higher quality if need be.
I’m not sure where this reply fits into the topic of how Haskell forced them to think about separating concerns, where Python doesn’t.
In inane examples like this in the real world the better programmer delivers and may not care about separation of concerns. At the risk of sounding like someone like Zed Shaw.
If a Python hack grows, requires proper tests, anything, the coder will learn about separation of concerns. That’s what’s required in the long run, right? Even if it wasn’t the language enforcing.
A lot of issues that pop around these topics are non-issues in practical life, and I’d be very surprised if this article series ends up giving Python a single point. But I’d expect there to be mainly ties and maybe an occasional contestable point for Haskell, like in this case, where the better programmer would have delivered already but with less prowess in purity.
If a Python hack grows, requires proper tests, anything, the coder will learn about separation of concerns. That’s what’s required in the long run, right?
This is a very hand-wavy argument. Just because separation of concerns (SoC) is the “right way” doesn’t mean that a competent programmer will discover it given enough time. And even if they do discover SoC, humans are fallible and they will forget to do it properly at times.
Haskell just automates this whole process for you.
Learning new languages is, of course, a fine thing, but something disturbs me here.
This example is just too simple and/or whatever. Maybe there’s deeper stuff coming, but so far learning a new language is an overkill solution.
The concepts aren’t unique to Haskell or whatever, either. A coder who cares can learn about practices separately from another language. Learn about how things are done in other languages and see how they apply.
Maybe it’s just this example that feels completely silly to me.
Am a bit underwhelmed by this article, as a long time Python programmer I’ve been eyeing Haskell for years but never invested the time to try for real. I would love to see an article from someone who made the jump, like Brian O'Sullivan.
Here you go: https://lobste.rs/s/lto5en/becoming_productive_haskell
Stephen Diehl has a pretty comprehensive list of useful things to know:
not haskell, but you should enjoy the posts about 0install’s migration from python to ocaml