▲ 46 points
back
30 comments
As an OOP afficionado, I am embarrassed by how mushy our discipline is compared to the crystal clarity of our functional bretheren. How I wish I lived in a world of such well-defined boundaries.
After all, everyone knows that FP was started with Lisp with the insight that the heart of FP is homoiconicty. Except where it isn't, as in ML and others.
Likewise, functional programming introduced a higher level way of expressing our intention without being bound to the low level machine representation of values. Unlike Fortran and Cobol, all functional languages use dynamically typed variables (except for ML and its derivatives) and operate at a level of abstraction above the primitive underlying machine (except for nil punning, car, cdr, etc.).
While OOP languages endlessly fiddle with syntax, functional languages all agree that only way to represent code is with s-exprs. Or not, as in ML. And that function arguments should be lists. Or is it tuples? Or curried?
Either way, syntax is just window dressing. What really matters is semantics, and here functional programming has always stood for a very firmly defined set of behaviors. Functions should be pure, as in Haskell. Except when they are not as in Scheme, Lisp, and ML. Evaluation should be by name. Or by need. Or eager.
There must be macros. Or not. They should not require hygiene since that is an artificial limitation, except that they should require hygiene because unhygienic macros are evil.
Let's not forget one of the key contributions that functional languages have given us: lexical scope. All functional languages use it strictly. Except for Emacs Lisp which does not, and Common Lisp and Clojure which have options to not use it.
OK, fine, I'm side-stepping the most important facet that all functional languages agree on: first class functions. This is the defining feature of FP languages: all functional languages have them, and all other languages do not. Except for Lua, C#, Java, C++, JavaScript, Self, SmallTalk, and others. But, functional languages certainly have first-class functions more thoroughly integrated into the rest of the language than non-FP languages do. Except for Common Lisp, which relegates them to a separate namespace.
In conclusion, I think we can all agree that object-oriented languages could learn a lot from FP about how to keep your terminology precise.
Slow clap :)
The main problem with the OOP community is that it has basically gone incognito. There are no edgy new ideological OO languages being pushed for mass adoption (like Scala, Clojure, Rust, or even Haskell); instead we have Dart and TypeScript as very pragmatic plays. Time to wake up.
And, as the article suggests, we all have completely different ideas of what OOP really is. It is all about the messages, or polymorphism, or classes/prototypes. Or maybe it is all about the nouns and object thinking. But as you suggest, the FP people have similar problems.
I'd love to see a pragmatic play in the FP space.
There are plenty of mature pragmatic FP languages out there, like OCaml, ML, F#, or even a disciplined subset of Scala.
Haskell is pragmatic.
What? FP has absolutely nothing to do with homoiconicity. And it was not started with Lisp. It started in 1930s, long before any programming languages existed. Lisp was never a real FP language and never intended to become one.
FP is perfectly well defined. Most people would agree that most "functional" languages are not really functional but only employing some elements of the functional programming. There is no such a wide disagreement as with the vague, useless, pathetic notion of OOP/OOD.
Congratulations on defeating all those straw men!
The article is silly, and so is your response. Functional programming most usually, the vast amount of time, refers to a declarative style of programming which involves using functions in the more mathematical sense, which means that one tries to avoid state and side effects. Not necessarily as a compiler-mandated thing, but as a convention. Does one still make "functions" from time to time which are really about mutating state and/or side effects? Yes, but then you would say that they are doing a more procedural/imperative style at that point in time. Like java can be procedural, if you try hard enough.
"[...], and all other languages do not." - Demanding that other languages - which might not self-identify as 'functional' - not have something seems like a futile demand. Are those languages just gonna be banned by the almighty FP wizards? :)
I've never seen things like the syntax of lisp, the homoiconicity of lisp, the lazy evaluation of Haskell, be equated with functional programming as a whole.
> The article is silly, and so is your response.
Guilty as charged, though I fear the original article doesn't realize it's silly too.
> Functional programming most usually, the vast amount of time, refers to a declarative style of programming which involves using functions in the more mathematical sense, which means that one tries to avoid state and side effects.
Maybe it's just me, but I've never found most functional code I've seen to be particularly declarative. I certainly like purity and immutability, but much of it still reads imperatively to me, just in a slightly more abstract style.
But, then, that's true of OOP code that I like too. I find method calls (in good APIs) just as declarative because there I'm describing what I want the object to do and not how to do it.
> Are those languages just gonna be banned by the almighty FP wizards? :)
I think they prefer the term "smug Lisp weenies", but they probably wouldn't turn down that title either. :)
I think arguments like this are silly because I don't really like any single-paradigm languages. I think functional, object-oriented, imperative, declarative, etc. are all styles and each of those styles has its place, often all within the same program.
People (like the author of this post I suspect) like FP because it rejects OOP, but I like OOP because it doesn't reject other styles. Mainstream OOP languages have no qualms about adopting higher-order functions, closures, immutability, and all sorts of different concurrency models. I like simplicity, of course, but I also like having a lot of tools at my disposal and not rejecting some for religious reasons.
> Maybe it's just me, but I've never found most functional code I've seen to be particularly declarative. I certainly like purity and immutability, but much of it still reads imperatively to me, just in a slightly more abstract style.
How much have you seen? If you can understand Haskell, the ideas in http://gergo.erdi.hu/blog/2012-12-01-static_analysis_with_ap... are pretty neat and directly exploit declarations.
Prolog is the poster child for declarative languages. To some extent SQL and Excel fall into declarative language camp.
Functional programming is as you say using functions and avoiding side effects. See Haskell, see ML, see LISP, I do not see declarative languages among them.
Two completely different animals.
Yeah, prolog. The declarative language where you just specify what you want, and still have to learn the underlying unification algorithm to use it[1], and sprinkle very procedural cuts around your code in order to keep the algorithm from taking unnecessary paths.
> Functional programming is as you say using functions and avoiding side effects. See Haskell, see ML, see LISP, I do not see declarative languages among them.
Heh, so you're saying that functional programming is not declarative because it is not prolog et al.? No, functional programming is also considered a declarative style of programming. It doesn't matter that it isn't logical programming, or excel.
(If you think this argument is a bit just-so, well it's a reply to the same style of "argument". If you want to claim that FP is not declarative, please argue why it is not declarative.)
[1] Which is often more effort to learn compared to the conceptual evaluation model of FP, since the FP evaluation model can often be viewed as a more restricted version of evaluation used in imperative languages.
I don't see where the gotcha is in 1 and 2. The meaning is pretty clear if you're familiar with the two languages. Simula is a procedural Algol-style language that includes a class-based OO system, analogous to Java or C++ today. Smalltalk is completely based on message-passing. The distinction between the two approaches is reminiscent of the ML/Haskell divide (strict+impure vs. lazy+pure).
3 and 4 is a statement of principle _preceded_ by an acknowledgement that the definition the book uses is not universal. 5 seems uncontroversial to me; the need for automatic memory management is a secondary outcome of other aspects of object-oriented systems, not a primary quality. And 7 doesn't seem to follow from the quoted excerpt.
All the quotes are from a single 33-year-old copy of Byte magazine. They don't conflict nearly as much as the commentary implies. Together they suggest that an idealized OO system consists strictly of objects passing messages, but that other languages blend OO and procedural features. The same is true today.
EDIT: retracted an unnecessary implication.
OOP... where originally specified as a queued serializable messaging-based topology of reusable components, i.e. what we now know as a actor/agent based programming.
... But where CPU stack-based function calls (cutely named "method calls") was what was actually delivered. Presumably because in the 80's, what was specified, was too costly on the CPU and memory to deliver. Oops, indeed.
A lot of bad decisions were made in the 80s in the name of CPU and memory. Just look at RDBMS still in the 21st century being the default persistence layer for 99% of applications.
OOP is a pattern that became popular for GUI programming because everything is inherently messaging-based already, and because Xerox and Apple adopted it and for some reason people thought it could be reasonably applied across all types of programming.
The problem with RDBMS being?
No sarcastic, just curious.
The problem being that to use RDBMS well with object-oriented software you need an ORM (object-relation mapping) layer, which adds complexity and cost and maintenance burden. RDBMS are a central point of failure and don't scale well. Relational data is typically overkill for the vast majority of applications which would be better suited to a document-based dataset at the expense of a little more memory cost. Etc etc... :)
I disagree. Database code is generally a lot less buggy than application code, probably due the declarative nature. Plus with a properly normalized schema, you can answer most questions about your data. Document databases have basically forced you to denormalise at step 1. I would say we should forget about the OOP and stick with the RDBMS, as that part works well.
RDBMS has its uses, I didn't say otherwise. However I did say adopting it as a "default" persistence mechanism is wrong. RDBMS is something you adopt with your eyes wide open as it is large architectural decision and ultimately a burden to take on board. And even then you may only adopt it for one particular subsystem of your product; for polyglot persistence is the best.
For application state, the big drawback of RDBMS is its lack of temporal and immutable persistence. This is where the temporal nature of event sourcing is a better fit for application state. Event sourcing can feasibly perform a superset of operations that SQL can do, and it can do all this without the the need for mutable state.
Relations work well with functional programs. Some people even want to make relations the default data type. (We did something similar at Standard Chartered.)
Just wait a couple of years until the SQL for NoSQL will arrive or something else at least remotely looking like a standard. Then we will have ORMs for NoSQL.
ReST shows that a person can invent a technical term, write a long dissertation on what it means, clarify any ongoing misconceptions on the web, and have people use the word to mean whatever they like.
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
> REST APIs must be hypertext-driven
http://msdn.microsoft.com/en-us/library/jj819168.aspx
> Using the REST Services with .NET > In order to make use of JSON serialization in .NET
This is not new. Codd spent ages talking about why every relational database was not a relational database.
REST came to mind for me as well.
Let's assume there is a platonic ideal for REST, or for OOP. Just talking about REST over HTTP (methods, response codes, URIs) clouds that ideal, making it hard to learn about and even harder to talk about with other programmers. The same could be said about OOP with classes, structs, prototypes, etc... or as some of this article's quotes do, about OOP in Smalltalk. Over time you could look at this in terms of SCOT theory[1] and I think it would be fascinating. You could look at all of the marketing, conflict, and the effects of collective perspective shifts where things are considered "solved" but they aren't really.
My own opinion about the platonic ideal of OOP is close to Chapter 18 of Pierce's Types and Programming Languages, which suggests these attributes: 1. Multiple representation 2. Encapsulation 3. Subtyping 4. Inheritance 5. Open recursion.
To me the kernel of OOP is mainly just #1 and #2. If you don't have #3, you should have a damn good alternative. I don't attach #4 and #5 to the core definition but certainly the former should imply the latter. Another favorite is "On Understanding Data Abstraction, Revisited"[2], which contrasts objects and ADTs in a different framework.
[1] http://en.wikipedia.org/wiki/Social_construction_of_technolo... [2] http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
It's sad that in the case of REST, this is not a minor deviation, but a major violation of core principles.
OOP was a programming paradigm sponsored by big enterprise. Just search YouTube for this string: "steve jobs object oriented"
Apple, NEXT were absolutely the biggest advocates of OOP. The word "object", for a time, literally pervaded all across their product lineups and marketing. Microsoft got on the bandwagon a little later, first with Visual Basic and later with COM (component object model) that was baked into Windows. The latter of which turned out to be an utter disaster.
Object oriented programming was being pushed in the same way that ORMs, RDBMS, etc etc. It was a whole sales pitch to make money. Whether it was actually "any good" is very much still up for debate.
There is no definition of OOP. It's a amalgam of features and best practices.
BTW, can we also get the 'The Humpty-Dumpty Guide to Functional Programming' which is as vague as OOP.
Over the years I've come to realize the the 'P' in OOP is not important at all. What you technically can or cannot do in a given programming language isn't really that important. In my opinion it should be OOT where 'T' stands for "thinking". To be able to "think" in objects is so much more important and beneficial than to understand some technical language construct.
Object thinking is actually a word (and also a book [1], but that is less important); and I agree. A definition of OOP and FP that focuses on how programmers are guided to solve problems would be much more useful. With OOP, you think in terms of objects and their interactions (names and naturalism rule). With FP, you are supposed to think more about the math of the program's universe (structure and equational reasoning rules), or maybe its just about the verbs and processes (for less pure styles).
[1] http://www.amazon.com/Object-Thinking-Developer-Reference-Da...
How could it be "beneficial" to artificially limit your thinking into such a narrow, mostly useless, alien framework? How can one see the world in all of its endless variety as a boring and irrelevant set of hierarchical taxonomies of message-passing entities?
Yes, that was something that always bugged me. I find it hard to model the real world using OOP constructs - something OOP was advertised as well-suited for.
Yeah, OOP is a fuzzy concept :) It reminds me of discussion under Eric Lippert's answer - http://programmers.stackexchange.com/a/234563/29029 - about whether OOP requires classes.