Ubuntu's Unity Written In Qt/QML For "Unity Next"

[dee.]

Well, Unity is a Ubuntu thing, and Mir is a Ubuntu thing.
So Ubuntu could easily make Unity depend on Mir and not care.

Or they could make Mir depend on Unity.

[uid313]

Or they could make Mir depend on Unity.

Indeed.

So my question is if Mir or Unity depends on each other?
I hope not.

While I am no fan of Unity, I hope it can still run on Wayland and X11 in the future.

[Luke_Wolf]

you either didn't understood what i was saying or i expressed myself wrong.

i know very well what modular means. might i suggest rereading my post?

your paragraph seemed to be going on about direct access, and saying that making stuff private or protected is cutting down on modularity, which is quite simply not the case. Direct access is actually arguably a bane of modularity simply for the fact that it allows you to rely upon an implementation as opposed to an interface, and on that point having the capability to define said interfaces, and in fact the entire reason you're declaring things should not be simply to stop bad usage, in fact to be doing it with that purpose indicates that the person writing the program is doing things wrong from an OOP perspective.

The entire point of access levels is to be able to define interfaces such that you've got a public interface how people interact with your objects, your protected interface of things that are useful to people deriving from your class that don't/shouldn't for most cases need to be changed, and then you've got your private interface/implementation that with the protected interface form the implementation of how it works.

Let me put this another way for you a class is like a miniature program it takes switches (member functions) and parameters (properties) and then it does stuff with those switches and parameters and gives you a result. With ls or grep or whatever you don't really care about how it's implemented, all you really care about is the results, same idea with a class, and so separation of the interface (public) from the implementation (protected, private) is very important to good OOP design, and again helps to increase modularity since you're relying upon an interface as opposed to an implementation. It's like relying upon the HTML standard as opposed to how IE does things.

And again yes people can get it wrong, but people can also crash cars, that doesn't mean either cars or OOP is bad. It simply means that the person writing the code or driving that car was bad. Just because Java is a shitty implementation of an OOP language doesn't mean that all OOP language implementations are bad or that the idea is innately wrong. Just because Java developers don't understand OOP and think that having those features means that they can be control freaks to limit "bad use" doesn't mean that the rest of us are like that, and in fact we're for the most part going "WTF Java? Being a megalomanical control freak is not how OOP works" and are instead simply using it for interface->implementation separation.

[Luke_Wolf]

Fuck Carnegie Mellon. All these academics who couldn't write code for shit. Seriously if they are any good why don't they build a company and make some serious money if they are so hotshot programmers. But wait. No. They are computer science. Not engineers. Bunch of fucking losers wannabes. They say OOP is bad cause they know all the money is in OOP. Everybody writes OOP these days so they have to be different to feel superior. OOP is anti modular? Who the fuck are these people? How do they even have the right to teach others programming?

Well just because some CompSci people are academics doesn't mean we all are. Essentially what is going on here is one of many language wars, just the functional vs OOP war is very one-sided. Because ultimately it's a war between Academics who failed to understand programming is not math, and people who understand that it's language but don't care about that group of academics beyond refuting their FUD and misunderstandings. Again there are legitimate pitfalls with OOP mostly related to complexity (arguments related to how a programmer chooses to work are of course invalid though) required to set up an OOP program on things that would otherwise be relatively trivial.

Now if I wanted to I could be ragging on how "functional" languages aren't, and about how functional languages create (almost) unreadable code but I don't really care enough to spend my time arguing those points as opposed to killing FUD and misunderstandings about OOP and programming.

[Sergio]

Well, see I disagree with that assessment because as much as programming has to do with math, programming isn't math. Programming is in truth about language and expressing and executing ideas. This is again not to say that it doesn't sometimes require a serious amount of math, but it in and of itself is not. At it's fundamental level you're giving directives to the computer in order to make it do something. This requires a means of doing so that is easy for people writing code to understand and that is easy for the computer to translate into something it can understand.

Well, actually I think it is suitable to think about programming as 'doing math'. When you express a computation, being through the modification of states as in Turing Machines, or more abstractly as in Lambda Calculus, it is all mathematics. This would mean that programming, fundamentally, is mathematics. Now, it is clear that in practice this is far from being the case, but that does not modify the very nature of programming.
Also, syntax and semantics are formalized in mathematical logic; this is essential to programming languages.

