Re: OO programming - illumination? - whoopsie

From: kjc (ksitron_at_elp.rr.com)
Date: 02/17/05 

Date: Thu, 17 Feb 2005 16:46:43 GMT

Hans Bezemer wrote:
> "Tom Dyess" <tdyess@dysr.com> wrote in message news:<PcMPd.5274$u16.806@bignews6.bellsouth.net>...
>
>>OOP is basically objects of which have procedures, so for code to be OO
>>doesn't mean it has to be devoid of procedural programming. Each object's
>>method is a procedure, but the difference is that procedure is part of an
>>object as opposed to just being a procedure sitting on it's own. The way OOP
>>utilizes this is that each object is responsible for procedures that it can
>>handle.
>
>
> Basically, I never liked object oriented languages at all. Somehow it
> seems wrong to assume that everything is part of another, greater
> thing that is totally encapsulated and has to take care of itself. If
> the world was organized that way, a screw would either screw itself
> into the wall or come with its own screwdriver.
>
> As a matter of fact, when you look under the hood of an object, all
> you see is a structure with a few pointers to functions. You don't
> need an object oriented programming language to produce such code, C
> will do just fine, thank you very much.
>
> BTW, structures are not very efficient. A structure gives usually rise
> to a frenzy of alignment problems that can only be solved by fillers.
> Actually, you really don't need structures, since it can also be
> represented by a host of loosely related arrays. It doesn't make much
> difference whether you write 'row.column' or 'column [row]', except
> that arrays of the same type are much easier to handle for both the
> compiler and the memory allocators.
>
> Basically, there are only one-dimensional arrays or do you really
> believe that by magic memory is wrapped into matrices and cubes? The
> compiler conveniently translates your 'array [x] [y]' notations into
> real offsets like 'array + ((x * size) + y)'.
>
> There are a lot of fancy datatypes, but basically they are just arrays
> of arrays. As a matter of fact, there are only two real datatypes, a
> word and a byte. A pointer is usually a word. The different
> pointertypes are just created to let the compiler do some work for
> you, so you don't have to remember what the real size of e.g. a
> character or an integer is. Thus, 'char* p + 1' can be translated into
> 'p + sizeof (char)'.
>
> I wonder why people need a 'typeof()' operator: after all these
> declarations in order to let the compiler do most of the work they
> seem to have forgotten halfway what type 'p' actually was. After all
> the help their object-oriented compiler gave them they have completely
> lost track of what they were doing. So, if it doesn't help, what good
> is it?
>
> As a matter of fact (hush!) there is no such thing as a pointer. It's
> just an address, in other words: it is a variable that holds a
> location in memory. A NULL pointer is just a variable that points to
> the very first byte in memory (address 0) and by (compiler) convention
> that is not a valid address. A NULL string is a pointer to a byte in
> memory that just holds a terminator, which is 0 by convention. Note,
> these are just conventions. You could define another convention which
> may work just as well or even better.
>
> Usually, I don't need much more than a stack (where I push my
> parameters (all words)) and a way to allocate an array of words and
> bytes. When I push a byte on the stack, it is expanded to a word and
> when I store a value from the stack into a byte its 'most significant
> bits' are lost. When I'm done, I terminate the allocation. I don't
> need a paranoid garbage collector to clean up my mess, thank you.
> Even less, I don't need a compiler to do the 'instantiation' or
> 'destruction' of 'objects', I'm quite capable to allocate or
> deallocate a bunch of bytes or words myself.
>
> BTW, the latter seems a lot easier. Not only that, but my programs
> seem to run a lot faster and are a lot smaller than most others. I can
> forgave C that it was typed so I was forced to do some casts to get
> rid of those ugly warnings. It still seems odd I have to prove a dumb
> machine that I know what I am doing. The problem is that with C++ I
> have to figure out what he is doing by using ugly things like class
> browsers. Normally, I don't even need a debugger, so why the heck
> should I use something as hideous as a class browser. When I'm really
> in trouble the assembly switch of a C compiler does wonders, even
> though most have forgotten it's in there.
>
> The streams library of C++ is notoriously difficult to use. With a
> file, you open it, dump a bunch of bytes there and close it. End of
> story. A file handle is just another word. Most of the forth programs
> I write professionally are between 25 and 150 lines long and written
> in minutes, not hours. They do their job and are developed quicker
> than even a C programmer can do. I recently wrote a program that
> interfaces with Graphviz. It scans the Forth source file, dumps a .DOT
> source file, which draws a graphic scheme of its call sequences. 150
> lines, less than 1 hour hack. Most definitions are a line long (as
> good Forth programs should). Try to beat me on that. And don't say
> maintenance is a horror. It is not. Since most definitions are a line
> long, it is easy to pinpoint what should be changed.
>
> A compiler should be created humbly, not arrogantly. Why not: it's
> there to help me; I forked out the bucks, so don't bug me. If it never
> heard of a 'byte class' or a 'word class', it should follow some
> classes, not me. And don't start to ask me for a 'constructor method':
> if I didn't allocate it, I didn't need it and you don't have to
> 'construct' it for me.
>
> Sometimes the world is not an object.. Better, if you look into
> nature, there are plenty of networks, but few pure, natural
> hierarchies. A hierarchy is a sub-class of a network anyway. Somehow,
> it seems strange to me that people want to tackle 'real life problems'
> with such limited tools.
>
> Hans Bezemer
Without debunking most of everything you stated.
It's clear to me that you know nothing about OO concepts.
Especially the modelling part. Objects are all around you.
You yourself are an object composed on many organs, those
organs can be further modeled to include cells and so on and so forth.
Each organ has it's own respsonsiblity. An organ, when needed
collaborates with other organs.

Are you getting any of this.

Oh, BTW.
The screw and it's ability to screw itself in.
Is just plane empty headed.

Relevant Pages

  • Re: OO programming - illumination? - whoopsie
    ... represented by a host of loosely related arrays. ... compiler and the memory allocators. ... As a matter of fact there is no such thing as a pointer. ... memory that just holds a terminator, which is 0 by convention. ...
    (comp.lang.java.programmer)
  • Re: Program speed execution question
    ... It might also be cache size, memory speed, total memory, or other features of the two machines, or it could be that the compiler optimizations are different for the two machines. ... With pointer arrays, the compiler must often assume that the arrays can overlap through hidden aliases, and this inhibits many optimizations. ...
    (comp.lang.fortran)
  • Re: OK folks, corrected
    ... int function; ... since this tells the compiler that this pointer can be 1 or more ... since you can't have arrays of incomplete type. ...
    (comp.lang.c)
  • Re: Problem bei make
    ... in vielen Faellen array und Pointer gleichzusetzen (auch wenn es ... Den Unterschied zwischen arrays und Pointern (auch konstanten ... Hersteller koennte seinen Compiler also durchaus Code erzeugen lassen, ... der bei solcherlei Pointer-Arithmetik zum Programmabbruch fuehrt und ...
    (de.comp.os.unix.linux.misc)
  • Re: Mex Overflow Error Using Free Borland Compiler
    ... >>>would clean up a lot of code by eliminating the pointer dereferences. ... >>>guaranteed by the standard and should not be relied on. ... >>>You can try the GNU C compiler available on mingw or cygwin. ... >>>the Constraints are then both operands shall have arithmetic type. ...
    (comp.soft-sys.matlab)