6 ms·

Are we beginning to see the tipping point where mainstream corporates are starting to question whether traditional OO is the right way to go? Not to start a fl

Are we beginning to see the tipping point where mainstream corporates are starting to question whether traditional OO is the right way to go? Not to start a flame war, but it seems that Clojure/Rich's strong anti-OO stance is almost a selling point of the language. IMHO, OO just put some lipstick on the procedural pig.

dominotw 12y ago
>Are we beginning to see the tipping point where mainstream corporates are starting to question whether traditional OO is the right way to go? Nope. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... First functional language on that list is F# at 19.
- RussianCow 12y ago
  "beginning to see" != "already at". There is TONS of existing code written in OO languages--you can't expect functional languages to replace that overnight. However, functional languages like Clojure and F# are starting to become more common, even in corporate environments. (I know eBay and Wallmart use Clojure for some of their projects, among others.) I don't know if the trend will continue (my guess is yes), but you shouldn't dismiss it just because C, C++, and Java are still the most widely-used programming languages in the world.
  - dominotw 12y ago
    But uptick is not significant enough to say that they have enough momentum. Most companies like amazon write services in lots of different languages. Just using a language is not enough proof, do you have examples of major services written in functional languages at these enterprise companies?
    - erichmond 12y ago
      Agreed there need to be "more" wins, but the amazon service seems like a pretty big one. From: https://lispjobs.wordpress.com/2014/11/25/clojure-software-development-engineers-amazon-com/ https://lispjobs.wordpress.com/2014/11/25/clojure-software-d... CORTEX is our next generation platform that handles real-time financial data flows and notifications. Our stateless event-driven compute engine for dynamic data transforms is built entirely in Clojure and is crucial to our ability to provide a highly agile response to financial events. We leverage AWS to operate on a massive scale and meet high-availability, low-latency SLAs.
- dj-wonk 12y ago
  Yes? No? Let's avoid false binary choices. A better question here is "to what degree?" That list's methodology seems somewhat arbitrary, but let's go with it. If you look at many top languages in use by a lot of companies, many have increasing functional aspects: Java (#2), Python (#8), and R (#12). (I may have left out some, too.) Python has many functional aspects. Java 8 brings lambda expressions. R has first-class functions and lazy evaluation. I'd say this is less about functional programming "destroying" OO and more about programmers reaching for some aspects of FP when OO brings too much complexity. For example, why create a new class just to write an event handler? Even Java is getting the picture!
seanmcdirmid 12y ago
Clojure is continuing the LISP subculture that has existed for a long time, nothing new here. OO will continue to be successful for accessibility reasons, and it's demise will continue to be predicted to have arrived.
- twic 12y ago
  I think you're right about OO's continued survival. I also think mikerichards is right that OO is just technicolor procedural programming. Moreover, i think these two things are related: OO is immortal in part because it's straightforward and obvious, just like procedural programming. But i don't think Clojure is just continuing the (equally immortal!) LISP subculture. I think LISP is growing by recruiting people from OO-ish languages like Java, Python, and Ruby, rather than from existing LISPs. This is the first time in a long time that a LISP has done that. It's also the first time in a long time that a LISP has got even this glimmer of mainstream use. pg wrote 'Beating the Averages' in 2001 [1], and even after that, everyone still thought LISPers were freaks. But announce you're using Clojure in production today, and nobody bats an eye. [1] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
  - seanmcdirmid 12y ago
    The advantage of OO has always been its accessible constructs and abstractions that mirror how we talk about things linguistically. Nouns are just sticky that way. It isn't a big delta over procedural programming, and you can find object systems in many C programs written before OOP was even a word. Heck, even Clojure has its own object systems; they just often call them entities rather than objects (what is an entity? well, its an object, but not the object you are used to). I think our current OO abstractions suck, but the paradigm is OK, especially when considered in the abstract (go back to the treaty of Orlando to see how diverse objects can be!). And the biggest pushers of objects in the early day were CLOS people like Richard P Gabriel, and CLOS (edit: Flavors actually as lipsm points out) gave us mixins, which are a pretty advanced OO construct (though RPG argues the mixins that got adopted in OO languages were not the ones CLOS intended). People were using LISP in production in the 90s as an advantage, but then they were also using Smalltalk or Objective C also (ironically often in the same places...on Wall street). A new generation is discovering LISP while learning other languages first, but the phenomena is the same: OO was just less popular in the past and so they would come from C or Perl instead of Java. [edit: not sure why you were downvoted, I thought your post was completely reasonable]
