Why functional programming matters
medium.com
medium.com
This isn't the best analogy as functional and imperative languages are both often used in a procedural fashion. If I simply replaced "global state" with "immutable arguments", this analogy fits functional programming as well. The fact that the arguments would be copied, however, would be implied.
> Each step needs to change, rotate, massage the workpiece precisely one specific way, so that it is prepared for subsequent steps downstream. Every step downstream depend on every previous step, and their order is therefore fixed and rigid.
This is more about tight coupling than imperative vs. functional paradigms. In general, imperative methods can be just as loosely coupled as functional methods. It basically comes down to what sort of data you're handling.
> Because of these dependencies, an individual computational step has not much use and meaning in itself, but only in the context of all the others, and to understand it, one must understand how the whole line works.
This, again, can be true of functional languages as well. You cannot always guarantee that a method is individually useful given the data at hand.
If you need to compare functional programming against something contrast it against OOP, which is a different architectural approach.
nothing!?
>The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together.
No idea what this means.
> The "functional" part determines the architecture by which the code is structured opposed to the style (vanity) by which the structure comes together.
I think it means a code can be functional but looks imperative. One example is the for-comprehension in Scala:
val aFuture = future(a)
val bFuture = future(b)
(for {
a <- aFuture
b <- bFuture
c <- futureC(a, b)
} yield c)
For an example library that can be used with a few different styles, have a look at this: http://jsuereth.com/scala-arm/usage.html
Exactly.
The most common ELI5 definition of functional programming I get from other developers is that you're piping multiple statements together into a single chain of processing [input(s) > multiple levels of processing > output(s)], without having to explicitly declare variables to hold the temporary inputs and outputs between each sub-statement within the chain. I know just enough to understand that this isn't the "proper definition", but that workflow is true enough that it's what many people associate functional programming with.
The problem with that particular definition is that it tries to make the primary benefit of functional languages seem to be this piping/chaining mechanism. Yet these languages are still written procedurally, executing multiple such pipes in sequence. You still have variables holding the inputs and outputs of each chain, so you can pass them to other unrelated chains. It reduces the overall number of statements and the manual variable/memory management required, but each statement is simply a compressed version of multiple statements merged into one, enforcing "fake immutable" variables for the inputs/outputs within the chain. You don't really have "immutability"; you simply have automatic variable management between sub-statements in a chain.
Now, show me a functional language where the entire program is written as a single piped chain, and I would classify that as its own genre. Literally, the entire program would have to be written top-down as a single block of code that chains every single required input from the top-level, all the way down to a single output, without using a single explicitly declared variable. Only the first line of code would be unindented at the first column, with all other lines having to be indented as part of that primary block. Now that would satisfy me as being "unique" or "different than procedural".
What is the primary metric of a functional language? Is it to write write golf code[1] that folds 10 "procedural statements" into a single 3-line "functional block"? To me that's not "functional programming"; that's just writing less code by chaining multiple operations into smaller blocks, reducing the complexity of having to explicitly declare more global or widely scoped variables.
Random thought association: is perl's well-known Schwartzian transform (@sorted = map { ... } sort { ... } map { ... } @unsorted), applied as a concept to an entire language, what makes a "functional language"? To me, that doesn't seem like enough of a scope change to warrant a different language "type".
https://gist.github.com/MarkusPfundstein/246446e428ab10dbd23...
Forgetting my expectations, the code example you linked is practically the antithesis for ES2015/ES6. You've abused the concept of "const". Your example is terrible, using "const" to define things that should have been defined as separate classes, without having to define so many global "const"s.
Even more critically... wtf are you doing with all those "const" definitions? That code is ultimately worse than what I saw in javascript in 1995. Please don't write code that way. :/
To go to the extreme, my ultimate reaction is that the code you linked is straight up unacceptable. You would fail an interview at my company with that code. It screams "I know ES6", while being the worst example of javascript I've ever seen, regardless of the Ecmascript version. You're overcompensating, trying way too hard to prove that you understand the latest spec. There are limits to what "modern javascript" means, and you have gone too far. A dozen global "const" declaration means you know ES6, but don't know how to write proper code.
tldr; Dial back a bit. Upgrading to ES2015/ES6 does not mean transforming all your code to be completely unreadable unless you know the latest spec. Your code should still look like javascript rather than 100% some-new-functional-language.
If you attempt to compose functions out of smaller functions, then you need variables to hold on to those small functions. What's wrong with that? And why would you need "separate classes" for those smaller functions? What problem would "smaller classes" solve?
The crucial thing to understand is, that those consts are just assignments for global modules that I use. They are NOT variables. But if you want to go to the full extreme and remove every single const: EASY! Just add all the modules to the environment of the most external Reader monad and inject them into the function chain. This would get rid of 99% of global consts that are not functions. I leave that as an exercise to you.
The rest of the consts are just function assignments. Instead of const f = x => ... I could also write function f(x) { } .. but honestly, I prefer the former. It is more elegant in my opinion ... So in order to get rid of them, just rewrite it. This is trivial.
Finally, you would want to get rid of the two local consts within the two functions putPublicationToElastic and createUploadDocument: Straightforward, they are just there for cosmetic. Again, they are NOT variables, they are just names to make some following lines a bit shorter. Again, exercise to you to remove them.
So if we do all the three steps above, the only const we would have left would be the config variable. The rest is one big function, composed in order to achieve a goal. Mind that calling the function will not produce any output (You'd have to fork it), so the function is even 100% pure...
Honest question to you: Why would I need a class here? I really don't see anything in that code that would profit from being put into a class. It's just a bunch of functions composed together and wrapped into a Reader monad. I can rename runApp to uploadSQLDocumentsToElastic and export it and have a perfectly fine, encapsulated logic. I don't think you could do better with a class. But if, please show me. I'm eager to learn!
P.S. Please tell me the name of your company. Another one I would NEVER ever want to work for ;-)
P.P.S. Sometimes people write code as an intellectual exercise. In order to try out some new paradigm, or coding style. I'd advise you to consider that next time before attacking their efforts.
This is known as point-free style. I think point-free style implies functional programming (at least locally; i.e., a point-free function will by definition be functional, although it can call imperative functions) but functional certainly does not imply point-free.
That said, Scheme is probably a good example. Lisps in general are a funny case for functional programming: historically they were described as "functional" but the word had a different meaning we would now call "procedural"; I think Lisp may have predated Algol so the concept of having functions at all was fairly notable. However, Lisps generally support functional programming and Scheme has embraced it more fully than the others. Note, for example, that Scheme doesn't actually have loops as a fundamental concept in the language; it emulates them with obligatory TCO and convenience macros.
It's true that abstractions in functional languages can seem foreign and hard to understand, but generally they have some purpose, being grounded in mathematical practice. OO abstractions and patterns OTOH, taught essentially in "elementary school" which possibly makes them seem easier to understand, do a very poor job of solving more problems than they create.
Learning a functional language is often a transformative experience that lasts throughout a career, whether you even use functional languages or not. It might make you do something as simple as partitioning which functions have side effects and which don't, even if the type system doesn't enforce it. Or use a form of quick/fuzz testing, even if it's not the standard test suite. Or make parts of the data immutable for scalability, auditability, etc. Or...
There really are few things as satisfying as developing a large codebase in a functional language. A lot of the frustrating maintenance work just goes away. But even if you don't, functional principles can yield similar benefits in imperative languages.
What do you think of the recent rise of 'hybrid' languages like scala?
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
Google primarily uses C++/Java. Facebook: Hack. Twitter tried Scala and as far as I know, abandon it and went to Java. LinkedIn definitely tried Scala, failed, and went to Java. Square is Ruby/Java.
I'd like to have something to point to as a success story of a company at scale with functional programming. Anyone know of one?
From the article "in this case for massive distributed systems Functional Languages are the right tool ...
Immutability at scale is really important because it allows you to go from 30k members to a staggering 2.5 Million+ and not even feel blip within 3 months, like we did here at Jet from the end of July to October. That’s powerful!"
Erlang was developed for Ericsson phone switches with a large proportion of uptime.
Whatsapp also use Erlang.
[1] http://harmful.cat-v.org/software/OO_programming/why_oo_suck...
Then, my thesis supervisor said "But you're wrong, Erlang is extremely object oriented". He said object oriented languages aren't object oriented. I might think, though I'm not quite sure if I believe this or not, but Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism.
..."
Read the rest. It's good.
I've heard of inheritance as a corrupting influence which has taken over and corrupted OO for years/ Funny enough, even most OO folks eventually realized that and moved to banish inheritance as a viable pattern.
For example: I've been developing for the last 3 years for the iOS and we been using FP and FRP almost everywhere with different teams and companies. Compared to the standard OO or Apple -way of doing things we have been able to make much better tests, stability/maintainability of the apps has increased etc.
I'm not sure if I can call this "the Haskell community consensus", but a lot of the Haskell community finds Scala too complex to be worthwhile. They find it introduces a lot of complexity above and beyond Haskell, but at the same time, fails to take proper advantage of it and the result is quite dirty, full of special cases, and consequently hard to reason about. So you get a lot of the costs, perhaps even more costs for compliance than a Haskell code base, but you get fewer benefits.
That's really the main issue per the original question. It's not that functional somehow fails on its merits to deliver, it's just that "at scale" means having enough developers who know it. The reality is that imperative/OO languages have the greatest mindshare, and thus it's far easier to find developers, and far less wind-up time, if you're using such a language.
Designed to replace and address flaws of an older language but ends up being huge and unmaintainable, with very questionable design decisions and a tool chain that's simply not up to standards in the 21st century (slow compiler, poor IDE integration that keeps breaking version after version, etc...).
In C++, some of these design decisions were driven by legacy pressure but in Scala, a lot of design decisions were driven by the pressure on the team to write research papers. Either way, both languages end up being monsters that implement all known programming language features known on Earth.
Your C++ to C analogy doesn't hold, because C++ is an (almost) superset of C, while Scala is not a superset of Java at all. Modern C++ compiler can compile most of C code with at most minor, cosmetic changes.
As for the toolchain - I'm working in it daily and so far it has been great. Ok, compiler is not as fast as Java (point taken), but this doesn't matter as long as I can compile my code fast enough. IDE support is stellar compared to most other popular languages, particularly dynamic ones like Python or PHP.
Odersky himself gave up on scalac and he's writing a compiler and a new language from scratch.
* C++ language specification: 1374 pages (and still includes plenty of "unspecified behavior" / "undefined behavior")
* Java language specification: 788 pages
* Scala language specification: 191 pages
> Odersky himself gave up on scalac and he's writing a compiler and a new language from scratch.
Odersky created a new language to be able to do research without sacrificing Scala stability, which is already mainstream and should not undergo any more major revolutions. So Dotty is for research / incubating language features, while Scala stays on the stable side of things, letting companies like Twitter or LinkedIn develop without fear that 2.13 will not compile their 2.12 code.
> also poorly designed overall
This is an opinion, not a fact.
> With so many features that they interact with each other in ways that are pretty much unpredictable.
Name three. I'm coding in it for several years, and didn't notice a single one issue. I heard this complaint about Scala being too hard a few times very long time ago (when Scala was at version 2.6, and its tooling was in fact terrible), but it was always from programmers, who had also major problems coding in Java, so I never treated this seriously.
Java has had lambdas and streams for awhile now. A pretty common design pattern has also become anemic domain models operated on by groups of functions, which fits in the spirit of functional programming. Modern java can, and is used in a functional style.
On the JS side, functional concepts are everywhere. Given how heavily FB and Twitter are invested in JS, I don't think they have abandoned functional programming at all.
Finally, IMO Scala is actually a pretty poor example of a language that can be used at scale. Without a highly enforced set of rules it can quickly become a write once/read never language. I'm sure there are exceptions, but given the choice between scala and java 8+, I would go with java. Clojure may be an option though.
Pojo's which are just data structures or a glorified HashMaps for holding data. And, if allowed, using Lombok to get rid of all the getter/setter cruft.
The second category of class types are just Service classes. These classes hold no state and are a logical grouping of methods that typically operate on a given data type. However, the class is based more on a specific role it performs than the type(s) it operates on. Also, there's considerable thought given to reuse of the Service classes outside the given context at hand.
The reason for this pattern is because companies look for easily replaceable developers.
To get into functional you need to be good at abstracting the business domain, this requires seniority which is hard to find. Most of the time, when you are working using functional programming you are implementing the business vocabulary. Entry level developers are not good/interested in this. Their worries are in how they can use Angular 2 in this project, or why we need to still use SQL Server instead of converting to {insert the newest database technology}.
It is easy to find (and replace) junior developers that are happy because they created something with the latest technology and it provides the immediate value intended. It sounds good, but it misses the point.
Software development in a company happens to support/enhance the business. This means that it has to stand the test of time, not only in reliability but also in adaptability. The only constant in software is that it will change. Here is where building a vocabulary that represents the business subjects pays off. Change now is a definition-change and, unless the business is pivoting, definitions rarely change; instead, they have constant adjustments. Functional shines in creating a vocabulary and having this adaptability.
Of course, you can adapt using OOP, but the question is not if adaptability is possible, it is instead how to make changes at the lowest risk.
Which is definitely part of the "company at scale" equation the GP referred to.
>Here is where building a vocabulary that represents the business subjects pays off. Change now is a definition-change and, unless the business is pivoting, definitions rarely change; instead, they have constant adjustments. Functional shines in creating a vocabulary and having this adaptability.
I tend to use the same arguments to make the case against FP for business modelling.
I tend to say that FP is good at adding new operations to existing things, while OOP is good at adding new things to existing operations. However when Software Development is used to model a business - as it should be for reasons you accurately explained - the reality it meets is the one of the business world in which business needs evolve and requirements get added. You start by supporting local groceries and then you grow to support global supermarket chains. OOP is more suited to model business because you can naturally extend existing types and apply existing operations to them (ie. pass a supermarket everywhere a shop was expected + things such as polymorphism). In FP, every time you add a type, you need to add switch cases to your existing operations (at best), or redefine them create / new ones (at worse), since the ubiquitous assumption of FP development is immutability and known types.
I'd be curious to know how you approach this conflict in a way that makes FP work in real world business modelling which needs to be extension-oriented. It seems to me that the more operations using a type you have, the more you will be screwed when you want to extend this type. The only reason I can see this wouldn't be the case would be to say that I approach FP with the wrong philosophy and that there is no such things as extending types in FP. But in this case I'd question if FP modelling really is the best tool to model real world business for which it is natural to define things as extensions of other things.
What you described is exactly the _expression problem_. And it has some solution.
See https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...
The functional and strongly typed value proposition of FP is very appealing on paper but only shines when you have a level of certainty and knowledge on requirements that you typically do not have in real world software development. OOP by design embraces this uncertainty (but as a trade off is less assertive on correctness than FP).
That being said, certain businesses do not have a high level of uncertainty in their developments while correctness is a big deal for them (banks, scientific researchers, etc...). It makes sense for them to reinvest this slack in correctness. However, for those iterating consumer facing products (which represents the majority of developments), OOP modelling usually is the way to go. Because of the expression problem (which should probably be called the expression dilemma to better highlight the fact that the assessment should be continuous and situational rather than ideological and/or philosophical)
"OOP is more suited to model business because you can naturally extend existing types and apply existing operations to them (ie. pass a supermarket everywhere a shop was expected + things such as polymorphism)"
The reason why you feel is more suited is because you are thinking in an object oriented way. It is not a bad thing, but it is not functional.
"... extend existing types and apply existing operations to them". This means you have things, and you do things to them. This is the OOP way, not the FP way.
In FP the things are immutable, so you don't do things to them because they cannot change; instead, you create new things out of what you have.
In OOP this is what you have, this is what it can do, and you put all the gears (or objects) together and you get your engine.
In FP you have pipes, this is what I have and if I put it through this pipe it becomes something else.
When a local shop there is a sale, there is a function that takes a bunch of arguments and produces something called a sale, Maybe is the total, maybe is a tuple with the different pieces of the sale.
When you move that to a supermarket, then the question is: how what the shop owner calls a sale in the local shop is different from what the supermarket owner calls a sale? How my vocabulary changed? for a lot of things, you will see that the meaning is the same, just over more data; and also, there are new words that didn't exist in the smaller context. A sale is in both cases the sum of the quantity multiplied by the price of the groceries, apply the tax, spit out the result. But maybe the meaning of Tax changed, instead of been a fixed percent, it needs to be the lookup in a table depending on where the supermarket is.
If you need to constantly add switch cases, then probably you are using a functional language using an OOP mentality.
The way that I have introducing FP to people is using Excel. Think on this syntax:
A1: 1 B1: 2 C1: A1 + B2
You don't need new cells, C1 does not mean the same thing and the formula have to change... the formula or is it the function?
When you model the real world, you can focus on the objects, map them to types, and go from there. Or you can focus on the meaning of the words, then you need just a few types, see how those meanings compound, and go from there.
"But in this case I'd question if FP modelling really is the best tool to model real world business for which it is natural to define things as extensions of other things."
I agree, FP is bad at extending things... but it is not FP fault that you see the world as things that need to be extended.
A middle step between what you are saying and FP will be Flow Programming (https://en.wikipedia.org/wiki/Flow-based_programming). It is not FP, nor OOP, but somewhere in between.
>Or you can focus on the meaning of the words, then you need just a few types, see how those meanings compound, and go from there.
>I agree, FP is bad at extending things... but it is not FP fault that you see the world as things that need to be extended.
I should probably give another look to FP and continue to study the subject, I have likely been approaching it with a OOP mindset as you suggest. One last question though, what about code duplication ? If you focus on the meaning of words and compounding these meanings to create new things, wouldn't it most of the time create lot of duplicate code ? For example in the case of the local shop and the supermarket, wouldn't you have two functions (or a switch case) containing exactly the same code to calculate the quantity multiplied by the price of the groceries ? One would take a local shop as parameter, and the other one would take a supermarket.
Splitting the sale processing function in two parts - one summing up the groceries and the other one calculating the taxes - so that you can reuse the first function implies knowing in advance the existence of the supermarket structure (which you will only know many years after putting your product in production). Not doing it in advance either means duplicate code or refactoring every time you add an operation. The extension mindset initially comes from the need to avoid code duplication which is known to make maintenance difficult.
Now maybe the strongly-typed experience of FP and its compile-time checks are so convenient in practice that they make the maintenance of this kind of code easily manageable ? Maybe it's not even really duplicate code since what would be a basic number in OOP would be two different types here in FP ? Or maybe it's still thinking about FP from an OOP perspective ?
What goes through the sale function pipe is not the store and its size, it really does not matter for the meaning of sale were the sale happened. What matter for the sale is the cart. The cart might be more or less sofisticated because the size of the store, but is still a cart.
So the sale function is a pipe that eats a cart and spits out a receipt.
Or if you want to put it in another way, a sale is something that might happen to a cart over time. Functions are the clock on the system. In a functional system, times does not pass until a function is executed (does it sounds like lazy evaluation?)
In functional programming, we avoid duplication of code by appliying functions to the data so it spits what the next function needs. If you have a function sale that can eat a simple cart, but now you have a complex cart, one solution is to create a function that converts the complex cart into the simple one that the sale function needs; another way is to make the complex cart having the same data as the simpler cart. What you choose to do is proportional to how different the meaning of cart is, or maybe the cart remains the same. In general terms, this type of thinking tend to produce less lines of code needed per similar acomplishment.
So in OOP your are using objects to put together the store, while in FP your are descriving what happens in the store by connecting pipes betweem the different data. It is not about what can happen to the data, but what makes the data travel. It is not about what steps makes it work, but the fluidity of the data life span.
In particular your demonstration was very convincing from a DDD perspective. I can see that FP is not less natural than OOP for domain modelling while it approaches things from a very different angle. However FP brings to the table rich domain semantics, high correctness guarantees, and I feel productivity gains too. And with the mindset you've presented, it is also clear that the unknown seems to be accounted for in FP too. As an architect, this last point was the grey area and the deal breaker for me. However now I see no reason not to invest in heavily leveraging FP moving forward. Thanks again jorgeleo.
This is incorrect. One of the former VPs said he would not use Scala. Twitter uses Scala massively and has published and continues to maintain several open source Scala projects.
> LinkedIn definitely tried Scala, failed, and went to Java
This is incorrect. A newly hired VP insisted on moving the front end from Scala to Java. In the offline backend stack Scala is used extensively. Check Kafka, Samza from LinkedIn or better yet ask current LinkedIn employees.
Apart from these Spotify, Foursquare, ebay, several banks use Scala. FP is huge in financial institutions, check K/KDB+. Jane Street etc. Thats where most FP programmers work. Also verizon, jet.com and walmart.com. There are several dozen large companies using FP.
FP is mainstream now. Traditionally, it was financial institutions using some flavor of ML/Haskell. With Scala/Clojure on the JVM, Si Valley has moved into FP in a big way.
JavaScript, for example, is ubiquitous in the industry, and, especially with the advent of ES6, can be written quite functionally. ReactJS is also widespread and can also enjoy an FP approach.
https://static.googleusercontent.com/media/research.google.c...
Imperative/object oriented languages are often more practical for real-world use (MapReduce itself I believe is written in C++), however it's the ideas of functional programming that matter most. Those with experience working in functional languages are at an advantage over developers who've never had that exposure, because they have a wider range of mental tools at hand with which to solve problems.
This is a good video, from Jane Street, on why they use OCaml:
Another approach is to run experiments but they are universally terrible. Their methods have so little relation to the way real software is developed, that it is hard to take any conclusions seriously.
I would also like some hard data, but don't hold your breath. Technology decisions will probably need to made based on other factors for the foreseeable future.
There was a recent post here on HN about empirical language design and I thought that was a refreshing change. I'd like to see a change in software culture towards an evidence based approach. It's long overdue. Alan Kay called the software world "pop culture" and I think he is right. Software is more fashion driven than Vogue magazine.
Academic research could be a vehicle for a more empirical approach. Research in the hard sciences embraces empiricism. Sadly, the academic research in software doesn't, generally, adhere to the same level of rigor.
I personally find it much easier to navigate and fix bugs in an Erlang code base than in the equivalent C++/Java/C# one. It mainly boils down to how state is updated. When I see NewState = update(Value, State) it is clear what is happening. In OO code, I usually need to remember what object inherits from, what are is the instance state so far (what other members have been called) and how it got there. I find that much harder to handle, for example.
Ruby is OOP. Elixir/Erlang is purely functional (although dynamically-typed... some will prefer typed... but the results speak for themselves).
If you are a long-time developer like me and are just coming across this, this news should strike you somewhere between "astonishing" and "pure fucking magic."
Here's the deal- Paradigm shifts, most people only see them AFTER they've finished. If you want to be ahead of the curve on this one and you want to reap the benefits, go functional (Haskell, Clojure, OCaml, F#, Elm, Erlang/Elixir). Today. That is my #1 piece of advice right now. (Well, that, and to avoid Scala and Go. Scala is just too overly complicated to keep your cognitive load down as a developer, and Go... Well, the name even says it: "Go!" As in, "don't stay!" ;) Go will suffer the same long term problems that all OOP/procedural langs share, compounded by its idiotic take on error handling /opinion)
Elixir: http://elixir-lang.org/
Phoenix: http://www.phoenixframework.org/
There are a lot of interesting aspects of functional programming, but there's no particular miracle here: Ruby, particular Ruby on Rails, is slow.
[1] https://www.techempower.com/benchmarks/#section=data-r13&hw=...
[2] https://www.iron.io/how-we-went-from-30-servers-to-2-go/
Also demonware [2], which is owned by Acitivision/Blizzard and manages online game lobbies for all their titles (ie Call of Duty series across all platforms), uses Erlang. They switched from C++ to Erlang before Call of Duty Black Ops was released. They said if they hadn't decided to switch before the release the company would have never been able to handle the 5 months of user growth the game brought to their platform [3].
[1] https://github.com/janestreet/core [2] https://www.demonware.net/ [3] https://news.ycombinator.com/item?id=14120506
[1]: https://www.cs.kent.ac.uk/people/staff/dat/miranda/whyfp90.p...
"However, there is a very important point that is often missed. When writing a modular program to solve a problem, one first divides the problem into subproblems, then solves the subproblems, and finally combines the solutions. The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together. Therefore, to increase one’s ability to modularize a problem conceptually, one must provide new kinds of glue in the programming language."
We need more kinds of glue. He argues that FP provides one (function composition, a Good Thing™) and lazy FP another (lazy eval, a bit more controversial).
But that's not a whole lot, is it?
There are also high order types polymorphism, that normally comes with FP but it not inherently linked to it.
But yes, overall, it's been fairly abysmal. Which is why I personally think we need to really, really focus on flexible glue: http://objective.st :-)
Also, if looking for glue, check out Wikipedia's list of programming paradigms or types of programming languages. Quite a few including some styles you may have not heard of.
Yep, have the book. In fact, my own OO/dataflow stuff[1] (also a good 20 years old now) is similar in some ways, and I am trying to merge ideas from Morrison as much as I can.
Have also started trying it out in GUI settings[2]
[1] https://github.com/mpw/MPWFoundation/tree/master/Streams.sub...
Now that you talked about constraints, there's constrained search that never got mainstream but is also great. This one does not mix well with other glues. Now I'm wondering what kind of polymorphism could make FP/imperative mix well with it.
Combinators, type-classes, ad-hoc polymorphism, monads, applicatives, FRP, ...
And FRP is, of course, just dataflow made more complicated by trying to squeeze it into an FP framework.
Hardly. The GoF patterns are pretty much all poor attempts at functional patterns, with disturbingly long-winded implementations. They are there because of missing features in OO languages (mostly first class functions). The GoF also label good programming practices as bad (anaemic domain model for example). They are a scourge on the world of programming.
My point was that there are language features for composition outside of functions (type-classes, ad-hoc polymorphism); as well as very sound composition approaches in code (monads, applicatives, FRP ... which actually still use functions btw). The code approaches are based on sound and provable maths, the GoF patterns are a joke, as is inheritance based composition, or pretty much any approach to composition in OO-land, because the 'glue' you talk of should be at a lower level (the function level), not at a class level or higher, where the shapes of the things you're composing don't match in any meaningful mathematical sense. Even the higher level glue in Haskell (type-classes) and Scala (ad-hoc polymorphism) is all about set theory and matching of shapes.
I'm saying this as a reformed OO dev; after spending 20 years believing the GoF (and OO world) dogma I finally changed my thinking about 7 years ago after a super large project I still work on became cognitively too difficult for the team to manage (the scale of the code-base combined with the extreme abstraction of components and hidden mutable state meaning it's very difficult - unless the coder wrote the feature - to know what mutation would go on behind the scenes; this is one of the big failures of hidden mutable state with packaged functionality that hides the mutation).
Inheritance is a myth, interface based abstraction is a myth, code reuse is a myth, OO composition is a myth. You may achieve this stuff once in a while, but if you 'abstract' a service behind an interface, 9 times out of 10 that service's own interface is imprinted in the abstract interface. And when you do decide to replace it later, unless it's trivial, then there is nearly always a change to the interface. If the thing behind the interface mutated state, then whether you like it or not, the code that uses it makes assumptions - which increases coupling. Abstraction is used liberally, even when you're only abstracting one type of thing. "Ah, I have a MyService class, let's abstract it behind an IMyService". "But there's only one of them?", "No matter, Martin Fowler said I should".
When you see whole DI frameworks and tooling, and mocking frameworks, you must realise that something is wrong? Why use DI when you can just use first class functions? Or a Reader monad? There are a lot of people in the OO world with opinions on the perfect architecture for applications, but none of them have any study backing them - but the dogma flows and flows, it's like, once somebody reads the GoF book they think they have all the answers. Yeah let's use the Visitor pattern to get over the fact we don't have algebraic data types. Let's use the Command pattern because we don't have first class functions, etc.
I prefer to rely on the proven technology: mathematics. It works, and writing 'expression oriented' code with immutable values just makes sense. It makes sense for the brain, it makes sense when you don't want code rot, it makes sense in parallel programming, it makes sense when you want programmers to know what the hell is going on.
Bringing in functional practices, and going away from the whole OO 'belief system' was enlightening, and I'll never go back. Neither will anybody on my team. I realise you've nailed your colours to the mast, and it's clear from this thread that you're living the OO dogma dream, and none of this will make any difference to you. But your blanket dismissal of anything from the functional programming world is very telling.
The argument is "learn these concepts that are not available in other languages to make you better at those languages". Can anyone explain?
This can be implemented in any language I guess. Most often you'll see explicit & imperative loops being refactored to shorter, descriptive code with anonymous functions, folds, filters and maps
Functional programming is generally more abstract in its approach to modelling the problem. If you get the model wrong, you will not end up with a working solution, forcing you to rethink your model.
While imperative programming allows you to reiterate towards a solution as you start to understand the problem better as you work towards it, it's obviously better and faster if your initial model of the problem is more accurate.
Functional programming forces you to create a viable model of the problem before you start. If you can extend that discipline over to an imperative language, you will need less iteration and the resulting solution will likely be more elegant.
The argument is not (or shouldn't be) about concepts, but about paradigms and discipline.
OO kind of lets you do anything you want, allowing you to store data anywhere and having any kind of flow you want. It's very easy to do something that "just works", and while there is a lot of value in that, you can keep bad habits for very long.
FP is a lot more constraining, and will force you to adapt how you think to fit said constraints.
Having to think differently offers a different perspective on code architecture, that will eventually give you ideas applicable beyond FP languages.
A quick example that can be faked in any language is a pure function [1]. The functions only inputs are the set of arguments, and from those arguments returns a side-effect free result. A pure function is easy to test and easy to reason about.
Contrast a pure function with an impure function that uses an objects internal state plus the arguments passed in to further tweak the state an/or return a result. It is immediately obvious the second is much harder to test and reason about. It becomes even more challenging when the object is thrown into a large system with a lot of moving parts.
Even before I really started learning about true functional programming, I had been writing 'pure' functions for years because they just made sense. Even internal private methods are simpler as pure functions. Shared state is evil for many reasons and should be avoided if possible.
Have you noticed that these articles almost never do?
they have argument from authority and anectdote. Language research is still in the phase of bad humors and blood letting.
Love this. Practically all the claims I've seen are just small code samples accompanied by the author's vague endorsement.
In category theory we might have different categories. Some might instruct the compiler and programmers that the function obeys certain rules when applying. It could be trivial to parallel or perhaps it specifies a strict sequencing for computation. Following Haskell research, you can really see the evolution as people find more useful generalizations (which in the end, has made things simpler!)
It's not like you cannot write short functions in other languages - you can - but it's often too easy not to do it.
It would be nice to have some empirical evidence for this, unfortunately I am not aware of any.
Without rigorous evidence we're left to argue from theoretical models / principles and anecdotal data. This is still useful. It would certainly be more useful to have rigorous empirical results to back up the claims and validate the models but we, as practitioners, have to make decisions on language choice now using the available resources.
The kind of empirical evidence you are asking for is extremely expensive to provide. Even if you conduct a massive controlled trial, experiment will have several biases which will invalidate any conclusion. As an exercise try looking for scientific evidence that programming in Java is more efficient than programming in assembly. No scientific evidence for this exists. Yet most of us would never choose to write a web service in assembly! The only evidence that can be provided are discussions and benefits of particular features and anecdotes.
Do you think programming productivity is possible to measure and if so how?
> Do you think programming productivity is possible to measure and if so how?
For the purpose of discussion, I would propose that a team of developers are given a simple task with highly specific and explicit functionality requirements. This team of developers should Ideally have no experience with any of the technologies used. Experience with the problem domain is acceptable. These developers would then be tasked with building out the solution with various different technologies (languages, frameworks, libraries). We then compare the time it took for the developers to complete the task relative to the amount of bugs present in the solution. For example, the team could be tasked to build a gui calendar with Haskell and then Python.
The issues with the above proposed experiment are as follows:
* We would need to find some way to adjust for problem domain familiarity. The developers are going to get better, and thus more productive, at the task after they have completed it the first time.
* We need some sort of concrete numerical measure of "bug likelyness" for lack of a better term. All software has bugs, but some are very hard to find or appear only during runtime under very specific conditions.
* We need to decide whether or not we take the language ecosystem into account. In the calendar example I provided above, Python would obviously be more productive because there are a ton of different packages available that make creating a GUI extremely trivial.
* Do we take into account time spent on learning the language/tool/package/framework/library? Do we measure the amount of time that it takes the team to feel comfortable working with a new technology?
All in all, it's an interesting thought experiment and I'm interested to hear what you think.
https://sites.google.com/site/stefanhanenberg/ https://link.springer.com/article/10.1007%2Fs10664-013-9289-...
The above papers are not about FP but about static type systems (there tends to be lots of crossover), but I think you'll find that what it really comes down to is guarantees provided by a language. I would be surprised if similar research that focused solely on purity did not exist.
This is an incredibly difficult area to study. "Better software" is a difficult metric, and even a more meaningful metric is incredibly hard to measure. For a field as young as CS it's no wonder that the research into this is still immature, so we largely have to rely on anecdotal evidence and common sense.
So yeah we have some research and we have some basic common sense and we have people demonstrating through their projects that it has worked well for them.
More to the authors point - what they are really talking about here is modularization being a benefit to a moving codebase. Their quotes, their 'argument from authority', is mostly about modularization. Their argument is that functional programming lends itself to modularization by limiting state space and focusing on composition.
> Real World OCaml is aimed at programmers who have some experience with conventional programming languages, but not specifically with statically typed functional programming. Depending on your background, many of the concepts we cover will be new, including traditional functional-programming techniques like higher-order functions and immutable data types, as well as aspects of OCaml's powerful type and module systems.
It's a nice segue into the world of functional programming if you're not ready to give up on imperativeness just yet.
http://chriswarbo.net/blog/2015-01-18-learning_functional_pr...
Eric Lippert's Monad Posts, starting at https://ericlippert.com/2013/02/21/monads-part-one/ - Uses C# to build up Monads using examples.
Slides: https://speakerdeck.com/swlaschin/domain-driven-design-with-...
Video of talk: https://vimeo.com/97507575
And then you go from there.
The last section there is important. In the real world, your language is not always your choice, but it's perfectly possible to put functional structure in most any language.
[1] - https://msdn.microsoft.com/en-us/library/hh314518.aspx
After all, if you try hard enough, you could code in a functional style in C.
The nice thing that either language will help introduce functional ideals. I recommend Erlang since its so unique.
[0] https://app.pluralsight.com/library/courses/csharp-applying-...
For me at least, this site made programming fun again! It's colorfully written and mostly easy to follow, though some of the concepts are a bit mind blowing if you are only familiar with OOP like I was (passing a collection of functions to map really made me stop and think). Oh and it's a pretty neat way to learn emacs if you haven't already.
There are advantages to functional programs, but I wouldn't say they're any easier to change than imperative programs. In fact, it's often more work to change a program where all functions depend purely on their arguments. Instead of adding a single imperative state update, you have to add a new argument to a whole group of functions and thread state through them appropriately.
Patterns like monads and monad transformers can make this easier, but massive stacks of monad transformers have their own issues (http://blog.ezyang.com/2013/09/if-youre-using-lift-youre-doi...).
(And besides, most functional programming languages apart from Haskell support mutable state (e.g. ML ref cells, Scheme set!) -- pure functions aren't fundamental to the functional paradigm.)
Functional vs. an alternative is nothing more than visually different styles that result in developers having a personal preference. Some languages offer optimizations for certain constructs, but even those depend on the implementation found in each language. A functional language doesn't automatically grant objectively better qualities, whereas a specific functional language might provide advantages that have everything to do with that specific language rather than the fact it happens to be functional.
Functional languages are interesting and the right tool for the job for many people. But they are not better, and when you have developers fighting hard to defend their language as "better", recognize that has a lot more to do with their ego than anything based on facts.
https://www.infoq.com/presentations/Simple-Made-Easy?variant...
In real OOP, we don't have to use inheritance for objects of different types to be substitutable, so "object based" doesn't exist as a separate phenomenon. We use inheritance when two or more things are internally similar, such that they can share a chunk of implementation. If things are similar only externally (API level) but have totally different internals, then we don't use inheritance.
OOP is happening when we substitute objects of different types into the same code and they work, regardless of whether those objects are related to each other by inheritance.
"Object based" is when we cannot do that.
It's basically a new (or not so new any more) term for "abstract data type" which is used when the abstract data type language supports obj.function(arg) syntactic sugar.
If we take Wirth's Modula-2 or Pascal exactly as-is (two languages exemplifying abstract data typing support) and then add the "obj.function(arg)" sugar, they suddenly become "object based".
... Alan Key, who coined the term "Object Oriented Programing" identified the following his definition of "object oriented":
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things."
Alan Key though Java and C++ were abominations. However he may feel, THAT is the state of Object Oriented Programming today. Objects are instances of classes, which typically also determine their type. :/
You're not wrong that Erlang and Scheme are just as much about objects and message-passing as they are about actors.
Kay may or may not agree with me, but I like to require a facet he mentioned in another discussion once: The uniform calling interface. This is the property of objects that you may send any message to any object. If you require this, then Java and C++ disqualify themselves neatly.