Is Object-Oriented Programming a Trillion Dollar Disaster? (medium.com) 782
Senior full-stack engineer Ilya Suzdalnitski recently published a lively 6,000-word essay calling object-oriented programming "a trillion dollar disaster."
Precious time and brainpower are being spent thinking about "abstractions" and "design patterns" instead of solving real-world problems... Object-Oriented Programming (OOP) has been created with one goal in mind -- to manage the complexity of procedural codebases. In other words, it was supposed to improve code organization. There's no objective and open evidence that OOP is better than plain procedural programming... Instead of reducing complexity, it encourages promiscuous sharing of mutable state and introduces additional complexity with its numerous design patterns. OOP makes common development practices, like refactoring and testing, needlessly hard...
Using OOP is seemingly innocent in the short-term, especially on greenfield projects. But what are the long-term consequences of using OOP? OOP is a time bomb, set to explode sometime in the future when the codebase gets big enough. Projects get delayed, deadlines get missed, developers get burned-out, adding in new features becomes next to impossible. The organization labels the codebase as the "legacy codebase", and the development team plans a rewrite.... OOP provides developers too many tools and choices, without imposing the right kinds of limitations. Even though OOP promises to address modularity and improve reusability, it fails to deliver on its promises...
I'm not criticizing Alan Kay's OOP -- he is a genius. I wish OOP was implemented the way he designed it. I'm criticizing the modern Java/C# approach to OOP... I think that it is plain wrong that OOP is considered the de-facto standard for code organization by many people, including those in very senior technical positions. It is also wrong that many mainstream languages don't offer any other alternatives to code organization other than OOP.
The essay ultimately blames Java for the popularity of OOP, citing Alan Kay's comment that Java "is the most distressing thing to happen to computing since MS-DOS." It also quotes Linus Torvalds's observation that "limiting your project to C means that people don't screw things up with any idiotic 'object model'."
And it ultimately suggests Functional Programming as a superior alternative, making the following assertions about OOP:
Using OOP is seemingly innocent in the short-term, especially on greenfield projects. But what are the long-term consequences of using OOP? OOP is a time bomb, set to explode sometime in the future when the codebase gets big enough. Projects get delayed, deadlines get missed, developers get burned-out, adding in new features becomes next to impossible. The organization labels the codebase as the "legacy codebase", and the development team plans a rewrite.... OOP provides developers too many tools and choices, without imposing the right kinds of limitations. Even though OOP promises to address modularity and improve reusability, it fails to deliver on its promises...
I'm not criticizing Alan Kay's OOP -- he is a genius. I wish OOP was implemented the way he designed it. I'm criticizing the modern Java/C# approach to OOP... I think that it is plain wrong that OOP is considered the de-facto standard for code organization by many people, including those in very senior technical positions. It is also wrong that many mainstream languages don't offer any other alternatives to code organization other than OOP.
The essay ultimately blames Java for the popularity of OOP, citing Alan Kay's comment that Java "is the most distressing thing to happen to computing since MS-DOS." It also quotes Linus Torvalds's observation that "limiting your project to C means that people don't screw things up with any idiotic 'object model'."
And it ultimately suggests Functional Programming as a superior alternative, making the following assertions about OOP:
- "OOP code encourages the use of shared mutable state, which has been proven to be unsafe time and time again... [E]ncapsulation, in fact, is glorified global state."
- "OOP typically requires a lot of boilerplate code (low signal-to-noise ratio)."
- "Some might disagree, but OOP code is notoriously difficult to unit test... [R]efactoring OOP code is really hard without dedicated tools like Resharper."
- "It is impossible to write good and maintainable Object-Oriented code."
Tiresome (Score:5, Insightful)
Following the logic I see here we should never have abandoned assembly language.
Re:Tiresome (Score:5, Insightful)
Following the logic I see here we should never have abandoned assembly language.
Correct :) If you can't do it in K&R C, then do it in assembler; If you can't do it in assembler then it can't be done!
Re: (Score:2)
Most languages process information in the way C/C++ set out to do it. You can find more here: https://en.cppreference.com/w/... [cppreference.com]
For your particular examples though, it isn't multiple operations on a single string. Instead, it is "take a string, perform first operation" and then "the returned value of said function, which just so happens to be a string, perform this other operation on that instead"
Re: OOP is far easier to maintain (Score:5, Insightful)
I don't see any other way to create large projects.
To play devil's advocate, I will say that sometimes what by all rights should be a small project is made a large project and OOP-style thinking is somewhat to blame.
At least some OOP developers jump straight to crazy levels of abstraction and exploding a simple class across multiple layers of inheritence "just in case they want to reuse it". In the process the make following some flows jump through many source files for the simplest task.
Of course, judicious use of OOP is fine and it is an intuitive way to manage namespace when you have justified large/complex codebase in play.
Long live France! (Score:2)
Re:Long live France! (Score:5, Insightful)
I do not like to claim "I know C", since the time I have started to learn language, around 1987. But let's say I am familiar with certain applications of the language. C++ however is an abomination that made me hate OOP concepts. Java was far away from the metal for most of my use cases, so only after discovering Python, I could get comfortable with OOP.
TFA OTOH is complete and utter BS.
Re:Long live France! (Score:5, Informative)
Bjarne has never said that C++ is an OO language, only that it supports the OO paradigm.
The headline 100% supports Betteridges law though:
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
You are apparently unable to think logically.
Re:Tiresome (Score:4, Insightful)
I often do OOP in C, there is no reason not to do it in ASM.
OOP is a way of structuring code, it isn't a language feature.
Linus doesn't see object models in C because we use different words and he didn't notice. He doesn't really do anything else so it doesn't affect him.
Re: (Score:2)
The organization, structural and scoping elements of OOP are just a small part of it though. I agree they are good, but for example C doesn't supply things like templates or inheritance or OO memory management by reference.
Many of the issues with OO are with that more advanced stuff, and in particular the C++ implementation of it. More modern languages like C# do a much better job with it.
Re: (Score:3, Insightful)
I often do OOP in C, there is no reason not to do it in ASM.
OOP is a way of structuring code, it isn't a language feature.
Correct, but a language with support for OO programming can make live an awful lot easier. This is where C++ shines because it gives you the choice. ...unlike Java, which simultaneously (a) forces you to use objects, and (b) removes essential OO features like inheritance of implementation (notice I didn't say "multiple inheritance" there).
Linus doesn't see object models in C because we use different words and he didn't notice. He doesn't really do anything else so it doesn't affect him.
Linus isn't right about everything. The person who wrote that article/summary is wrong about an awful lot of things.
Re:Tiresome (Score:5, Insightful)
Re: Tiresome (Score:5, Informative)
You're missing the single most important feature of C++ , ie. RAII
(and so is Java, et, al)
If you haven't grokked RAII yet then the whole of programming has simply gone whoosh over your head.
Not Tiresome, Hilariously Hypocritical (Score:5, Funny)
There's no objective and open evidence that OOP is better than plain procedural programming...
...which is followed by the author's subjective opinions about why procedural programming is better than OOP. There's no objective comparison of the pros and cons of OOP vs procedural just a rant about some of OOP's problems. But the real icing on the cake has to be:
Precious time and brainpower are being spent thinking about "abstractions" and "design patterns" instead of solving real-world problems...
...says the person who took the time to write a 6,000 word rant on "why I hate OOP".
Re:Not Tiresome, Hilariously Hypocritical (Score:4, Informative)
There's no objective and open evidence that OOP is better than plain procedural programming...
...which is followed by the author's subjective opinions about why procedural programming is better than OOP. There's no objective comparison of the pros and cons of OOP vs procedural just a rant about some of OOP's problems.
We start from the point-of-view that OOP has to prove itself. Has it? Has any project or programming exercise ever taken less time because it is object-oriented?
Precious time and brainpower are being spent thinking about "abstractions" and "design patterns" instead of solving real-world problems...
...says the person who took the time to write a 6,000 word rant on "why I hate OOP".
Sadly, that was something you hallucinated. He doesn't say that anywhere.
Re:Not Tiresome, Hilariously Hypocritical (Score:4, Insightful)
I don't need to ask if you're stupid, using libraries doesn't equal using OOP.
Re: (Score:3)
Did we read the same article? He never says procedural is better, he says functional is better.
Re:Tiresome (Score:4, Insightful)
You didn't follow the logic. (That may not be your fault; the logic was split across 15 classes.)
The author specifically called out Alan Kay, so if you want to do OOP, by all means use Smalltalk or Scheme or Erlang.
Re:Tiresome (Score:5, Funny)
Screw that, even Assembly is a disaster. It is Turing complete, which makes pretty impossible to formally verify to be correct. You never know when it's going to end.
The trick is use a piece of string to tie the computer's plug to the printer's carriage then send a "CR" when the program is finished.
Re: (Score:3)
Although I never made it my job, I did have 2 years formal training in computer science. From the moment I started using OO language (java and C++), I never could get the point of it. As far as I understood (and understand to this day), it never felt any different from using well defined functions, sub-functions and libraries for any task that became even slightly complex. Discussing it with people around, I've never met anyone who could define it as something else than that, when we got down to i
Re:Tiresome (Score:5, Informative)
> OO language (java and C++), I never could get the point of it. As far as I understood (and understand to this day), it never felt any different from using well defined functions, sub-functions and libraries for any task that became even slightly complex.
Your view is basically correct -- but is a little incomplete. While it is true that one can use OOP in any language (even assembly) OOP solves many problems (and creates others but that is a separate discussion) but some of the problems it solves in C++ are:
* initializing fields to sane values if we want when the object is created
* define what should happen on assignment (shallow copy? deep copy?)
* provides STANDARD names for common operations
* provides an "API" for operations
* hiding of data so other people can't accidentally modify it
* the possibility for syntax sugar for readability.
For example, lets code a 3D vector with addition and dot product. In purely procedural fashion you would have functions like:
void v3add( float *sx, float *sy, float *sz, float ax, float ay, float az, float bx, float by, float bz )
{
*sx = ax + bx;
*sy = ay + by;
*sz = sz + bz;
}
float v3dot( float ax, float ay, float az, float bx, float by, float bz ) ;
{
return
(ax * bx) +
(ay * by) +
(az * bz)
}
However this is error prone. Some of the things that makes this easy to screw up include:
* With 6+ arguments it is WAY to easy to mismatch argument order,
* What if the function has two names of the parameter names switched?
In good C you would start with a POD (Plain Old Data). Now our function would look like this:
struct v3
{
float x, y, z
};
void v3add( v3 *sum, v3 a, v3 b )
{
*sum.x = a.x + b.x;
*sum.y = a.y + b.y;
*sum.z = a.z + b.z;
}
float v3dot( v3 a, v3 b )
{
return (a.x * b.x) + (a.y * b.y) + (a.z * b.z);
}
It would be nice if we could tell the compiler that our params a and b are never modified -- this might allow it to generate better code. This is called "const correctness". This also tells other programmers that are params are "read only"
Notice how we are always passing around a struct. We could extend this struct and add functions to it to define what _operations_ we can do on it. We an also add syntax sugar to use the '+' and '=' operator instead of wordy words.
class v3
{
float x, y, z;
public:
v3() {
x = y = z = 0.0f;
}
v3( float _x, float _y, float _z ) { // constructor
x = _x;
y = _y;
z = _z;
}
v3& operator = ( const v3& rhs ) {
this->x = rhs.x;
this->y = rhs.y;
this->z = rhs.z;
return *this;
};
Re: (Score:3)
As a game programmer, I would like to point out that 99% of our work is done OOP, in C++. Any data oriented design isn't an afterthought, per se, but it's not what most programmers are concentrating on until closer to the end of the dev cycle. Then we go and spot-optimize. But everything except the core engine is really generic C++ programming.
C++ and OOP don't scale well for a lot of things—possibly game programming—but it works well enough, and that's what our tools are geared towards, so that
Re:Tiresome (Score:5, Interesting)
Inheritance, while not "inherently" bad, is often the wrong solution. See: Why extends is evil [javaworld.com]
Composition is frequently a more appropriate choice. Aaron Hillegass wrote this funny little anecdote in Cocoa Programming for Mac OS X [google.com]:
"Once upon a time, there was a company called Taligent. Taligent was created by IBM and Apple to develop a set of tools and libraries like Cocoa. About the time Taligent reached the peak of its mindshare, I met one of its engineers at a trade show. I asked him to create a simple application for me: A window would appear with a button, and when the button was clicked, the words 'Hello, World!' would appear in a text field. The engineer created a project and started subclassing madly: subclassing the window and the button and the event handler. Then he started generating code: dozens of lines to get the button and the text field onto the window. After 45 minutes, I had to leave. The app still did not work. That day, I knew that the company was doomed. A couple of years later, Taligent quietly closed its doors forever."
The issue (Score:5, Insightful)
It's really just Eternal September brought to programming. When you make it easy for anyone to join, that's exactly what you get.
Re: (Score:2)
In embedded C programming almost all the large Apache 2 licensed libraries use OOP.
Re: (Score:3, Informative)
Functional keeps failing, givvittup (Score:3)
Indeed. Most Functional programming (FP) demonstrations on realistic domains don't show any objective benefit. It's usually claimed it helps you "think better", which is really hard to measure.
FP has been around since the early 1960's. It's been tried and retried and reretried. It has failed in the mainstream* market-place for many decades despite bein
Re: (Score:2)
Re: (Score:3)
Sometimes you just don't do it that way. If the code is that big, split it up. Have multiple programs that talk to each other. Define what each program does and how it communicates, then don't worry about the how each program does its stuff. Don't worry that one single person can't understand it all, delegate this job to multiple people and have them communicate with each other.
Many of these million line programs evolved from relatively simple systems that grew over time without following any sort of des
Re: (Score:3)
Re:The issue (Score:5, Insightful)
Almost every programming methodology can be abused by people who really don't know how to program well, or who don't want to. They'll happily create frameworks, implement new development processes, and chart tons of metrics, all while avoiding the work of getting the job done. In some cases the person who writes the most code is the same one who gets the least amount of useful work done.
So, OOP can be misused the same way. Never mind that OOP essentially began very early and has been reimplemented over and over, even before Alan Kay. Ie, files in Unix are essentially an object oriented system. It's just data encapsulation and separating work into manageable modules. That's how it was before anyone ever came up with the dumb name "full-stack developer".
Lol again modded down for facts (Score:3)
Another fact: Moderation on slashdot is broken by design
Re:The issue (Score:5, Insightful)
As a developer who started in the days of FORTRAN (when it was all-caps), I've watched the rise of OOP with some curiosity. I think there's a general consensus that abstraction and re-usability are good things - they're the reason subroutines exist - the issue is whether they are ends in themselves.
I struggle with the whole concept of "design patterns". There are clearly common themes in software, but there seems to be a great deal of pressure these days to make your implementation fit some pre-defined template rather than thinking about the application's specific needs for state and concurrency. I have seen some rather eccentric consequences of "patternism".
Correctly written, OOP code allows you to encapsulate just the logic you need for a specific task and to make that specific task available in a wide variety of contexts by judicious use of templating and virtual functions that obviate the need for "refactoring". Badly written, OOP code can have as many dangerous side effects and as much opacity as any other kind of code. However, I think the key factor is not the choice of programming paradigm, but the design process. You need to think first about what your code is intended to do and in what circumstances it might be reused. In the context of a larger project, it means identifying commonalities and deciding how best to implement them once. You need to document that design and review it with other interested parties. You need to document the code with clear information about its valid and invalid use. If you've done that, testing should not be a problem.
Some people seem to believe that OOP removes the need for some of that design and documentation. It doesn't and indeed code that you intend to be reused needs *more* design and documentation than the glue that binds it together in any one specific use case. I'm still a firm believer that coding begins with a pencil, not with a keyboard. That's particularly true if you intend to design abstract interfaces that will serve many purposes. In other words, it's more work to do OOP properly, so only do it if the benefits outweigh the costs - and that usually means you not only know your code will be genuinely reusable but will also genuinely be reused.
Re:The issue (Score:5, Insightful)
[...] I'm still a firm believer that coding begins with a pencil, not with a keyboard. [...]
This!
In fact, even more: I'm a firm believer that coding begins with a pencil designing the data model that you want to implement.
Everything else is just code that operates on that data model. Though I agree with most of what you say, I believe the classical "MVC" design-pattern is still valid. And, you know what, there is a reason why it is called "M-V-C": Start with the Model, continue with the View and finalize with the Controller. MVC not only stood for Model-View-Controller but also for the order of the implementation of each.
And preferably, as you stated correctly, "... start with pencil & paper ..."
Re:The issue (Score:5, Insightful)
I struggle with the whole concept of "design patterns".
Because design patterns are stupid.
A reasonable programmer can understand reasonable code so long as the data is documented even when the code isnt documented, but will struggle immensely if it were the other way around. Bad programmers create objects for objects sake, and because of that they have to follow so called "design patterns" because no amount of code commenting makes the code easily understandable when its a spaghetti web of interacting "objects" The "design patterns" dont make the code easier the read, just easier to write.
Those OOP fanatics, if they do "document" their code, add comments like "// increment the index" which is useless shit.
The big win of OOP is only in the encapsulation of the data with the code, and great code treats objects like data structures with attached subroutines, not as "objects", and document the fuck out of the contained data, while more or less letting the code document itself.
Re: (Score:3)
This
The big win of OOP is only in the encapsulation of the data with the code
it's difficult to find the right words to describe how much of an advance an ORM is over plain SQL statements. I have a massive and old application that has no shred of OOP and does all its data handling via SQL into variables. It's a mess and hard to organize in any meaningful way. Bringing the same data together into objects and abstracting the database to an ORM made the whole thing so much easier to understand, maintain and expand.
Re: (Score:3)
I learned OOP with Eiffel, and for a while I was hooked. I left it behind. These days I do C and use Python as glue and keep OO elements to a minimum. As it turns out, OOP is just much more effort than procedural and it rarely pays off to invest that effort, at least for me.
Re:The issue (Score:4, Insightful)
The problem isn't the object orientation paradigm itself, it's how it's applied.
The big problem in any project is that you have to understand how to break down the final solution into modules that can be developed independently of each other to a large extent and identify the items that are shared. But even when you have items that are apparently identical don't mean that they will be that way in the long run, so shared code may even be dangerous because future developers don't know that by fixing problem A they create problems B, C, D and E.
Eternal September? (Score:4, Informative)
Re: (Score:3)
Any time you make something easier, you lower the bar as well and now have a pack of idiots that never could have been hired if it weren't for a programming language that stripped out a lot of complexity for them.
Exactly. There are quite a few aspects of writing code that are difficult regardless of language and there the difference in skill and insight really matters.
Re: (Score:2)
I am not a software developer. Still, I sometimes code a bit, mostly private projects which help me automate some tasks, for example, or explore a "what-if" scenario... you know, beginner stuff.
With that being said, I always favored procedural programming. Dunno, maybe it's easier to work with as a beginner, maybe it better fits my way of approaching a problem.
Re:The issue (Score:5, Insightful)
I have about 35+ years of software development experience, including with procedural, OOP and functional programming languages.
My experience is: The question "is procedural better than OOP or functional?" (or vice-versa) has a single answer: "it depends".
Like in your cases above, I would exactly do the same: use some procedural language that solves my problem quickly and easily.
In large-scale applications, I mostly used OOP (having learned OOP with Smalltalk & Objective-C). I don't like C++ or Java - but that's a matter of personal preference.
I use Python for large-scale scripts or machine learning/AI tasks.
I use Perl for short scripts that need to do a quick task.
Procedural is in fact easier to grasp for beginners as OOP and functional require a different way of thinking. If you start developing software, after a while (when the project gets complex enough) you will probably switch to OOP or functional.
Again, in my opinion neither is better than the other (procedural, OOP or functional). It just depends on the task at hand (and of course on the experience of the software developer).
its the way OOP is taught (Score:5, Interesting)
Re:its the way OOP is taught (Score:5, Insightful)
deal with idiotic assignments like making a random number generator USING CLASSES, or displaying text to a screen USING CLASSES.
Part of the problem is that the use cases where OOP is actually a reasonable fit, tend to be beyond the scope of what fits neatly packaged into a short class assignment. As such, they need contrived cases to shoehorn it in where it normally would not be used.
Re: (Score:2)
OOP fits easily into small programs too. Often it might not seem like OOP to someone with a strict definition about enforced encapsulation and inheritance rules though. You can do OOP with basic C. Every time you use a file you're essentially using something that's object oriented.
Re: (Score:2)
Mostly self-taught here. Of course he's right that OOP can get a mess. But that does not mean that linear coding automagically results in a stable maintainable code base.
Plenty examples of OOP gone wrong. There's also plenty examples where using OOP saves the day. Where using OOP saves you from a bunch of trouble and overhead, had you done it with linear code. Starting with memory management and not ending with parsing data or states in a multi-threaded or modular environment. If done right. As with anythin
Re: (Score:2)
He doesn't suggest using pure procedural code as an alternative. Even the summary tells you that.
Re: (Score:2)
*THIS* is exactly the point. I've been following a twitter thread of some guy trying to write a faster string-compare function in C#... watching the code evolve is just driving me insane with the amount of abstraction in it. Like...
string a = str1.getchar(x);
string b = str2.getchar(x);
if (chrcode(a) == chrcode(b)) return true;
and doing this in a loop. except the getchar functions are things he rolled as well. the entire process is insanely bad and complex, yet he's happy to be able to compare ~10kb in ~5ms
Re:its the way OOP is taught (Score:5, Interesting)
That and the obsession with absofrackinglutely EVERYTHING just having to be a formally declared object including the while program being an object with a run() method.
Some things actually cry out to be objects, some not so much.Generally, I find that my most readable and maintainable code turns out to be a procedural program that manipulates objects.
Even there, some things just naturally want to be a struct or just an array of values.
The same is true of most ingenious ideas in programming. It's one thing if code is demonstrating a particular idea, but production code is supposed to be there to do work, not grind an academic ax.
For example, slavish adherence to "patterns". They're quite useful for thinking about code and talking about code, but they shouldn't be the end of the discussion. They work better as a starting point. Some programs seem to want patterns to be mixed and matched.
In reality those problems are just cargo cult programming one level higher.
I suspect a lot of that is because too many developers barely grasp programming and never learned to go beyond the patterns they were explicitly taught.
When all you have is a hammer, the whole world looks like a nail.
Re: (Score:2)
Amen to that.
Slavish adherence to formal ritual is a sign that one has nothing better to think about.
Re: (Score:2)
deal with idiotic assignments like making a random number generator USING CLASSES,
That doesn't seem like a terrible fit, it's a bit like std::random from C++ but with virtual functions. e.g. define a base engine that has a single method that generates a uint64_t or something. Then have several classes derived from it that provide concrete implementations, e.g. xorshift, linear congruential (not mt19937 for this class, it's way too big), maybe even access to /dev/urandom.
Then provide some implementations of
Re: (Score:3)
the kids were being taught EVERY program was to to be assembled solely by sticking together bits of libraries. There was no coding, just hunting for snippets of preexisting code to glue together. Zero idea they could add their own, much less how to do it.
Lego coding. It's why the answer to every Javascript question on StackOverflow is jQuery. Slap another brick on top, the heavier the better because it must be full of kewl, and if you end up with a tower of 2x10 bricks stacked badly on top of a 1x1 brick, w
Re: (Score:2)
Re: (Score:2)
Word salad. Nothing about OOP lessens the need for locks if you share state between instances, and nothing about non-OOP code requires sharing state. Just as you can have a reference to a unique instance per-thread, you can have a separate struct that stores state, and is passed to functions. That's how you'd do it with procedural and functional code.
Re: (Score:2)
Yup. For example, you've got a cryptographically strong random number generator that you need for making keys, and a relatively weak but fast random number that you use for implementing randomized backoff times. Stick a consistent API around them, encapsulate the implementation details so that they can both be used interchangeably, and you've got an object oriented random number system.
Ahh yes, the absolute dearth of C++ is terrible (Score:5, Funny)
Re: (Score:3)
No large codebases in the world are built on C++, it's a disaster! Android, Unreal Engine 4, Windows. Entirely unusable trash doomed to failure, only plebians would write in anything but assembly using punchcards! No get off my damned lawn!
Not only that but all the major optimising C compilers are written in C++ now, so Linux relies on C++ for anything approaching decent performance.
Re: (Score:3)
Well, if you look at the bug count of your average Windows version, the word "trash" seems an euphemism.
Re: (Score:3)
Technically UE3 did exist in 2004. In fact, it existed in 2002.
Tim Sweeney: Unreal 3 engine has been in development for [over] 18 months now.
-- June 2004, from https://www.eurogamer.net/arti... [eurogamer.net]
But you're right, they didn't start work on UE4 in 2004. They started work on it in 2003.
Rein: "We've been working on Unreal Engine 4 for two years"
-- August 2005, from https://web.archive.org/web/20... [archive.org]
Yeah, I can believe there's a level of technical debt - but since the source code is available, you can download it and see.
Almost right (Score:5, Funny)
The entire software world is a multi-trillion dollar disaster. Agile, Waterfall, Oop, fucking Javascript or worse its wannabe spawn of the devil Node. C, C++, Java wankers, did I say wankers? Yes wankers. IT architects, pundit of the week, carpetbaggers, Aspies, total incompetents moving from job to job, you name it. Disaster, complete and utter. Anybody who doesn't know this hasn't been paying attention. About the only bright spot is a few open source projects like Linux Kernel, Postgres, Samba, Squid etc, totally outnumbered by wankers and posers.
Re: (Score:2)
Re:Almost right (Score:5, Insightful)
I have no idea why you were modded funny.
Software is a crapshot. Most of it actually is built from spit and bubble gum. It's very much in its infancy, and the fact that half the world now runs on something we are still busy figuring out should scare us all to death. The fact that just bugs vulnerable to exploits are such that it takes a five-digit enumeration scheme every year to give them numbers is mind-boggling.
Unlike you, I don't think there are many bright spots, and they are not in the open source world. They are in the very closed circles of companies that can't get it wrong. NASA has (or had, don't know about the current state of affairs) an entirely different programming culture than almost everyone else, and the most important difference is how they treat each and every bug.
As it stands, software is a disaster. But in the evolutionary sense - as long as it is barely good enough to survive, it will. As long as the environment isn't so hostile that it kills off all the bad crap, that bad crap will prosper.
Re: (Score:3)
Software should be an engineering science by now
Disagree slightly. It should have an engineering science, not be one.
I very much love to dabble, to write small software for myself or a small audience that solves a specific problem. It just frightens me that most commercial software is written with much the same attitude.
No, you cannot do that!. You can hack up a hobby project in your backyard with an old bath tub and two motors from old vacuum cleaners. That's fine for your YouTube channel, and it's fun. But you can't build a mass-manufactured car/helico
Re: (Score:2)
You seem to have reading comprehension dysfunction. I posted nothing about oop per se, just the whole broken software world, including you.
Re: (Score:2)
Gotta take a shot at real oop, I guess.
Rust does it 30% faster!!!!11!! (Score:3)
Obviously Not... (Score:5, Interesting)
Well, nothing is a trillion dollar disaster, but bonus points for the headline getting attention.
But, even if OOP and Design Patterns can and are abused, the fact is the basic abstractions do work and OOP, in the Java and C# forms exist for a very good reason. They allow average programmers to tackle business logic with a reasonable chance of creating something useful.
Of course, functional programming is mentioned in the article with almost reverent attitude. The author claims that OOP was never studied with rigor. This is false, the semantics of OOP were defined in numbers of papers and well researched.
Also, functional programming did not start with Haskell. I am surprised at how many programmers laud Haskell as some amazing new discovery and don't know it evolved from SML, a language in the 80s.
Functional programming has a major problem. It's elegance comes at a cost. Programming is hard enough, but there are few programmers that write elegant functional code. The abstractions are harder to understand and teach. Frankly, there's just more complex math involved.
OOP, mutable state and the like does cause issues, but they are easier to understand and use.
Finally, C# and Java have adopted many functional paradigms. While Java (due to problems with type erasure and generics, separation of object and primitive types) makes it more tricky, both languages allow for functional abstractions to be used. I mean, C# has a form of pattern matching now.
In short, of course elegant solutions and languages have a great appeal, but they still struggle to be used by average developers to solve average problems. C#, Java and even JavaScript have faired better in this regard. I argue we would have much, much less software without them.
Re: (Score:3)
Functional programming has a major problem. It's elegance comes at a cost. Programming is hard enough, but there are few programmers that write elegant functional code. The abstractions are harder to understand and teach. Frankly, there's just more complex math involved.
More importantly, it's impossible to do without cheating. Try printing something to the console, or saving it in a database, without changing state. It's impossible. Not even Haskell pretends to be able to do it.
Re: (Score:3)
Actually, Haskell does manage to do IO and databases etc without mutating state. It uses monads to achieve this. Two things though:
1. Monads are a fairly simple concept that is, for some reason, virtually impossible for newbies to understand. I think I got it on about the fourth attempt and the Wikipedia page was, for many years a completely impenetrable mess.
2. (And this is the really telling one) Having found a way to use monads to do IO etc, they invented some syntactic sugar ("do notation") to make it l
Re: (Score:2)
Classic satire (Score:2)
More strawmen than can fit in a barn (Score:5, Insightful)
Does anyone recall anyone promising that the introduction of OOP would make bad programmers and bad software architects disappear? I sure don't.
Is there anyone around who actually thinks that designating an OOP language means that nobody will try to implement a bad object model? There might be somebody who thought this but I never met them.
Does anyone dispute you can take an OOB language and write procedural, non-OO code with it? This isn't done that I have seen but I think I know the reason that it isn't.
Brother Ilya is full of himself and needs to get over it. Yes "Some People" oversold some software (Java's original write-once-run-everywhere comes to mind) technology. Who cares.
Many many more serious (and less self-absorbed) project teams adopted whatever language as a tool that needed to be used correctly and with discipline, not worshiped as a religion. Every tool has strengths and weaknesses and more importantly a proper way to use it and mature, productive workers understand this.
And even those teams will cock it up now and then and when they do they go back and fix it not pretend everything would have been fine if only we had stuck to C.
Re: (Score:3)
Everything would have been fine if only we had stuck to C.
Not OOP. Java. (Score:5, Insightful)
It isn't OOP design patterns that are the problem. It is Java's perversion of OOP design patterns. When you start getting atrocities like factory classes that allocate factory classes (it's factory classes all the way down, you see), you're heading down a rabbit hole from which there is no escape other than to shout "off with its head" and start over from scratch.
OOP done right is more like Objective-C. You start out with a bunch of well thought out base classes, and you construct primarily through adding new functionality to existing classes (composition, not inheritance). Instead of passing in some custom factory class abomination whose sole purpose is to provide methods that create some other class, you just pass in the underlying Class object that you want to create, and ensure that its class methods conform to a protocol (typically "alloc/init"). Or, more commonly, you pass in some instance of that class from the outside, depending on what you're doing.
One thing that Objective-C got wrong, of course, was overuse of delegates. We'd be better off if blocks had been around from the very beginning, as probably 99% of delegates would be better if they were instead used method calls that take a block parameter to call upon completion and/or stored reference to blocks that get performed whenever something happens.
And there are a lot of linguistic quirks in Objective-C that are problematic, like how tedious it is to construct an array out of a pile of objects, some of which may be nil, presumably because the language was designed back before people thought about rolling out features remotely after a release.
And then, there are NeXT/Apple's use of class clusters; that's a special kind of h*** that makes subclassing nearly impossible for no outwardly obvious reason.
But on the scale of horrors, Objective-C's OOP tends not to feel like an "oops" nearly as often as in other languages.
Re: (Score:2)
Re:Not OOP. Java. (Score:5, Interesting)
Factory classes are just a symptom of bad system design, not a problem of the language itself.
A I see it both Java and C# suffers from shortcomings (or rather shortcuts) that makes things less strict than they should be, which in turn creates some problems. A better way would have been to actually work with Ada, but no big software company provides a good and cheap Ada development environment, and Ada have some issues that makes it less appealing to work with.
I'm the kind of programmer that likes strong static typing with explicit exception declarations so that I always know which exceptions that I can expect and don't get nasty runtime surprises if there's a type change somewhere remote that I have missed. Getting the problems displayed right at compile time is as I see it preferred over discovering them later as this will make the time to fix as short as possible. Static code analysis is the next stage, and is also an important part of the work, even though some tools are a bit weird on that matter and are pointing out acronyms as spelling errors etc.
Right solution for the time (Score:2)
Re: (Score:2)
That's why embedded C uses OOP so often; asynchronous events.
Criticizing Microsoft and Oracle? (Score:2)
C# is from Microsoft. [wikipedia.org] Java is from Oracle. [wikipedia.org]
Is C++ OOP okay? [wikipedia.org]
Who? (Score:3, Insightful)
clicks TFA
Clean up your own house, first. The current impending disaster is that people are building "full stacks" in a programming language where you can add NaN to NaN, divide that be zero, compare the result to undefined, and not get a single exception along the way--a language with coercion rules so irreparably wrong-headed that it had to add a coercionless equality operator!
You don't need OOP to have promisculously-shared mutable objects. You don't need OOP to have an abstraction mess. You don't need OOP to have conflated concerns and unmaintanable spaghetti.
You get all those things by not realizing that API design is a totally separate skill from implementation--almost to the same degree that being able to write coherent documentation is a separate skill. Instead of recognizing that separation, industry conflated them, and OOP was the crutch used to give people without API design skills a cargo-cult religion for building things.
Used well, OOP can express relationship between complex concepts as easily as FP models relationships between types. Used poorly, you get the same garbage you get from using anything poorly. It's just that OOP garbage tends to be more verbose.
FP is not an alternative (Score:5, Insightful)
Regret.... (Score:2)
Sounds like this guy is not educated enough to use the right tool for the right job.
You don't go using OO in a database report.
In actual fact, the key time when you should be using OO is when creating a framework. The resulting use of that framework, in the business context, would be procedural.
It depends... (Score:5, Insightful)
There are a lot of mediocre programmers who follow the principle "if you have a hammer, everything looks like a nail". They know OOP, so they think that every problem must be solved in an OOP way. In fact, OOP works well when your program needs to deal with relatively simple, real-world objects: the modelling follows naturally. If you are dealing with abstract concepts, or with highly complex real-world objects, then OOP may not be the best paradigm.
In Java, for example, you can program imperatively, by using static methods. The problem is knowing when to break the rules. For example, I am working on a natural language system that is supposed to generate textual answers to user inquiries. What "object" am I supposed to create to do this task? An "Answer" object that generates itself? Yes, that would work, but an imperative, static "generate answer" method makes at least as much sense.
There are different ways of thinking, different ways of modelling a problem. I get tired of the purists who think that OO is the only possible answer. The world is not a nail.
Re: (Score:3)
I get tired of the purists who think that OO is the only possible answer. The world is not a nail.
You and me both. But available evidence suggests rather strongly that to most people the world is indeed a nail.
No, not really, don't think so. (Score:2)
OOP has been a golden hammer ever since Java, but we've noticed the downsides quite a while ago. Ruby on rails was the convention over configuration darling child of the last decade and stopped a large piece of the circular abstraction craze that Java was/is. Every half-assed PHP toy project is kicking Javas ass on the web and it's because WordPress gets the job done, fast, despite having a DB model that was built by non-programmers on crack.
Most critical processes are procedural, even today if only for the
No, it isn't (Score:5, Insightful)
But I love it when you talk about your monads, it makes me feel all hot and tingly.
You gotta love functional programming: "there's no state! We don't need state! State is an abomination! Down with state! And if you need to do something stateful, like IO, we just give it a silly name, so we look really smart."
Does functional programming have its place? Sure. Is it a silver bullet that can replace everything? Of course not, don't be silly. And perhaps an article about the virtues of functional programming would be more convincing if it could stand on its own, without needing to tear into other methodologies.
ur doing it wrong (Score:2)
"OOP typically requires a lot of boilerplate code (low signal-to-noise ratio)."
If your code requires a lot of boilerplate code, you're doing it wrong. Stop writing so much boilerplate, that's on you.
Class? Object? (Score:4, Interesting)
Re:Class? Object? (Score:5, Funny)
A bit trollish (Score:2)
Functional programming, despite being "the next big thing" since the 70s, and being all the rage in the CS scene, hasn't caught on as much as it was foreseen, because it is difficult for modelling the reality of the tasks that typically get automated by software, and becaus
Terrible article with some valid points (Score:3)
There certainly are bad things about object oriented programming and various languages which implement it, but there's no real analysis here. Much of the article is spent on trying to find real world analogies, which are completely irrelevant, or even the wrong ones, which to me indicates that the writer doesn't really 'get' object oriented programming.
I definitely agree that in practice there are often problems like killing encapsulation with references, and all sort of evils, but pretty much every framework forces a way of thinking that doesn't always fit how people think about what needs to be done. It's easier to work with concepts, and object orientation makes it easier than procedural programming. From my limited experience with functional programming, it's not actually better at that.
In the end, it's possible that it's harder to create bugs in functional programming than in modern object oriented programming, but it's also possible that it's because it requires more up front design to get right. I don't have enough experience to really judge if either the premise or my speculation are right.
Going back to Torvald's quote.... (Score:5, Funny)
GTK
No (Score:3)
That said, it's completely fine in moderation. The same goes for functional programming. Most programmers can wrap their heads around things like functions, closures / lambdas, streams and so on. But if you mean true functional programming then forget it.
As for the kernel's choice to use C, that really boils down to the fact that a kernel needs to be lower level than a typical user land application. It has to do its own memory allocation and other things that were beyond C++ at the time. STL would have been usable, so would new / delete, and exceptions & unwinding. And at that point why even bother? That doesn't mean C is wonderful or doesn't inflict its own pain and bugs on development. But at the time, it was the only sane choice.
abstractions (Score:5, Insightful)
Like so many other things, abstractions are a useful thing to use.
Except for the consulting trap. You see, when the only thing you understand about a domain is how to abstract its functions and split them into parts, then sooner or later it is abstract interfaces all the way down.
OOP has its place. I have many pieces of software that have genuine objects and thinking about the problem space in objects makes things a lot easier. I also enjoy writing functional software when the "do this, then that" path is the most useful way to think about the problem.
Where OOP is a total failure is when you abstract the abstraction of the interface with a factory that inherits a trait from the abstract class that describes the... I mean, I've digged through source code trying to find a bug where the first line of code that actually does anything was six layers deep.
Abstractions are nice, but when you need to add +1 to a variable, it is much more useful to write "a+=1;" than it is to define an abstract class that performs additions, write an interface class for it and a factory to set it up. Yes, even when you might want to perform some other addition somewhere else in your code in the future.
Bullshit (Score:3)
Why am I reading the musings of a developer with 9 years of very pedestrian experience?
Re:680,303 lines (Score:4, Insightful)
680,303 lines of Java code in the main project in my system.
Probably would've been more like 100,000 lines if you had used a language whose ecosystem doesn't goad people into writing so many superfluous layers of indirection, abstraction and boilerplate.
Re: (Score:3)
There's an enormous amount of embeded work that uses plain C and doesn't even have proper operating systems or threads, just an executiv loop. Quite frankly the cavalier ways of desktop and web app programming is of little interest to them.
Re: (Score:3)
Re:OOP allows for hack coders (Score:5, Informative)
Isn't that like complaining engineers don't spend enough time doing meaningful fundamental physics research?
No.
Most problems in the world are variations on ones that already have solutions, but requires someone to specialize and customize the solution
Things like concrete don't go obsolete or pass into a weird "unmaintained" state that doesn't work with newer shovels, etc.
Re: (Score:3)
I cannot understand why a programmer masturbates over the fact that s/he can code "the whole program"
Because front-end and back-end coding are different disciplines, with different areas of attention, often using different languages, dealing with very different end users. The design considerations, operating environments and support structures are all different It makes sense to split these into two different jobs...
... At least it does in today's world of hyperspecialisation. IT work has been compartimentalized to such a degree that some people are amazed if a programmer is able to code both the fron