Neeum Zawan wrote:

>     Try lying in front of the house when the bulldozers come. And if you 
> see someone coming along hugging a towel, become friends with him. 
> Otherwise your life will be in danger.
> 
>     And not because of the bulldozers.
> 
I'm not at all clear what this means. Submit to the destructors (or to 
your fate)?
Do you mean OOP is a bulldozing machine predestined to level all. That 
I'm an
obstructor of the progress man and should be removed? That my life is
in danger from irate OOP programmers? What did you mean?

David

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> Neeum Zawan wrote:

> >     Try lying in front of the house when the bulldozers come. And if you 
> > see someone coming along hugging a towel, become friends with him. 
> > Otherwise your life will be in danger.
> > 
> >     And not because of the bulldozers.
> > 
> I'm not at all clear what this means. Submit to the destructors (or to 
> your fate)?
> Do you mean OOP is a bulldozing machine predestined to level all. That 
> I'm an
> obstructor of the progress man and should be removed? That my life is
> in danger from irate OOP programmers? What did you mean?

  Can I ask you how old are you?

  You don't understand the concept of smileys, you don't understand the
concept of object-oriented programming, and you can't even get a hitchhiker's
reference.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   You said "That's an IDE issue, not a language issue." I read that to mean
> that a language (like C# in this case) doesn't need to be designed to be
> readable because an IDE can be used to make it readable.

No, that was specifically in response to "I like header files because it 
gives me a nice summary of the functionality of the code." I'd rather have 
the specification of the code there once, and to have tools to generate 
documentation from the code, rather than to have the compiler require me to 
write the same specification twice just so it knows there's documentation.

I dunno - on big projects, I usually wind up writing a program that reads my 
.C files and generates the .H files automatically anyway. But then, I'm the 
kind of programmer who documents code before writing it, which is apparently 
terribly rare.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > "WTF - what does *this* crap have to do with *programming*?!"
>
>   It has to do with program design. The larger the program is, the more
> important it is for it to have been designed properly. A large program
> without proper design easily becomes unmaintainable and incomprehensible.

You didn't get my point.

*Now* you're talking about something OOP- and programming-related:
Modularization. But what on earth does your previous post's talk of "concepts",
pens, cars, dogs and cats have to do with this?

Well, with some experience with OOP concepts, *I* do know how to map them to the
constructs prevalent in this type of blurb, but it's still blurb and not the
real thing.


>   One of the most basic methods for keeping a large program manageable is
> to subdivide it into smaller parts, hierarchically. When you write something
> inside the large program, you shouldn't have to be keeping in mind the
> *entire* program in order to be able to write that small part. You should
> be able to keep in mind only the *relevant* parts of the rest of the program
> necessary to make that small part work.

BTW, note how the blurb may help to confuse: You're now talking about modular
hierarchies (going back to cats, they're comprised of a body, a head, for legs
and a tail); in your previous post, you were talking about conceptual
hierarchies (cats and dogs both being animals).

You *need* the modular hierarchies for large projects; but the blurb focuses on
the conceptual hierarchies.

>   The solution presented (although not originally invented) by object
> orientedness to this problem is the concept of modules: Modules can have
> both functionality and data, and they enclose both in a way that makes
> managing the data easier in a large project. Modules can also form a
> hierarchy (so modules can define sub-modules inside them, or own instances
> of other modules, etc).

Note that encapsulation in OO goes a step beyond what would typically be
considered modularization: A module is typically thought of as a collection of
code, typically coming with various data structures and a bit of module-global
data as an aside, and a project would typically have one instance of each
module. In OO, the focus is more on the data and the interface, with the code
taking on the role of an aside, and the whole project would be dealing with
multiple instances at once.


> > Despite all claims, I'm convinced this has virtually *nothing* to do with how
> > normal people *really* think (at least when faced with the task of explaing to
> > some dumb box how it should *do* something), and has even less to do with OO
> > *programming*.
>
>   Oh, it has a lot to do with how normal people think, and how other things
> (such as big companies) are organized.

Read again: "(at least when faced with the task of explaing to some dumb box how
it should *do* something)"

And notice that I'm talking about the blurb here, the cats and dogs and pens BS,
*not* OOP. I *do* agree that OO is indeed a very natural way of thinking when
analyzing or planning complex systems. It also very closely resembles the
design of e.g. complex machines, btw. But the typical OOP introduction blurb
tends to be very far from that.

And yes, in a sense this may further some "elite" thinking: With OOP being
introduced this way, students may get the impression that it is something
totally different from older programming paradigms, when in reality it is just
adding a few not really complicated concepts.


>   I'm sorry, but I think that the one writing bullshit is you.

Well, sorry if I got you a bit upset - I didn't do full justice to your post, as
it's still rather on the humane side of blurb; but it's still blurp-ish enough,
and I know you have a tough skin.

Post a reply to this message

