Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Object Oriented Programming

Name: Anonymous 2010-09-21 13:22

As a novice programmer and as someone who started learning programming with C, OOP just seems annoying to me. Seems as though it's easier to accomplish the same tasks without it. Is it actually necessary to learn it?

Name: Anonymous 2010-09-21 13:24

Yes

Name: Anonymous 2010-09-21 13:25

>>1
Only if you aren't interested in getting a job as a programmer.  Can you even find a job these days that has an explicit requirement of "non-OOP?"

Name: Anonymous 2010-09-21 13:28

>>3
I'm in engineering actually, so it's likely that I will be doing some programming though probably not as much as a 'real' programmer.

Name: Anonymous 2010-09-21 13:29

>>3
U MENA NO EXPLICIT REQUIREMENT FOR OOP?

Name: Anonymous 2010-09-21 13:30

>>3
Systems programming. There is NO requirement for OOP as it's all done in C.

Name: Anonymous 2010-09-21 13:35

>>5
I've seen jobs with explicit OOP with "[so many] years of experience."  What kind of requirement is that?  These days it's hard to come across a desire for languages that can't even simulate OOP.

Name: Anonymous 2010-09-21 13:44

>>7
Luckily, with enough boilerplate, even assembly can simulate objects.

Name: VIPPER 2010-09-21 14:20

What the fuck is an object? Is that some kind of struct with functions, that operate one the struct itself?

Name: Anonymous 2010-09-21 14:23

>>9
Seriously? No wonder all you say is 66JEWS]99.

Name: Anonymous 2010-09-21 14:43

>>10
Seriously?

Yes, YMCHNBT.

Name: Anonymous 2010-09-21 15:18

>>1
Forget about learning OOP.  Nearly all of learning will be memoizing buzzwords associated with simple ideas.  Just take a couple of PLs with support for both ``kinds'' of OOP (e. g. C++ and Smalltalk), if you find out how two of this work, as a systems programmer you'll learn pretty much everything there is to learn about implementation).

>>4
There isn't much use for objects in engineering.  No language/system for modeling, number crunching or FPGA that I can think of and that is actually used requires objects.

Name: Anonymous 2010-09-21 16:05

I can't tell if >>1 is a troll, but it's not a ridiculous question to ask whether OOP is valuable or not.

If you're competent in C, your code naturally becomes more "table based."  Big switch statements get replaced by function tables.  Your data structures tend to fall into arrays-of-structs or structs-of-arrays.  You separate related code into libraries and document well.  And once you become comfortable with a style like this, OOP doesn't really offer you much.

Name: Anonymous 2010-09-21 16:20

>>13
One could argue that you are doing "OOP", just on a module level.

As for >>1,
Is it actually necessary to learn it?
As with everything, that is up to you, but this sounds like a plea to justify your laziness. It is always better to try it out and get your own informed opinion, than to remain an ignorant parrot.

Name: Anonymous 2010-09-21 16:33

arrays-of-structs or structs-of-arrays
Learn about processor caches you incompetent person. It's either structs of arrays, or too fucking slow to be worth writing it in C. Arrays-of-structs almost guarantee that every next struct will be a cache miss.

Name: Anonymous 2010-09-21 16:34

>>14
One could argue that you are doing "OOP", just on a module level.
Yes, except that you own it.  You control how it's organized, instead of some standards organization.  Plus, you don't get all the unwanted baggage templates anyone? that someone thought would be useful but isn't.

Name: Anonymous 2010-09-21 17:03

>>12
ust take a couple of PLs with support for both ``kinds'' of OOP (e. g. C++ and Smalltalk)
What, the broken kind and the actual kind? If you want to learn OOP, you should know about Smalltalk style and CLOS style. Factor comes with some good examples of the latter. But don't get mixed up with C++ until you understand OO. The system there is pretty WTF and includes features (the whole public/private/protected system) that are really only relevant when you're working with morons or are a moron.

Don't inherit too much.

Name: Anonymous 2010-09-21 17:08

>>17
features (the whole public/private/protected system) that are really only relevant when you're working with morons
So, so true.  So many sepplers don't get this.  They seem to think that public/private is a substitute for documentation.

Name: Anonymous 2010-09-21 17:48

>>18
public/private is good for automated documentation systems.  Users of your classes don't want to browse a fuckton of internal circuitry, they want a clean API so they can get shit done instead of looking through stuff they don't need for ages.  Good, competent users who demand that complexity and side effects be documented.
I don't see a lot of objections to internal functions in modules like non-exported stuff in Haskell.  Even Perl has export lists.  Private methods are like that, only for classes.
It doesn't make a lot sense for classes like Point, Circle, HelloWorld though, that's why it keeps being brought up.  It does have a use in real world.

Name: Anonymous 2010-09-22 14:56

>>19
Automated documentation isn't good.

Name: Anonymous 2010-09-22 15:01

>>20
Documentation isn't good. Real men don't need it. Never.

Name: Anonymous 2010-09-22 15:04

>>20
...for class HelloWorld

Name: Anonymous 2010-09-22 15:12

>>21
True, but Real Men would still be making do with rocks and sticks for weaponry, and the abacus skills would be their computer science.

