[mrkeen]

Think of it like other features:

* Encapsulation? What's the point of having it if's perfectly sealed off from the world? Just dead-code eliminate it.

* Private? It's not really private if I can Get() to it. I want access to that variable, so why hide it from myself? Private adds nothing because I can just choose not to use that variable.

* Const? A constant variable is an oxymoron. All the programs I write change variables. If I want a variable to remain the same, I just wont update it.

Of course I don't believe in any of the framings above, but it's how arguments against FP typically sound.

Anyway, the above features are small potatoes compared to the big hammer that is functional purity: you (and the compiler) will know and agree upon whether the same input will yield the same output.

Where am I using it right now?

I'm doing some record linkage - matching old transactions with new transactions, where some details may have shifted. I say "shifted", but what really happened was that upstream decided to mutate its data in-place. If they'd had an FPer on the team, they would not have mutated shared state, and I wouldn't even need to do this work. But I digress.

Now I'm trying out Dijkstra's algorithm, to most efficiently match pairs of transactions. It's a search algorithm, which tries out different alternatives, so it can never mutate things in-place - mutating inside one alternative will silently break another alternative. I'm in C#, and was pleasantly surprised that ImmutableList etc actually exist. But I wish I didn't have to be so vigilant. I really miss Haskell doing that part of my carefulness for me.

[DeathArrow]

>I'm in C#, and was pleasantly surprised that ImmutableList etc actually exist.

C# has introduced many functional concepts. Records, pattern matching, lambda functions, LINQ.

The only thing I am missing and will come later is discriminated unions.

Of course, F# is more fited for the job if you want a mostly functional workflow.

[mrkeen]

I don't want functional-flavoured programming, I want functional programming.

Back when I was more into pushing Haskell on my team (10+ years ago), I pitched the idea something like:

  You get: the knowledge that your function's output will only depend on its input.

  You pay: you gotta stop using those for-loops and [i]ndexes, and start using maps, folds, filters etc.

Those higher-order functions are a tough sell for programmers who only ever want to do things the way they've always done them.

