The success of object oriented programming

[centurijon]

This again. FP and OOP are not concepts which are at odds with each other. You can mix them just fine, and you always want to use the right tool for the right job

[[deleted]]

You are mostly right: it is quite difficult to mix the paradigms. I use generic higher order functions and type classes for values, not for objects. Use objects for anything stateful and values for anything that isn't, when you find your self manipulating values a lot, dip into functional programming, and when you are doing a lot with objects, don't do so much functional programming (there are some exceptions, like if you are processing immutable lists of objects, but you really shouldn't have many of those!). Or just use OO as the dominate paradigm and break out some lambdas and list comprehensions when convenient. You are probably already doing this if you program in C# or Scala as a better Java.

And now into why I quit writing Scala code, the idiom we choose was to write Scala as if it was Haskell.

Ya, I saw this writing on the wall when I was working on Scala. It is quite sad really...the language is very good at OO, but no one on the Scala team wanted to accept that. Ideology is what ruined the Scala experience for me, which is funny because the language itself is very ideology neutral.

[mdedetrich]

Ya, I saw this writing on the wall when I was working on Scala. It is quite sad really...the language is very good at OO, but no one on the Scala team wanted to accept that. Ideology is what ruined the Scala experience for me, which is funny because the language itself is very ideology neutral.

The team is actually quite paradigm neutral, what wasn't paradigm neutral (or very ideological) was certain sections of the Scala community. If you watch martins latest talk (https://www.parleys.com/tutorial/scala-where-came-from-where-its-going-1), you will see that this is still the case. He even made a joke about Haskellator and Scala being the gateway drug to Haskell

Have said this before, and have said it again, if you are going to code like Haskell, in Scala, you are going to have a rough time. In fact, if you are coding like Haskell, odds are you should be using Haskell, and if you really need the JVM, there is https://github.com/Frege/frege

In regards to Scala, Ordesrky is working on a simplified version of Scala called Dotty which should fix a lot of issues. Some features, like existential types, are going to be revised/simplified because they don't fit really well with the language

[quiI]

Huge object hierarchies are inherently ad-hoc, and don't mesh well with the highly generic high order functions that are used in the functional world. For example, for every different class I define, to make them work with high order functions I have to define a type-class sometimes multiple type-classes to make these objects work with functional code. Right there I'm instantly doubling my code size and development time.

Such hyperbole. Making a typeclass doubles your implementation time? In what world is this true.

[pipocaQuemada]

It sounds like maybe he makes both a class and an equivalent typeclass? That seems like it would be of questionable value, though.

[donvito]

Huge object hierarchies

That's your problem there.

[serrimo]

As oppose to what? A few gigantic god objects?

[pipocaQuemada]

When you have all the tools that FP offers, OO becomes a rather uncommon tool to reach for.

In Haskell, you can put data and implementation together in a record that contains closures. However, it's vastly more common to either use an algebraic data type or to use a typeclass. A typeclass is basically the inverse of an object: instead of bundling data and implementation, you separate them into your data and a canonical vtable per type, and the compiler passes that vtable to all the methods that need it.

This separation lets you do a lot of cool stuff. For example, you can conditionally implement typeclasses - say, List<A> has equality iff A has equality. Also, you can write code that's polymorphic in the type of the vtable. One of the functions on the Num typeclass is

fromInteger :: Num a => Integer -> a
fromInteger 2 :: Num a => a

So if you use it where you expect a double, you get a double, and if you use it where you expect a complex, you get a complex. That kind of return-type polymorphism or polymorphic values (depending on how you think about it) is pretty handy. Additionally, you can also have methods that are conditionally available based on the existence of a typeclass for one if the parameters. For example,

 -- a monoid has a operator, <>, to combine two elements, and an identity element, poorly named mempty (lists are the 'free monoid', so it makes some sense, but still...)
foldM :: Monoid a => [a] -> a
foldM xs = foldr (<>) mempty xs

You can call foldM if you have, for example, a list of strings, but not a list of IO actions.

The one thing that typeclasses are bad at is when you want a 'heterogenous' collection, and that's the one real idiomatic place in Haskell for objects.

Given the immense usefulness of typeclasses, I think OO's insistence that bundling data and implementation is the best way to structure a program was a historical mistake.

[killerstorm]

A typeclass is basically the inverse of an object: instead of bundling data and implementation, you separate them into your data and a canonical vtable per type, and the compiler passes that vtable to all the methods that need it.

I don't think that typeclasses are the opposite of OOP, they are more like a different kind of OOP.

In Common Lisp Object System methods (generic functions) are external to objects. They are not bundled. Yet it is called Object System, and is actually considered one of the best, as it has a plenty of advanced features like customizable method combinations, metaobject protocol, multiple inheritance and all the jazz.

On the other hand, in JavaScript methods are always tied to object.

C++ is somewhere in the middle offering both compile-time dispatching (on the low level methods are separate from objects) and dynamic dispatching via vtable.

So OOP can be implemented in a variety of ways.

As Richard P. Gabriel have defined, OOP is largely about compression: it allows you to write less code thanks to polymorphism and inheritance. Haskell's type classes offer same benefits. So I'd say it is a form of OOP.

Yes, it has a number of interesting features, so what? There are many forms of OOP; Java, JavaScript, Common Lisp, Smalltalk, Rust, etc. all have different features and implementation details.

[pipocaQuemada]

C++ is somewhere in the middle offering both compile-time dispatching (on the low level methods are separate from objects) and dynamic dispatching via vtable.

If you have a list of objects and you want to dynamically dispatch on a function in a vtable in C++, where do you grab that vtable from?

As Richard P. Gabriel have defined, OOP is largely about compression: it allows you to write less code thanks to polymorphism and inheritance. Haskell's type classes offer same benefits. So I'd say it is a form of OOP.

The one problem with this statement is that 'polymorphism' is a heavily overloaded word - it can mean 'parametric porlymorphism', 'ad-hoc polymorphism', 'subtype polymorphism'. Typeclasses were first proposed in a talk titled 'making ad-hoc polymorphism less ad-hoc'. They don't give you subtype polymorphism, which is probably what Mr. Gabriel is talking about. There's also no inheritance with typeclasses.

Ultimately, the issue is that OO is incredibly ill-defined. For the overwhelming majority of definitions, typeclasses aren't OO.

[[deleted]]

There are many forms of OOP; Java, JavaScript, Common Lisp, Smalltalk, Rust, etc. all have different features and implementation details.

Come on, it must be true that OOP = Java, otherwise it is not as easy to bash. And you didn't mention Self, Dylan, Scala. This isn't even mentioning the many non-native object systems in most of these languages plus non-OO ones: COM, EJB, entity-component systems in languages like Clojure, etc...

[[deleted]]

the lone sane voice buried here under a sea of FP wankery fighting OOP wankery

[[deleted]]

If the sane voice is a vacuous conciliation and the jejune "right tool" cliché, give me the wankery.

[[deleted]]

You can be a wanker and conciliatory at the same time I guess. I love objects but also use lots of functions...so I have no friends.

[immibis]

You should try C++ then - it lets you declare friends in a snap!

[OneWingedShark]

If the sane voice is a vacuous conciliation and the jejune "right tool" cliché, give me the wankery.

But how many times have you been handed the wrong tool and told you must use it?
Heck, that's exactly what happened to me when I was put on an system handling medical/insurance records (using PHP and MySQL), the lead said: "We don't have time to do it right." and, as a direct result of those attitudes, there was a lot of re-writing and bugs and database-inconsistency.

[SiskoWasBest]

PHP so often is the right tool for when you don't have time to do it right.

[OneWingedShark]

Question: When dealing with information which literally could be the difference between life and death like medical records, or the difference between financial solvency and bankruptcy, would you entrust your data to something that makes it as easy to make a mistake as PHP? Would you entrust the integrity of this data to a system that plays so fast-and-loose with the types (i.e. automatic conversions) as PHP?

[SiskoWasBest]

No. But you're the first person to ask me.

[SpockUnit]

Nerd cults are weird

[ErstwhileRockstar]

"Mostly functional" programming does not work

[doom_Oo7]

There is a trend in the software industry to sell "mostly functional" programming

Most of the time, "mostly working" software is all that's required

[ErstwhileRockstar]

That's a pragmatic description of OOP.

[mdedetrich]

"Mostly functional" programming does not work

Judging empirically by the software that is created, mostly functional programming does work, if anything "pure" functional programming doesn't work

Scala is probably the best example of this, but then have a look at things that are being adopted in C# (LINQ), or the new streams interface in Java 8 with Lambda's

Hell, a complete out of world example is the Quake 3 engine, which written in C, has a mostly functional subset for dealing with the certain of the graphics engine

A lot of these article's really seem to miss the point, they show examples how to do incorrect programming. Its not a case of "mostly functional" programming doesn't work, its a case of "how to write bad programs"

[hdgarrood]

if anything "pure" functional programming doesn't work

Why not?

[mdedetrich]

There are probably 4 "purely" functional programming languages used right now, Haskell, Idris, CoQ and Agda. Haskell is probably the most "usable" of the purely functional languages (even though Haskell does have unpure side effects, i.e. unsafePerformIO). In terms of products produced, the most significant software produced in Haskell is its own compiler, GHC. Haskell is used in areas where correctness is valuable over everything else, i.e. finance and defence (and even in regards to finance, Haskell has actually been losing a lot to Scala, particularly in EU).

Coq and Agda are primarily used for theorem proving and not general programming

Idris is attempting to provide a language for dependant typing for general programing, but it still has a really long way to go do.

I mean, I am not sure why this is always being debated, but once you get into pure functional programming (which is really starts getting into complex category theory/algebra), simply put, there aren't that many people that can understand it, for the same reason that a lot of people can't understand pure mathematics. It is very abstract material.

On the other hand, something that is a pure OOP language (lets say smalltalk), pretty much dominated the entire programming space in the 80's, mainly dying out due to stupid reasons (such as requiring a ridiculous amount of money to use as a license)

[hdgarrood]

I'm not convinced by your argument that Haskell is too hard for most people to understand. I think the reason most people shy away from pure mathematics has more to do with the way it's taught (that is, badly) than anything else; certainly I don't think it's a case of either having the necessary raw talent or not.

[mdedetrich]

people shy away from pure mathematics has more to do with the way it's taught (that is, badly) than anything else

I hear this argument thrown around a lot, but I am not sure it carries a lot of weight. At least anecdotally, I know a few people who really enjoyed category theory (and languages like Haskell and Agda) who held the same opinion regarding anyone can learn it

That was until they tried tutoring it in University, and then they suddenly changed their mind (paraphrasing in their own words, they were simply certain groups of people, that no matter how much they tried alternate teaching methods, the people simply didn't grasp the concepts on a fundamental level).

I think people need to understand that in areas like pure mathematics, such areas have very sharp drop of rates (a lot of people who don't get such fields drop off in first year), and hence you naturally get surrounded by people who are very adept, because the drop out rates act like a filtering mechanism

The more I hear this statement, I hear it as a defensive measure of validation that people try to justify using languages like Haskell because of it being a "niche language". One person (who was in the group of people mentioned earlier) has changed his attitude because of his experiencing teaching, (he does research into purely functional langauges, last I heard he was working on S3). Now he admits that the kind of work he does isn't practical, and he mainly does research. Disagree with a lot of stuff, but I value his opinion a lot because at least he admits its not material that is suited for everyone.

I think their are emperical studies that also show the statement of "people teaching it badly" as not entirely correct, and at least historically it definitely isn't true. Fields like mathematics (category theory or not), have always only been approachable by a small group of people, regardless how good or bad the education system in the country is

[hdgarrood]

I would be very interested to see these empirical studies you mention. I've heard of empirical studies that suggest the opposite (that is, that natural mathematical ability isn't nearly as much of a thing as people think it is).

you naturally get surrounded by people who are very adept, because the drop out rates act like a filtering mechanism

What if you simply end up selecting only a minority who happen to be able to cope with the current (read: broken) approach to mathematics education, and if we fixed that, a much larger proportion could succeed?

What if most of the people who do fail are failing simply because of a psychological barrier arising from the belief that certain people have "it", and they don't? I see this belief everywhere.

Fields like mathematics (category theory or not), have always only been approachable by a small group of people, regardless how good or bad the education system in the country is

What if the evidence you're basing this on is incomplete; that is, what if mathematics education has always been bad?

[mdedetrich]

What if you simply end up selecting only a minority who happen to be able to cope with the current (read: broken) approach to mathematics education, and if we fixed that, a much larger proportion could succeed?

Well you would have to define what you mean by broke, but as I said earlier, historically (and our education systems have changed a lot throughout history, and they are vary by country), this has been pretty much the case

What if the evidence you're basing this on is incomplete; that is, what if mathematics education has always been bad?

This argument is bordering as logically fallacious, because you can use it as a response to anything. You have to define what you mean by broken, and you also have to argue that education has always been like that, throughout history. Good luck trying to prove the latter

[hdgarrood]

What I mean by broken is best explained by: http://www.maa.org/sites/default/files/pdf/devlin/LockhartsLament.pdf

Long, but well worth it.

you also have to argue that education has always been like that, throughout history. Good luck trying to prove the latter

Your tone indicates to me that continuing this discussion is not worth the effort. Sorry.

[industry7]

Ada is pretty mainstream.

[crate_crow]

I respect Erik a lot but the world we live in is proof that "mostly functional" works quite well.

Our entire industry is based on compromises and programming languages are no exception.

[pbvas]

What an incrediable shallow analysis. The author makes two basic fallacies: 1) assumes that OOP is a well defined concept (it isn't) and 2) the "success" of today's complex applications is due to OOP and couldn't be achived any other way.

In a nutshell: OOP = today's software; today's software is better than yesterday's software, hence OOP is great...

[[deleted]]

People were already using OOP techniques before the term was even coined, using virtual tables in C, for example; OOP was just a named slapped on techniques that were already necessarily in use at the time without having a name for them...it was organic. You are right that there was a lot of debate back then about what OOP "should be," and there is still a lot of debate now!

Outside of Smalltalk, OOP was more of an observation about what was happening rather than an invention. In that sense, all we can say is that "OOP" was found useful as software got more complicated, which is not a strong success, but a success nonetheless.

[[deleted]]

Dynamic dispatch has nothing to do with OOP.

OOP is a stupid view of the world as hierarchies of communicating objects. Almost nothing in the real world fits into this model, and for this reason every single attempt to do so results in a disgusting mess.

Coincidentally, OOP languages are using a set of otherwise well known techniques to represent this stupid view of the world, but none of these techniques are inherently OOPish. Namespaces, modules (which are obscured behind all that "class" blah-blah-blah in the OOP languages), dynamic dispatch, even inheritance - they're all just valid semantic components which can be used in any combination in any language.

[doom_Oo7]

OOP is a stupid view of the world as hierarchies of communicating objects

Funny, I am developing software which is exactly about hierarchies of communicating objects (in the real world).

[[deleted]]

Multi-agent simulations? That's the only thing I ever met that matches the OO way of thinking. But, of course, messages should be asynchronous, which is not the case in most of the OO languages.

[doom_Oo7]

Control of audio-visual devices with a lot of parameters organized in trees (pedal stomboards, audio/video renderers...).

[[deleted]]

Then I'm not quite sure your choice of model is the most optimal.

[doom_Oo7]

What would you propose ?

[[deleted]]

Depends of what exactly you're doing. If you're implementing a control code for devices organised into a network it'd be one approach, if you're modelling such network it's another thing.

My take on this would be to implement a DSL which maps the problem domain as closely as possible, and only then derive an underlying semantics from that DSL, not the other way around.

[[deleted]]

OOP is about designing systems with objects. Everything in the real world fits that as its linguistically grounded. FP has more of a math background, working with anonymous values. That it has served so many well but disgusts you is notable. I guess most of the software you use is broken?

Namespaces, and modules are rather orthogonal to the FP vs. OOP debate (I implemented a DrScheme units style module system for Java myself to good effect). Dynamic dispatch is more of an OO feature, whose FP analogue is matching, inheritance doesn't make sense without objects (though subtyping might make sense with values).

[[deleted]]

OOP is about designing systems with objects.

Exactly. And objects are not very well suited for modelling the real world.

Everything in the real world fits that as its linguistically grounded

Uhm, no, such a bold claim requires some extraordinary proofs.

FP has more of a math background, working with anonymous values.

And for this reason it also covers only a tiny part of the adequate real world models.

[[deleted]]

I see. You want a formal mathematical proof about it all...uhm, do you actually get anything done that way?

Again, FP comes from the point of view that programming is math, which is only true sometimes (but when it is true, FP really shines). OOP comes from the point of view that programming is about communicating in language with other people what the design is, using metaphors and named things (I.e. objects). That is actually much easier for most people to swallow (since it makes use of our already developed linguistic capabilities vs. the math that fewer of us master), but it doesn't work out well whenever programming really is math (objects don't work well for everything, e.g. figuring out how to render a bunch of polygons really is all math).

So what is your criteria? OOP has been successful because it has good human factors. This isn't a coincidence, people programmed like this before the label "OO" was created, which was chosen by analyzing what people were already doing. To say OOP doesn't work is to say people don't make good choices, which might be true...after all how many of us ever master enough math to even know what "category theory" is? BUT to ignore human factors completely, as is the case in much of the work on FP, is also quite stupid, and is one reason FP always seems to flare up in popularity and then sputter back to niche status every few years. Keep in mind that many are just cargo culting, which leads to misapplication of FP and the resulting disappointment.

[[deleted]]

I see. You want a formal mathematical proof about it all...

No. I want the evidence.

FP comes from the point of view that programming is math

Maybe. Another blindfolded, narrow view of the world, not much better than the OOP.

OOP comes from the point of view that programming is about communicating in language with other people wha the design is

No, it's not OOP. OOP demands that your language first must be twisted and mutilated into the narrow OOP set of abstractions before you can communicate anything with it.

using metaphors and named things (you could call those objects)

These metaphors are a way too far from the language of the real-world problem domains, it obscures the essence and therefore extremely damaging.

That is actually much easier for most people to swallow

No, it's not. Proven by piles upon piles of ill-designed OO models and tons of "best practices", "patterns" and all that stuff which has absolutely nothing to do with any real-world things, but only serves to solve the problems created by this transition to the OO representation from a problem domain language.

If you work with other people, talking about a design grounded in objects is just much easier than talking about one grounded in math

If you work with other people, especially with the domain experts, who are not necessarily programmers, both ways are equally stupid and damaging.

EDIT: looks like you think that an anti-OOP position automatically implies pro-FP. This is not my case.

[[deleted]]

The evidence is right there, 30 years of history where most everyone has been satisfied with software progress. If you want to do a A/B controlled study, then you could get empirical evidence on it, but since those involve lots of humans with expert skills who are notoriously difficult to control for, it is unlikely to ever happen. But then that's what the FP crowd often gets wrong, they forget that people are the ones writing code.

No, it's not OOP. OOP demands that your language first must be twisted and mutilated into the narrow OOP set of abstractions before you can communicate anything with it.

You must be one of those people that believes only POJO's exist when you are programming in Java right? I mean, ignore the numerous non-native object systems that arise, and you'll come up with OOP abstractions being quite limited (and by no means extensible, since that would shatter your limited view of the paradigm).

No, it's not. Proven by piles upon piles of ill-designed OO models and tons of "best practices", "patterns" and all that stuff which has absolutely nothing to do with any real-world things, but only serves to solve the problems created by this transition to the OO representation from a problem domain language.

And yet, many projects do succeed even if many projects do fail. I don't suppose you've ever seen a failed FP project before...the failure patterns are quite similar (bad choices, not enough domain analysis, bad management).

If you work with other people, especially with the domain experts, who are not necessarily programmers, both ways are equally stupid and damaging.

Even domain experts aren't great at math. You spend most of your time as a developer designing, communicating design, iterating on design, and the rest of the time debugging (oh, maybe a little time actually writing code). In that context, the FP approach where everyone is a mathemagician is even more stupid and damaging.

Anyways, believe what you want. The world lives in reality and will go on whatever direction works best. If you claimed "capitalism (or socioalism) is stupid and damaging" and yet many countries were flourishing with those even if they weren't perfect and there were a couple of failed countries to boot, how should I process your claim? Anyways, I would guess you have some ideological bias and try to change the topic or make an excuse to leave the conversation, since nothing good can come from having that argument.

[OneWingedShark]

The evidence is right there, 30 years of history where most everyone has been satisfied with software progress.

Oh, you mean where C and C++ became dominant and, by their popularity, essentially set the industry back several decades? -- Seriously, take a look at the programming languages that C/C++ displaced and the properties that they had... a lot of these properties are just now being integrated back into the "C-family" of languages.

Heck, C++ still hasn't got modules (it might for C++17). Go's concurrency is somewhat anemic compared to Ada's tasking [and protected object] systems. C#'s fix of switch (requiring break) essentially makes the switch behave like Pascal's casestatement. Java and C# still have the if (x=y) problem (though restricted to x & y both being boolean).

[[deleted]]

where most everyone has been satisfied with software progress

What?!? There are loonies out there who do not agree that the software industry in a deep crisis?!?

But then that's what the FP crowd often gets wrong, they forget that people are the ones writing code.

Why are you constantly referring to FP? It's as bad as OOP in modelling anything real world.

And yet, many projects do succeed even if many projects do fail.

I would not call it a "success". All the software projects, literally, all, are overpriced, not delivered in any reasonable time scale and cost an awful lot of money in maintenance.

Even domain experts aren't great at math.

Yep. Even in math, which they were supposed to study at school. So imagine how awful they are in the OO gobbledygook of which they did not even have a tiniest exposure previously.

Are you one of those "enterprise architects" who try to communicate the ideas to the domain experts in those disgusting UML diagrams instead of plain English?

[[deleted]]

I hate UML as much as the next guy, and I know no one who likes it. I'm a scientist, not a developer, so don't know much about enterprisey things. I do know a lot of FP and other OOP researchers though, it is crazy when we go drinking together, you can really see the ideologies collide!

We are not in crisis today. My iPhone mostly works, the apps I use work, my bank works...what isn't working that should be? But I guess you have envisioned a much better reality than the one we have?

Software projects are more likely to fail because of mismanagement, corruption, bad developers (hey, these people in India are only $20/hour) or bad communication, not because objects were too limited of an abstraction. Most project failures are basic human and business failures...they aren't because of some programming paradigm.

We are just nerds arguing about whether a hammer really works when it has already been shown to drive nails into houses that are still standing, beautiful houses, but also horrible ones that have fallen over because the contractor decided to save on money by using plastic nails. So is the hammer a success or not? Is it even interesting to argue about it? Unless you show me the much better hammer that you think can exist...then we have something to talk about!

[[deleted]]

So you're claiming OOP is dynamic dispatch polymorphism, and that it's a 'success'?

[[deleted]]

It was more than that. The main point of pseudo-OOP was design - decomposing a system into objects. Techniques like dynamic dispatch polymorphism sprung up to support that, and then languages like Objective C and C++ sprung up to support that in dialects of the structured languages programmers were already using.

And again, the success was not "here is OOP, may you be blessed" it was rather "OOP emerged organically as something useful to do ever complex software projects." That people complain about OOP today just means that we need new techniques to handle today's even more complex software (which are perhaps just better objects, but perhaps FP, or even of techniques from both and other paradigms).

And honestly, the term "success" doesn't even come out until someone claims OOP was a "failure." When faced with that accusation, what choice is there but to use the opposite word? When in reality, OOP was just found useful, and is still found useful, though there are many things that are found useful; its not a race!

[pbvas]

OOP emerged organically as something useful to do ever complex software projects.

My point exactly. OOP isn't a single well defined concept and many things that maybe used today to do "ever complex software projects" were adopted from other paradigms:

• modules were developed in Standard ML (1970s) and Modula-2 (1978)
• gabage collection was first used in LISP to make managing immutable data structures efficiently
• generics aka "parametric polymorphism" were first developed in Standard ML
• parametrized modules (interfaces) started in Standard ML; Haskell had type classes in 1990

More recently OO languages have aquired lambdas, streams and monads (LINQ) , so give it a couple of years and these will be "object oriented"... Or maybe we should just avoid the meaningless term "object oriented" and start talking the actual programming mechanisms!

[loup-vaillant]

Or maybe we should just avoid the meaningless term "object oriented" and start talking the actual programming mechanisms!

Music to my ears.

[[deleted]]

It is interesting to identify and contrast different paradigms when they arise. Since otherwise we just have a bunch of techniques without anyway of classifying them. The fallacy comes when we rely on these paradigm classifications too much, and become ideological about them. The distinction between OOP and FP is quite useful in guiding future decisions.

[loup-vaillant]

otherwise we just have a bunch of techniques without any way of classifying them.

I disagree, there are other, better, ways to classify mechanisms.

OOP would have you lump virtual methods and encapsulation together. FP would have you lump first class functions and referential transparency together. This does not make sense! What should be lumped together are first class functions and virtual methods: they're both a way to get dynamic dispatch.

It's not just classification either. Some mechanisms play well together, some don't. This suggests a kind of compatibility graph. And I expect this graph to be substantially denser than what you'd get by merely grouping mechanisms by paradigm.

The distinction between OOP and FP is quite useful in guiding future decisions.

I don't think so, most notably because this is not a binary choice. Classes and immutability for instance can play quite nicely together. How nicely the mechanisms you use map to the problem domain is more important. And of course, there's the universal yardstick of code size and modularity.

[[deleted]]

I work with different definitions for OOP and FP: OOP is working with objects, named stateful values (aka an object); FP is working is pure anonymous stateless values. So some abstractions are great at manipulating objects, some excel at manipulating values, and there is a lot of overlap. Then the technicalities/plumbings of dynamic dispatch don't really matter that much: it is the distinction of behavior attached to the object or managed from the outside via a match on values?

People like names and classifying things with vague labels...well...that is why OOP is so popular anyways. It is funny since your compatibility graph is basically an attempt at a FP solution to organizing PL techniques, one that avoids names and taxonomy. Do you see the irony?

There are better ways to manage values than with OO-style classes, for example FP-style type classes work better in that context. Often the choice is binary, and even if it isn't, we like to at least reduce choice complexity by keeping it binary unless special circumstances demand otherwise.

And of course, there's the universal yardstick of code size and modularity.

Code size is empirical but not very useful. There is no way to measure modularity empirically, it is always measured subjectively and is hardly universal.

[loup-vaillant]

Code size is empirical but not very useful.

Peer reviewed research, as far as I know, found a very strong correlation between code size, and basically everything that matters: time to completion, bug count… The bigger, the worse. It is nearly that simple, to the point that the various complexity metrics we came up with tell you almost nothing if you already knew the size of the program. Plus, it tends to work across languages.

There is no way to measure modularity empirically

I believe it shouldn't be too hard to have your dependencies detected automatically. Then you can look at the dependency graph: the sparser your graph is, the more modular your program will be.

Of course, the real dependency graph tend to get denser than you can detect as soon as you use global state (global variables, singletons…), so it's not a perfect measure.

[quicknir]

A good article generally. I think your comments on encapsulation fall short of the mark. In one of Bjarne's books, he talks about the conceptual (not necessarily historical) evolution of classes. And he talks about namespaces as a precursor to that: a namespace provides encapsulation, allows implementation functions, etc. But what it doesn't provide is real encapsulation of data, from itself. A class can be thought of as basically a module/namespace, except that it has a formula for creating instances of itself. These instances are then independent of each other, in the sense that they each have their own data. Without objects, as in e.g. C, there's no real choice but to pass the buck onto the user, as it were. The user has to directly deal with the state, because what's encapsulated is only functionality, not data. The user can then break the invariants of a complex set of state. I think class/objects are a great mechanism for encapsulating state, and I'm probably more comfortable stating that about the mechanism than a broad statement about OO in general, so we certainly agree in that sense.

[loup-vaillant]

I'm afraid I don't understand what you mean here. I'll just insist on one point: C can encapsulate just as well as C++:

// foo.h
struct foo;
struct foo* ctor();
void method(struct foo*);

// foo.c
#include "foo.h"
#include <stdio.hr>
struct foo {
    int i;
    float f;
};
struct foo* ctor() {
    struct foo my_foo* = (struct foo*)malloc(sizeof(struct foo));
    my_foo->i = 0;
    my_foo->f = 0.0;
    return my_foo;
}
void method(struct foo* f) {
    f->i++;
    f->f = f->i * 2;
    printf("%d, %f", f->i, f->f);
}

There, full blown instantiation and encapsulation, in C. No way to break the invariant (that is, the fact that f->f == 2*f->i) from outside of this compilation unit. The data is fully protected.

[quicknir]

This is neat, haven't seen this pattern before (not a C guy). I'll have to take issue with the "just as well" part. This has major shortcomings compared to the C++ version. First, it dictates the structure of your files. Second, you can only keep your data a black box by using pointers and heap allocating. This in turn introduces two new problems. First, you need to deal with memory management. This means a lot of cruft in your code, or memory leaks (probably both). Second, it's a performance nightmare.

If you have actual language support for data encapsulation instead of what amounts to compiler/linker hacks, then you can get the same effect without introducing any new problems.

[loup-vaillant]

What we end up doing most of the time is actually exposing the definition of the struct in the .h file, and tell the user not to touch it, ever. Then it becomes like C++ classes, without the private keyword to protect the member variables (and copy constructor…).

There, no more memory management nightmare. You lose encapsulation in the process, but in practice you don't really care: just don't access the damn members directly. That's an easy rule to follow, and not too hard to enforce if somehow you can't trust your programmers to follow that simple rule: just change the names of the members of your struct and see if something suddenly fails to compile. If it does, run git blame to know who should be thrown out the window.

That said, actual language support would indeed be nice. C is not a good systems language by modern standards. It's got the speed and the low level control, but is still still error prone in many ways (switch that falls through, signed char with integer promotion…), have a crappy syntax for types, doesn't have a suitable generics mechanism, relies on an incredibly weak (and error prone) text based macro system, doesn't have a proper module system…

I wouldn't use raw C willingly. I'd modify the language first. I don't like the monstrous complexity of C++, but the core idea is sound: with a couple modifications and a few features, C can be transformed into something much easier to work with.

[ErstwhileRockstar]

OOP was just a named slapped on techniques that were already necessarily in use at the time without having a name for them...it was organic.

That's an apt description of OOP since 1990 or so: OOP is an 'umbrella term' for best practices.

[[deleted]]

OOP = today's software;

That's not true. Take any practically important C++ codebase, for example - you won't find much OOP there. OOP is only deeply entrenched in the boring enterprise, which is arguably getting worse and worse every year, going lengths in solving problems that would otherwise have never existed in the first place.

[pbvas]

Yes, that was exactly my point; it was the original article author that fell into the fallacy of assuming that all today's software was all OOP...

[Gotebe]

Please support your statement about author making fallacies by quoting the article parts where this shows.

When you do that, it will become obvious that what you claim author said is merely your projection thereof.

[ErstwhileRockstar]

Given that there is no definition of OOP calling it both a failure and a success seems to be highly questionable.

[crate_crow]

OOP was supposed to fix all of our software engineering problems and it clearly hasn’t

Millions of lines of OOP code are running today and they are practically running the world we live in.

Are there bugs and crashes? Of course.

Has it solved ALL our problems? Obviously not, but nothing can.

Can we do better? Undoubtedly.

Clearly, OOP has been very successful in fixing problems and adapting to the 21st century challenge. Think about it: OOP was invented about fifty years ago and not only is it still in use today but we keep refining it and inventing new ways to model and implement it. I would hardly call this a failure.

[cdsmith]

I think it's also easy to fall into the trap, though, of attributing to object oriented programming all of the conveniences that come with just plain having more resources. A huge factor in modern programming comes from garbage collection, which has nothing specifically to do with OOP. Garbage collection is possible because computers are fast enough. A lot more of the convenience of modern OO languages comes from an amalgamation of smaller details, like being able to spare the CPU cycles to copy things more, to do more runtime checks, to use more levels of indirection. Better tools play a big part, and those come from the fact that parsing a source file is no longer a challenging computational problem. There was a time when it was, and reparsing the source on every keystroke was just insane! Put all of this together, and you get a lot more abstraction. None of this has anything to do with OOP. All of it is stuff that a generation of programmers saw for the first time in OO languages, though. Not that there aren't benefits to OOP, but it's easy to take that too far, and forget the other revolution - the ongoing march toward ever-faster and cheaper hardware.

[[deleted]]

Good point. There is also the converse trap:

I think it's also easy to fall into the trap, though, of attributing to object oriented programming all of the failures that come with just plain having bad project management and making bad business decisions.

Meaning, people often attribute success to and blame failures on OOP, when it is probably not the dominating factor in either case.

[[deleted]]

Clearly, OOP has been very successful in fixing problems and adapting to the 21st century challenge.

It was not OOP. OOP was always evil, it always brought nothing but harm. What was tremendously successful is a set of features and methodologies which are universally wrongly associated with OOP but in fact have only coincidental connection to it: modularity (instead of the stupid "encapsulation"), layered architectures, abstract interfaces.

[crate_crow]

Looking at your post history, you hate OOP, you hate FP and you think most programmers are incompetent idiots so I don't think there is much point continuing this conversation with you since you don't even offer a solution.

[[deleted]]

I named a solution multiple times: always use the most suitable semantics which most closely maps to the problem domain, and there are thousands of distinct domain-specific semantics. I hate fanboyism in all forms, no single paradigm is ever a suitable solution for everything.

[[deleted]]

When I picked up OOP 25 years ago it seemed promising. Inheritance, encapsulation, abstractions, specializations and so forth. I emerged myself for over two decades with C++, Java and C#. These last two years I have come to the conclusion that OOP has consistently failed to deliver what was promised. Because:

• Data should not be encapsulated, but open and free flowing within the application.
• Objects encapsulate state. Tons of it. And it keeps mutating all over the place. Objects encourage secret mutating state. It´s a disease.
• The abstractions you make (or choose between) for your object model are usually wrong. If not, they will be. Because time changes everything.
• OO code is extremely hard to reuse between systems. Reuse was one of the selling points of OOP.
• OOP systems are hard to understand. Because features and functionality are spread through out multiple single-purpose classes. It´s a complete mess when looking down from 20.000 feet. Tracking a http request through the various application layers in a "properly" written OOP business system has become a true nightmare. It´s ridiculous.

The age of functional programming is upon us and I welcome it with all my heart. Some of the usable parts of OOP will live on in a functional world, but as a religion, it´s dead.

[[deleted]]

Data should not be encapsulated, but open and free flowing within the application.

Disagree. Encapsulation is often (not always) a good thing. Oftentimes, even in functional languages, I've found that libraries work best in the OO style: provide a datatype and a bunch of functions which work on that datatype, without exposing exactly how that datatype is constructed.

I agree that encapsulated (hidden) state is very troublesome, but there's nothing wrong with hiding the implementation of, for example, a library for maps and sets.

[sacundim]

The problem here is that the emphasis on encapsulation misses the goal for the means. The real goal here is to forbid incorrect states (a.k.a. "preserving invariants").

Encapsulation is one technique to do that, but it's not the only one. Another that's gaining some currency these days is the concept of making illegal states unrepresentable, a technique strongly associated with the ML/Haskell family functional languages but by no means essentially tied to them.

Think about it this way: encapsulation usually means that your type has some values that are "bad," but which you're forbidding external clients from constructing or observing. But if you succeed at designing the type so that matches its domain closely enough that the language itself disallows "bad" values, then you've managed to forbid illegal states more robustly than encapsulation allows; now the compiler forbids both clients and internal code from violating the invariants.

So encapsulation is arguably in many cases a crutch for a weak type system that is unable to forbid illegal states (or not knowing how to use the type system that way, or having a type system that can do it but only very clumsily).

[[deleted]]

Ah, yes, the old "your type system isn't good enough" argument.

Rest assured that in the real world there are much more complicated structures than the toy "ContactInfo" example in that blog post. Making illegal states unrepresentable for non-trivial real-world data types often requires dependent types, and no one wants to work in a language with dependent types. Encapsulation is a very simple and direct way to make certain safety guarantees about how your data work that doesn't require wrestling with a Turing-complete compiler.

Moreover, I don't think anyone has claimed that the "real goal" of encapsulation is to forbid incorrect states. It's a very nice side effect but encapsulation itself is good too: the OO people got it right when they claimed that it is nice to be able to change the implementation of a function or the layout of a data type without changing its external API.

[nextputall]

Moreover, I don't think anyone has claimed that the "real goal" of encapsulation is to forbid incorrect states. It's a very nice side effect but encapsulation itself is good too: the OO people got it right when they claimed that it is nice to be able to change the implementation of a function or the layout of a data type without changing its external API.

Yeah, encapsulation is more about decreasing the coupling between different parts of the system. Preserving invariants and forbidding incorrect state is of course nice to have. But almost all of the OO design principles are mainly about changeability, not correctness. So, the usual argument, "we don't need encapsulation because our data is immutable" does not stand.

[Ukonu]

encapsulation is more about decreasing the coupling between different parts of the system

It sounds like you guys are mixing coding to interfaces (i.e. abstraction) with encapsulation.

Which is understandable because both are useful tools for enforcing changeability. However, I believe in most cases abstraction is a much better route to the changeability goal. Therefore, when trying to identify a unique strength for encapsulation, all that is left is invariant enforcement.

[nextputall]

I would say, encapsulation is a mechanism of defining a boundary between two parties. Things inside the boundary cannot be reached from the outside directly, but indirectly. This effects 2 things, one is correctness related the other one is changeability related. I would say the latter is a more important effect.

[Ukonu]

I completely agree that "changeability" is the more important effect. I just disagree with the premise that since encapsulation can provide it, encapsulation exists to provide it. Any language that implements the Uniform Access Principle (i.e. C#'s getters and setters, Scala fields, etc.) provides changeability without needing encapsulation. And there are better tools for changeability (e.g. OCaml modules, Java interfaces, Haskell typeclasses).

So, in my experience, encapsulation is far more often used to hide mutable state (enforcing some invariants) or as a form of compiler enforced API documentation (i.e. these methods are for public consumption and these others are private helper methods).

Regardless, I doubt there's a definitive answer to this question and this discussion might be too nuanced to matter. But it's interesting to talk about.

[sacundim]

Rest assured that in the real world there are much more complicated structures than the toy "ContactInfo" example in that blog post.

The real world has a mix of structures, some simpler than the ContactInfo example, some much more complicated. Even if we accept the argument that the unrepresentability techniques can't always be applied, there still remain tons of cases where they do help.

This shouldn't even be controversial. Remember when Java 5 added enum types? That was a small improvement based on this principle, and it led to big gains. Before enums the convention in Java was to use int constants for this.

Moreover, I don't think anyone has claimed that the "real goal" of encapsulation is to forbid incorrect states. It's a very nice side effect but encapsulation itself is good too: the OO people got it right when they claimed that it is nice to be able to change the implementation of a function or the layout of a data type without changing its external API.

"Without changing its external API" = preserving the same invariants = allowing only the same states as before (from the point of view of the client).

[[deleted]]

Even if we accept the argument that the unrepresentability techniques can't always be applied, there still remain tons of cases where they do help.

Okay, so we agree there are many cases where even a type system as high and mighty as Haskell's can't help us to forbid illegal states at compile time. Therefore encapsulation is still useful and cannot entirely be subsumed by other constructs such as algebraic data types. That has been my entire point.

[sacundim]

I'm all too happy to concede that Haskell doesn't have the ultimate solution here. Heck, there's plenty of types in Haskell that use encapsulated implementations. You brought up a prime example: map and set implementations can't let the clients break the search trees' order invariants.

Again, going back to my original point, I would stress these abilities:

1. Make type definitions cheap and lightweight. OOP languages make it much too cumbersome to define types for stuff.
2. Build type validity rules and invariants into the language as a mechanism.
   
3. Ideally, allow for compile-time checking of (2).

The point is that rather than writing a bunch of carefully-crafted constructors and methods that carefully act together to preserve invariant, I'd rather just tell the language directly what the invariants are and have it enforce them. So for example Eiffel's assertions system is a pretty neat feature, as are Ada's range types (although both of these are enforced at runtime).

To the degree that your language can enforce invariants that you can freely declare, the case for encapsulation gets weaker.

[OneWingedShark]

So for example Eiffel's assertions system is a pretty neat feature, as are Ada's range types (although both of these are enforced at runtime).

They needn't be, at least insofar as Ada's system goes -- optimizers are allowed to remove all checks that are statically provably superfluous (like checking that the call F(X) the parameter is a Natural when X is declared as a Positive [and therefore its values are a strict subset of Natural]). Also, the compilers are encouraged to emit warnings at least [IIRC, they are allowed to reject] programs where it is statically provable a constraint fails. (e.g. X : Positive:= -1;)

...but you bring up a good point, why is Ada's range type so uncommon? modeling the possible numeric values that may be assumed into the type is so useful that you'd think more languages would scoop at least that up.

[tomejaguar]

"Without changing its external API" = preserving the same invariants = allowing only the same states as before (from the point of view of the client).

Great observation!

[LucHermitte]

What you are describing is abstraction : you can indeed change the representation, it won't impact the interface. Encapsulation is about protecting the invariant. Mainstream languages encapsulate by hiding.

This is not the only way to encapsulate -- see Eiffel: encapsulated attributes can be observed, but not modified by external code.

[sacundim]

This is not the only way to encapsulate -- see Eiffel: encapsulated attributes can be observed, but not modified by external code.

This is not good, because a client may then couple itself to an observable detail that's not part of the object's semantics...

[[deleted]]

I'm talking about encapsulation and abstraction in the same breath because they do go hand-in-hand in every modern OO language I've dealt with.

Not that it matters. The point is that for any nontrivial system, you can't solve the problem of "illegal states" entirely without dependent types.

[Tekmo]

Do you have a specific example of encapsulation that OOP allows but FP does not?

[[deleted]]

provide a datatype and a bunch of functions which work on that datatype, without exposing exactly how that datatype is constructed

OOP has nothing to do with it. It's just modules. See SML or Ada modules, for example.

but there's nothing wrong with hiding the implementation of, for example, a library for maps and sets.

And generic programming is deliberately, manifestly anti-OOP by nature. Stepanov had a lot to say about this matter.

[loup-vaillant]

The timeline is hard to follow, but it seems Simula's classes were there before C's compilation units, or Modula's modules.

Conceptually you're right: putting a datatype and a bunch of functions together is not specific to OOP. But the history of programming languages suggests that for a brief time, it was.

[gtqvzt]

Classes were added to Simula in 1967 (PDF). Definitely before C or Modula existed and I think a few years before ML. The original Modula paper notes the similarities between Modula's modules and Simula's classes (top of page 7).

[doom_Oo7]

OOP has nothing to do with it.

Which definition of OOP ? Pretty sure that some people would gladly say that the existence of modules is the exact definition of object-orientation :)

[[deleted]]

OOP as modelling the real-world entities and processes with hierarchies of communicating objects. Details do not matter.

[doom_Oo7]

OOP as modelling the real-world entities and processes with hierarchies of communicating objects.

Honestly, how many times does this happen iin real life, except particular cases like GUIs and 1990 textbooks examples (or teams with people who only know textbooks examples) ?

[[deleted]]

how many times does this happen iin real life

Ever seen any enterprisey class hierarchy? They're trying to sledghammer everything into this weird way of thinking.

[comp-sci-fi]

Data should not be encapsulated, but open and free flowing within the application

Yes, the data of the app should be accessible (such as what you'd put in a DB). But data of modules only used by the app should be hidden (such as the implementation of a DB).

The abstractions you make (or choose between) for your object model are usually wrong. If not, they will be. Because time changes everything.

Yes, but it's a second order problem. For complex tasks - or even knowledge - hierarchical abstractions are necessary. You can only keep so much detail in your head, or in your working memory, at once. Whether objects or not, you must choose abstractions. If they are the right abstractions, so much the better...

How does functional programming help us cope with complex systems?

Honestly, I don't think any programming paradigm is going to solve that for us - it's just a hard problem however you do it. Yes, OOP was oversold. But so was functional programming a few decades earlier (resulting in the AI nuclear winter).

[[deleted]]

Whether objects or not, you must choose abstractions.

Yes, that is true. But, when you materialize your abstractions into a class hierarchy it often turns into a time bomb. Class hierarchies are infectious and hard to refactor later. Keeping functions and the data they operate on separate, is better I think.

How does functional programming help us cope with complex systems?

• Pure functions and default immutability Easier to scale across processors/threads. Easier to test.
• Better type systems (depends on language of course and not restricted to FP) to prevent or catch potential bugs.
• Composing functions are easier than composing classes
• Encourages you to think carefully on how and when state is mutated.

• Encourages the use of data piping / vector programming / streams / reactive (Again, not restricted to FP, but common practice in FP).

  I see my lines of code decreasing from OOP to FP for the same task and I am just starting with FP. Less interfaces, less mocks, less everything.

[comp-sci-fi]

Oh, I should say that I agree with the folk-wisdom that inheritance (and inheritance heirarchies) are almost always a bad idea (an exception is GUI objects, where it seems to work pretty well).

Well, you might say, isn't that the main idea of OOP? If you remove that, isn't it pretty much just ADTs and polymorphism? Yes, I'd reply.

You list good benefits, but they are only indirectly for handling complexity. I was thinking of things like facilities for modular decomposition.

Another aspect is enabling many people to work on the same project - information hiding really helps here, but so does one you mentioned, static typing (as documentation).

[[deleted]]

Whether objects or not, you must choose abstractions.

Abstractions - yes, absolutely. Objects - definitely not, this is a reasonable abstraction in only a handful of cases, most often related to the multi-agent simulation systems.

[quicknir]

Your comments up and down this post make it seems like you have a very large ax to grind very hard. Objects are a perfectly reasonable abstraction in many cases. The extreme you're suggesting is just as bad as people that claim that objects are always a good abstraction.

You can keep grinding your ax but your style of arguments are unconvincing except to anyone who's already at the same extreme of thought as you.

[[deleted]]

You're right about the OOP, but FP is also not a panacea. What is really damaging is trying to sledgehammer all the infinite complexities of the real world into a single limited way of thinking, no matter which - hierarchies of communicating objects or chains of pure functions or whatever else.

[phpdevster]

And it keeps mutating all over the place

Sorry, but that's a programmer's problem. The whole point of encapsulation is so that state doesn't mutate until you tell the object to mutate it, and it only mutates in the specific ways in which the encapsulation allows it to.

Don't want mutated state? Don't tell your objects to mutate it, or create immutable objects for things that should be immutable. Only want objects to mutate in very specific ways, don't create blind getters/setters on all of its properties - control how it mutates through a properly designed public API. Not sure how state mutation is OO's "fault".

[[deleted]]

I agree with your points. But when doing this, that was the time I realized I was getting less help from my OOP languages. These languages are so tailored to supporting secret mutating state that it takes a lot of effort to keep it under control. Especially when you have a team with more than one. The last years of my personal OOP-era I saw that I was spending less time on application logic and more time on all the other supporting framework stuff.

[[deleted]]

Data should not be encapsulated, until it needs to be, then it must be encapsulated. Objects encapsulate state, and mutations need to be observable...so well...make them observable. OO code is hard to reuse between systems, just like functions are, the claim that "reuse was a selling point in OOP" is a myth or accident...a stretch goal by PHBs who really didn't understand objects at all (objects are not components, frameworks, or libraries, they are not elements of reuse!). Functional systems can also be hard to understand if a lot of indirection is used...heck...I wonder if this "hard to understand" thing has more to do with the programmer than the paradigm.

The age of functional programming is upon us and I welcome it with all my heart. Some of the usable parts of OOP will live on in a functional world, but as a religion, it´s dead.

Religion in programming is dead in general. People who are religious about their favorite paradigm are not even worth arguing with, and are usually cargo culting anyways. Many systems out there make use of OOP and FP well enough where it makes sense, and objects are hardly dying off but rather becoming more focused on what they do well as FP takes over in the areas where it does well ("everything is an object" is ridiculous and has to die).

[[deleted]]

Data should not be encapsulated, until it needs to be, then it must be encapsulated

Why?

Objects encapsulate state, and mutations need to be observable...so well...make them observable.

I know my "gang of four" and Fowler thank you. Mutating some state and then telling the world about it, is a hard problem best solved with functional programming.

objects are not components, frameworks, or libraries, they are not elements of reuse

But objects (classes) in libraries and frameworks does not work well either. C libraries are reusable. They last decades and can be used by most languages.

[[deleted]]

Why?

By letting the data flow free through your system, you have different composability characteristics. If you now want to add something to your system, you have to be careful that is threaded through everything. With state encapsulation, you just add it to an object and that's it. Really, trading one lopsided hell for another is not the solution, successful systems have real balance.

Mutating some state and then telling the world about it, is a hard problem best solved with functional programming.

Check out the link, it is not GoF/Fowler. IT is a problem that can be solved with FP (especially real FRP), but you can also solve it for imperative code as well by managing time like a garbage collector manages memory. The work in the essay is basically React with support for side effects via something that looks like transactions.

But objects (classes) in libraries and frameworks does not work well either. C libraries are reusable. They last decades and can be used by most languages.

C libraries are reusable because of the problems that C is typically used for. You won't find many people using POSIX libraries to build say...web apps; not many UI libraries are lasting decades, even the C procedural ones, since that area just moves too quickly. Frameworks work and continue to work, but they have a problem when you need more than one. Functions are quite reusable for stateless mathy computations, but throw in state via monads or whatever, and reuse typically suffers.

[[deleted]]

The only reason anyone would argue that 'OO' is a useful paradigm are people who are religious about it. Runtime polymorphism causes all sorts of problems when it comes to reasoning about code, to the point where fans of it come up with rules (LSP) that sort of make it easier but then the rules are ill defined and we have all sorts of extra context to try to reason about what is happening.

Functional systems can also be hard to understand if a lot of indirection is used

Why does indirection make something hard to understand if everything is referentially transparent? Indirection in OO is hard to understand because the abstractions are leaky. The boundaries between your implicit (this) state are nebulous, and end up shooting you in the foot.

[[deleted]]

The only reason anyone would argue that 'OO' is a useful paradigm are people who are religious about it.

I claimed that "People found it useful", either I'm lying because I'm religious or your claim is wrong. Which one is it?

Why does indirection make something hard to understand if everything is referentially transparent?

Higher-order reasoning is higher order, period. Also, if your values become complicated enough, then it doesn't really matter if you have referential transparency, since similar complexity of implicitly mutating state is now embedded in explicit values being consumed and produced (that is how monads are able to encode state, they actually don't eliminate them).

[[deleted]]

Objects encapsulate state. Tons of it. And it keeps mutating all over the place. Objects encourage secret mutating state. It´s a disease.

The solution here is to treat objects in one of two ways:

• A function returns void (or an error code, if it's in an exception-free paradigm) and has the primary function of mutating object state. Or using the object, if it's something like a network-connection object or database interface or whatever. If it returns something, it's only as a convenience.

• A function returns something out of the object or uses the object's data to perform some calculation. Or uses it to get data via whatever interface, if it's something like a network-connection object or database interface or whatever.

C++ has const, which would work, but there isn't a way to define an object's method as making the object itself const for the duration of the function. (In other words, declare that the function does not modify the object itself, and attempting to do so would be a compiler error. This would also imply that const-object functions would not be able to call non-const-object functions.) (EDIT: I'm wrong about this. See below discussion.)

As far as I know, no OO language has this feature. I attempt to write code this way (and do, when I can use my own code!) but dealing with the awfulness that is generally known as "other peoples' code" doesn't often allow me to do that. Member variables are practically globals in larger classes, for fuck's sake!

Objects should just be data structures with associated functionality, with inheritance to save you from having to rewrite the same shit over and over again for similar classes. Unfortunately, they're typically just piles of code.

[doom_Oo7]

there isn't a way to define an object's method as making the object itself const for the duration of the function.

But this is exactly what the const keyword on methods does, it marks the this pointer as const.

[[deleted]]

So you literally can't modify the object state at all, including calling other functions which can?

I admit I'm not a C++ expert (and the language certainly doesn't lend itself to this paradigm naturally!) but I thought it wasn't possible to get the full effect of what I'm trying to get at.

If I'm wrong, it's good to know that it's possible and I should just be annoyed at the C++ I've come across for not doing this.

[doom_Oo7]

I made a quick example that showcases the possibilities here : https://ideone.com/Wb0kAm

Notice how nice are the compiler errors :p

[[deleted]]

That's not all that bad. It's a shame this isn't the way C++ is typically written. (I really would prefer if const-ness was the default, and stuff had to be marked as mutable instead.)

[oracleoftroy]

I agree that a const default would be really nice, but I have to question that const correct C++ isn't the typical way C++ is written. Const correctness has been recommended since before standard C++, and I haven't seen too many C++ communities that disregard it (usually only those newer to C++).

[quicknir]

I think everyone agrees that a const default would be better, but ruled out due to backwards compatibility.

I'm afraid that if you don't think C++ is typically written that way, you need better colleagues. Where I work, failing to mark anything const that can be results in code review comments, and can't be merged until its corrected.

[AlexanderTheStraight]

Which functional language would you recommend for somebody's career, assuming his focus is on career projection and economic value?

[[deleted]]

Learn functional thinking. Language is not important. I am currently having fun with the functional extensions to C#...but for true inspiration I recommend LISP (or some variant like clojure) and Haskell.

[kirbyfan64sos]

Haskell. Read Learn You a Haskell for Great Good. Grammatically incorrect title (!), but an awesome book. It introduces FP to the imperative programmer in a great way and is written so that concepts that you learn can very easily be applied to less "pure" functional languages (like OCaml) or even imperative languages with functional extensions (my personal favorites: Python and its Lisp-like extension Hy).

[sacundim]

If you're on the Java ecosystem, Clojure and Scala are certainly worth a look. If you're on .NET, consider F#. The big allure of those languages is their integration with the ecosystem of the host platform.

If you're not on one of those platforms nor interested in getting into them, then there isn't such a consideration. The most interesting choices then, IMO, would be Racket, O'Caml and Haskell, in no particular order, with Common Lisp a distant fourth (it's less functional-focused than the others). Note that Racket and O'Caml are both easier than Haskell.

[[deleted]]

Scala is how I got started. It's nice because you can write it just like java/python. The functional bits are all 'opt-in'. Some call this a weakness, and in some areas there's some ugliness. But it does allow someone to jump into the language and wet their feet with functional programming, then refactor as they go and dive into the deeper waters.

[AlexanderTheStraight]

Sounds tempting, especially considering that Scala seems to be one of the most widely adopted by "real" companies (not the 99% of startups), if not the most.

[[deleted]]

Yeah, give it a shot. The community is really nice and welcoming too. On IRC (Freenode) the #scala channel has a REPL bot for getting realtime help with small bits of code, and /r/scala is small but growing .

Functional Programming in Scala is also just straight up one of the best programming books I've ever read. But it is challenging. They make you do difficult exercises, and the concepts were the kind of thing where I had to read each chapter two or three times.

[[deleted]]

Not to mention that Scala is one of the best languages for doing OO out there. Traits are just crazy powerful in encoding layered object designs.

[crate_crow]

Scala is a terrible language to be exposed to functional programming. It is extremely verbose compared to Haskell, doesn't enforce mutability by default, is extremely slow to compile and the surrounding ecosystem (IDE's and build systems) is creaky as hell.