I would personally argue that OOP is for the most part the natural in terms of how this intermediate language shakes out, because here's the thing let's take an example sentence:

fundamentally this breaks down into two noun verb noun s where an object is acting upon another object in short

and of course these apple objects have the property of being bright red, even Databases are actually taught in an object oriented fashion... guess what normalization is? It's actually the process of breaking down tables of data into objects. In fact all of our data languages such as XML are object oriented, because you've got say a paragraph object with properties such as font being a certain type and size, as well as color, and data languages really can't not be object oriented.

Perhaps the foundations of programming and OOP are not mutually exclusive; it could be possible to have OOP on top of a firm mathematical foundation for programming. Indeed formalizations for programming exist, it is just that in practice they are seldom used.

Now implementation wise sometimes it's not the best thing to go with, however from a conceptual standpoint OOP is the "best" approach, because it most closely matches how our non-programming languages such as english are designed.

If OOP is not always "the best thing to go with", then it is obviously not a foundation for programming, right?

EDIT: Math is actually arguably another language with a different though similar target as programming languages. In short expressing calculations, as opposed to being designed to express ideas to a computer. Which then Math can be used as another language underneath a programming language since little further translation is needed for a computer to understand it

Mathematics may not be used directly to talk to the computer. Instead, mathematics can be used to abstract essential things in programming. For example, using algebra to reason about programs.

[Luke_Wolf]

Well, actually I think it is suitable to think about programming as 'doing math'. When you express a computation, being through the modification of states as in Turing Machines, or more abstractly as in Lambda Calculus, it is all mathematics. This would mean that programming, fundamentally, is mathematics. Now, it is clear that in practice this is far from being the case, but that does not modify the very nature of programming.
Also, syntax and semantics are formalized in mathematical logic; this is essential to programming languages.

Quit thinking about the underlying implementation of how the language works, Think about the forest not the trees. Now what are you doing when you program? Well you're talking to a computer and telling it what you want it to do. Now what are you doing when you are doing math? You're expressing and solving calculations. See the difference? As part of programming you can express to the computer that you want to do a calculation in which case you write in a derivative of math depending upon the limitations of the programming language itself.

Perhaps the foundations of programming and OOP are not mutually exclusive; it could be possible to have OOP on top of a firm mathematical foundation for programming. Indeed formalizations for programming exist, it is just that in practice they are seldom used.

Trying to force math on another language is just plain silly when the goals of programming languages are different and far greater in scope than the goals of math.

If OOP is not always "the best thing to go with", then it is obviously not a foundation for programming, right?

Wrong, because think about how language works, the foundation of english and other languages is that we've got Nouns verbing other nouns, or even verbing themselves. However just because that's how the foundation of English and other languages are, doesn't mean that creating lists of things isn't useful in communications. Also arguably one could say that in a shell script you are having nouns verb nouns with the scripting telling a program object to run with certain parameters, essentially a script could be argued to be equivalent to a main function and not being able to write classes and such, only dealing with what's there. So fundamentally even the example I use to show as antagonistic is in fact based on OOP, just you don't write it in a traditional OOP fashion, you understand what I'm getting at?

The main issue with going with OOP again in normal non-scripting cases essentially has to do with increasing the order of complexity. It doesn't mean going the OOP way is not the best way of going about it if you want the best design, but that it takes something trivial and makes it more complex for the purposes of being better engineered and more extensible in the long run.

Mathematics may not be used directly to talk to the computer. Instead, mathematics can be used to abstract essential things in programming. For example, using algebra to reason about programs.

Where functions and algebra come into play is where math and programming start having crossover however just because there's crossover doesn't mean they're the same thing.

EDIT:
Even math can be argued as being largely if not completely object oriented because you've got number objects verbing through addition, subtraction, etc other number objects, and you've got an equation object that contains number and operator objects capable of taking derivatives of itself and so on...

[Sergio]

Quit thinking about the underlying implementation of how the language works, Think about the forest not the trees.

Indeed I am thinking about the forest, or at least trying; I want to know what are the foundations to programming.

Now what are you doing when you program? Well you're talking to a computer and telling it what you want it to do. Now what are you doing when you are doing math? You're expressing and solving calculations. See the difference? As part of programming you can express to the computer that you want to do a calculation in which case you write in a derivative of math depending upon the limitations of the programming language itself.

