Programming without objects

Honestly, while I think OO programming in the broadest sense does that, I think class-oriented OOP (what the article mostly focusses on) languages, particularly statically-typed class-oriented languages in the C++/Java lineage--don't do a great job of either supporting that intuition or facilitating applying it intuition to the construction of correct, maintainable computer programs. They aren't useless in that respect--there is a reason why they flourished--but there's also a reason that after them an important programming paradigm for several decades, and a dominant one since at least the late 1980s, there's a whole lot of moves away from traditional class-oriented OOP in newer languages.

I think that we're seeing a model--which is mostly viewed as being within the FP tradition but which has learned a lot from OOP languages and supports a lot of OO thinking--emerge (and that this article points to a lot of its elements) that provides a framework that better matches the intuition than class-oriented OOP does, while also better supporting building correct, maintainable, easy-to-reason-about systems.

No, skeuomorphism involves ornamental details, which are at best hints about how something is to be used.

How you break-down the responsibilities of your system and name them is much much more important than that.

With how widespread OO is now and in the last decades, how much it is taught and how important it is in a fair share of popular programming languages (or even mandatory, for all practical purposes), this point might just be a self-fulfilling prophecy (if I'm using that expression correctly).

I would consider this a disadvantage, not an advantage. Human thoughts are imprecise and carry rich but ambiguous connotations. The major advances of mathematics in the 19th century (or thereabouts) onward are closely tied to the divorce of notation and natural language.

The ancient version of the Pythagorean theorem is something like, "The area of a square whose side is the length of a hypoteneuse of a right triangle is equal to the sum of the areas of squares whose sides are equal in length to the other two sides." A modern version is more like, "Let a, b, c be the lengths of sides of a right triangle, where c is the length of the hypoteneuse. Then a^2 + b^2 = c^2." You can see as time goes on, the text becomes simultaneously clearer, more concise, and more abstract.

This is why natural language programming is doomed to failure. Others have expressed the point better than I do (notably Dijkstra). But you can look at the examples of how inheritance in class-based OOP systems work and you will get sick just looking at them: examples of Dog inheriting from Animal, and Penguin from Bird (but penguins don't fly), et cetera. The real disadvantage here is that once people start thinking about taxonomy in general (which class-based OOP encourages), you're not thinking about programming any more.

The difficulty people have with even simple problems like "how do you describe squares and rectangles in a computer program" is another good illustration of how the class-based object-oriented system of thinking is unsuited for solving computational tasks, at least compared to the alternatives.

I first encountered functional programming in the 1980s on my Computer Science degree course a few years before I encountered OOP (CLOS and then C++) and I'm not convinced that OOP is fundamentally closer to "how humans think" than FP. Most programmers these days were taught an OOP language first so think that is most natural - but I don't think there is anything fundamental about that.

It seems to me that you're sort of confusing OOP with programming interfaces.

An interface describes a model of how to use a certain piece of code, and indeed a good one can be almost "obvious" and it begins to feel like a "natural" way to reason with it. But it's all about the interface: not about from what kind of language constructs the interface is composed of.

Interfaces can be done in object oriented programming too but for some reason, possibly exactly because of the resemblance to real items and concepts and how human people are so fond of those, most interfaces in OOP languages are utter horror.

This could be because it's so easy and almost fundamental to create "things that do stuff", i.e. classes in OOP, there will be a lot of them. The design pattern craze kind of formalized that for good, which is why we've all enjoyed our share of abstract factory builder singleton visitor, or whatever.

In contrast, you tend to see really good interfaces surprisingly often in... C.

As a disclaimer, this is a big reason why I like C language -- it forces you to think simple because it offers so many guns to shoot yourself in the foot and a lot of other places too that you need to focus on what's essential to your program. With an easier but inevitably more complex language, the lull times in the day of programming seem to produce lots of implementation and interfacing complexity that a C programmer would never dare to attempt. C programmers also use paradigms associated with OO but only where appropriate because it's a bit of hurdle to implement those in C.

I've also observed that there's a vague parallel between complex (object oriented) interfaces vs. simple (C) interfaces and the Alan Perlis' notion of to better have 100 functions operating on one data structure rather than 10 functions operating on 10 data structures. Good OO interfaces tend to be really simple and short, even so that they're not even particularly OO anymore.

The OO, procedural, FP paradigms are mostly orthogonal and can be combined freely in sensible amounts where needed, but they're also orthogonal to concepts such as encapsulation, polymorphism, type hierarchies, and inheritance which themselves aren't tied together either.

Citation needed.

Browsing around Google Scholar for variations of "object oriented empirical comparison" shows a huge body of research comparing various OO approaches to each other, but very few comparing OO approaches to anything else. Those which I have been able to find compare OO to procedural code, and find either no significant difference in comprehension levels, or that procedural code is easier to understand (ie. closer to "how humans think") than OO:

An empirical study of novice program comprehension in the imperative and object-oriented styles

http://ftp.cs.duke.edu/courses/fall00/cps189s/readings/p124-...

Assessing the cognitive consequences of the object-oriented approach: A survey of empirical research on object-oriented design by individuals and teams

http://arxiv.org/pdf/cs.HC/0611154

An exploratory study of program comprehension strategies of procedural and object-oriented programmers

http://www.ptidej.net/courses/inf6306/fall11/slides/11%20-%2...

I've only been able to find one source comparing OO with functional programming, which didn't measure comprehension. Instead, it compared code quality metrics between C++ and Standard ML. Most showed no significant difference, except for SML taking longer to run its tests (it also had more tests), having higher code and library re-use and having a larger number of errors per 1000 lines (although the same number of known errors overall):

Comparing programming paradigms: an evaluation of functional and object-oriented programs

http://eprints.soton.ac.uk/250597/1/report3_Harrison_95.pdf

Steve Yegge's "Execution in the Kingdom of Nouns" has some interesting commentary on the idea of OO being in any way how humans think. The allegory has some harsh things to say about Java, which are not my intention in suggesting this link. The observations that objects tend to be nouns while functions tend to be verbs is very interesting.

/* footnote 3 is hilarious */

Let's not confuse "how humans think" with "how humans ought to think to self problems effectively". There is little evidence that OO is any better than other principled approaches to programming.

Objects are always a struggle. I see students new to programming take as long as their junior year before they even start to "really get it" and design reasonable classes.

Rolling identity, state, values, types, functions, polymorphism, modules, resource management, and who knows what else into a single thing is inherently going to result in something pretty damn complicated, compared to trying to keep those concerns orthogonal and thus only pulling in those that are needed for the task at hand.

I would certainly say that OOP-based software engineering has vast advantages in certain cases, but my hypothesis would be that its "ease" advantages is more one of mindshare rather then something inherent in the human mind. This hypothesis, however, is worth extensively testing... for a discipline that relies on stretching human cognitive performance to its limits, we spend far too little time actually figuring out exactly what limits those are.

I avoid "traditional" OO in my own work for the some of the same reasons the author points out; not least of which that traditional classes are a kitchen sink.

But many of the ideas of OO; notably extensionality (what the author incorrectly calls intensionality), I could never do without. I agree with you, that exposing the innards of my data structures is a crime: not only do I lose control over their construction and use (including defining equality), but I'm restricted from ever modifying the structure.

But nothing in FP prevents hiding structure. You can see it all the time in OCaml: a module signature will declare an opaque, possibly parametric, type, as well as a set of operators over that type. The internal structure of that type is never exposed. All creation and use, and ideally comparisons (though it is unfortunately not enforced in OCaml) must go through the module's API.

(Module signatures, it should be noted, may be shared by multiple implementations, permitting compile-time dispatch.)

Yet while maintaining opacity, I am free to dispense with the excess baggage an OO class entails: run-time dispatch; a single "self" (i.e. the "friend" problem); that abomination known as inheritance; all these things I need no longer worry about, and my code can be cleaner and more efficient.

The core FP idea is to focus on immutable data and data transformations. This is the minimal set of concepts one needs to juggle to get computations going. When modules communicate, they need to pass data and identify the transformations, so there is no dichotomy here between FP and OO (!). Especially if you think of method tables as data.

The String / Data.Text split in Haskell is an artefact of Haskell's ecosystem. It is not a conceptual hurdle, but rather an implementation detail. It is not too hard to imagine a different FP ecosystem where one can readily substitute different implementations under the same immutable data structure API, all with very explicit parametrization of the data transformations. All of (1)immutability, (2)simple data API, (3)polymorphism and (4)explicitism are important. Note that OO systems encourage (3), while FP systems encourage (1), (2) and (4).

Code as if you have immutable data and apply data transformations, tune performance by using the best implementations under the common simple data API. The question becomes how to build a system where all of them are ergonomic to use. IMHO, Haskell is not quite it, rather places like Dart / C# offer better ergonomics.

The other example is also thought provoking. In a system with polymorphism support, it's relatively straightforward to supply one's favorite String implementation, including one that prints a log on every String construction. The question is how to provide the new module to clients, which is reminiscent of dependency injection, but concrete implementations of DI are magic bad. In an explicit style, this would be realized by making modules functors of other modules and explicitly passing in the method tables:

  function Foobar(string) 
    return {
      foo: function(x) 
        return string.concat(x, string.new('abc')) 
      end
    }
  end

  function main1()
    string = String()
    foobar = Foobar(string)
    foobar.foo(string.new('xyz'))
  end

  function LoggingString()
    return String() + {
      new: function(x)
        print(x)
        return String.new(x)
      end
    }
  end

  function main2()
    string = LoggingString()
    foobar = Foobar(string)
    foobar.foo(string.new('xyz'))
  end

There are a lot of things wrong with, say, Haskell '98 from the perspective of a modern Haskell programmer. Strings are one, but monads aren't applicative functors, it took us a long time to figure out how we wanted to write monad transformers, lazy I/O is terrible and we should use conduits or whatever instead. But you picked strings. This example does not help your point for the following reasons:

1. You can't just change the implementation of the string type without messing up someone's program. For a fantastic example, look at the recent change to Oracle's string type in Java. In theory, the interface is the same. In practice, it made a bunch of people mad.

2. You can encapsulate data in Haskell. Look at the "Text" data type, and ignore Text.Unsafe which exposes the gory innards. This is module level encapsulation, which is just as good as class-level encapsulation (better, actually, since it's more flexible). You could replace Text with a UTF-8 implementation or a UTF-32 implementation or some magic implementation that switches between the types, and you wouldn't break consumers of the Text interface.

> For example, try modifying a Haskell program to print a log every time a string is made. You can't!

This is a really contrived example. First of all, there is the question of whether you will need to create a string whenever you log something to a file, and presumably you wouldn't want to log those strings. Second, this is something you'd do with a debugger, you wouldn't actually do this to a program.

Besides, if you had access to the string implementation (which I'm assuming here is Text, because that's what most people use), you could just put some kind of unsafePerformIO call in front of uses of the Text constructor, and since the Text constructor isn't exported from the Text module, you're done.

You're conflating the fact that Haskell had poor modularity when it was first conceived and String first defined, with the claim that only OO can provide the necessary modularity.

Clearly ML modules provide and always provided the necessary modularity to abstract over string representations, but there's no OO in most MLs. And now with support for ML modules as first class values, we don't need objects for modularity at any level of programming.

I was exposed to functional programming my first year at university (it was used in the introductory courses) and quickly noticed that contrary to the hype (similar to yours), functional programs tended to be more bloated with trying to work around limitations of the less expressive programming model/language and not particularly more robust.

That doesn't mean certain aspects can't be nice to have ('let' is kinda nice), but even that is mostly for programming-in-the-small.

Your unsubstantiated claim of 3x productivity increase is, er, "interesting".

Here is the truth: in a few years, you'll realize that OOP is actually vastly superior to FP. It's okay if you don't believe me right now, you haven't progressed enough yet. Maybe you will, maybe you won't. If you succeed, you'll look back on FP and you will wonder how you could ever tolerate such an inferior programming model.

In this discussion of major programming paradigms it is important to realise a couple of things: That this is very old discussion and that there are no clear winner. The productivity and usefulness of a language is ultimately shown when it is put to the test of big practical development projects. Currently business is dominated by the object-orientated languages (C#, Java, JavaScript, Objective-C, C++ etc.) and probably for good reason: The dominant problems that software spends its line count on seems to be things like user interface and interface to other "platforms/paradigms" such as relational databases, web services or data files. Object-orientation have arguably shown itself to solve these problems well.

Why was OOP considered a good idea? Before OOP, programs were just structs and functions that operated on them. But as programs got larger, that approach broke down. Someone on a team of programmers would create an instance of a struct, but would initialize it in a way that some function (written by a different programmer) would regard the struct as having an inconsistent state. Or some function, which was meant to only be a helper function for other functions that were the API, would be called directly by some ignorant and/or lazy programmer. The result was increasing chaos as programs got larger.

OOP was viewed as the fix to that kind of problem. It was somewhat successful as a fix, too.

So the problem with most of these pro-FP articles is that they show you small examples. But the pre-OOP style worked fine on the small examples, too. In fact, almost any style works on small examples.

And showing that I can write the same thing in fewer lines by using FP isn't the answer, either. It's like saying that your algorithm has a smaller scaling constant than mine does. That's fine, but first let's talk about whether your algorithm is O(n^2) and mine is O(n log n). That is, if your approach scales worse than mine for large problems, then showing me that your way is more efficient for small problems completely misses the point.

But to build a convincing case for that, you'd have to do something like having a team of competent OOP programmers write a large-ish program (say, 10 person-years of work), and have a team of competent FP programmers write the same thing, and report on the results. Oh, yeah, and have the teams maintain the programs for five years. That could be a convincing paper, because it would address the actual issues.

Unix-like tools such as grep (or ghc) are very much like pure functions: programs that accept input, and produce an output data. It's not surprising that they lend themselves well to FP techniques. But other programs, like the web browser I'm using now, have lots of "inputs" and "outputs." There's many knobs that can be turned, and output goes to screen, disk, network, other programs...

I suspect these programs have a larger essential "hairiness." grep only has to search text. But Find in a text editor has to show a progress bar, cancel button, intermediate result count, etc. These features are intimately intertwined with the algorithm itself, and that's often hard in FP. Try writing a Haskell function that does text find/replace with live progress reporting. It's not easy, and it ends up looking a bit like Java.

Note that the land of unix-like coding isn't very good at UIs either!

Somehow nobody complains about this when coding in Erlang. Now do the analogy of actor ~ object.

Besides, why do you think that it's easier to think about large function composition graphs rather than large object graphs?

Interfaces are very heavily used, along with dependency injection (boy, do Java programmers love their dependency injection).

Inheritance is now widely discouraged. "Java Beans" are everywhere, which are glorified structs breaking every single rule of encapsulation.

Java runs fast, is garbage collected, has great support for multithreading, great Unicode support, and many other advantages. But it's certainly not very object oriented, especially in the Alan Kay sense.

FP languages have different ways to inject new behavior. You could for example define a function a -> (a -> Int) -> Int. This function now works for any type for which you can also provide the "interface" a -> Int.