Name: Anonymous 2010-09-22 15:32

protip: object oriented programming doesn't necessarily have anything to do with classes

Name: Anonymous 2010-09-22 16:16

>>24
Tell us how prototype-based programming is the real true OOP.

Name: Anonymous 2010-09-22 16:28

>>25
why would i tell you that?

Name: Anonymous 2010-09-22 23:59

>>25
I prefer protos myself.

Name: Anonymous 2010-09-23 0:22

>>27
Enjoy not being able to proxy cannon anymore.

Name: Anonymous 2010-09-23 1:14

>>28
I will, along with my job.

Name: Anonymous 2010-09-23 4:08

>>1

It's convenient, esp. if you want to get paid. And yes, it's annoying if your language sucks (C++, Java). It's not quite so if you get a decent language with decent abstraction capabilities that don't involve enterprise mess and design patterns/copypasta.

>>6

Then again, C is about as big a pain in the ass as OOP.

>>9

Basically, yes. Some kind of struct, some of its members being functions, and these functions being bound to (or sometimes explicitly passed) an object which is itself. Basically, if obj is an object of class cls, obj.function(x) would be the equivalent of cls:function(obj, x).

>>14

Listen to this man

>>16

Ever heard of abstraction?

>>17

posts truth like the fist of an angry god hits the face of the Earth. Listen especially to this guy.

>>24

True.

>>25

Less kinds of animals; more generic and powerful objects.

>>28

Yes but I can barrel roll.

Name: Anonymous 2010-09-23 6:13

>>16
I do not understand why people like you say templates are unwanted baggage.

Do you seriously think generic parametric polymorphism is a bad thing? Have you completely ignored the past 30 years of language development? Or do you just not fucking want to understand how templates work?

Of all the ridiculous features in C++, templates are just about the only useful one.

Name: Anonymous 2010-09-23 10:58

>>31
Maybe they're annoyed at the fact templates bite in C++ because C++ sucks, but would enjoy decent OOP if given a decent language.

Name: Anonymous 2010-09-23 11:12

OOP is a design method for your software. If your specs result in a system that's easily divided into "objects", then you would ideally use an OOP design for the system. Programming in OOP should be as simple as programming in any other design method: your implementation should always follow the designated system models and specs.

I would bet that anybody here that complains about OOP (or C++ for that matter) are the sort of lone cowboy programmers that don't even do tangible system models (on a piece of e/paper that's ready to be file) let alone actually code according to a system model.

Name: Anonymous 2010-09-23 11:58

>>30
kinds of animals
FFFFUUU–

Why does everyone pick the worst examples on Earth to illustrate OOP, anyway? In TC++PL, Bjarne uses employees and their subclass "manager" to demonstrate inheritance. Yeah, let's just spend a chapter modeling something no one in their right mind would actually do. It's no wonder OO confuses people, when this is how it's taught.

Name: Anonymous 2010-09-23 12:46

>>34

I see where you are coming, but you are not coming from my post as I intended it. By "less kinds of animals" I meant less language axioms/concepts/core objects/element types. A class-based object system requires objects, and then it requires classes, or a special type of object which is a class and which you may make instance of while this doesn't hold true for other objects. On the other side, a prototype-based object system requires little speciality, and is thus cleaner, simpler and more flexible. That's what I meant; not some convoluted example of OOP.

Name: Anonymous 2010-09-23 12:58

>>34
The examples are contrived to avoid distracting complexity. Real-world object use is always partly to hide some greater complexity, so to give and explain a genuine example would involve presenting a volume of incidental junk that just gets in the way. Try coming up with your own example and you'll see what I mean. (Or: prove me wrong--that would be cool.)

Name: Anonymous 2010-09-23 13:14

>>36

class Fart:
    - smell (1 to 10)
    - noise (average, in dB)
    - function Rip(seconds)

class WetFart subclasses Fart:
    - shit (in grams)

Name: Anonymous 2010-09-23 14:05

>>35
I thought you were advocating for fewer animal examples.

>>36
If a little more complexity is what it takes to show a good use of OOP instead of a real world structure that you would never, under any circumstances, want to encode, I think that's fine. If we really want to use animals, for example, we could use an example somewhat like this:
(defclass aminal ()
  (number-of-legs
   brain
   has-claws
   ...))

(defclass brain ()
  (vision-center
   hearing-center
   ...))

(defclass human-brain (brain)
  (language-center
   ...))

It's not necessarily perfect, but (in addition to showing composition as a bonus) it does illustrate a somewhat viable use of inheritance, since brains differ in ways potentially relevant to the operation of the program, and share a certain number of slots (justifying the superclass).

Name: Anonymous 2010-09-23 14:21

>>38
It looks like Dwarf Fortress creature gen code.

Name: Anonymous 2010-09-23 14:38

>>38
And yet your code is never used. In that sense it's worse than the average example.

Usually you want to mess with an object or class because you got it from somewhere else. This is where the examples tend to break down, they take the view that you're writing the object, and taking the long way around to get functionality you could have added in the first place. Personally I'd start with subclassing and work backwards (and forwards) from there. In fundamentally OO-languages that's about all you can do and the concept doesn't take a lot of time to master.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List