4 ms·

C++, java and other oop languages have been battle tested, and enabled a trillion dollar economy. Sure, others could do the same, but they didnt. Google, msft

C++, java and other oop languages have been battle tested, and enabled a trillion dollar economy. Sure, others could do the same, but they didnt. Google, msft uses c++, c# and a bunch of others and they are probably the most complex software developers in the world. It works. Can it be better? Sure. Rust brings safety guarantees, f# enables functional programming mindset, julia is good for data processing. But oop did bring a lot of to market. We are evolving, and our languages will also evolve.

flukus 7y ago
Using an OOP language does not mean OOP programming. There is plenty of java/c++/c# code out there that use classes as glorified namespaces and stick to POCO/POJO objects. From my own experience I'd say that this describes the best and easiest to maintain code in those languages. The hardest to maintain code is almost usually a mess of inheritance and generics/templates by someone far to "clever" that thinks OOP is the goal and not the tool. More often than not an inheritance hierarchy is basically (not literally) an abstraction over if/switch statements, except the logic will usually be spread out over multiple files and it's impossible to track all these potential branches in your head because they're purposefully obscured from you.
- mikekchar 7y ago
  This is a good point, however it also creates code that has no branch points (ideally) and is therefore easier to reason about. It is virtually identical to the situation of passing a flag to a function and branching based on the flag. This leads to a function that is more complex. You can move the branch above the function and write 2 functions, one which handles each case. But these 2 functions are inherently coupled (and may even share code). So it's a tradeoff. The OO style of programming also often moves the decision point. Instead of having an if statement above the 2 functions, you have the if statement at the construction of the object. If you happen to be writing code where you are doing mostly the same things, but certain details change in certain situations, you can group the differences into objects. If you are familiar with pattern lingo, this often happens if you are doing something that lends itself well to a template pattern. You can then use a bridge pattern to ensure that there is only ever 1 branch, instead of adding a decision point every time you want to vary the behaviour. Where I find people (reasonably, IMHO) disagree is that having the decision point at the place where the behaviour diverges allows you to see the logic of the situation right at that point. If you have a bug in the code related to that, then it's very easy to figure out where it is, because all of the logic is local. On the other hand, if you are refactoring the code, or changing the behaviour across the system, then it is very difficult to change because you have to search for all of those decision points. It's also harder to reason about on an architectural scale because it takes discipline (that may be lacking) to ensure that you always do things exactly the same way. You have a lot more flexibility because you can add all sorts of different logic to each decision point. The lack of constraint means that you have to inspect each case to determine if your overall change is going to work. I'll be honest. I like OO. There are a lot of really diabolical ways you can write bad OO code, but there are lots of diabolical ways you can write any code. I'm familiar and comfortable with imperative, modular code. I'm familiar and comfortable with FP. I'm even familiar and comfortable with declarative code (I wrote some large XSLT systems). There are trade offs which every approach. It's easy to see problems in code that you are not happy with and then throw the baby out with the bath water. Having said that, I don't think there is a problem with having a preference of one style over another, but it's a good idea not to fool oneself into thinking that it solves every problem.
  - goalieca 7y ago
    > On the other hand, if you are refactoring the code, or changing the behaviour across the system, then it is very difficult to change because you have to search for all of those decision points The very best programmers optimize their code for readability. Most of our day is spent reading code.
    - tehlike 7y ago
      That is very true. Reading code is also one hell of a way to understand the bigger picture, and opportunity to familiarize ourselves with a larger system.
  - flukus 7y ago
    > If you have a bug in the code related to that, then it's very easy to figure out where it is, because all of the logic is local. More often than not I find this isn't the case. If we have an inheritance tree of (A -> B -> C) then you'll run into cases where the bug is in a object of type C but it's calling a method defined on type A, overridden in type C and accessing a variable in type B. So you have to look at why A and C diverged, where the value is set in B, what else calls the method on A, etc. You have to know the whole graph and the abstractions are trying to hide it from you. This is particularly true the older code gets because all those little "just overload this function" adds up and it can't be refactored because it's impossible to understand.