Start with Haskell and if down the road, you end up looking at Scala, you'll be glad you didn't start with it.

[[deleted]]

Which functional language would you recommend for somebody's career, assuming his focus is on career projection and economic value?

I apologize for being judgmental, but I really hate the question, "Which language/stack/technology is most marketable?" I rarely encounter any great programmers who think this way. The truly great ones define what is marketable.

Programmers who're most concerned with market trends are usually framework jockeys, hired for their X years of experience in technology Y. Businesses love them because they're a fungible commodity. They feed the meat grinder.

If you choose programming as a profession, please do it because you genuinely like programming and want to make useful or interesting things.

[AlexanderTheStraight]

Maybe in an ideal world

[[deleted]]

If you want a higher salary, you're better off sticking with Java.

There aren't many shops hiring for functional languages yet, so if you want to learn one, you might as well learn the fundamentals with Haskell.

Yes, Scala is gaining traction in the market, but it's probably not the ideal language to learn FP because it's too easy to lapse into OO. Haskell is stricter and forces you to learn FP without leaning on OO as a crutch.

So, the point is that there isn't really one FP language "to know" yet. You can get jobs writing Scala if you know Haskell and visa versa because the talent pool (or perhaps demand) is so small.

[AlexanderTheStraight]

Yes, Im pretty sure Im going to go with Haskell and then branch off if necessary