This is just plain wrong. It is not true that "...what are you doing when you are doing math? You're expressing and solving calculations". Expressing and solving calculations is not what you do when you 'do math'; then computers would be capable of doing math and, particularly, they would be capable of proving that certain problem is undecidable. Of course you can't expect the computer to prove the undecidability of a problem; it would just 'do its best'. A mathematician, of course, is aware of the nature of the problem and 'that's it'; he does mathematics. This is what I mean with 'to do math'.

Just to make my point, I'll quote the preface of the book "Elements of Programming", from Alexander Stepanov. Note that I'm not claiming that he is right; I just want to express my idea through an authority in the field:

"Elements of Programming provides a different understanding of programming than is presented elsewhere. Its major premise is that practical programming, like other areas of science and engineering,must be based on a solid mathematical foundation. The book shows that algorithms implemented in a real programming language, such as C++, can operate in the most general mathematical setting. For example, the fast exponentiation algorithm is defined to work with any associative operation. Using abstract algorithms leads to efficient, reliable, secure, and economical software.The book’s value is more fundamental and, ultimately, more critical for insight into programming. To benefit fully, you will need to work through it from beginning to end, reading the code, proving the lemmas, and doing the exercises. When finished, you will see how the application of the deductive method to your programs assures that your system’s software components will work together and behave as they must."

An engineer from Adobe, who took Stepanov's course, states: “Ask a mechanical, structural, or electrical engineer how far they would get without a heavy reliance on a firm mathematical foundation, and they will tell you, ‘not far.’ Yet so-called software engineers often practice their art with little or no idea of the mathematical underpinnings of what they are doing. And then we wonder why software is notorious for being delivered late and full of bugs, while other engineers routinely deliver finished bridges, automobiles, electrical appliances, etc., on time and with only minor defects. This book sets out to redress this imbalance. Members of my advanced development team at Adobe who took the course based on the same material all benefited greatly from the time invested. It may appear as a highly technical text intended only for computer scientists, but it should be required reading for all practicing software engineers.”

What I see very clear is that, at the very least, the foundational roll of OOP is debatable.

[Luke_Wolf]

Indeed I am thinking about the forest, or at least trying; I want to know what are the foundations to programming.

The foundation is language and linguisitics which is the entire point that OOP gets at. It's an examination of how language actually works and the realization that in all languages including math are inherently based upon objects. The difference is that Logic Languages like math or any programming language operate rather differently than traditional spoken languages as Logic Languages are inherently certain whereas a spoken language by nature must have uncertainty.

This is just plain wrong. It is not true that "...what are you doing when you are doing math? You're expressing and solving calculations". Expressing and solving calculations is not what you do when you 'do math'; then computers would be capable of doing math and, particularly, they would be capable of proving that certain problem is undecidable. Of course you can't expect the computer to prove the undecidability of a problem; it would just 'do its best'. A mathematician, of course, is aware of the nature of the problem and 'that's it'; he does mathematics. This is what I mean with 'to do math'.

Your statement here doesn't make much sense, and in no way disproves my point. To do math you must first express a calculation that is to be done in the language of math, let's just say for simplicities sake: 9 = x+5. We are then using the rules of the language of mathematics in order to solve it eventually culminating in: x=4. That's it, and nothing more. Even proofs are simply expressions and usage of language rules. Now you can use a logic language, such as math or a programming language to model a situation but to do so you naturally become more object oriented, because then you're modeling objects and how they work and interact with things.

Just to make my point, I'll quote the preface of the book "Elements of Programming", from Alexander Stepanov. Note that I'm not claiming that he is right; I just want to express my idea through an authority in the field:

"Elements of Programming provides a different understanding of programming than is presented elsewhere. Its major premise is that practical programming, like other areas of science and engineering,must be based on a solid mathematical foundation. The book shows that algorithms implemented in a real programming language, such as C++, can operate in the most general mathematical setting. For example, the fast exponentiation algorithm is defined to work with any associative operation. Using abstract algorithms leads to efficient, reliable, secure, and economical software.The book’s value is more fundamental and, ultimately, more critical for insight into programming. To benefit fully, you will need to work through it from beginning to end, reading the code, proving the lemmas, and doing the exercises. When finished, you will see how the application of the deductive method to your programs assures that your system’s software components will work together and behave as they must."

