5 ms·
This page made me permanently write off Haskell: https://wiki.haskell.org/Prime_numbers https://wiki.haskell.org/Prime_numbers It is so much work, so much eff
by Areading314 7y ago
This page made me permanently write off Haskell:
https://wiki.haskell.org/Prime_numbers https://wiki.haskell.org/Prime_numbers
It is so much work, so much effort to develop some very mediocre, very slow, and incomprehensible implementations of an undergraduate level algorithm. I ended up picking CL for the project I was working on (Project Euler) and never looked back.
- yingw787 7y agoYou are of course entitled to your own opinion, but I would say that’s unfairly harsh towards Haskell. GHC Haskell not only compiles down to a binary, it can also transpile to C—-, both of which can run performantly. I started off FP with lodash, then moved to Python and built in functions, and I’ve tasted the benefits of applying functional programming in production, and so that’s what makes learning Haskell interesting and worthwhile to me. I’m looking forward to bringing what I’ve learned from Haskell towards the rest of the code I write, even if it’s not in Haskell.
- Areading314 7y agoI write Python for a living, and it is an astoundingly productive language. What it gets right is the compromise between functional, object-oriented, and imperative styles. I too have been fascinated by the "pure functional" type languages, but they always fall short when it comes to "real world" projects.
- yingw787 7y agoI think it’s definitely hard for practitioners to adjust to FP, especially when under the pressure to ship. I think a great opportunity to look for ways to apply FP would be in small utilities or libraries. I’m planning my next project in Python but if I’m fortunate to ship that I’ll see if I can circle back to Haskell and go from beginner to intermediate by building a small library.
- Areading314 7y agoIf you're interested in FP, I highly recommend checking out Let Over Lambda. It made me realize that there is actually lot in common between OO and FP. https://letoverlambda.com/ https://letoverlambda.com/
- hopia 7y agoWeirdly, I never found functional programming Python anyhow enjoyable. It just doesn't seem to have enough facilities to support it, feels like a sort of anti-pattern on it.
- TylerE 7y agoYou'd probably like ML (especially Ocaml) then. It can do all the crazy FP drugs (including lazy evaluation), but it's also painless to write normal imperative code in. Syntax is a hair grotty though.
- pdexter 7y agoC-- is one of the stages of its compilation to a binary IIRC. I wouldn't say it "can transpile to C--", as if C-- is an optional target which the user then does something else with.
- bjoli 7y agoYou can implement the regular sieve of erathostenes using mutable unboxed vectors if you like. If you did not spend enough time in Haskell to realize that you are in no position to judge it. On the other hand, I would have used CL as well...
- whateveracct 7y ago> If you did not spend enough time in Haskell to realize that you are in no position to judge it. Sadly this will never stop anyone from doing it anyway. I had a VPE (didn't know Haskell) who tried to read some of the team's Haskell and couldn't grok it despite his many years of software experience. His response? Spout that "people are saying the Haskell codebase is hard to understand" without any indication that he was in fact "people."
- Areading314 7y ago"mutable unboxed vectors"? You mean like a C array? How primitive and horrifying!
- whateveracct 7y agoOne fun thing people don't know about Haskell is it lets you get as low-level as C (modulo still having an RTS.) Manually memory management, pointer arithmetic.. it's all there in the standard library!
- bjoli 7y ago... and fast!
- oisdk 7y agoWhat's developed on that page is not a simple sieve of Eratosthenes. You can of course write a simple prime sieve in Haskell like you would write in any imperative language, and it would be pretty much just as efficient. The algorithms on that page are for incremental prime sieves. These are far more difficult to implement than a fixed-size sieve. What's more, I would argue that the Haskell implementations on that page are far shorter and easier to understand than the imperative counterparts. Take this version, for example: joinT ((x:xs):t) = x : union xs (joinT (pairs t)) where pairs (xs:ys:t) = union xs ys : pairs t gaps k s@(x:xs) | k < x = k:gaps (k+2) s | otherwise = gaps (k+2) xs primes = 2 : _Y ((3:) . gaps 5 . joinT . map (\p-> [p*p, p*p+2*p..])) Compare those 5 lines to any of the algorithms found in: Pritchard, Paul. ‘Improved Incremental Prime Number Sieves’. In Algorithmic Number Theory, edited by Leonard M. Adleman and Ming-Deh Huang, 280–88. Lecture Notes in Computer Science. Berlin, Heidelberg: Springer, 1994. https://doi.org/10.1007/3-540-58691-1_67 https://doi.org/10.1007/3-540-58691-1_67. Sorenson, Jonathan P. ‘Two Compact Incremental Prime Sieves’. LMS Journal of Computation and Mathematics 18, no. 1 (2015): 675–83. https://doi.org/10.1112/S1461157015000194 https://doi.org/10.1112/S1461157015000194.