5 ms·
I know this is a "toy" paper, but is enough to reason as to why few use Haskell in production (ignoring the tooling issue). It's pretty gnarly even for a basic
by adamjc 4y ago
I know this is a "toy" paper, but is enough to reason as to why few use Haskell in production (ignoring the tooling issue). It's pretty gnarly even for a basic problem.
> Functional programmers! Remember higher-order functions!
I didn't realise utilising HoF meant rolling your own interpreter ;).
Pure FP is very interesting, but having to write entirely without side-effects would be a real challenge for me. I use js+ramda[0], we effectively write our services as a `pipe`, you just stick in transforming fns whereever you need to, e.g.:
const handler = pipe(
fn1,
fn2,
fn3
)(event)
The underlying implementation of `fn1` for example doesn't need to be written in an fp paradigm, it can be written imperatively. You could then slowly-slowly chop out the imperative functions for fp ones if you really wanted, but IMHO some problems are best solved imperatively.
My advice is instead: "Programmers! Remember to use the right tool for the job!"
[0] https://ramdajs.com/docs/ https://ramdajs.com/docs/
- cmeacham98 4y agoThis paper takes a deliberately weird solution to the problem. FizzBuzz can be done more "normally" in Haskell with similar levels of simplicity as non-FP languages: https://wiki.haskell.org/Fizzbuzz https://wiki.haskell.org/Fizzbuzz
- spacemadness 4y agoThis looks very clear and straightforward even knowing nothing about Haskell syntax.
- jrumbut 4y agoI found this to be well above average as an intro to Haskell.
- kasajian 4y agoplus you don't even need the first line.
- antonvs 4y agoThe paper even gives three normal examples early on, including one similar to the one in your link. People who miss that are clearly looking hard for some reason to dismiss the work.
- frozenlettuce 4y agoThat is the FP version of the classic https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... . One can overengineer stuff in both FP and OOP.
- rebeccaskinner 4y agoYou're looking at this the wrong way. The paper isn't showing Haskell is gnarly for a basic problem, it's using a basic problem to demonstrate a particular technique that you can use in Haskell. There are plenty of simpler ways to implement this kind of thing in Haskell, and even some that are both simpler and show off some of the more unique features of Haskell. The goal here wasn't "let's find the best way to write fizzbuzz in Haskell", it was "let's show off how to build an interpreter to solve problems, using a small problem everyone is familiar with". Haskell isn't ill-suited for something like fizzbuzz at all, it's just _also_ suited for things like quickly writing interpreters and solving problems that way when it makes sense.
- whateveracct 4y agoI find a lot of people don't get pedagogy. They want immediate, authoritative statements on what is good or bad. Haskell isn't really about that. It's about the 10s of equivalent ways to solve every simple problem. That's what makes it fun. And fun is Haskell's secret sauce.
- nearmuse 4y agoCase in point: it can prompt people to gush about a fizzbuzz implementation.
- wernercd 4y ago"10s of equivalent ways to solve every simple problem." Why doesn't C#, Java, etc have the same problem with perception because they have the same "many ways" to solve problems. "fun" brainfuck is fun too and no one uses it.
- epgui 4y agoBecause C#, Java, etc are more familiar to most people. People tend to struggle with unfamiliar things. Haskell is simple even if unfamiliar to you. Brainfuck is complex even if familiar to you.
- Waterluvian 4y agohttps://stackoverflow.com/a/6957469 https://stackoverflow.com/a/6957469 This seems very elegant and clean and I don’t know the slightest bit of Haskell other than “MONADS!!!”
- thedataangel 4y agoThe one you linked is close to how you'd write this in idiomatic Haskell. The paper is describing a particular technique, and using FizzBuzz as an example problem, not suggesting that the technique is a good way to solve FizzBuzz.
- throwaway81523 4y agoI don't like that solution very much because of the 4 cases, or generally n*2 cases if there are n tokens. My favorite Haskell solution uses monoids (specificaly the Monoid instance of Maybe String) and is quite natural in Haskell but would take some explanation for non-Haskellers. My version looks like the below. I didn't originate the approach but I like this spelling. It won't make total sense to non-Haskellers though. {-# LANGUAGE MonadComprehensions #-} import Data.Maybe import Data.Monoid fizz :: Int -> String fizz n = fromMaybe (show n) $ f 3 "Fizz" <> f 5 "Buzz" where f :: Int -> String -> Maybe String f d msg = [msg | n`rem`d == 0] main = mapM_ putStrLn [fizz n | n <- [1..100]] This extends in an obvious way to FizzBuzzHissHowl, lets the Monoid instance manage concatenating the special tokens together while remembering if any of the rules have matched, and uses a monad comprehension on the Maybe monad to cleanly lift the token into the Maybe monad if the number is a multiple of whatever. The type annotation on f is added to make it a little bit clearer what is going on. The use of monoids and the monad comprehension may be slightly flashy, but the use of Maybe to remember whether a rule has triggered is second nature in Haskell.
- turboponyy 4y agoThis is not too dissimilar to the final solution outlined in the essay, but is much more readable, in my opinion, due to its use of mappend over Maybe Strings instead of implementing the same sort of compositionality using regular function composition. Very elegant!