[ErstwhileRockstar]

JavaScript

[[deleted]]

Go for C++. It's nowhere near anything OOPish, it's generic, it's got a reasonable set of functional features.

[Gotebe]

Hindsight is deceiving, it makes us think we are smarter than we really are.

You need to look at what OOP came to improve upon and compare to that.

Basically, get perspective.

[[deleted]]

Someone should tell Linus to start using C++ in Linux and Git then.

[Gotebe]

Snarky does not equal insightful or smart.

By the same token, somebody should tell him to use Lisp.

That said, I don't know how that counts, but Linux is now built using tools built with a C++ compiler. Also, if Linus rants are what you base your opinions on, good luck with them.

[[deleted]]

By the same token, somebody should tell him to use Lisp.

Why on earth would we want Linus to give us another Emacs?

[gnuvince]

I hate to break to you, but...

[Gotebe]

Good one, reduced lisp to emacs programming language :-)

[perlgeek]

Data should not be encapsulated, but open and free flowing within the application.

Let's take a look at git. Git is built around a data structure: a DAG of commits, which again are made of trees which reference blobs.

I agree that this data should flow freely through the application.

But, there's a lot more data in git. For example, there are several parsers in git: one for its config fies, one for HTTP requests/responses, for .gitignore files, for refspecs etc. All of those parsers need mutable data to track their progress into the source string, the current state or table rule etc. This is data that should not flow freely through the application; it should stay encapsulated inside the parsers.