An engineer from Adobe, who took Stepanov's course, states: “Ask a mechanical, structural, or electrical engineer how far they would get without a heavy reliance on a firm mathematical foundation, and they will tell you, ‘not far.’ Yet so-called software engineers often practice their art with little or no idea of the mathematical underpinnings of what they are doing. And then we wonder why software is notorious for being delivered late and full of bugs, while other engineers routinely deliver finished bridges, automobiles, electrical appliances, etc., on time and with only minor defects. This book sets out to redress this imbalance. Members of my advanced development team at Adobe who took the course based on the same material all benefited greatly from the time invested. It may appear as a highly technical text intended only for computer scientists, but it should be required reading for all practicing software engineers.”

What I see very clear is that, at the very least, the foundational roll of OOP is debatable.

The problem is this guy has the misunderstandings of an academic. Yes there is value to having a strong mathematical underpinning in your education and it can in theory improve your code quality, however the actual issue there is boiling down to how accurately are you designing your model? This is where object oriented programing and math come in. They're not just saying "Okay X=Y+z+r*sqrt(54)" no they're saying things like "Force = Mass * Acceleration" and we've got three objects there being modeled: Mass, Force, and Acceleration, and those aren't just numbers each one of those is a model unto itself.

To be blunt here we are in a world of objects with properties and methods of interaction. Our Languages and thus communications in general rely upon objects, our math relies upon objects, even mental constructs are objects.

This is fundamentally the point of OOP and why it's the foundation of programming, and why ALL languages are fundamentally object based...

The other thing is the Adobe's guy point is just bad. What a Software Engineer is doing is more or less what engineers involved with R&D are doing. The thing about bridges is this most of the fundamental work is already done for you, somebody has done it before and so there's a known way for it to be done. Remember that the first of the modern bridges broke due to resonance. Today's engineers doing that are essentially in the position of a Software Engineer who is maintaining code, which yeah it's a lot of hard work and takes quite a bit of skill and time to understand it all but fundamentally speaking they're not really doing anything new, unless they're doing R&D on new types of bridges. Writing new complex programs on the other hand takes a lot of work and design to get right, and just like those R&D engineers, things don't always work the first time or the second, or even the 10th time, but eventually things get to the point where the program moves out of R&D and into more typical engineering.

[Sergio]

The foundation is language and linguisitics which is the entire point that OOP gets at. It's an examination of how language actually works and the realization that in all languages including math are inherently based upon objects. The difference is that Logic Languages like math or any programming language operate rather differently than traditional spoken languages as Logic Languages are inherently certain whereas a spoken language by nature must have uncertainty.

No... This is not the case. Let's suppose that its foundation is indeed "language and linguistics" and that these languages indeed are not natural languages; they are formal languages. You seem to ignore completely the field of mathematics known as mathematical logic (no, it is not a generic name for using mathematical reasoning; it is a field on its own). This field dictates every foundational aspect about formal languages. Have you heard about Gödel's Incompleteness Theorem? It is actually the mathematical reasoning behind undecidable problems, and this is pretty much the core of algorithms. Mathematical logic also establishes en equivalence between syntax and semantics. Stop treating mathematics as a language. It is not; it is much more than that.
So, if language is at the core of programming, and mathematics establishes the foundations of languages, then obviously mathematics is at the core programming.

Your statement here doesn't make much sense, and in no way disproves my point. To do math you must first express a calculation that is to be done in the language of math, let's just say for simplicities sake: 9 = x+5. We are then using the rules of the language of mathematics in order to solve it eventually culminating in: x=4. That's it, and nothing more. Even proofs are simply expressions and usage of language rules. Now you can use a logic language, such as math or a programming language to model a situation but to do so you naturally become more object oriented, because then you're modeling objects and how they work and interact with things.

