This kind of sweeping unsupported assertion is actively harmful for FP evangelists. Anyone who isn't already a fanboy is most likely going to read that and say “clearly this person has no idea what they're talking about. [close tab]”.

If you want to make a productive form of this argument it'd be better to focus on discussing why the mathematical abstractions are so much better with comparisons to their actual recommended OOP counterparts. The points you mentioned about things like side effects or immutability are good but you need to not give someone a reason to go away before getting there, especially since there are going to be common tasks like I/O which are _not_ going to look like an improvement for anyone who isn't already on-board.

That seems as much an unsupported assertion (i.e. opinion) as what I wrote.

I don't think it's useful to try to write a comprehensive essay with no ambiguity every time I comment, and I don't have the time. Doesn't mean I don't believe the things I say. :)

If you decide to close the tab because I said functional programming languages are much better at abstraction, that's too bad, but it's not exactly an unsupported assertion--and I'm not trying to sell you anything anyway.

If it helps, most of my FOSS stuff is written in Go, a language Haskell fans generally vehemently dislike for "ignoring 30 years of PL research." I actually like Go for a similar reason I like FP: It does away with a lot of the bad abstraction (classes) and emphasizes the good (interfaces.)

FP is not that pervasive and anyone trying to make the case that it's better across the board has to address that familiarity gap. Try to think about, say, the average Java or C# developer working on a large project. They aren't spending their day saying “OOP is terrible” and when you say something is better because it's “grounded in mathematical practice” that's really non-obvious to someone who's thinking the main way their life would improve would be if they could get the business stakeholder to make a decision and stick with it for more than 24 hours, stop using Oracle products, etc. Talking about avoiding shared state and side-effects, going beyond Java-level typing to make refactoring safer, etc. is a lot more useful since those probably are things they spend time on regularly.

I was an imperative programmer for a decade before I looked at functional languages, and it was because of glowing but unfamiliar praise that I looked deeply in the first place. Now I know that a lot of that praise was warranted. Everyone's different!

Also, as I noted in another comment, the "elementary school" comment was not meant to imply that it's simple--alas, one of my main gripes with OOP is that it isn't simple in the ways it needs to be--just that it's something you're almost certainly exposed to early on, so it quickly becomes what's familiar.

We weren't really taught classes in my high school course, so everything we did was entirely imperitive. I came across a problem where I had about 20 different entities in a game who all had a special way of updating during each tick, but I didn't want to have to write a switch statement for each one. I looked up "How to have an array of functions", and without knowing it at the time I was trying to implement first-class functions in this language which it just so happened to have.

From there it's easy to see how once you understand the concept of first class functions, many FP concepts start to fall in line, and by the way the language was set up it was difficult to use side-effects in this language, generally you use a function to output to the screen or to return a new resulting value. In fact when it finally came around to learning about classes, I had a very difficult time understanding how they worked or what purpose they served, made my Java classes in University difficult for some time.

I'm not sure what point I'm making here, I just thought how it was neat looking back that my first language I learned I naturally branched into more FP-oriented programming.

Because they allow you to compose higher level entities?

(Incidentally, one would generally compose objects).

"When programming a component, the right computation model for the component is the least expressive model that results in a natural program." -- Concepts Techniques and Models of Computer Programming

So when a less expressive model (such as FP) is sufficient for a "natural" program, definitely use that. And of course that has been the general recommendation. Switch to a more expressive model once this is no longer the case. In my experience, FP tends to be good for "computation", at least if performance isn't a primary concern. However, most of what "computers" (badly named) do today isn't computation, and modeling communication and storage over time tend to get awkward (though obviously possible).

That isn't true. FP still uses data records, they're just not tightly coupled to the functionality like OO. Pure functions + immutable types is a more powerful programming paradigm than data and functionality encapsulation via classes and methods.

Also more advanced techniques like combinators can encode more complex and extensible patterns in a significantly more robust way than any OO class hierarchy (see 'parser combinators' for an example).

Lots of parser-combinator libraries in OO languages.

You can express object models in FP so what you are saying is very confusing to me.

Note that they are talking about general models of computation, in particular including at least:

- Declarative sequential model (strict functional programming, deterministic logic programming, dataflow/logic variables, higher-order procedures). Component behavior is independent of rest of program.

- Declarative concurrent model (explicit threads, by-need/lazy computation, data-driven concurrency, demand-driven concurrency). Almost as simple as declarative sequential. Declarative model with exceptions: allows nondeterminism to be visible.

- Message-passing concurrent model (declarative plus ports/communication channels). Allows nondeterminism, and allows nondeterminism to be restricted to particular components.

- Stateful model (declarative model extended with explicit state). Allows components to keep history. Typical of sequential OO programming.

- Shared-state concurrent model (declarative extended with both explicit state and threads). Typical of concurrent OO programming.

- Relational model (declarative extended with search). Search space explored by testing choices until result is satisfactory. Encompasses Prolog-style logic programming.

- Constraint programming and still other models are discussed elsewhere in the book.

http://wiki.c2.com/?PrincipleOfLeastPower

EDIT: Just to be clear, I don't think this is a good idea. It's usually better to pass in one or more data structures and one or more first class functions separately. I'm just saying that it's not too different.

For some kind of projects (video games, applied math, anything else that is sufficiently performance or latency sensitive), data structures are just as important as code. And they need to be composed, too.

