31–40 of 171 posts
Great I am looking forward to seeing mode code like this: timeslotRepo.findAll().stream().filter(timeslot->timeslot.getEndDate()==null).first().ifPresentOrElse(()->{}, ()->{new Timeslot(DateTime.now())})
Well, that's an ignorant reduction of functional programming but suit yourself.
I'm not sure how I feel about this. If you look at my code in "multi-paradigm" languages like typescript, there's not a heck of a lot of loops, mutations or side effects. I like expressions, and immutability, and higher order functions. They make things shorter and means there's less state for me to keep track of - or screw up. But at the same time, I like objects. Almost all of mine are immutable. I went through a p…
With immutable objects, aren't you just left with syntactic sugar around structs and functions? I'm picturing CLOS, which is undoubtedly an OO system but lacks 100% of what you use objects for. Are there languages which let you use dot-syntax for "methods" which just wrap normal functions?
I'm not sure how I feel about this. If you look at my code in "multi-paradigm" languages like typescript, there's not a heck of a lot of loops, mutations or side effects. I like expressions, and immutability, and higher order functions. They make things shorter and means there's less state for me to keep track of - or screw up. But at the same time, I like objects. Almost all of mine are immutable. I went through a p…
Great I am looking forward to seeing mode code like this: timeslotRepo.findAll().stream().filter(timeslot->timeslot.getEndDate()==null).first().ifPresentOrElse(()->{}, ()->{new Timeslot(DateTime.now())})
Well, that's an ignorant reduction of functional programming but suit yourself.
I'm not sure how I feel about this. If you look at my code in "multi-paradigm" languages like typescript, there's not a heck of a lot of loops, mutations or side effects. I like expressions, and immutability, and higher order functions. They make things shorter and means there's less state for me to keep track of - or screw up. But at the same time, I like objects. Almost all of mine are immutable. I went through a p…
The problem with state in objects is that in more complex systems you often need to change a bunch of related state at one time. When it's all bound up in individual objects that manage their own state this becomes very complicated.
newData = f(oldData)
newObject = oldObject.f()Functional 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…
Pure functions are easy to debug. Run it, check the result against expectations. Step in if necessary.
Earlier quoted context omitted.
Koka-lang and Roc-lang? What are those?
https://koka-lang.github.io/koka/doc/index.html https://www.roc-lang.org/ Both working on making functional programming practical and very fast. Koka is more of a research language, also developing Algebraic Effects and making them practical, which is very cool.
Great I am looking forward to seeing mode code like this: timeslotRepo.findAll().stream().filter(timeslot->timeslot.getEndDate()==null).first().ifPresentOrElse(()->{}, ()->{new Timeslot(DateTime.now())})
So you're filtering specifically for timeslots where the end date is null and therefore guaranteeing that you return a timeslot dated to now?
if timeslots.stream().matchNone(Timeslot::hasntEnded) {
new Timeslot()
}
People are quick to act insulted whenever I give some critical remarks about FP.
When would you use a forEach function instead of a for each statement, I suggest maybe only use the function if the callback is actually a higher order function you get from somewhere else as I don't see the point of wrapping your logic in a closure.
Same thing with the use of observables/reactivity in UI programming, again it is illegal to question this orthodoxy. But then you take a look at how graphics programmers use immediate mode programming and fancy compute shaders to draw the entire frame every frame it makes me smile at how much simpler everything becomes.
Earlier quoted context omitted.
The problem with state in objects is that in more complex systems you often need to change a bunch of related state at one time. When it's all bound up in individual objects that manage their own state this becomes very complicated.
Sorry, I don't get what how that's harder. newData = f(oldData) VS newObject = oldObject.f()
newObject = oldObject.f().g().h().i().j().k()
newData = k(j(i(h(g(f(oldData))))))Functional 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…
a = [1, 2, 3]
b = a.append(4) // append: list->int->list
// Rest of the code never refers to a, but refers to b