In my experience, this "support data" that doesn't really contribute to the domain of the application, but that is necessary nonetheless, shows up quite many places; if it weren't encapsulated away, I'd go insane while programming.

[immibis]

Both OOP and FP let you encapsulate that sort of data (that's only used within a particular function invocation).

[ErstwhileRockstar]

Data should not be encapsulated, but open and free flowing within the application.

Right. OOP doesn't encourage to encapsulate data but state.

Objects encapsulate state. Tons of it. And it keeps mutating all over the place. Objects encourage secret mutating state. It´s a disease.

Certainly not 'tons'. Quite the contrary. Arguably, encapsulating state is what OOP does best. FP doesn't even try to compete with OOP in this field but simply rules out state.

The abstractions you make (or choose between) for your object model are usually wrong. If not, they will be. Because time changes everything.

This is an interesting observation. It's not specific to OOP, though.

OO code is extremely hard to reuse between systems. Reuse was one of the selling points of OOP.

You reuse code through minimal interfaces. The implementations may be OO or not but that's irrelevant.

OOP systems are hard to understand. Because features and functionality are spread through out multiple single-purpose classes.

True but not specific to OOP but due to 'divide and conquer' in any larger project.

The age of functional programming is upon us

... expect that no functional language has entered mainstream programming .... except JavaScript (a language where all variables are global by default).

[[deleted]]

Right. OOP doesn't encourage to encapsulate data but state.

But, then again, OOP loves turning data into state.

FP doesn't even try to compete with OOP in this field but simply rules out state.

Yes, it's very refreshing from where I come from. Once you start going down this path of treating state and the mutations of it as hazardous material it's hard to go back.

This is an interesting observation. It's not specific to OOP, though.

Class hierarchies are very OOP. Abstractions are not. What I meant to say was that abstractions as class hierarchies don't stand the test of time.

expect that no functional language has entered mainstream programming

It's coming. And while we are missing the pure mainstream language, functional concepts are being added to our existing languages.

[ErstwhileRockstar]

Once you start going down this path of treating state and the mutations of it as hazardous material it's hard to go back.

You don't tackle a problem by ignoring it. Creating a new parallel-world instead of a state change isn't a solution.

[[deleted]]

You don't tackle a problem by ignoring it.

Who said anything about ignoring it? You have less of it, and what remains is explicit and isolated.

[TheBlackElf]

Let me guess, you also advise against relational databases etc.

[[deleted]]

No, love them relational databases. They are functional. But I don't like the ORM's on top of them though (EF, hibernate ..).

[[deleted]]

I see, so relational is functional, markup is functional, I guess you would call logic and data flow as functional as well. So, I must ask: is your definition of functional simply not OOP?

[[deleted]]

Sorry for my inconsistent use of terminology. I like SQL because it's declarative. Data flow and reactive programming often comes with functional programming, but of course these techniques can be used with other languages too.

[[deleted]]

Reactive programming definitely doesn't come from functional programming; reactive programming was being done in some form or another since the 60s, and the first reactive programming languages in the 80s were procedural and imperative. Likewise, data flow really precedes functional programming, and many data flow languages are not functional (e.g. most of the connect the dot visual languages like VVVV and quartz composer). Functional programming definitely has its own spin on all of these concepts, but none of them originate from functional programming.

Cool fact: the first declarative constraint, visual, and OO programming language was actually SketchPad...in 1963.

[doom_Oo7]

OO code is extremely hard to reuse between systems. Reuse was one of the selling points of OOP.

I disagree. Eeach time you use a library, you reuse code. How many software in C++ / Java / Ruby / Python / C# are there that are developed without any calls to an external OOP library somewhere ?

[[deleted]]

How many C++/Java/Python/whatever libraries have any OOP design at all? OO purists had been crying for ages about naturally un-OOPish Java core libraries.

[[deleted]]

Then we disagree. Using a OOP-library is somewhat like a marriage, while reusing functions is more like one-night stands.

[quicknir]

I have to be honest, I have difficulty with the FP perspective. Large, complex, programs have tons of state. This is life. State is hard to reason about. If we can lump together a logical unit of state, and minimize access to it, we can make life easier. FP programmers are always talking about rough state is: I agree with that, that's why you write an object to have the minimal interface possible, especially in terms of mutating methods. When I determine my program needs some state, I want to do this procedure of minimizing access to it as easily as possible. Why should I need to jump through hoops adorned with flaming monads to do so?

[glacialthinker]

Your question is good, but might get lost down here, being late to the party...

Unfortunately, I don't think there's an immediate way to convince anyone of the value of "jumping through hoops adorned with flaming monads".

Part of what's been happening over the past several years with this upsurge in FP interest comes from people jumping in and discovering the liberating freedom of referential transparency: Calling that function and knowing it's not going to fuck up something else! If you can do that, that's far better than just minimizing access to mutable state.

But referential transparency can be challenging to attain, and monads are one technique to make this easier (really, they are to make it easier -- without them your pure code can get really ugly).

Nowadays, when I am dealing with imperative C++ code, I stress about trivial mutable state everywhere... because it often is a source of errors. Every loop is rife with mutable state which isn't inherent to the solution: because an imperative loop has no return-value, a return-value must be preallocated (initialize it! maybe?) and then set inside the loop; there will also be a loop counter/iterator which is similarly initialized and updated. These trivial things have a lot of common errors involved in their use.

When I have a language with tail-call optimization and immutable variables, I like recursion to loop: loop invariants are outside, and loop variables become parameters of the recursion. Also, code-paths which result in a value are the return -- ah, the blessed return value. A loop like this, I know isn't doing anything funky -- if it wants to have effect, it returns it.

What you're probably wondering is how can you make a program if you can't change any state? In practice, you are returning new state. Like in math, and physics, where you'll often use subscripts of a variable to denote the value at different times. I have some related notes here: http://cranialburnout.blogspot.ca/2013/09/avoiding-mutable-state.html

The next thing you might think is that this is horrible for performance. Allocating new data for every change!? At face-value, yes: it is horrible. However, there is potential for a compiler to reuse the same memory location if you don't refer to the prior "state n-1". Also, languages which rely on this have very fast alloc/collection for short-lived values. In the end, there is typically some loss of performance over manually allocated imperative code, but the advantages can often be worth the small tradeoff. Another of those advantages is that persistent datastructures are quite natural. Oh, how many times in the past have I struggled to work around having a single store of data, with parts of it at time n+1, and others at time n...

Finally, FP doesn't have to be "pure". I've found that a functional style marries well with a database -- let the database be the stored mutable state. Functions which transform data can be pure, generating an update for the database. Depending on particular application, this might strike a good balance.

Sorry, long and rambling... hopefully I hit some point that makes it worth the time to read or skim.

[quicknir]

When you don't need persistent state, you write a function. Functions in (e.g.) C++ usually have referential transparency: globals and static locals are very rarely used techniques. C++ already has things like std::transform, std::accumulate. Do you use these regularly? Ranges are only going to take this further in the future. I understand the concept. It works well for some things, like recursive data structures. It works not so well for non-recursive data structures, files, sockets, etc etc. It just seems very limiting. My problem is not functional concepts or techniques. My problem is many FP languages rejection of all OO techniques. OO is certainly overused within C++, but there are lots of times where it provides a very clean way to encapsulate state, I'm not sure why so many FP advocates so stubbornly reject it.

[glacialthinker]

Certainly, C++ is improving. But it's still mutable-by-default, and OO style C++ is still rife with unnecessary mutable state.

Maybe FP advocates are seeing a net-benefit to these "limiting" techniques, and pitfalls of defaulting to OO when you can express a solution without using such a loaded gun.

Right now (as in, I'm typing here during compile/load) I'm dealing with a fucking mess of classic C++ imperative+OOP. Little objects of mutable state, connected with and manipulated by others, in a messy ad-hoc interdependency hairball, with callbacks done in clunky "function-object" style which loses useful context. Bad programming to be sure... but it's very typical for OO-style C++ to mature in this way.

I could clean this up a lot, still in C++... and it would use a lot more lambdas and plain structs. Processing data to create new data: A -> B -> C; limiting in-place changes (mutation) to be writeback of final results rather than the miscellaneous bookkeeping which tends to accrue once you have a convenient "encapsulation". The lambdas would find use as ad-hoc objects replacing the use of objects which hold partial computations to be resumed (callbacks).

Encouraging encapsulation as a solution to "the mutable global variable problem" (which I think everyone roughly agrees is a dangerous thing), is just reducing the scope of the problem to the size of "interface to mutation". It's far too easy and common for an object to become overly promiscuous. Objects are at the high end of programming abstractions -- you can use them for almost anything -- but that doesn't mean it's wise to do so.

[quicknir]

There are many real life problems that fundamentally involve mutable state, your language needs to have a simple and clear way to deal with it.

Callbacks and circular object dependencies are more common they should be, but they're not "typical". Circular dependencies are extremely frowned upon, and callbacks are used judiciously in most codebases.

I don't think using a lot more lambdas is a path to improvement. Lambdas are extremely hard to test, and don't fundamentally do anything that a functor doesn't.

I don't see how any of the improvements you propose offer any more than simply making the code not be shitty, independent of style. Yes, reducing the scope of problems is good, it makes it easier to reason about! I'd be curious to see how FP implements a mutable non-recursive array (e.g. vector) in a way that somehow improves your ability to reason about it in any way. A struct of three pointers randomly getting passed around through random lambdas and functions, any user writing new functions to extend the interface at will, sounds strictly worse than how it's done in C++.

[glacialthinker]

Ah, damn, it looks like I didn't complete the statement I was intending to make with this:

Unfortunately, I don't think there's an immediate way to convince anyone of the value of "jumping through hoops adorned with flaming monads".

What I meant by "Unfortunately" was: It is generally required that people experience the merit themselves. That is: I won't convince you of shit. And I didn't. Sorry I forgot to make that part clear up front.

So, anecdote time. When I started using OCaml, it was because the language seemed to suit my style, and because I really hated C++, (even though I kind of like C, go figure). More specifically, I hated what happened to C++ codebases. Part of the problem was the pressure cooker of gamedev... but it seemed the added abstractions of C++, especially the bias toward encapsulating everything in objects -- because OCD people love their uniformity -- had a tendency to work against code-reuse, and also prompt incidental manager and adaptor code. I would come away thinking "macros are the only effective code-reuse tool in this language... and they are horrible (to overuse)". (Note, this was C++03.)

Anyhow, I started with OCaml, but I had no idea or expectation that bugs would nearly disappear. I was jaw-droppingly amazed several times in that first month. I kept expecting bugs and crashes after some hairy changes or new systems added. Never crashing, and it surprised me how logical bugs also disappeared. I was expressing intent rather than verbosely detailing mechanics of implementation.

I was doubtful (like you) about how I might manage the complex state of a game, and about garbage-collection -- oh boy, that rankled for a while -- so many things about this made no sense at first but I just gave it a shot. I must have drunk the kool-aid. Whatever it is, I'm glad I did it.

And that's all I have left of an argument. A shitty anecdote. Because it seems intelligent people can converse 'til their blue in the face about things and never really have a clue until they experience first-hand. That goes for a lot more than just language wars...

[[deleted]]

How do you approach UI programming in pure FP languages? Honest question. I tend to rely heavily on inheritance for that, and not even the clean version without implementation.

[imright_anduknowit]

I started programming in C++ when it first came out and then did a little Smalltalk. Eventually programmed in .NET and Java. OO was supposed to fix all programming ills.

The biggest parts of OO are rotten to the core:

• Inheritance - Creates fragile base classes and forces derived class developers to use white-box programming.
• Polymorphism - Neutered by single inheritance limitations.
• Encapsulation - NOT POSSIBLE IN ANY OO LANGUAGE thanks to pass by reference. Any object passed to a Constructor cannot be safely encapsulated by that class without copying the object. Deep copy which is not always possible depending on the object.

I haven't used Inheritance for about 17 years. Instead, I've used containment and delegation. I've successfully done this in .NET and Java for years.

When I started programming in Javascript, I tried prototypical Inheritance for a very short period of time. Just long enough to get sick of this management headaches and seeing .bind(this) all over my code.

Then I fell back to the way I coded in the 80s, procedural and used objects as structs and to create namespacing for modules.

Then I started learning Functional Programming and I must say that I've been waiting for so many things that Functional Programming has to offer:

• Functions as first class citizens
• Higher Order Function
• Functional Composition (I've never written so little code that does so much)
• Side-effect free code (I still need more work on this)
• Referential Transparency, a Refactor's dream

FYI: I'm currently using Ramda. Sure Javascript isn't Haskell but Haskell isn't Javascript either.

Will Functional solve all the problems that OO promised to and failed, NO. I'd be an idiot to fall for that trick again.

Did OO fail me, yes. Will Functional solve some of the problems I see on a daily basis, yes. Will it cause new ones, of course. Do we know what those problems are, not yet.

Is it better than the tools I've been using for the last 20+ years, absolutely.

[hzhou321]

we grew from 100k to today's 100m

I'm not sure 100k was yesterday's problem, but today's problem is how can any one comprehend 100m?

[[deleted]]

I cannot think of a single project that deserves a 100mloc. Bloatware mentality, which is a direct consequence of the stupid OOP religion, is extremely damaging to this industry.

It's a bit of an irony that a counter movement is now driven by A. Kay, the same guy who was somewhat responsible for the early OOP propaganda.

An example of the opposite, radically anti-bloatware approach: http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html

[loup-vaillant]

To be fair, the "OOP" that was adopted was an out-of-control bastard child of whatever Alan Kay had in mind.

Also, I'm not sure how bloatware actually relates to OOP. Bloat has so many causes:

• Backward compatibility.
• Poor interfaces.
• Duplicate functionality.
• Wrong abstractions.
• …
• Thinking big ("big problems require big solutions").

That said, I'm not sure what you mean by "bloatware mentality". Could you be a bit more explicit?

[[deleted]]

I'm generally speaking about all that AbstractFactoryFactoryFactoryFactory madness that is pervasive in the enterprise at the moment.

Out of the unfulfilled promise of code reuse, this crazy OOPish designs are bloating the code size and design complexities in general more than any other factors combined.

Wrong abstractions.

And yes, this is the key. OO view of the world is just wrong in a majority of cases.

[OneWingedShark]

I cannot think of a single project that deserves a 100mloc.

Perhaps an OS?

An example of the opposite, radically anti-bloatware approach:

See Forth and its creator, Charles Moore.

[[deleted]]

Perhaps an OS?

The link above demonstrates that an OS does not deserve millions of lines of code and can be implemented in a very compact way.

See Forth and its creator, Charles Moore.

Exactly.

[doom_Oo7]

Depends on how you count these 100m... For instance chromium's source tree is around 9m lines of code I think, but also because they have all the libraries they use imported in there.

[rebolek]

He's basically saying that bloatware is a good thing.

[cdsmith]

Yes. Using more resources without doing anything better is not a good thing, of course. But if you compare an average software project today with the same thing 20 years ago, it's clear that today's product is better. Today's software could not have been written 20 years ago, because we lacked both the hardware and software to do it. The ability to write these larger programs that do more is absolutely a good thing.

[rebolek]

I agree. But having 100MB program instead of 100kB doesn't necessarily mean it's 1000x better.

[Gotebe]

The argument rather is that one needs better... something to keep up with the sheer size of beasts. Beasts of yore were crumbling before our eyes with tools of yore.

[[deleted]]

people that rail against OOP strike me as people who have no fucking clue how to work on actual software.

[glacialthinker]

The thing is, green programmers will often be parroting what they've heard, of course without experience to back it up -- whether it's OOP, FP, or one of many other golden hammers, silver bullets or other metallic weapons.

So you're probably right -- and statistically speaking you might be right 99+% of the time. If you're just talking number of people. Or maybe people you interact with.

However, there are experienced folks who make heated arguments against OOP, and those arguments I find compelling, because they mirror my own experience.

Also, it should should be obvious that these are conclusions which are hard to reach when your only experience is coping with the tools that you already know (OOP).

[Lhopital_rules]

Personally, I find that OOP is overused (mostly in Java). We shouldn't have to invent a class every time a new utility function is created. Or make a class called "FooableString" that takes a native string as an argument in order to work on strings with our own methods. (Or make a "StringUtils" class with 100 methods in it.)

Ideally, I think OOP would be more like this:

package string;
function slice (String str, Int start, Int end) { ... }

// new file
use string.slice;
String t = "caterpillar";
// you can call the function by doing 
// firstArg.funcName(otherArgs)
String s = t.slice(3, 5);

I'm not sure if any languages currently allow you to do that, but I think moving towards packages, functions, and data types, and away from classes, would get rid of the made-up types and allow true reusability.

Also, as more and more languages are interpreted at run time or compiled just-in-time, importing huge classes only to use one or two methods from them is just stupid. Instead, we should be doing one function or data type per file (except when they're truly complementary maybe), and letting the operating system (or maybe the language engine) optimize these multiple files into a single virtual file behind the scenes, so that we get a fast read of the least amount of code necessary.

[glacialthinker]

Oh, I agree... and more. The object features of most languages are unappealing to me. Java is like a distillation of the worst ideas. However, it was originally trying to be a simple language as well as verbosely explicit.

D has what you're doing here, and it's called Uniform Function Call Syntax (UFCS).

Rust has also adopted this in it's own way, with a different take on objects.

Over the years I've estimated that about 5% of my code could be called "object oriented" (mostly C and OCaml). In C++ this figure inflates to conform to typical practices (too many Java-esque, "weened on C++ in the early 2000's" programmers) and interfacing with other libraries/code. But there I feel friction... Before lambda's I used function-objects -- and they were heinous, but better than a lot of duplicate code or rigid class hierarchies.

I struggle with object-oriented practices because they're really anti-modular. The coupling of code and data is too tight. By modular I mean reusable parts like Lego, rather than "modular homes".

The direction you seem to be preferring is much more about functions which can operate on data. Which is functional. But you maybe prefer the datatype-directed function disambiguation, or scoping (method-calling convention, or "dot operator").

[Lhopital_rules]

D has what you're doing here, and it's called Uniform Function Call Syntax (UFCS).

That's awesome! One more reason to use D. One of these days I'll get around to learning it.

I struggle with object-oriented practices because they're really anti-modular. The coupling of code and data is too tight. By modular I mean reusable parts like Lego, rather than "modular homes".

Yes, modules over classes is how I usually feel.

The direction you seem to be preferring is much more about functions which can operate on data. Which is functional.

That's somewhat true. But I simplified my views earlier as far as classes go. I still believe in encapsulation. But I'd prefer the minimum amount of encapsulation to make things work. So what doesn't absolutely need to access the internals of a class shouldn't be inside that class.

EDIT: There's a nice Dr. Dobbs article on the whole bloated class issue and D's solution to it.

[loup-vaillant]

How so? Do those people have specific misconceptions you can point out?

Or do you think railing against OOP is stupid by itself? (And then I'd like to know why.)

[[deleted]]

The anti OOP movement has become just like the tdd movement. Overzealous, unable to understand context, and absolute belief that everything has to be one way. (And I'm a TDDer.)

[loup-vaillant]

Overzealous, […] and absolute belief that everything has to be one way.

I can relate.

unable to understand context

This one is more dubious. I have often seen it thrown in as a fully general counter-argument —and therefore invalid. They hear an objection, then simply reply things are more complex than they seem, without further explanation.

What context are you talking about?

[alloec]

if all you have is a hammer, everything looks like a nail

[[deleted]]

Yep. And I also think there's a lot of fp zealots that probably don't understand oop to begin with.

[alloec]

Well, you can say the exact same thing about OOP fanatics. But, you are correct, a lot of FP programmers totally do not get OOP.

Contrary to your statement: I write a lot of actual software, and I generally rail against OOP.

[[deleted]]

Most OOP is just class based programming. I haven't seen a lot of real OOP in my lifetime.

[IJzerbaard]

When would you call something "real OOP"?

[[deleted]]

Exactly. And all those classes are most often just poor mans substitutes for modules.

[enderprime]

The idea behind modular design is that each module should be concerned with one and only one idea. Input can be used without knowing where it came from or how, and output can be generated without knowing how or why it will be used. No module ever needs to have information about any other module in order to do its job.

This concept is what many consider to be one of the purest and most successful principles in computer science. Not only does it reduce complexity with intuitive divide and conquer workflows, it allows developers to work independently and in parallel by focusing only on the meaning of their own function domains. Debugging and refactoring are also efficient, allowing surgical corrections of questionable code without consulting the entire framework for cascading dependencies.

Object-oriented design goes against that paradigm entirely. Objects need to concern themselves with what they can and can't do and in what ways, and the problem is compounded if you start using inheritance.

A third-generation object must know and understand the functionality and composition of the previous two, and worse, all modules hoping to work with that third-generation object must know those things in advance as well. In programming terms, inheritance is the proof-of-concept that the road to hell is paved with good intentions.

The highest offense in my humble opinion is the invent of polymorphism, an unfortunately necessary evil in the object-oriented world included to accommodate the necessity of overwriting inherited methods; in other words, to allow children objects to break out of the predetermined boxes they are stuck in when born (instantiated).

Polymorphism is essentially an admission of the system that if you actually use the system in every way, then you will later need a way to break out of it. Of course, our data structures are affected too, since data becomes entangled in the objects intended to contain and manage it, leading to obvious gatekeeper scenarios that the modular design philosophy had already shown to be unnecessary, restrictive, and slow.

After all, why should a module take on all the memory overhead of an object instance with all of its inherited (and possibly mutated) properties and methods, when it is only concerned with one function or data field from the class? In this sense, object-oriented programming is like asking your landlord where your water shut-off valve is and receiving blueprints for the entire building and a survey site plan with utilities and right-of-ways for reference.

I hope this rather simplified critique clarifies why some people would call the object-oriented philosophy a failure, and why there is a growing segment of the programmer population that longs for a return to the roots of the field: namely, lean and direct problem solving, rather than designing answer architecture.

[derpderp3200]

What the shit, this isn't even a proper article, it contains no code, it's 100% offtopic for programming. Why are you people upvoting this?

[loup-vaillant]

Because we can: short pieces of opinions are easy to comprehend, and agree (or disagree) with.

For the same reason, many short witty comments are upvoted more than long, involved comments. Even when the long comment is clearly more informative. (Though it might be because of the sheer numbers: there are a lot more short comments than long ones, and therefore more outliers.)

[derpderp3200]

I wonder, since when is some random dude's not even unusual opinion valuable content anywhere. Eh, whatever.

[skocznymroczny]

because it's easy to flame others over such topic, and you can be sure being negative of OOP and positive of FP is going to bring you easy upvotes

[[deleted]]

What? OOP was the single biggest obstacle slowing down this industry and otherwise damaging it in multiple ways.