Definitely agree that mainstream languages are adopting functional features, but records aren't a functional feature.

Records are basic data modeling and something that has been around since the beginning of programming languages, whether procedural or functional. It's one of the bare minimums of having a type system, and Java didn't have this due to the misguided belief that "everything is an object". I think records being added is more of a symptom of that belief weakening.

There are functional features that have made it over to Java which are the things related to functions, i.e. lambdas and such which are a welcome addition.

Java records are object-oriented construct

Maybe. It depends what the definition of "object-oriented" is, which depends what the definition of "object" is. Neither of which has any semblance of agreement among programmers.

Many people would define an object as something that has externally visible behavior and internally hidden _data_. Objects could never be compared to each other for equality, because one could not access the internal data, only its public behavior. However, Java records can be compared for equality which objects would not.

Java records also cannot be extended from. Inheritance is the only uniquely OOP feature, which doesn't apply here either.

So I'm not sure that Java records are an object-oriented construct. First, the precise definition of OO should be established, and then we'll see

OOP is about bundling state and behaviour into units that hide their internal mechanisms by some kind of interface.

Records can have no state - compared to regular classes - so they are an anti-OOP feature.

I would say OOP revolves around the concept of modeling real-world entities or concepts as objects in code. Records encapsulate data fields within an object, providing a way to model real-world entities.

Very few classes model a real world entity in my experience. Maybe that was the plan but it’s just not the reality of OOP in the industry.

Yeah this is why I always chuckle when people claim that OOP "models the real world".

Oh, because your "FooWidgetController", "FooWidgetService", "FooWidgetRepository" are all real world things?

> I would say OOP revolves around the concept of modeling real-world entities or concepts as objects in code.

This is just data modeling, has nothing to do with OOP.

Records existed before and influenced OOP, and they exist outside of OOP today, in imperative and pure functional languages: https://en.wikipedia.org/wiki/Record_%28computer_science%29

Summary by Wikipedia is pretty good:

>Object-oriented programming (OOP) is a programming paradigm based on the concept of objects,[1] which can contain data and code: data in the form of fields (often known as attributes or properties), and code in the form of procedures (often known as methods). In OOP, computer programs are designed by making them out of objects that interact with one another.

But also, from same wikipedia page:

>Attempts to find a consensus definition or theory behind objects have not proven very successful (however, see Abadi & Cardelli, A Theory of Objects[68] for formal definitions of many OOP concepts and constructs), and often diverge widely. For example, some definitions focus on mental activities, and some on program structuring.

https://en.wikipedia.org/wiki/Object-oriented_programming

But I also recommend reading the chapter on objects from "Programming Languages: Application and Interpretation" by Shriram Krishnamurthi. https://www.plai.org/3/2/PLAI%20Version%203.2.2%20electronic...

One sentence summary there is: "Objects — the bundling of data with operations over them — are a generalization of closures."

I'd agree with this and add that pattern matching and functional interfaces are additional examples of tools from the FP toolbox being subsumed into existing programming languages.

Pure functional programming seems tempting. In small projects it can produce beautiful, readable code. In large projects I've only seen it result in messes, and I still haven't decided whether that's due to limitations of functional purity, due to the team (and myself) misusing features that we don't understand, or both.

What mainstream languages have a good suite of FP features though?

If you try to write mostly pure code in Java I’m afraid you’re in for a bad time, despite the (big!) improvements of records and lambdas.

Minimum viable FP starts at OCaml, F#, Scala and Closure, yet none of these are mainstream.

I code in C# and use a ton of LINQ when writing business logic. It's FP-ish enough to avoid logic mistakes. The mediator design pattern, which is kind of bringing another FP paradigm to the OO world, also features heavily.

I think this is the point really, not that mainstream, "general purpose" languages support FP well, but that FP ideas and aspects have been adapted into many of them.