But 5 years after that, in Java-land everyone was using maps, folds and filters like crazy (Or in C# land, Selects and Wheres and SelectManys etc,) with some half-thought-out bullshit reasoning like "it's functional, so it must good!"

So we paid the price, but didn't get the reward.

[hnra]

Using map, fold etc. is not the hard part of functional programming. The hard part is managing effects (via monads, monad transformers, or effects). Trying to convert a procedural inner mutating algorithm to say Haskell is challenging.

[jcadam]

Never used monads with Clojure (the only Lisp I've done "serious" work in). Haskell introduced them to me, but I've never done anything large with Haskell (no jobs!). Scala, however, has monads via the cats or (more recently) the ZIO library and they work just fine there.

The main problem with Monads is you're almost always the only programmer on a team who even knows what a Monad is.

[mrkeen]

> The hard part is managing effects

You can say that again!

Right now I'm working in C#, so I wished my C# managed effects, but it doesn't. It's all left to the programmer.

[codr7]

I don't know, stacking monads is a comparable level of pain to me.

[tpmoney]

One struggle I’ve had with wrapping my head around using FP and lisp like languages for a “real world” system is handling something like logging. Ideally that’s handled outside of the function that might be doing a data transformation but how do you build a lot message that outputs information about old and new values without contamination of your “pure” transducer?

You could I guess have a “before” step that iterates your data stream and logs all the before values, and then an “after” step that iterates after and logs all the after and get something like:

``` (->> (map log-before data) (map transform-data) (map log-after-data)) ```

But doesn’t that cause you to iterate your data 2x more times than you “need” to and also split your logging into 2x as many statements (and thus 2x as much IO)

[trealira]

So, do you mean like you have some big array, and you want to do something like this? (Below is not a real programming language.)

  for i in 0 to arr.len() {
      new_val = f(arr[i]);
      log("Changing {arr[i]} to {new_val}.\n");
      arr[i] = new_val;
  }

I haven't used Haskell in a long time, but here's a kind of pure way you might do it in that language, which I got after tinkering in the GHCi REPL for a bit. In Haskell, since you want to separate IO from pure logic as much as possible, functions that would do logging return instead a tuple of the log to print at the end, and the pure value. But because that's annoying and would require rewriting a lot of code manipulating tuples, there's a monad called the Writer monad which does it for you, and you extract it at the end with the `runWriter` function, which gives you back the tuple after you're done doing the computation you want to log.

You shouldn't use Text or String as the log type, because using the Writer involves appending a lot of strings, which is really inefficient. You should use a Text Builder, because it's efficient to append Builder types together, and because they become Text at the end, which is the string type you're supposed to use for Unicode text in Haskell.

So, this is it:

  import qualified Data.Text.Lazy as T
  import qualified Data.Text.Lazy.Builder as B
  import qualified Data.Text.Lazy.IO as TIO
  import Control.Monad.Writer
  
  mapWithLog :: (Traversable t, Show a, Show b) => (a -> b) -> t a -> Writer B.Builder (t b)
  mapWithLog f = mapM helper
    where
      helper x = do 
        let x' = f x
        tell (make x <> B.fromString " becomes " <> make x' <> B.fromString ". ")
        pure x'
      make x = B.fromString (show x)

  theActualIOFunction list = do
    let (newList, logBuilder) = runWriter (mapWithLog negate list)
    let log = B.toLazyText logBuilder
    TIO.putStrLn log
    -- do something with the new list...

So "theActualIOFunction [1,2,3]" would print:

  1 becomes -1. 2 becomes -2. 3 becomes -3.

And then it does something with the new list, which has been negated now.

[tpmoney]

Does this imply that the logging doesn't happen until all the items have been processed though? If I'm processing a list of 10M items, I have to store up 10M*${num log statements} messages until the whole thing is done?

[siknad]

Alternatively, the Writer can be replaced with "IO", then the messages would be printed during the processing.

The computation code becomes effectful, but the effects are visible in types and are limited by them, and effects can be implemented both with pure and impure code (e.g. using another effect).

The effect can also be abstract, making the processing code kinda pure.

In a language with unrestricted side effects you can do the same by passing a Writer object to the function. In pure languages the difference is that the object can't be changed observably. So instead its operations return a new one. Conceptually IO is the same with the object being "world", so computation of type "IO Int" is "World -> (World, Int)". Obviously, the actual IO type is opaque to prevent non-linear use of the world (or you can make the world cloneable). In an impure language you can also perform side-effects, it is similar to having a global singleton effect. A pure language doesn't have that, and requires explicit passing.

[trealira]

Yes, it does imply that, except since Haskell is lazy, you'll be holding onto a thunk until the IO function is evaluated, so you won't have a list of 10 million messages in memory up until you're printing, and even then, lists are lazy, too, so you won't ever have all entries of the list in memory at once, either, because list entries are also thunks, and once you're done printing it, you'll throw it away and evaluate a thunk to create the next cons cell in the list, and then you evaluate another thunk to get the item that the next cell points to and print it. Everything is implicitly interleaved.

In the case above, where I constructed a really long string, it depends on the type of string you use. I used lazy Text, which is internally a lazy list of strict chunks of text, so that won't ever have to be in memory all at once to print it, but if I had used the strict version of Text, then it would have just been a really long string that had to be evaluated and loaded into memory all at once before being printed.

[troupo]

Now repeat it for every function where you want to log.

Now repeat this for every location where you want to log something because you're debugging

[trealira]

For debugging purposes, there's Debug.Trace, which does IO and subverts the type system to do so.

But with Haskell, I tend to do less debugging anyway, and more time getting the types right to with; when there's a function that doesn't work but still type checks, I feed it different inputs in GHCi and reread the code until I figure out why, and this is easy because almost all functions are pure and have no side effects and no reliance on global state. This is probably a sign that I don't write enough tests from the start, so I end up doing it like this.

But, I agree that doing things in a pure functional manner like this can make Haskell feel clunkier to program, even as other things feel easier and more graceful. Logging is one of those things where you wonder if the juice is worth the squeeze when it comes to doing everything in a pure functional way. Like I said, I haven't used it in a long time, and it's partly because of stuff like this, and partly because there's usually a language with a better set of libraries for the task.

[BeetleB]

> You get: the knowledge that your function's output will only depend on its input.

> You pay: you gotta stop using those for-loops and [i]ndexes, and start using maps, folds, filters etc.

You're my type of guy. And literally none of my coworkers in the last 10 years were your type of guy. When they read this, they don't look at it in awe, but in horror. For them, functions should be allowed to have side effects, and for loops is a basic thing they don't see good reason to abandon.

[zelphirkalt]

Statistically most of ones coworkers will never have looked at and used to write actual code with a functional language, so it is understandable they don't get it. What makes me sad is the apparent unwillingness to learn such a thing and sticking with "everything must OOP" even in situations where it would be (with a little practice and knowledge in functional languages) simple to make it purely functional and make testing and parallelization trivial.

[BeetleB]

> Statistically most of ones coworkers will never have looked at and used to write actual code with a functional language, so it is understandable they don't get it.

I'm not against functional languages. My point was that if you want to encourage others to try it, those two are not what you want to lead with.

[mrkeen]

But that's the irony of it, they did abandon the for-loops!

Maps and folds and filters are everywhere now. Why? Because 'functional is good!' ... but why is functional good?

[troupo]

> I don't want functional-flavoured programming, I want functional programming.

> you gotta stop using those for-loops and [i]ndexes, and start using maps, folds, filters etc.

You mean what C# literally does everywhere because Enumerable is the premier weapon of choice in the language, and has a huge amount of exactly what you want: https://learn.microsoft.com/en-us/dotnet/api/system.linq.enu...

(well, with the only exception of foreach which is for some odd reason is still a loop).

> But 5 years after that

Since .net 3.5 18 years ago: https://learn.microsoft.com/en-us/dotnet/api/system.linq.enu...

> So we paid the price, but didn't get the reward.

Who is "we", what was the price, and what was the imagined reward?

[mrkeen]

> Who is "we", what was the price, and what was the imagined reward?

Slow down and re-read.

>> You get: the knowledge that your function's output will only depend on its input.

>> You pay: you gotta stop using those for-loops and [i]ndexes, and start using maps, folds, filters etc.

[troupo]

Still makes no sense. Once again: who paid, what was the price, what was the expected reward?

[tmtvl]

Who paid: programmers switching to FP.

What was the price: two things:

- The programmers must stop using for-loops and [i]ndexes.

- The programmers must start using maps/folds/filters/et cetera.

What was the expected reward: the knowledge that their functions' outputs will only depend on their inputs.

In short: programmers who change their behaviour get the benefit of certainty about specific properties of their programs.

[pfdietz]

Those starred rhetorical questions initially looked to me like a critique of Lisp! Because that's how Lisp (particularly Common Lisp) works. All those things are softish. You can see unexported symbols even if you're not supposed to use them. There is no actual privacy unless you do something special like unintern then recreate a symbol.

[bobbylarrybobby]

> you (and the compiler) will know and agree upon whether the same input will yield the same output

What exactly does this mean? Haskell has plenty of non-deterministic functions — everything involving IO, for instance. I know that IO is non-deterministic, but how is that expressed within the language?

[mrkeen]

Functions which use IO are tagged as such in the type system. IO can call non-IO, but not vice-versa.