IMHO Scala did more for practical FP than any other PL except for maybe JS as it is basically bastardized Lisp.
I think Erlang did more for practical fp than scala.
Functional programming is finally going mainstream
71–80 of 171 posts
Re: Functional programming is finally going mainstream
#72Re: Functional programming is finally going mainstream
#73My experiences with the encroachment of FP into otherwise imperative or OO languages has mostly been: 1. Write a bunch of functional code. 2. Marvel at how clean and neat things are. 3. Get customer reports of performance problems. 4. Spend a lot of time ripping out FP components and replacing them with imperative code.
What languages? Did you performance profile before to see what was slow?
Re: Functional programming is finally going mainstream
#74Great I am looking forward to seeing mode code like this: timeslotRepo.findAll().stream().filter(timeslot->timeslot.getEndDate()==null).first().ifPresentOrElse(()->{}, ()->{new Timeslot(DateTime.now())})
I'm generally a proponent of OO, and I actually think this kind of filtering chain is one of a number of places where fp code can be more readable than imperative loops.
It's also, more or less, the "fluent interface" style if laid out differently, other than the lambdas (but even those are in both C# and Java):
timeslotRepo.findAll()
.stream()
.filter(timeslot->timeslot.getEndDate()==null)
.first()
.ifPresentOrElse(()->{}, ()->{new Timeslot(DateTime.now())})
Re: Functional programming is finally going mainstream
#75My experiences with the encroachment of FP into otherwise imperative or OO languages has mostly been: 1. Write a bunch of functional code. 2. Marvel at how clean and neat things are. 3. Get customer reports of performance problems. 4. Spend a lot of time ripping out FP components and replacing them with imperative code.
I've ran into this before, but to be fair I was using Monad Transformers.
Re: Functional programming is finally going mainstream
#76My experiences with the encroachment of FP into otherwise imperative or OO languages has mostly been: 1. Write a bunch of functional code. 2. Marvel at how clean and neat things are. 3. Get customer reports of performance problems. 4. Spend a lot of time ripping out FP components and replacing them with imperative code.
That's the common theme even when using clojure too.
Re: Functional programming is finally going mainstream
#77off topic: what is github/readme? medium by github?
Re: Functional programming is finally going mainstream
#78Functional programming with immutable state cannot possibly win in the general case. There are two truths that ensure the dominance of imperative software: 1. At some level of software complexity, programmers MUST start to organize data into composite objects. They have to do this because working outside of well-defined problem domains is a recipe for buggy software and spaghetti code. 2. Copying memory around to ena…
The biggest problem I have with functional programming is debugging. On imperative code, execution is easy to follow. Instructions go one after the others, loops loop, function calls and local variables go on the stack, globals are always visible. Optimization aside, what you code is what the computer runs. You often have a debugger to step through your code, or some logging facilities, even if it is just a printf. O…
> On imperative code, execution is easy to follow. Instructions go one after the others, loops loop, function calls and local variables go on the stack, globals are always visible. Optimization aside, what you code is what the computer runs. You often have a debugger to step through your code, or some logging facilities, even if it is just a printf.
I think you're doing something wrong.
Because your experience should be exactly the opposite. Imperative programming by distributing its state can only really be understood in context. You need to understand that instruction one after another, just like you said. You need to understand globals and the overall state.
In functional programming you understand code without context. Everything is local. There's nothing to trace.
> Then you let the compiler do its magic, it is actually really good at that and not slow. But then you end up with something that doesn't look at all like what your wrote (computers are imperative), and if, in the end, the result is wrong, good luck finding where
What does the compiler have to do with anything here?
You can print out whatever state you want, your debugger can provide you with whatever local state you want. There's nothing obscure or mysterious about functional code compared to imperative code. It's just a matter of not distributing your state widely.
Re: Functional programming is finally going mainstream
#79My experiences with the encroachment of FP into otherwise imperative or OO languages has mostly been: 1. Write a bunch of functional code. 2. Marvel at how clean and neat things are. 3. Get customer reports of performance problems. 4. Spend a lot of time ripping out FP components and replacing them with imperative code.
What languages? Did you performance profile before to see what was slow?
C++, Python, Kotlin, some others I can't remember anymore.
The most common issue is hidden O(n) situations, which don't show up except in production. So what we end up with is a mix of various paradigms worthy of Dr Frankenstein, and a debugging nightmare.
I've been in engineering long enough to see most trends repeat at least twice (Javascript UIs are ALMOST back to the point of the 90s for example). After awhile you learn to distrust anyone who evangelizses a "new" way that was actually invented in the 60s (and is likely being introduced as a panacea instead of with the original caveats).
Now that I'm a greybeard myself, I finally understand why greybeards were always so grumpy.
Re: Functional programming is finally going mainstream
#80Earlier quoted context omitted.
Furthermore, it chains nicely and offers pleasant autocompletion in your IDE: newObject = oldObject.f().g().h().i().j().k() VS newData = k(j(i(h(g(f(oldData))))))
Just to steel man the "Functions and Data" side of the equation in a lot of FP languages that'd be something like newData = oldData |> f |> g |> h |> i |> j |> k
And to straw man the OO way a little...
newData = oldData.f().g().h().i().j().k()
wont work by default unless you also happen to return the object after every method (builder style) which looks weird and is not standard