geophile 12y ago
Yes, that's exactly what it did. I started my programming career in FORTRAN and BASIC, and really appreciated the advances of structured programming and the control structures in the languages that supported it -- the Algol family, Pascal, C. I see OO as doing more of the same, providing language constructs for commonly used patterns, and I think it is very successful at doing that. I think that a lot of the OO hatred comes from OOs failure at meeting goals that were claimed during the peak of the OO hype cycle. I think that another, well-justified source of hatred is the architecture astronaut stuff -- AbstractFactoryProxyFactory and the like. Personally, I like Clojure (which I am just learning now) in spite of the lack of objects. I think that the ability to write a Point class, encapsulate the coordinates, and expose an API is great. In my opinion, representing a Point as a vector or map, and then having a set of unassociated functions operating on these point-like collections sacrifices some good ideas that came from object-orientation.
- adambard 12y ago
  > Personally, I like Clojure (which I am just learning now) in spite of the lack of objects. I think that the ability to write a Point class, encapsulate the coordinates, and expose an API is great. In my opinion, representing a Point as a vector or map, and then having a set of unassociated functions operating on these point-like collections sacrifices some good ideas that came from object-orientation. Since you mentioned you were learning, I thought I'd share that, although I like functions-on-data as much as the next guy, I often use protocols and records for tasks like this, generally for no reason other than organization and self-documentation: (defprotocol Pointy (add-vectors [this other]) ; ... ) (defrecord Point Pointy (add-vectors [{this-x :x this-y :y} {other-x :x other-y :y}] (->Point (+ this-x other-x) (+ this-y other-y))) ;... ) I think this has more to do with type-safety than object-orientation though.
  - weavejester 12y ago
    Protocols and records exist purely for polymorphism. If you want type safety, then perhaps try core.typed: (defalias Point (HMap :mandatory {:x Num, :y Num} :complete? true)) (ann add-vectors [Point Point -> Point]) (defn add-vectors [a b] {:x (+ (:x a) (:x b)) :y (+ (:y a) (:y b))})
lmm 12y ago
Scala remains ahead of Clojure because it permits traditional OO. OO is wonderful; try writing some programs in a language that forces you to do proper OO (e.g. Smalltalk). Even if you ultimately decide you prefer non-OO, you'll learn techniques that make your programs better, and you'll at least be able to understand the thing you're criticising.
- psykotic 12y ago
  > OO is wonderful; try writing some programs in a language that forces you to do proper OO (e.g. Smalltalk). Have you tried implementing a numeric tower with proper OO in Smalltalk? Would you describe the experience as wonderful and the program as beautiful? Rinse and repeat for any other problem that requires simultaneous pattern matching on several values. I do think Smalltalk's style of single-receiver message passing is a sweet spot for structuring many kinds of programs.
  - dragonwriter 12y ago
    > Have you tried implementing a numeric tower with proper OO in Smalltalk? The number of languages that I've seen with a proper numeric tower that aren't Scheme (or direct descendants of Scheme like Racket) are zero, so "OO makes it hard to do something almost no one ever does"...? > Rinse and repeat for any other problem that requires simultaneous pattern matching on several values. No problem requires pattern matching, much less on several values, any more than a problem requires OOP. Pattern matching and OOP are idioms that can be used to solve problems, but they are never the exclusive idiom that can be used to solve a problem (though either might be the only one that a particular language provides.)
    - psykotic 12y ago
      > The number of languages that I've seen with a proper numeric tower that aren't Scheme (or direct descendants of Scheme like Racket) are zero, so "OO makes it hard to do something almost no one ever does"...? It doesn't have to be an elaborate Scheme or Common Lisp numeric tower. I mean any kind of lattice ("X and Y gives Z") that would normally be implemented with case analysis. Especially if that lattice has symmetries (e.g. commutativity). > No problem requires pattern matching, much less on several values Of course, but I think you know what I mean. Take any of the standard problems that are not amenable to natural forms of cascaded single dispatch. Pattern matching has its own limitations, but sometimes it's the right tool for the job.
