The reason I prefer functional programming over OOP is that I'm just not smart enough to understand all the OOP abstractions and how to build reliable systems with it. Functional programming is just easier to grasp mentally, as it takes away a lot of the foot-guns (mutable state, inheritance, etc).
• protocol glue (which is OOP/actor modelled)
• business logic (which is best served by being strongly-typed and statically verified.)
I'm a big fan of writing most of your code as libraries and "engines" in a language like Haskell or an ML (or Rust, if your algorithms are best specified on a pointer or RAM-word machine); and then taking those components and hooking them up to the outside world using an actor language like Erlang.
IMHO, this uses each language for its strengths. You've given the argument for why business logic is suited to languages like Haskell, so I'll give the other half:
Languages like Erlang, or Smalltalk, or other "true" OOP languages (i.e. languages where actors control not just their own state, but their own executing code) are good at reacting to arbitrary untyped messages, doing clever things after only partially parsing them, without needing a complete understanding of what they mean. This allows for components like proxies or brokers to react to metadata on RPC requests without needing to constantly be told about the typings of new messages. This also allows rolling upgrades of distributed systems that don't require a preliminary "teach the system that the new message-type exists and it should ignore it" upgrade.
(If not... Hint, hint, nerd-snipe, nerd-snipe?)
(The goal won’t be to get anyone to use this language; just to get the concept understood in a way where other language maintainers might then choose to bring in a spin on it in their own designs.)
Yuck-o. That's a physically painful amount of bias.
Systems that don't describe themselves as OOP just have one "object": the OS process. This object is still there, and still has to pass messages through IPC, sockets, disk IO, etc.
(Or, if you drop the OS altogether and write a unikernel, your "objects" are [real or virtual] machines.)
This isn't an argument in favor of OOP as a be-all end-all paradigm for writing all your code in, mind you; it's just an argument against thinking you can have a language that has no OOP aspects whatsoever. Maybe you can, if that language only models pure, side-effect-free computations! (eBPF could theoretically be non-OOP, I guess?)
State, or the existence of an "object" does signify OOP any more than the existence of a function or a function call signifies FP.
Trying to understand type signatures that are 3 lines long with nested class types/generics and getting your code to fit into some kind of monad transformer pipeline can get confusing very fast.
For problem domains where you have a lot of state that is shared all over the place (like trying to implement a vector editing program, electronic schematic editor/simulator, or game development), I find OOP models easier to work with.
Monads can be used when you have shared context, but then your code gets constrained and a bit unnatural; you have to worry about Kleisli composition, endofunctors, and plumbing things into and out of the state monad. Yuck.
FP is a tool. OOP is a tool. Know their strengths and weaknesses and when to use each. Yes, you can work entirely with a single paradigm but IMO you're handicapping yourself by doing so.
What hath God wrought
Like, not even the super simple examples which show you a side-by-side comparison.
I've trudged through a few Lisp books and tutorials and at least part of a Haskell book. You're right that syntax-wise they're very different than Python & Java, but the simple examples aren't hard once you learn more. Granted, I can't write even moderately advanced Haskell code, but quick-sort and some list comprehension code shown in "Learn you a Haskell" is pretty straightforward. "Real World Haskell" is also not too bad (at least the first few chapters). If you're even aware of Lisp & Haskell, you'll be able to pick them up at least at a superficial level with a little effort. Lisp is just weird due to the parentheses and the pre-fix notation, but the principles are very simple and allow you to directly manipulate the syntax tree as there is no difference between code and data. For example the simple lisp expression (+ 2 2) returns 4. What about (* 2 (+ 2 2))? The inner expression returns 4 and that is passed to the multiplication operator with 2: (* 2 (+ 2 2))###### (* 2 (4))###### (* 2 4)###### 8######
Edit: I have no idea how to format things on HN, so I out six "#" to represent a new line.
Btw...David Touretsky's Common Lisp book is extremely high level and approachable. My biggest issue with many lisps is that installing and learning the tooling (Ex: Emacs) is a huge pain. I'd recommend you start with Racket as it is like Python in that it comes with a simple IDE, so you can focus on the language and not the tooling. Racket also has a lot of libraries for a niche language.
(* 2 (+ 2 2))
(* 2 (4))
(* 2 4)
8After the first chapter or two you can move away from working in the trenches and work on a more abstract level. The concepts are what make FP shine, and once you know them, you can bring those concepts into many OOP languages to your advantage.
It's actually a very enjoyable coding flow to create closures in stateless objects using C# or Java.
Smalltalk-80 collections pretty much offer a subset of LINQ.
"as it takes away a lot of the foot-guns (mutable state, inheritance, etc)" Agree. And it is far easier to test functional code!
I am not a programming language expert, but I think that enkisting the help of the compiler for stubbing and mocking could potentially ease a lot of pain.
An OOP purist would tell you to abstract-out your fancy private logic into a DI-injected service that can then be tested separately.
Many OOP purists don't seem to think about ways the language itself could work differently to support them better. All these guys seem to remember is their set of favorite hammers.
The above is my "layman's" understanding of OOP (I've never taken programming classes, but I have been using OOP extensively in the code I write to do my machine learning research).
Can someone describe FP in a similar manner to someone like me? Because every couple of years I stumble upon another "intro to FP", and it just does not click for me. When exactly should I use it? How "monads" or "functors", or whatever else is important in FP, map to the real world, and real tasks? Maybe I just don't write the type of code that would benefit from it.
There is some truth to this, but programs don't store data, they just process it. We already model the data in our data store. If we're accessing data from a DB or receiving it in a defined structure like JSON or XML, the data has (or at least should have been) modeled and classified already. What's the advantage of doing it again? The other issue I have with this core OOP concept of modeling things in human terms is while humans think like this, computers don't. It's just a machine. OOP just seems to create complex abstractions that don't really correlate to how a computer actually works.
That being said, I don't think the purist approach to FP is a magic solution to our coding woes either. The pure FP style definitely has it's uses but I would never recommend that someone build something like a web app in Haskell or Erlang.
Personally I favor a hybrid style. Just use what works and makes sense for the task. Don't restrict yourself to some arbitrary set of self-imposed "rules" that define how you code. Any style of programming is equally capable of producing "bad" code, OOP and FP included.
If my task is to write a program that adds 2 numbers together the correctness of my coding style in relation to my chosen paradigm is irrelevant if the answer to "2 + 2" isn't "4".
Step 1: Use this tool (instance of a class) to perform that modification (call a mutating method) to affect this workpiece (another class instance). Step 2: Now use that tool...
So if I’m building a cabinet, my mind plans out something like:
saw.cut(wood1);
saw.cut(wood2);
wood3 = glue_bottle.apply(wood1,wood2);
sander.sand(wood3);
I’ve always thought of a program as just a more elaborate series of step by step commands. Computer do this to this thing, now do that to that thing (which may, through a subroutine, mean doing other nested tasks). I can’t wrap my mind around accomplishing a step by step process with functional programming. Just haven’t made that mental leap yet, probably because I’m so used to thinking the other way.
Yes, it's a hard mental leap the first few times. And there's another leap to logic programming that is almost as large as the jump to functional programming.
Perhaps a physics analogy would be useful.
A physicist may use a local, kinematic view: the object is here and has this velocity, and this force on it, so in a fraction of an instant that will make it move this much, and in another fraction of an instant it will move this much more...
A physicist may also use a global view: if I consider the set of all possible paths that start at point A and end at point B, what distinguishes the one an object will actually take?
Both are useful, and things that are obvious in one are usually quite obscure in the other.
sand(
sander,
glue(bottle,
cut(saw, wood1),
cut(saw, wood2)))That's a really commonly held view, and I think it goes off the rails in several fundamental ways:
1. The templates as a separate language feature are unnecessary, a vestigial inheritance from previous languages. One of the things I really like about JavaScript is that it took Self's object system, so I don't need to have a class to get an object. Sometimes it's useful to have a function to generate a family of similar objects. Sometimes it's not.
2. Objects (values in the language) mapping to real world entities/concepts is a dead end. This was actually realized by the database community by 1970, with the relational model. In a relational database, you define relations which may be aspects of an entity, but except in simple cases the entity exists only as a smeared out set of aspects across tables. And further, there need not be an entity that all those aspects describe, or there may be a complex web of entities and different sets of aspects may pick out contradictory, overlapping members of that set. I have found the terminology of phenomenology (suggested reading: Sokolowski, 'Introduction to Phenomenology') as a really good vocabulary for thinking about this.
3. The original motivation for OOP was very different. Consider that you're exploring an idea for a new programming paradigm, approach to AI, something that expresses itself in a mathematical formalism. One of the bottlenecks of CS and AI research was implementing these formalisms as programming languages. OOP came from the observation that you can express these formalisms in terms of message passing actors, and message passing actors are a straightforward thing to implement. So if you have a programming system that's built on message passing actors and you want to try a new formalism, you can add a new arrangement of message passing actors to the same, live system to implement your formalism, which is a lot faster than writing a whole new compiler or interpreter.
> Can someone describe FP in a similar manner to someone like me?
The impetus for FP comes from Backus's Turing lecture "Can programming be liberated from the von Neumann style?" Backus's observation was that thinking programming in terms of "do A, then do B, then do C" doesn't scale to intellectual complexity very well, and pointed out that the obvious way to scale is to have some kind of "combining forms" that let you combine hunks of programs, and that a somewhat restricted form of function is particularly easy to combine.
The simplest version that we all know is a shell pipeline. This assumes that each command is a function from string to string and uses a function | to compose functions. We take it for granted that each shell command can't mess with or look at the inner workings of the other ones in the pipeline (a restricted form of function that is easy to combine).
In bash you would write
ls . | grep pig | wc -l
(getDirectoryContents .) . (filter (=="pig")) . lines . length
And then you start climbing up the ladder of abstraction, looking for similarly easy sets of primitives that you can express stuff in and combine them. Monads, applicative functors, arrows, lenses...these are all structures that people have found while building such sets of primitives. There's nothing magical about them from that point of view. It's kind of like the fact that sequences (lists, arrays) show up everywhere in procedural programming.
programming in terms of "do A, then do B, then do C" doesn't scale to intellectual complexity very well
I think that's the bit I'm struggling to understand. You gave an example of shell pipe, but that's easy to implement with simple procedural programming:
f = ls(.)
g = grep(f, "pig")
h = wc(g, mode="lines")
print(h)
When you write a procedural program, there are larger patterns or strategies that you use again and again, such as the simple pipeline you show above. Or you repeat until a condition is met, or you iteratively adjust a value. Any competent procedural programmer deploys these strategies with barely a thought. They aren't things in the language that can be manipulated and combined. And, truthfully, a lot of this has been dragged into what we think of as procedural languages today.
So consider a procedural implementation of listening on a socket and on each connection reading the request and sending a response. It's straightforward to write in a procedural language, but if we want to reuse that behavior, we need to parameterize it over the handler. That may seem obvious today, and it's a trick that C programmers have known forever (see qsort in the stdlib). But imagine setting up the whole language like that, making all the strategies that we toss out so blithely in procedural code, into higher order functions.
This pays off because you can debug and perfect the strategy and the particular parameters for behavior separately, which turns out to be a really useful separation. Get the socket listener code working where the response is echo, then plug in your web app's handler.
Can you please elaborate on this?
By “message passing” are you referring to ObjectiveC-style virtual calls - or to message-passing in the context of OOP loose-coupling for disseminating events (i.e. broadcasting) instead of using strong references to call event-handlers?
FP, on the other hand, is more like a set of tools. You can use many of those tools in many OOP languages. In this way FP is a lot like procedural programming paradigm, as it too is a set of tools.
And that is why
>I grasped the concept of OOP pretty easily. Can't say the same about FP.
is a no. Not because FP is difficult, but because it isn't a singular object.
From that function chaining originates from the FP world and is used in modern languages like Python quite heavily.
You mentioned research, so a valid example of this is the difference between Spark and MapReduce. Spark was introduced to optimize processing large sets of data, by streaming it. MapReduce does not.
For a more heavy example, a few data structures that are quite powerful come from the FP world. For example, this cppcon talk is introduces one, which gives near O(1) time for all uses (insert, delete, lookup, ...), and can be used in a thread safe way: https://youtu.be/sPhpelUfu8Q
OOP was designed for humans, and not computers; of course it is going to be easier.
That's about as far from FP as you can get.
Are you saying CPUs are object oriented?
Or maybe you just latched onto the comment about FP and decided to argue against it in isolation.
I am saying that CPUs are NOT object oriented and that functional programming is closer to how a CPU operates than OOP is, and therefore much easier for a compiler (and a compiler author) to reason about and to optimize.
No.
> Are you saying CPUs are object oriented?
No.
> Or maybe you just latched onto the comment about FP and decided to argue against it in isolation.
Yes, because it was flat-out wrong. FP is not in any way closer to how a CPU operates. (I mean, the rest of your post had problems, too, but that one bit was glaringly wrong.)
> I am saying that CPUs are NOT object oriented
That I will agree with.
Which functional programming languages are you specifically referring to with that statement?
Computers are inherently procedural. Their code is inherently "unstructured". Structured Programming was developed for humans, for the maintenance and communication of programs by and to humans. And that's just basic procedural programming. Functional and OO programming are even more divorced from the underlying machine. And that's not a problem, that's a good thing for most programs that need to be written.
EDIT: Actually, even assembly was designed for humans. It's just that there's usually a 1-to-1 mapping between an assembly language and the underlying machine code.
I guess Lisp and Scheme derived languages aren't functional then.
Only through the glasses of "Haskell, the only true way".
When I hear "functional", I usually interpret it to mean languages influenced or derived from the ML family of languages. Notable features of these languages include algebraic data types, match expressions, emphasis on monadic operations (fold, scan, map, etc), support for TCO, and a expressive static type system (though unfortunately not necessarily supported higher kinds), and a discouragement of mutations.
Common Lisp doesn't really emphasize any of those things, and Scheme only a couple.
F#, Standard ML, Caml Light and Objective Caml would fail that bullet point list.
Scala has partial TCO, surely not cross recursive calls like Scheme language standard requires and how it is defined from CS point of view.
Same applies to F#, because neither JVM nor CLR have direct support for TCO.
It's also usually untyped, and I think the hard to write bad functional code line is mostly true of statically typed pure functional code.