Warp wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
>>>   You clearly don't understand what "object-oriented programming" means.
>>> Then you come here to tell us that you don't want it, whatever it might be.
>>>
>> I have seen a number of object oriented programs.
> 
>   Ironically, by saying that you are only *confirming* what I just wrote.
> 

OK I have seen OOP programs but I don't know what object orient 
programming mean.
Object Oriented Programming does produce Object Oriented Programs, but 
looking
at them doesn't tell me what Object Oriented Programming means. I'll 
accept that. Now, I ask again
tell me what Object Oriented Programming means.

David

Post a reply to this message

Warp wrote:
>   There aren't many programming languages out there which would allow the
> same kind of "controlled compiler abuse" as C, which is precisely why it's
> so popular to write kernels and device drivers.

True, but there are a number that do. :-)  Most people don't need controlled 
abuse.

> but right now I can't say what other languages have been used to write
> kernels.

Well, Ada is high on the list, as is FORTH. Algol was used for the B-series 
from Burroughs. That's why I mentioned them.

>   Sometimes you just have to. No programming language can account for every
> single feature a kernel needs. Sometimes you just *must* bypass the standard
> language and poke the hardware directly.

Sure. But, for example, take a look at the list of things that Ada defines 
how to do that C doesn't that would be useful for kernels:

Interrupt hooking, interrupt prioritization, interrupt disabling while 
running a higher-priority interrupt. Packed structures where you can define 
what and where every bit goes. Switching stacks (as in, context switching). 
Atomically writing to memory-mapped hardware. Test-and-set. Dynamically 
loading code and then executing it. Mapping data structures to particular 
addresses. Well-defined language structures for inline assembler. Plus 
everything C++ does (including interfacing to other calling conventions) 
except maybe turing complete templates. :-)

Oh, and I think it handles segmented memory, but I might be mistaken there.

Sure, if you need to invoke some magic opcode to blink the front panel 
lights, it's going to be really hard to make that portable. But you can do a 
lot better than C does.  Of course, Ada has another 25 years of experience 
on C, so it's not really a fair comparison.

I really think C got off the ground just by being used for the first 
portable kernel. The same as FORTRAN still being tops in numeric analysis 
because it had the first portable numeric analysis libraries.

>   The only other alternative would be to write the kernel in assembly, which
> would be enormously less portable and less manageable than C.

As I said, lots of kernels are written in FORTH (for small machines) or Ada 
(for dangerous machines).

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Warp wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
>> Neeum Zawan wrote:
> 
>>>     Try lying in front of the house when the bulldozers come. And if you 
>>> see someone coming along hugging a towel, become friends with him. 
>>> Otherwise your life will be in danger.
>>>
>>>     And not because of the bulldozers.
>>>
>> I'm not at all clear what this means. Submit to the destructors (or to 
>> your fate)?
>> Do you mean OOP is a bulldozing machine predestined to level all. That 
>> I'm an
>> obstructor of the progress man and should be removed? That my life is
>> in danger from irate OOP programmers? What did you mean?
> 
>   Can I ask you how old are you?
> 
>   You don't understand the concept of smileys, you don't understand the
> concept of object-oriented programming, and you can't even get a hitchhiker's
> reference.
> 
True, I didn't recognize the reference to the Hitchhikers Guide and 
wouldn't have
for a million years without your hint.  I have read it, saw the PBS 
version and
had successfully forgotten them. And I didn't know how to make smileys, 
if that constitutes
not understanding the concept. And I don't know much about OOP 
programming, but
these exchanges have taught me a lot about OOP devotees.


I'm 63 over the hill and senile. Just an uncultured ignorant old retard 
who needs to get out
of the way and let you young folk take over.

Can I ask how old you are? :)

David

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Sure. But, for example, take a look at the list of things that Ada defines
> how to do that C doesn't that would be useful for kernels:
>
> Interrupt hooking, interrupt prioritization, interrupt disabling while
> running a higher-priority interrupt. Packed structures where you can define
> what and where every bit goes. Switching stacks (as in, context switching).
> Atomically writing to memory-mapped hardware. Test-and-set. Dynamically
> loading code and then executing it. Mapping data structures to particular
> addresses. Well-defined language structures for inline assembler. Plus
> everything C++ does (including interfacing to other calling conventions)
> except maybe turing complete templates. :-)

An interesting thought here:

How high is the influence of the most favorite programming languages on the
further development hardware design?

> As I said, lots of kernels are written in FORTH (for small machines) or Ada
> (for dangerous machines).

Maybe the latter is somewhat comforting. Not that the pure *existence* of
dangerous machines would be.

Post a reply to this message

scott wrote:

> 
> Even if POV4 does change to an OOP model that you don't like, a) that is 
> not going to be released for decades, and b) you are free to still use 
> the latest stable 3.x release.  I wouldn't worry about it.

Crap. I'm gonna be old by the time its released.


-- 
~Mike

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> Now, I ask again
> tell me what Object Oriented Programming means.

  I have already written extensively about it in several posts in this
thread.

-- 
                                                          - Warp

Post a reply to this message