swannodette 12y ago
Clojure's anti-OO stance is far subtler than people seem to understand. It's primarily about not reaching for classes as a first tool and eliminating local state (and even this is allowed!) However there are times when the OO approach makes sense and you have a full range of tools from multimethods to protocols. In ClojureScript you even have Self-like functionality in the form of `specify`.
- mikerichards 12y ago
  Multimethods and Protocols seem to get better results than what OO is trying to achieve...at least when it comes to polymorphism.
- dkersten 12y ago
  Is there any documentation on "specify"? I've seen it used from time to time (eg in your Om code), but the only documentation I've found is the dev wiki page[1]. [1] http://dev.clojure.org/display/design/specify+i.e.+reify+for+instances http://dev.clojure.org/display/design/specify+i.e.+reify+for...
  - swannodette 12y ago
    At the moment there is not, someone should add something to the wiki. Basically it clones the target and adds the specified protocol implementations - basically instance level extend-type.
  - ddellacosta 12y ago
    This is an old post but I talk about it a bit here (toward the bottom): http://www.davedellacosta.com/cljs-protocols http://www.davedellacosta.com/cljs-protocols (I need to update my github link to point to a static version of Om's code!)
ww520 12y ago
> Not to start a flame war, but it seems that Clojure/Rich's strong anti-OO stance is almost a selling point of the language. > IMHO, OO just put some lipstick on the procedural pig. <sarcasm> Not to start a flame war, IMHO functional bigots just like to incite language wars rather than solving real problems. </sarcasm>

dominotw 12y ago

>Are we beginning to see the tipping point where mainstream corporates are starting to question whether traditional OO is the right way to go? Nope. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... First functional language on that list is F# at 19.

RussianCow 12y ago
"beginning to see" != "already at". There is TONS of existing code written in OO languages--you can't expect functional languages to replace that overnight. However, functional languages like Clojure and F# are starting to become more common, even in corporate environments. (I know eBay and Wallmart use Clojure for some of their projects, among others.) I don't know if the trend will continue (my guess is yes), but you shouldn't dismiss it just because C, C++, and Java are still the most widely-used programming languages in the world.
- dominotw 12y ago
  But uptick is not significant enough to say that they have enough momentum. Most companies like amazon write services in lots of different languages. Just using a language is not enough proof, do you have examples of major services written in functional languages at these enterprise companies?
  - erichmond 12y ago
    Agreed there need to be "more" wins, but the amazon service seems like a pretty big one. From: https://lispjobs.wordpress.com/2014/11/25/clojure-software-development-engineers-amazon-com/ https://lispjobs.wordpress.com/2014/11/25/clojure-software-d... CORTEX is our next generation platform that handles real-time financial data flows and notifications. Our stateless event-driven compute engine for dynamic data transforms is built entirely in Clojure and is crucial to our ability to provide a highly agile response to financial events. We leverage AWS to operate on a massive scale and meet high-availability, low-latency SLAs.
dj-wonk 12y ago
Yes? No? Let's avoid false binary choices. A better question here is "to what degree?" That list's methodology seems somewhat arbitrary, but let's go with it. If you look at many top languages in use by a lot of companies, many have increasing functional aspects: Java (#2), Python (#8), and R (#12). (I may have left out some, too.) Python has many functional aspects. Java 8 brings lambda expressions. R has first-class functions and lazy evaluation. I'd say this is less about functional programming "destroying" OO and more about programmers reaching for some aspects of FP when OO brings too much complexity. For example, why create a new class just to write an event handler? Even Java is getting the picture!