For example, in C++ I can put small structures into couple megabyte-sized vectors, because memory controllers love sequential RAM access. Then I put these vectors in another vector, because address space might be fragmented and memory manager might not be able to give me continuous 1GB buffer, also to save CPU time + RAM bandwidth when growing my dataset to gigabytes. Then I wrap these vectors into another container that creates and maintains an index over the whole dataset using a hash map, because besides sequential access, other times I want to lookup my values by some key, and I want the lookups to run fast. And so on.

FP paradigm is just fine for composing functions. AFAIK, FP offers little for composing data structures. And those sophisticated specialized data structures are often the key for writing high-performance code.

While it's worth mentioning that Haskell does allow you to get pretty low level, it nonetheless has a GC, and the code you end up writing often looks more like C than FP. Rust is a great alternative that combines a lot of the raw performance and control over memory of C/C++ and good stuff from FP (e.g. sum types/pattern matching.) (Or even better, use something like Haskell and FFI with Rust for performance-critical parts.)

In C++ I can add hashmap-based index to existing collection of values without duplicating the values, because I can only keep pointers in the map. I can add linked list-based LRU tracking to existing collection of values. I can use pointers to implement graph-based structures. While there’re workarounds in Rust, such as reference counted pointers, raw pointers in C and C++ are just faster.

This is incorrect, Rust has raw pointers. Those reference-counted pointers that you mention are all just standard library types implemented using raw pointers under the hood.

Regardless of how you call them, you still can’t use them to compose data structures into higher-level structures in Rust.

In C++ with raw pointers, I can combine a hashmap with an existing collection of values to speed up lookups, without duplicating values. I can combine hash map with linked list to create an efficient LRU cache, with a few lines of my own code.

C++ can do that because collections, std::unordered_map, std::list and the rest of them, expose raw pointers at their API boundaries. It’s possible to store these pointers in other collections, encapsulating one or more simple data structures into a higher-level specialized data structure, with the performance characteristics suitable for the job.

However, look at the Rust implementation of the LRU cache: https://github.com/contain-rs/linked-hash-map/blob/master/sr...

See how much code is there (more than 1k lines), and note most code is unsafe.

In C++, one would probably use list<pair<K,V>> for storage, together with unordered_map<K, list<pair<K,V>>::iterator> for indexing. And the implementation would be trivial, because there’s no need to re-implement a linked list, you only need to implement these get/set methods that update both collections at the same time.

In Rust however, they had to come up with their own implementation of linked list. The LinkedList from standard library doesn’t expose raw node pointers in the API, therefore it can’t be used for the job.

I think rust safety model prevents rust containers from returning mutable pointers to the contained items. Especially pointers to item's implementation details, like nodes of that linked lists.

And without raw pointers to items, you can’t easily compose containers to make higher-level data structures from them.

(That is, many data structure _do_ do this, and you _can_ do it. It is an oversight.)

The difference is the mindset. FP makes it really easy to compose higher-level functions. But composing higher level functions typically means little control where the intermediate results are stored (which is what Game developers need).

You can absolutely write C++ style in Haskell by composing imperative functions (e.g. IO monad). The only problem I see is the syntax. There is no built-in syntax for indexing and assignment. Writing

    do
        v1 <- readArray a i
        v2 <- readArray a (i+1)
        writeArray a (i+2) (v1+v2+1)

    a[i+2] = a[i] + a[i+1] + 1;

Exactly.

I need my code to access sequential RAM addresses as much as possible, because performance.

And sometimes my RAM layout is fixed, because I’m directly sending large sequential blocks of RAM to GPU (e.g. on Windows, by calling ID3D11Device::CreateBuffer or ID3D11DeviceContext::UpdateSubresource), and GPU can only consume C-array of POD types with very specific alignment and padding requirements.

This does not mean that there is anything wrong with FP or with lazy languages. They're just not the right tool for all purposes. When they're not the right tool, don't use them for that.

Why only do one while you can do both?

Modern languages have first class functions and support class polymorphism and parametricity, which is still a very powerful way to describe problems intuitively.

Theoretically you can do both. Practically, few languages give you the tools you'd want to ensure functional purity.

C++ is a multi-paradigm language, for instance. But it doesn't have any concept of immutable data. The 'const' keyword exists but it only does a very shallow check for immutability (i.e., the pointer won't change but its data might). And even with a 'const', there are still huge backdoors (the 'mutable' keyword).

Point being, it's possible, but you'd be relying on convention in your design and care in your implementation to make it work.

In practice, Java's weaker `final` (immutable references) appears to be a reasonable middle ground.

What did I just read, you're joking right?

Disclaimer: The above is an opinion. Double-blind trials have not been performed!

What I meant was not that it's easy to do something, rather that it's something that often comes early, and is mandatory, in your journey of discovery. The concepts you learn early on, while not easy to fully grasp, stick, and make other paradigms seem alien.

What do you think of the recent rise of 'hybrid' languages like scala?

While I haven't really written anything in Haskell since leaving school, learning Haskell has informed (and in my opinion improved) the way I program in every language more than basically anything else I've done.

Personally, I found that diving directly into the language that represents a paradigm in the "pure" form (for FP I would recommend Haskell) works best for me. It makes it most obvious why things are done certain way.