News for hackers. Stuff that matters.
Re:Case against OOP is understated, not overstated (2020) by momentoftop on Friday February 11, 2022 @01:10AM (#30297672)
Here's a pure computation:

    import Data.List (nubBy)

    refuteGoldbach :: Integer
    refuteGoldbach = head $ [ n
                            | n <- [4,6..]
                            , not $ n `elem` [ p1 + p2 | p1 <- primesTo n, p2 <- primesTo n ]
                            ]
      where primesTo n = takeWhile (< n) $ nubBy isMultiple [2..]
            isMultiple m n = n `rem` m == 0
If you think you already know the answer to this computation, get yourself a Field's medal.

And then there are pure functions. Every time you compute a function using an input no-one has tried before, you are probably computing something that is not already known. You do this routinely even with a calculator.

Re:Case against OOP is understated, not overstated (2020) by Scarblac on Friday February 11, 2022 @02:19AM (#30298102)
And if you don't store the answer in some kind of state, it's lost and computing the pure function was useless.
Re:Case against OOP is understated, not overstated (2020) by HelloNurse on Friday February 11, 2022 @05:17AM (#30299593)
In typical functional languages state is managed so that it doesn't hurt, not completely absent.

For example, a REPL keeps state in the messages it prints to the terminal and this state isn't visible in the pure function definitions and expression the program is concerned with.

Re:Case against OOP is understated, not overstated (2020) by Life_exe on Friday February 11, 2022 @02:51PM (#30306209)
You don't have to throw away the result. That's what the State Monads are for. Immutable State is Ok. Memoization is Ok.
Re:Case against OOP is understated, not overstated (2020) by linspace on Friday February 11, 2022 @03:29AM (#30298704)
> get yourself a Field's medal.

Unfortunately I'm over 40, otherwise I would try