seanmcdirmid 12y ago

Clojure is continuing the LISP subculture that has existed for a long time, nothing new here. OO will continue to be successful for accessibility reasons, and it's demise will continue to be predicted to have arrived.

twic 12y ago
I think you're right about OO's continued survival. I also think mikerichards is right that OO is just technicolor procedural programming. Moreover, i think these two things are related: OO is immortal in part because it's straightforward and obvious, just like procedural programming. But i don't think Clojure is just continuing the (equally immortal!) LISP subculture. I think LISP is growing by recruiting people from OO-ish languages like Java, Python, and Ruby, rather than from existing LISPs. This is the first time in a long time that a LISP has done that. It's also the first time in a long time that a LISP has got even this glimmer of mainstream use. pg wrote 'Beating the Averages' in 2001 [1], and even after that, everyone still thought LISPers were freaks. But announce you're using Clojure in production today, and nobody bats an eye. [1] http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- seanmcdirmid 12y ago
  The advantage of OO has always been its accessible constructs and abstractions that mirror how we talk about things linguistically. Nouns are just sticky that way. It isn't a big delta over procedural programming, and you can find object systems in many C programs written before OOP was even a word. Heck, even Clojure has its own object systems; they just often call them entities rather than objects (what is an entity? well, its an object, but not the object you are used to). I think our current OO abstractions suck, but the paradigm is OK, especially when considered in the abstract (go back to the treaty of Orlando to see how diverse objects can be!). And the biggest pushers of objects in the early day were CLOS people like Richard P Gabriel, and CLOS (edit: Flavors actually as lipsm points out) gave us mixins, which are a pretty advanced OO construct (though RPG argues the mixins that got adopted in OO languages were not the ones CLOS intended). People were using LISP in production in the 90s as an advantage, but then they were also using Smalltalk or Objective C also (ironically often in the same places...on Wall street). A new generation is discovering LISP while learning other languages first, but the phenomena is the same: OO was just less popular in the past and so they would come from C or Perl instead of Java. [edit: not sure why you were downvoted, I thought your post was completely reasonable]

geophile 12y ago

Yes, that's exactly what it did. I started my programming career in FORTRAN and BASIC, and really appreciated the advances of structured programming and the control structures in the languages that supported it -- the Algol family, Pascal, C. I see OO as doing more of the same, providing language constructs for commonly used patterns, and I think it is very successful at doing that. I think that a lot of the OO hatred comes from OOs failure at meeting goals that were claimed during the peak of the OO hype cycle. I think that another, well-justified source of hatred is the architecture astronaut stuff -- AbstractFactoryProxyFactory and the like. Personally, I like Clojure (which I am just learning now) in spite of the lack of objects. I think that the ability to write a Point class, encapsulate the coordinates, and expose an API is great. In my opinion, representing a Point as a vector or map, and then having a set of unassociated functions operating on these point-like collections sacrifices some good ideas that came from object-orientation.

adambard 12y ago
> Personally, I like Clojure (which I am just learning now) in spite of the lack of objects. I think that the ability to write a Point class, encapsulate the coordinates, and expose an API is great. In my opinion, representing a Point as a vector or map, and then having a set of unassociated functions operating on these point-like collections sacrifices some good ideas that came from object-orientation. Since you mentioned you were learning, I thought I'd share that, although I like functions-on-data as much as the next guy, I often use protocols and records for tasks like this, generally for no reason other than organization and self-documentation: (defprotocol Pointy (add-vectors [this other]) ; ... ) (defrecord Point Pointy (add-vectors [{this-x :x this-y :y} {other-x :x other-y :y}] (->Point (+ this-x other-x) (+ this-y other-y))) ;... ) I think this has more to do with type-safety than object-orientation though.
- weavejester 12y ago
  Protocols and records exist purely for polymorphism. If you want type safety, then perhaps try core.typed: (defalias Point (HMap :mandatory {:x Num, :y Num} :complete? true)) (ann add-vectors [Point Point -> Point]) (defn add-vectors [a b] {:x (+ (:x a) (:x b)) :y (+ (:y a) (:y b))})

