Comments on: What’s there after Objects?

By: Greg M

Greg M — Thu, 10 Jul 2008 03:56:35 +0000

As a rough generalization: OOP gives you a single layer of abstraction, and then you wonder why it doesn’t scale. FP gives you tools (higher-order functions, expressive type systems) with which to build your own layers of abstraction at the granularity that’s appropriate for your problem domain. This way you don’t suffer the disconnect you cite between the high level and the low level. (and yes,as a bonus because you can state your intention more clearly it’s easier for your compiler to optimise it for increasingly complex hardware – but that’s only a bonus which I’m not sure is too important at this stage)

As I see it, abstraction and quarantining the effects of state are the two biggest factors in program complexity, and OOP tries to apply one mechanism to handle both of them. FP handles state properly (i.e. explicitly!), leaving you free to use abstraction to model your problem domain, rather than having your abstractions partially dictated by the machine model. So although adding functional features to OOP languages can be convenient, it doesn’t deliver the necessary paradigm shift. But hopefully it _will_ smooth the way to mainstream adoption of referential transparency as a basic language requirement.

By: The End of an Era, the Beginning of a New One

The End of an Era, the Beginning of a New One — Sat, 28 Jun 2008 18:55:39 +0000

[...] What’s there after Objects? [...]

By: Sébastien

Sébastien — Fri, 27 Jun 2008 23:43:10 +0000

This article is really enlightening, even though it’s four years old. Now Sergey underlines 3 major issues with mainstream OOP languages: expressivity, maintainability and learning curve. I would personnally add the quality issue. Since there is so much work needed to translate your ideas into code, there is all the more space for human errors and we’ve come to see practices like TDD as a necessary virtue, even though they are merely a workaround for the limitations of OOP.

By: Sébastien

Sébastien — Fri, 27 Jun 2008 22:46:43 +0000

Oh my! That Language Oriented Programming is exactly what I was starting to think about. This is exactly what I needed. Those Jetbrains guys definitely have some talent. Walter, thanks a lot for the link: I think I’ll investigate a lot in that direction.

Alex, I kind of agree with you: those will not replace OOP but merely superset it, like OOP does with procedures and functions (that are now methods), and like we’re still using assembly language in the virtual machine for example. But if those lower level constructs are hidden behind a set of more powerful tools, I think it will be for the greater good. I like Sergei’s analogy of stone and fire ages. It’s exactly that.

By: Alexander Snaps

Alexander Snaps — Fri, 27 Jun 2008 11:48:02 +0000

JetBrains’ MPS and DSL are indeed an abstraction above, yet they address a different issue. And as of now, it would be expected out of “developers” to use a _set_ of DSL inside one application, and not a simple language.
You probably also would want to see the “Building DSLs in Static & Dynamic Languages” presentation by Neal Ford.
Yet those will not be replacing, but “supersetting” lower level languages.

By: Walter Mourão

Walter Mourão — Fri, 27 Jun 2008 11:38:06 +0000

It looks to me the following article has a point: http://www.onboard.jetbrains.com/is1/articles/04/10/lop/ . And looks like some ideas could be used in Andromda.

By: Ricky Clarkson

Ricky Clarkson — Thu, 26 Jun 2008 22:32:16 +0000

Functional programming doesn’t mean that you have to think about your customer’s problems purely in terms of functions and lambdas any more than OOP means that you have to think in terms of message passing and inheritance. We programmers have a tool called abstraction. Given a language with only lambda and a few other primitives, you can build datatypes, give them names, associate operations with them, etc. You could even call them objects.

The main difference is that you wouldn’t typically change their state, but construct new objects to represent new state. This makes it easier to compose larger systems from small parts, because the larger systems no longer suffer from having more moving parts.

The best way I know to say it briefly is a little ambiguous, but here goes: OOP seeks for values to *be* items from the domain, whereas functional programming seeks for values to *model* items from the domain.

A model of a tennis ball flying through the air might never mutate an instance of Ball, but be a function over time. An object seeking to *be* a tennis ball is tempted to have a value according to the time involved. The non-mutating model is more composable – each user of it does not need to know what each other user of it is doing.

Another approach is to refine your OOP programs as far as you can. Reduce duplication. Remove it entirely and you probably reinvented functional programming.

By: Alexander Snaps

Alexander Snaps — Thu, 26 Jun 2008 17:07:26 +0000

This isn’t really performance related… While it does also address it.
Yet multi-core systems are becoming (oh wait, they already are) reality! And multi-threading as always been something (especially in UI) developers had to address, particularly in the gaming industry. Yet concurrency is a complex topic and you can’t really expect having every average developer deal with it correctly, especially in OO. The situation is simply there and functional programming addresses it. This just correlates well. Now if this (r)evolution is leading us down the right path, I have no clue… Hopefully there isn’t just a single path! Still, mathematicians will always tell you that functions are better suited to model the world than our objects…

By: Sébastien

Sébastien — Thu, 26 Jun 2008 16:53:15 +0000

It’s interesting because it seems like a schism between people favoring the intrinsic “performance” of software paradigms and those who favor the “usability” of it. And I have the impression that both directions are antagonist, like you can’t have a paradigm that is both intuitive and optimized.

As far as I’m concerned, when I realize that there is about the same calculation power in an iPod as what Appollo had in their ship when they landed on the moon, I tend to think that optimization is not and will never be a mainstream issue IN SOFTWARE. That’s why I don’t think that a paradigm whose primary purpose if to make things more performant or mathematically more correct will not solve what seems to me as our main issue: software usefulness.

By: Alexander Snaps

Alexander Snaps — Thu, 26 Jun 2008 16:44:15 +0000

I would tend to agree with Rick. Especially as the multi-core systems are rising and today developers don’t have the tools to address this…
It is an industry driving force already, and while many of us stick their head in the sand, we will have to face it, rather sooner than later. Function oriented programming languages might be a solution and hence might gain a whole lot of popularity. Scala already being labeled as Java 3 by “people”…