[HN Gopher] FizzBuzz in Haskell [pdf]
       ___________________________________________________________________
        
       FizzBuzz in Haskell [pdf]
        
       Author : revskill
       Score  : 25 points
       Date   : 2022-11-21 21:04 UTC (1 hours ago)
        
 (HTM) web link (themonadreader.files.wordpress.com)
 (TXT) w3m dump (themonadreader.files.wordpress.com)
        
       | yakubin wrote:
       | See also the fastest FizzBuzz written in x86-64+AVX2 Assemby,
       | running at 45GiB/s:
       | 
       | <https://codegolf.stackexchange.com/questions/215216/high-thr...>
       | 
       | <https://github.com/orent/htfizzbuzz/blob/master/fizzbuzz.S>
        
         | metadat wrote:
         | Discussed one year ago:
         | 
         | https://news.ycombinator.com/item?id=29031488
         | 
         | (1260 points, 256 comments)
         | 
         | p.s. It's actually 55GB/s :)
        
       | adamjc wrote:
       | 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/
        
         | cmeacham98 wrote:
         | This 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
        
           | kasajian wrote:
           | plus you don't even need the first line.
        
           | antonvs wrote:
           | The 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.
        
           | spacemadness wrote:
           | This looks very clear and straightforward even knowing
           | nothing about Haskell syntax.
        
         | rebeccaskinner wrote:
         | You'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 wrote:
           | I 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 wrote:
             | Case in point: it can prompt people to gush about a
             | fizzbuzz implementation.
        
         | Waterluvian wrote:
         | https://stackoverflow.com/a/6957469
         | 
         | This seems very elegant and clean and I don't know the
         | slightest bit of Haskell other than "MONADS!!!"
        
       | dottedmag wrote:
       | Ugh. There are languages that encourage this kind of time
       | wasting. Avoid them. Also,
       | 
       | > Exhibit A, in some cases, performs the 'mod' 3 and 'mod' 5
       | tests more than once
       | 
       | Isn't Haskell a language with controlled side-effects? Compiler
       | ought to see that the same operation is performed twice and
       | factor it out. There are no mutable variables in the scope.
        
       ___________________________________________________________________
       (page generated 2022-11-21 23:00 UTC)