It is clear that you don't know what mathematics is really about (don't take this bad). Mathematics is not a language; mathematics can be used to formalize languages, like propositional calculus, or first-order calculus, but to equate mathematics to a language is to take away its soul.
I agree that there exists a foundational aspect about thinking in terms of objects. But, as Stepanov says, saying that everything is and object is saying nothing at all; how do these objects relate? what structure governs them? This is what mathematics does best, and algebra in particular can be used to reason about programs, as is done in Stepanov's book.
By the way, some mathematical proofs are divine, and saying that "Even proofs are simply expressions and usage of language rules" is having no clue about the nature of mathematics (again, don't take this the wrong way).

The problem is this guy has the misunderstandings of an academic. Yes there is value to having a strong mathematical underpinning in your education and it can in theory improve your code quality, however the actual issue there is boiling down to how accurately are you designing your model? This is where object oriented programing and math come in. They're not just saying "Okay X=Y+z+r*sqrt(54)" no they're saying things like "Force = Mass * Acceleration" and we've got three objects there being modeled: Mass, Force, and Acceleration, and those aren't just numbers each one of those is a model unto itself.

So academics, the ones that do research and devote their lifes to really understanding suffer from misunderstandings? What about the other way around? isn't more possible than an empirical practitioner suffer from this?
What he is suggesting is not that mathematics is a mere technique to help improve code (as can be though of OOP); he says that mathematics is the foundation of programming.

To be blunt here we are in a world of objects with properties and methods of interaction. Our Languages and thus communications in general rely upon objects, our math relies upon objects, even mental constructs are objects.

I do agree about this one, only that more important than "methods of interaction" is how the relate to each other. This gives the whole idea a structure, which is pretty much what algebra does through groups, rings, etc.
I do think that you have a point when suggesting the object nature of our world but, again, to say that everything is an object hardly gives structure to programming (structure as studied in algebra). I am convinced that algebra is fundamental to programming, and that it dictates its nature.

This is fundamentally the point of OOP and why it's the foundation of programming, and why ALL languages are fundamentally object based...

This is not true. Formal languages consists of not only 'things' and what those 'things' can do; structure is a fundamental part of them, and structure is about relations. If you study first-order calculus, and pretty much every mathematical theory, you'd see this.

The other thing is the Adobe's guy point is just bad. What a Software Engineer is doing is more or less what engineers involved with R&D are doing. The thing about bridges is this most of the fundamental work is already done for you, somebody has done it before and so there's a known way for it to be done. Remember that the first of the modern bridges broke due to resonance. Today's engineers doing that are essentially in the position of a Software Engineer who is maintaining code, which yeah it's a lot of hard work and takes quite a bit of skill and time to understand it all but fundamentally speaking they're not really doing anything new, unless they're doing R&D on new types of bridges. Writing new complex programs on the other hand takes a lot of work and design to get right, and just like those R&D engineers, things don't always work the first time or the second, or even the 10th time, but eventually things get to the point where the program moves out of R&D and into more typical engineering.

What about structures that haven't been realized before? For example (just putting something random), a trasatlantic bridge or something like that?
This is analogous with the engineering happening when sending men to space: Do you think OOP is fundamental on these projects? Because this programs must not break, they use mathematics. If buildings were implemented like commercial computer programs, they'd all fall the same day.

[Luke_Wolf]

No... This is not the case. Let's suppose that its foundation is indeed "language and linguistics" and that these languages indeed are not natural languages; they are formal languages. You seem to ignore completely the field of mathematics known as mathematical logic (no, it is not a generic name for using mathematical reasoning; it is a field on its own). This field dictates every foundational aspect about formal languages. Have you heard about Gödel's Incompleteness Theorem? It is actually the mathematical reasoning behind undecidable problems, and this is pretty much the core of algorithms. Mathematical logic also establishes en equivalence between syntax and semantics. Stop treating mathematics as a language. It is not; it is much more than that.

Do note that I said Logic Languages not Formal Languages, and yes Mathematics IS a language. A language at it's fundamental basis is a model for conveying information, in math's case what it is conveying is calculations, and there were many different languages of math before we came to it's modern incarnation. We eventually settled on that of india's because the concept of having a null was a breakthrough that made things much easier and better than having to deal with the roman numeral system or otherwise. The particular dialect of base 10 is nice for people as it fits well with their fingers but the dialects of bases 8 and 16 are of course useful in our line of work. Maybe someday someone will come up with a better language but who knows?

But the fact that both math and all programming languages are logic languages means that they can of course express logic (remember what I said about certainty?), and as a result both fundamentally operate in a similar method and can use the same algorithms, in fact within limitations you can design things the same. However they are not the same.

So, if language is at the core of programming, and mathematics establishes the foundations of languages, then obviously mathematics is at the core programming.

Logic yes, math no

It is clear that you don't know what mathematics is really about (don't take this bad). Mathematics is not a language; mathematics can be used to formalize languages, like propositional calculus, or first-order calculus, but to equate mathematics to a language is to take away its soul.
I agree that there exists a foundational aspect about thinking in terms of objects. But, as Stepanov says, saying that everything is and object is saying nothing at all; how do these objects relate? what structure governs them? This is what mathematics does best, and algebra in particular can be used to reason about programs, as is done in Stepanov's book.