C# LINQ, being a round-about implementation of do-notation, is a pretty advanced FP feature, and beyond most mainstream languages. C# is certainly a step up over Java etc.

However, most developers wouldn’t understand, say, a result monad implemented via LINQ, so you’re still fighting the ecosystem somewhat.

Hold on... Purity and functional programming are different things. Functional programs can be pure but not necessarily.

Functional programming means functions are first class citizens and can be constructed on the fly. Modern python, c++, rust, even java now do this.

Purity is a nice to have (and arguably rusts borrow system enforces a kind of purity).

> Functional programming means functions are first class citizens and can be constructed on the fly.

FP is much more than this one language feature.

Yes, the field of FP is much more, but the core of FP is that. A language doesn't become non-FP simply because it has some imperative abilities, or logic programming builtin, etc.

I’m arguing it’s not FP when you take an OOP language and bolt on lambdas. Lambdas are necessary but not sufficient.

You need expression orientation, immutability by default, persistent collections in the standard library, some way to handle monadic code, etc…

Immutability by default is not a requirement for functional programming (I mean... if it were, Haskell would be obviously not FP since the 'default' entrypoint is very mutable).

Neither are monads. There are entire FP languages without monads for effects (obviously, you can write a monadic interface in them, but it's not part of the idiomatic core). For example, clean uses linear types to control effects and purescript / Idris use a custom effect-system. So no, monads are not a requirement, and even if they are, modern c++ fully supports them, as does rust, javascript, etc. It's very common in javascript to use Array.map() and Array.flat().

> Immutability by default is not a requirement for functional programming (I mean... if it were, Haskell would be obviously not FP since the 'default' entrypoint is very mutable).

I mean the bindings and collections. For example, when you make an array in JS, the default syntax is a mutable list with a mutable binding:

    let xs = [ 1, 2, 3 ]

> Neither are monads. There are entire FP languages without monads for effects (obviously, you can write a monadic interface in them, but it's not part of the idiomatic core).

I should be more precise - there needs to be some way to mange effects. Monads with syntax extensions is simply the most common (Haskell, Scala, F#, Closure macros)

> and even if they are, modern c++ fully supports them, as does rust, javascript, etc. It's very common in javascript to use Array.map() and Array.flat().

JavaScript does not have good monad support. This is why async/await was added as a new language feature. Yeah, I know you can hack together something with generator functions, but it’s hardly idiomatic.

But we’re getting into the weeds here. My point is: I don’t consider a language to support FP when writing functional code in that language leads to lots of friction compared to what is idiomatic.

Have you ever tried FP in Java? It works for some toy thing but then you hit the lack of TCO, or the ridiculously long type names (not inferred) or the pyramid of doom…

Java streams.

java.time

Valhalla even

Hybrid languages are sub-optimal in a lot of ways. One of the joys of functional programming are the guarantees that imperative languages can't offer (primarily immutability).

The moment you have any database or filesystem or remote-service, the hybridization starts anyway.

Sure, technically a single computer's local RAM is being managed with strict guidelines, but that correlates less and less to overall application state and behavior these days.

The promise of FRP was to solve this problem. It makes "state change" a first class object, and organizes your code around it.

The problem is that nobody made an usable FRP system yet. It's not obvious why it's so hard, and everything feels like it should be easy. But everybody just keep failing.

True, but you can isolate side effects.

Knowing that a small collection of functions is not referentially transparent is better than having to deal with any part of the program potentially changing your state.

“Functional style” doesn’t offer the same guarantees, sure, but I wouldn’t underestimate the structural and readability benefits it can offer for certain kinds of tasks.

> Hybrid languages are sub-optimal in a lot of ways.

The real world is messy and stateful.

> e.g. records in Java

Aren't these just C structs?

> You get most of the benefit of FP

FP = Functions. Same output for the same input. No capability to interfere with (or to be interfered with) other functions.

> Aren't these just C structs?

Are C structs guaranteed to be immutable at compile-time?