pmorais 7y ago
I’d argue that until C++11 C++ was /objectively/ a terrible language and the only reason people used it (and continue to use it) is because it’s nearly 40 years old and therefore ubiquitous. C++ is a language that is literally famous for being famous. I know I certainly wouldn’t be using it if I had any other viable (high performance) language with the same ecosystem, support and tooling. It’s not “battle tested” it’s just too big to fail, and therefore a lot of smart people have dedicated a lot of effort to developing tools and standards that make it just barely passable for enterprise use.
- pjmlp 7y ago
  C++ is part of my favourite languages list, despicte some of the flaws, which I also criticize. I belive that if Java and .NET actually had a proper AOT toolchain since day one, instead of being commercial only (Java's case) or doing basic optimizations (NGEN), there would be even less use cases for its use. EDIT: typo
- mathw 7y ago
  I concur. I used to work with C++98 (roughly, we had some weird levels of compiler support for some of it) and it was utterly foul. The only reason to use it was that there weren't really any better alternatives at the time. We needed something relatively manageable with really high performance, and that's what we got, but my goodness was it a mess in practice. Modern C++ is much better, unfortunately there's stuff from the past they can't ditch without breaking compatibility so it really isn't much better - yes it's got better tools, but nothing's going to make you use them unless your compiler has some clever analysis features you can turn on and do things like make raw "new" an error.
  - mikekchar 7y ago
    I haven't written C++ code since the 90's, but I enjoyed writing code that way. I've also written Java code and C# code (in the late 90's and early 2000's). I enjoyed C++ at least as well as those. Some things are better, some things are worse. I've been doing some Rust lately and probably I would reach for that before I would reach for C++. There's a lot I don't like about Rust. I think it would be great if someone designed a language in about 5 years from now that contains all the things learned about Rust, but was designed from the beginning to solve the problems elegantly. Still, it's a fun language to use. For me modern C++ is interesting, but it has even more of the problems that Rust has. There are lots of good ideas that help fix problems we've seen over the last 40 years or so (man, I'm old...), but I think unless you are already a C++ programmer it's probably more convenient to start with a language that was designed from the beginning to solve those problems. If someone paid me, I'd very happily write C++ code again, though.

flukus 7y ago

Using an OOP language does not mean OOP programming. There is plenty of java/c++/c# code out there that use classes as glorified namespaces and stick to POCO/POJO objects. From my own experience I'd say that this describes the best and easiest to maintain code in those languages. The hardest to maintain code is almost usually a mess of inheritance and generics/templates by someone far to "clever" that thinks OOP is the goal and not the tool. More often than not an inheritance hierarchy is basically (not literally) an abstraction over if/switch statements, except the logic will usually be spread out over multiple files and it's impossible to track all these potential branches in your head because they're purposefully obscured from you.

mikekchar 7y ago
This is a good point, however it also creates code that has no branch points (ideally) and is therefore easier to reason about. It is virtually identical to the situation of passing a flag to a function and branching based on the flag. This leads to a function that is more complex. You can move the branch above the function and write 2 functions, one which handles each case. But these 2 functions are inherently coupled (and may even share code). So it's a tradeoff. The OO style of programming also often moves the decision point. Instead of having an if statement above the 2 functions, you have the if statement at the construction of the object. If you happen to be writing code where you are doing mostly the same things, but certain details change in certain situations, you can group the differences into objects. If you are familiar with pattern lingo, this often happens if you are doing something that lends itself well to a template pattern. You can then use a bridge pattern to ensure that there is only ever 1 branch, instead of adding a decision point every time you want to vary the behaviour. Where I find people (reasonably, IMHO) disagree is that having the decision point at the place where the behaviour diverges allows you to see the logic of the situation right at that point. If you have a bug in the code related to that, then it's very easy to figure out where it is, because all of the logic is local. On the other hand, if you are refactoring the code, or changing the behaviour across the system, then it is very difficult to change because you have to search for all of those decision points. It's also harder to reason about on an architectural scale because it takes discipline (that may be lacking) to ensure that you always do things exactly the same way. You have a lot more flexibility because you can add all sorts of different logic to each decision point. The lack of constraint means that you have to inspect each case to determine if your overall change is going to work. I'll be honest. I like OO. There are a lot of really diabolical ways you can write bad OO code, but there are lots of diabolical ways you can write any code. I'm familiar and comfortable with imperative, modular code. I'm familiar and comfortable with FP. I'm even familiar and comfortable with declarative code (I wrote some large XSLT systems). There are trade offs which every approach. It's easy to see problems in code that you are not happy with and then throw the baby out with the bath water. Having said that, I don't think there is a problem with having a preference of one style over another, but it's a good idea not to fool oneself into thinking that it solves every problem.
- goalieca 7y ago
  > On the other hand, if you are refactoring the code, or changing the behaviour across the system, then it is very difficult to change because you have to search for all of those decision points The very best programmers optimize their code for readability. Most of our day is spent reading code.
  - tehlike 7y ago
    That is very true. Reading code is also one hell of a way to understand the bigger picture, and opportunity to familiarize ourselves with a larger system.
- flukus 7y ago
  > If you have a bug in the code related to that, then it's very easy to figure out where it is, because all of the logic is local. More often than not I find this isn't the case. If we have an inheritance tree of (A -> B -> C) then you'll run into cases where the bug is in a object of type C but it's calling a method defined on type A, overridden in type C and accessing a variable in type B. So you have to look at why A and C diverged, where the value is set in B, what else calls the method on A, etc. You have to know the whole graph and the abstractions are trying to hide it from you. This is particularly true the older code gets because all those little "just overload this function" adds up and it can't be refactored because it's impossible to understand.

pmorais 7y ago

I’d argue that until C++11 C++ was /objectively/ a terrible language and the only reason people used it (and continue to use it) is because it’s nearly 40 years old and therefore ubiquitous. C++ is a language that is literally famous for being famous. I know I certainly wouldn’t be using it if I had any other viable (high performance) language with the same ecosystem, support and tooling. It’s not “battle tested” it’s just too big to fail, and therefore a lot of smart people have dedicated a lot of effort to developing tools and standards that make it just barely passable for enterprise use.

pjmlp 7y ago
C++ is part of my favourite languages list, despicte some of the flaws, which I also criticize. I belive that if Java and .NET actually had a proper AOT toolchain since day one, instead of being commercial only (Java's case) or doing basic optimizations (NGEN), there would be even less use cases for its use. EDIT: typo
mathw 7y ago
I concur. I used to work with C++98 (roughly, we had some weird levels of compiler support for some of it) and it was utterly foul. The only reason to use it was that there weren't really any better alternatives at the time. We needed something relatively manageable with really high performance, and that's what we got, but my goodness was it a mess in practice. Modern C++ is much better, unfortunately there's stuff from the past they can't ditch without breaking compatibility so it really isn't much better - yes it's got better tools, but nothing's going to make you use them unless your compiler has some clever analysis features you can turn on and do things like make raw "new" an error.
- mikekchar 7y ago
  I haven't written C++ code since the 90's, but I enjoyed writing code that way. I've also written Java code and C# code (in the late 90's and early 2000's). I enjoyed C++ at least as well as those. Some things are better, some things are worse. I've been doing some Rust lately and probably I would reach for that before I would reach for C++. There's a lot I don't like about Rust. I think it would be great if someone designed a language in about 5 years from now that contains all the things learned about Rust, but was designed from the beginning to solve the problems elegantly. Still, it's a fun language to use. For me modern C++ is interesting, but it has even more of the problems that Rust has. There are lots of good ideas that help fix problems we've seen over the last 40 years or so (man, I'm old...), but I think unless you are already a C++ programmer it's probably more convenient to start with a language that was designed from the beginning to solve those problems. If someone paid me, I'd very happily write C++ code again, though.