lmm 12y ago

Scala remains ahead of Clojure because it permits traditional OO. OO is wonderful; try writing some programs in a language that forces you to do proper OO (e.g. Smalltalk). Even if you ultimately decide you prefer non-OO, you'll learn techniques that make your programs better, and you'll at least be able to understand the thing you're criticising.

psykotic 12y ago
> OO is wonderful; try writing some programs in a language that forces you to do proper OO (e.g. Smalltalk). Have you tried implementing a numeric tower with proper OO in Smalltalk? Would you describe the experience as wonderful and the program as beautiful? Rinse and repeat for any other problem that requires simultaneous pattern matching on several values. I do think Smalltalk's style of single-receiver message passing is a sweet spot for structuring many kinds of programs.
- dragonwriter 12y ago
  > Have you tried implementing a numeric tower with proper OO in Smalltalk? The number of languages that I've seen with a proper numeric tower that aren't Scheme (or direct descendants of Scheme like Racket) are zero, so "OO makes it hard to do something almost no one ever does"...? > Rinse and repeat for any other problem that requires simultaneous pattern matching on several values. No problem requires pattern matching, much less on several values, any more than a problem requires OOP. Pattern matching and OOP are idioms that can be used to solve problems, but they are never the exclusive idiom that can be used to solve a problem (though either might be the only one that a particular language provides.)
  - psykotic 12y ago
    > The number of languages that I've seen with a proper numeric tower that aren't Scheme (or direct descendants of Scheme like Racket) are zero, so "OO makes it hard to do something almost no one ever does"...? It doesn't have to be an elaborate Scheme or Common Lisp numeric tower. I mean any kind of lattice ("X and Y gives Z") that would normally be implemented with case analysis. Especially if that lattice has symmetries (e.g. commutativity). > No problem requires pattern matching, much less on several values Of course, but I think you know what I mean. Take any of the standard problems that are not amenable to natural forms of cascaded single dispatch. Pattern matching has its own limitations, but sometimes it's the right tool for the job.

swannodette 12y ago

Clojure's anti-OO stance is far subtler than people seem to understand. It's primarily about not reaching for classes as a first tool and eliminating local state (and even this is allowed!) However there are times when the OO approach makes sense and you have a full range of tools from multimethods to protocols. In ClojureScript you even have Self-like functionality in the form of `specify`.

mikerichards 12y ago
Multimethods and Protocols seem to get better results than what OO is trying to achieve...at least when it comes to polymorphism.
dkersten 12y ago
Is there any documentation on "specify"? I've seen it used from time to time (eg in your Om code), but the only documentation I've found is the dev wiki page[1]. [1] http://dev.clojure.org/display/design/specify+i.e.+reify+for+instances http://dev.clojure.org/display/design/specify+i.e.+reify+for...
- swannodette 12y ago
  At the moment there is not, someone should add something to the wiki. Basically it clones the target and adds the specified protocol implementations - basically instance level extend-type.
- ddellacosta 12y ago
  This is an old post but I talk about it a bit here (toward the bottom): http://www.davedellacosta.com/cljs-protocols http://www.davedellacosta.com/cljs-protocols (I need to update my github link to point to a static version of Om's code!)

ww520 12y ago

> Not to start a flame war, but it seems that Clojure/Rich's strong anti-OO stance is almost a selling point of the language. > IMHO, OO just put some lipstick on the procedural pig. <sarcasm> Not to start a flame war, IMHO functional bigots just like to incite language wars rather than solving real problems. </sarcasm>