IMHO Scala did more for practical FP than any other PL except for maybe JS as it is basically bastardized Lisp.
Functional programming is finally going mainstream
61–70 of 171 posts
Re: Functional programming is finally going mainstream
#62Functional 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…
Others already argued against your point, but I want to point out that (2) is simply wrong. You can have mutability in functional programming -- not in general, but there are cases where this can be expressed. For example, in a very simple example: a = [1, 2, 3] b = a.append(4) // append: list->int->list // Rest of the code never refers to a, but refers to b In this code, you can prove that it's safe to move a's memo…
Right, but FP has been around for quite some time, and given that none of the current implementations actually solve this issue right now I think it is a valid critique of FP because it's simple what current FP implementations are limited to.
Maybe a "sufficiently advanced compiler" in the future will solve this, but it's not at all clear such a thing can be created in a way that's practical right now.
Re: Functional programming is finally going mainstream
#63Earlier quoted context omitted.
Well, that's an ignorant reduction of functional programming but suit yourself.
Yes, it’s far too readable to be actual functional programming.
I only write code in an FP language and it never looks like that. Usually I’m passing function results into another function or into a match to break out success and failure states. It doesn’t have to be Haskell wizardry, or even clever.
Re: Functional programming is finally going mainstream
#64I'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?
Dynamic dispatch is really what differentiates OO from just being syntactic sugar around structures and functions.
Re: Functional programming is finally going mainstream
#65IMHO Scala did more for practical FP than any other PL except for maybe JS as it is basically bastardized Lisp.
I do not think it is reasonable to call JS a Functional programming language.
Re: Functional programming is finally going mainstream
#66Re: Functional programming is finally going mainstream
#67Earlier quoted context omitted.
Others already argued against your point, but I want to point out that (2) is simply wrong. You can have mutability in functional programming -- not in general, but there are cases where this can be expressed. For example, in a very simple example: a = [1, 2, 3] b = a.append(4) // append: list->int->list // Rest of the code never refers to a, but refers to b In this code, you can prove that it's safe to move a's memo…
Right, but FP has been around for quite some time, and given that none of the current implementations actually solve this issue right now I think it is a valid critique of FP because it's simple what current FP implementations are limited to. Maybe a "sufficiently advanced compiler" in the future will solve this, but it's not at all clear such a thing can be created in a way that's practical right now.
> ...and given that none of the current implementations actually solve this issue right now...
This has been possible in Haskell for a long, long time. A ton of languages do something very similar with strings (Python, JavaScript, etc.) Strings are immutable in both Python and JavaScript, but rather than using a "StringBuilder" class like in C# or Java, the compiler and runtime will optimize certain pure functional operations (like string concatenation) into a mutable operation on a buffer. If you are not aware of this optimization, you might find yourself benchmarking some simple string operations and be completely shocked at how fast they are. (There are a couple questions on Stack Overflow where people are confused about why their Python code is faster than their C++ code when benchmarked.)
I think the term "sufficiently advanced compiler" does a bit of a disservice. People have used that phrase a lot, not only when talking about high-level languages but also when talking about things like ISAs. It turns out that people are bad at predicting what kinds of optimizations compilers will be able to do in the future.
The other reason I don't like the phrase "sufficiently advanced compiler" is because these optimizations are often tied to something other than the compiler. They may come from advances in library implementations, advances in programming languages, or advances in language runtimes.
Take a look at how Haskell does it. You have array implementations with a pure interface but impure implementation. You have a system called "stream fusion" which lets the compiler take array operations that logically produce arrays as values, and transform these into simple operations that loop over the array. Stream fusion is a feature that doesn't really require a "sufficiently advanced compiler", but rather some relatively simple compiler features (all things considered, "simple" is relative) and the ability to annotate library functions with transformations that improve the generated code at the library functions' call sites.
I think of stream fusion as more of a "let's write good libraries" feature, and less of a "compiler magic" feature.
Then take a look at how Python does it. When you concatenate strings, the library code can check that the left-hand argument has no other references, and modify it in-place. All the compiler has to do is make sure that variables are killed as soon as possible, which is a very ordinary thing for compilers to do. It's not magic, there are ways to break this optimization from happening, but it does work.
Re: Functional programming is finally going mainstream
#68My 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.
Re: Functional programming is finally going mainstream
#69Great 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.
Re: Functional programming is finally going mainstream
#70Functional 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…
> At some level of software complexity, programmers MUST start to organize data into composite objects. I don't understand this point. All functional programming languages have algebraic data types and records, which are composite types. If this is not a "composite object", you'll have to clarify what you mean. > Copying memory around to enable to facilitate these immutable structures is SLOW. Slower than what and in…
> I don't understand this point. All functional programming languages have algebraic data types and records, which are composite types. If this is not a "composite object", you'll have to clarify what you mean.
I think they meant data structures, not data types. Things like lists of records that each contain further records.