I've taken calculus thank you. Also whining about taking away it's soul is like a writer whining about saying that saying the English he's writing in is language is taking away the soul of his work...

and what Stepanov is saying amounts to hand waving there, essentially he's saying nothing at all. However Saying everything is an object sets up a fundamental understanding of the universe if you will, it sets up a basis from which you can then begin to examine the interactions and properties of these objects.. The relations if you will, and from there you can continue to build up.

Here's the thing Language requires nouns, be it math, be it english, be it C++ or some other programming language, it all requires nouns to work, and you build up with verbs, prepositions, pronouns and other constructs from there. Let's think about that sentence I brought up earlier:

Sally went to the store and picked up a bunch of bright red apples.

What happens if we remove the nouns?

went to the and picked up a bunch of bright red.

you see how that means nothing? on the other paw if we have just the nouns:

Sally store apples

you have these nouns and you know they're somehow related but you don't know what the relations are and then you add in verbs (functions in programming)

Sally goto store,  Sally pickup apples

Well it's clear what happened, it's not pretty but okay lets add in some prepositions

Sally went to the store, Sally picked up apples.

okay and to finally bring us full circle lets add in some adjectives (properties), linking words, and quantifiers:

Sally went to the store and picked up a bunch of bright red apples.

Do you see how that builds up and works now?

By the way, some mathematical proofs are divine, and saying that "Even proofs are simply expressions and usage of language rules" is having no clue about the nature of mathematics (again, don't take this the wrong way).

I didn't know math was a religion now. Should I be praying to the almighty equals sign?

So academics, the ones that do research and devote their lifes to really understanding suffer from misunderstandings? What about the other way around? isn't more possible than an empirical practitioner suffer from this?

Absolutely, because you've got it backwards. An emperical practitioner is the one who is really doing the research and spending time having to understand it because they have to use it. All an Academic does for the large part is write grant applications and it helps for them to not actually come to real conclusions because then that can invalidate renewing grants. As well they're spending inordinate amounts of time playing around with institutional politics and other such bullshit while the empirical practitioner is spending his time actually working with the damn thing. That may at first sound overly cynical but if you've actually been around major universities you know I'm right.

What he is suggesting is not that mathematics is a mere technique to help improve code (as can be though of OOP); he says that mathematics is the foundation of programming.

And I say that's short sighted and a misunderstanding as linguistics is the foundation for both math and programming, and OOP isn't a mere technique, it's a recognition of what language is and applying it.

I do agree about this one, only that more important than "methods of interaction" is how the relate to each other. This gives the whole idea a structure, which is pretty much what algebra does through groups, rings, etc.

Have you heard about this cool part of OOP, I think it's called classes, Polymorphism, and inheritance, you just might want to look them up.

I do think that you have a point when suggesting the object nature of our world but, again, to say that everything is an object hardly gives structure to programming (structure as studied in algebra). I am convinced that algebra is fundamental to programming, and that it dictates its nature.

Well Algebra is the part of logic languages where they all become more or less the same. So yes and no..

This is not true. Formal languages consists of not only 'things' and what those 'things' can do; structure is a fundamental part of them, and structure is about relations. If you study first-order calculus, and pretty much every mathematical theory, you'd see this.

See classes, polymorphism and inheritance

What about structures that haven't been realized before? For example (just putting something random), a trasatlantic bridge or something like that?
This is analogous with the engineering happening when sending men to space: Do you think OOP is fundamental on these projects? Because this programs must not break, they use mathematics. If buildings were implemented like commercial computer programs, they'd all fall the same day.

Again note the bridge I pointed out here's a video of it https://www.youtube.com/watch?v=j-zczJXSxnw , Also sending men into space is a very bad example for this. You do realize just how much trial and effort was put into sending men into space and just how many times those trials failed to launch? Here's a hint, they failed a lot of times, which is why it took so long before they were comfortable moving from just getting rockets to work to putting men in them. Even today we're still having issues which is why the Constellation program flopped... HARD.

Also in complex programs OOP makes it far less likely for a program to break because it's application of the UNIX philosophy towards programs, because what you're doing is you're encapsulating and breaking up your big program into a bunch of tiny little programs which are reusing and thus testing your code in as many ways as possibly, also this is where unit testing as a part of OOP development comes in.