Or they could make Mir depend on Unity.
Printable View
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.
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.
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.
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.
If OOP is not always "the best thing to go with", then it is obviously not a foundation for programming, right?
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.
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.
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.
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.
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...
Indeed I am thinking about the forest, or at least trying; I want to know what are the foundations to programming.
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.
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.
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.
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.
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.
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).
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.
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 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.
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.
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.
Logic yes, math no
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:
What happens if we remove the nouns?Code:Sally went to the store and picked up a bunch of bright red apples.
you see how that means nothing? on the other paw if we have just the nouns:Code:went to the and picked up a bunch of bright red.
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)Code:Sally store apples
Well it's clear what happened, it's not pretty but okay lets add in some prepositionsCode:Sally goto store, Sally pickup apples
okay and to finally bring us full circle lets add in some adjectives (properties), linking words, and quantifiers:Code:Sally went to the store, Sally picked up apples.
Do you see how that builds up and works now?Code:Sally went to the store and picked up a bunch of bright red apples.
I didn't know math was a religion now. Should I be praying to the almighty equals sign?
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.
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.
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.
Well Algebra is the part of logic languages where they all become more or less the same. So yes and no..
See classes, polymorphism and inheritance
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.