jshowa1
I pointed out that just because the literature is original doesn't mean it can't be superseded. I gave generics as an example that was later implemented in OOP languages and fail to see how implementing these perverted the original intentions.
I was then told that OOP intentions were originally meant to be dynamically typed and that the static typing of generics was meant to put it towards the original intentions of this dynamic structure (this is untrue because Alan Kay just didn't like static typing, but didn't make dynamic typing a requirement for OOP). Upon further research, the earliest OOP concepts were explained in the 1960's and the first OO language (Simula) was statically typed and a superset of ALGOL 60 which was a language made in 1960, with Simula following in 1965. Smalltalk came in at 1972 (around the time of generics) and is considered the definitive OOP language which is dynamically typed.
So its hard to say, without direct sources, what the original intentions of OOP were, but considering OOP appeared before the first languages that contained generics (i.e. 1970's), generics is an idea that superseded OOP.
Considering the utility of generics, its clear that later concepts that were added to OOP did not somehow perverse the original literature.
So we've established the following: 1) The earliest OOP language (Simula) was statically typed. 2) Generics came in after Simula 3) The original intention of OOP could probably be attributed to Alan Kay, who created Smalltalk, but it borrowed heavily from Simula. And while Alan Kay coined the term OOP, the idea was not created in a vacuum as OOP concepts predate Smalltalk.
Hopefully this provides some clarification. But my guess is people will continue to misinterpret what I meant.
Again, you don't write the ORM classes, the framework does it for you.
And what you advocate is essentially sending a table over the network. So, what happens if your data within that map is complex? Are you suggesting to send every piece of a complex data type over the wire in separate chunks? If so, how do you relate it in the application? You still to make some sense of that JSON data in your application. Having it in a big map structure is akin to a god object.
I my mind all you're doing is masking objects in different concepts just because you don't like using classes.
When they were finally implemented in OOP, it superseded the original intentions of OOP.
The question is, are we now supposed to remove generics because they don't conform to the early literature of OOP?
Looks like the OOP edited his comment though, so my point is irrelevant.
> And if you want to use other people's objects (say from a library) you first have to make a layer that translates them from your own objects
Funny, I've been using .NET framework objects without any type of translation. And the point is to use inheritance to mitigate the translation.
Don't blame the model for its poor use. If there's no way to get the data you need, then that means the class was designed so you didn't actually need it or there are other ways to get it (i.e. through an interface).
>Clojure gets it right and that's what I use.
Except Clojure uses OOP principles and even admits to saying it uses immutable objects in the form of interfaces. Interfaces are essentially stripped down abstract classes. How this is not a subset of OOP, I don't know.
I'm sure Clojure is great, but can you write interactive applications with it without integrating OOP libraries?
In short, work is just like college group work. One person does 90% of the work while the others do about 10%.
No, but your general point was that classes aren't taught in a beneficial manner, when in fact they are and are often directly applicable to what you're doing. It may be abstracted away to the point where you think you aren't using them, but you very much are. And this illustrates the point of not needing to know the how and why something works and why its often less beneficial to do so because knowing more detail often leads to more confusion.
>While you're clearly proud of this fact, I'm not sure why that's relevant here?
It was simply an example of a direct application of something I learned in college and is thus evidence that what you learn is useful and applicable. I mentioned that it helped a senior engineer because learning such abstractions can make experience irrelevant. You were the one that seemed to bring pride into the picture.
> This is basically the exact opposite of my complaint. I was complaining that differential equation courses essentially focus on teaching a bag of tricks for solving specific types of equations.
So why even mention that things like differential equations are taught in a inadequate manner?
> the effort many students give to college is less than average
Yes, its quite possible that student effort does not follow a normal distribution. All I can say is, from my experience, it was high. Do I have data to back this up? Not rigorously, but given the numerous complaints about how college isn't teaching things right and that professors and universities aren't stupid, I'm just assuming its lack of effort, priority, or skill.
>But surely you must agree there is room for improvement, right?
Be careful with this line of thinking. You could say the same thing to assume improvement must be made in the way a course is taught, when its really another factor that's the cause of peoples complaints that isn't mentioned (i.e. effort, professor, lack of skill, etc.)
> Given that you made no attempt to substantiate your opinion - it seems to me that the logical thing to do here is to side with the majority.
You haven't done the same either. And the most logical thing is to abstain from siding with any position until more evidence is present. After all, the majority of people believe in a religion as taught from selected texts, of which such texts have numerous factually incorrect statements in them.
And of course my opinion is in the minority because nearly everybody under the sun complains about how useless college is and how things should be taught with more application without realizing that things are taught minus application for a reason (so that you can apply things generally instead of specifically) and that many of the hot technologies are just re-purposed PhD research.
Also, the effort many students give to college is less than average (at least from personal experience going through a private engineering school) and probably for most college students. So their complaints are really just the result of laziness and lack of responsibility more than anything.
A minority opinion does not make it invalid or worth less, unless you have evidence to discredit it.
Basically the equivalent of, if the course makes you feel good, then the course is good. Not something that I'd advocate.
By the way, a differential equation is simply an equation with a derivative in it. If you can't recognize that, then you didn't go far enough in math.
The code is almost never trivial either. It often involves integrating complex systems and making sure that they work which, if done right, involves writing several unit tests.
Using God is a poor excuse to determine ethics because there's no evidence one exists. It's especially a problem when you don't share the code because then, instead of creating improvement to the job for the company as a whole, you've written a pass to be lazy. The real job comes from supporting whatever you write to the masses. If you don't have any interest in that, you're simply selfish.
The problem is people react in different ways, but it seems like the most common way is to not tell anyone which in my mind is foolish because even if you do get fired, you've improved your skills enough to find a better job anyway. Not only that, I can just as easily come up with an example of someone getting promoted for automating job tasks.