OO programming - illumination? - whoopsie

OO programming - illumination? - whoopsie

Post by Tom Dyes » Tue, 15 Feb 2005 02:36:26


'm a little hungover, so bare with me. Lol.


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. For example, lets say I have a Patient object in a Servlet and I
want to process some HTML describing that patient. With the patient object,
I can have a simple DrawHTML procedure so that each patient can draw itself.
To take this to another level, say I have a PatientList object which is a
container of Patient objects. If I want to draw the entire list, I can
fashion a drawHTML at the PatientList object (note: this is not
polymorphism, it's aggregation) which then calls each Patient's DrawHTML
method. So, to draw patients, I call PatientList's drawHTML method which
then calls each Patient's drawHTML method. This way, I don't have to have a
single procedure that is responsible for determining the list of patients to
draw AND drawing each patient. This is beneficial if I want to change the
list in any way. Say I want to draw a list of patients that start with the
letter A: I just have to modify the PatientList drawHTML method which will
not affect the patient's drawHTML method. It isolates the patient's drawHTML
code so I don't have to worry about it. Furthermore, say I want multiple
procedures in PatientList to draw patients: 1 for patients beginning with
the letter A, one with a complete list of patients. I never have to change
the patient's drawHTML code. Ofcourse, you can do this procedurally by
having a drawPatientHTML(String name, String id, etc) but with OOP, I can
just pass a Patient object. It's cleaner to have the patient draw itself in
OOP.


Just because a language is OO, doesn't mean that it forces developers to
code in an OO fashion. Java is VERY OO in the fact that everything is an
object except simple data types, and they have associated objects as well
(ie int and Integer obejct).


It's good procedural form to keep your methods short (typically I keep them
under a "screen page") just so you don't get lost in the code. I was coding
after someone who didn't quite understand this and had formed a very complex
procedure to be around 16 "printer pages" and was very difficult to work
with. Before refactoring a huge chunk of the app, I broke it down to more
managable procedures that the main procedure called.


I know absolutely nothing about SmallTalk, but this seems very strange to
me. Are you talking about inheritance?


I would say "procedurally written crap." All of the Java and Delphi code I
write is heavily OO. I can't stand using procedural languages, but
unfortunately in designing web apps, I have to use JS which is very
procedural and not strongly type casted (which is another issue).


This doesn't have anything to do with OO/Procedural coding that I can think
of. Lets say I want to add a Patient object to the PatientList. If I were
storing the Patients in a HashMap and created an add(Patient pat) on the
PatientList object, I would not need to return a variable in this method. If
it was in an Array or ArrayList, I could return the index, but that is
dependent on the container I'm using, not whether I'm using OO or procedural
programming.
 
 
 

OO programming - illumination? - whoopsie

Post by hansof » Sat, 19 Feb 2005 01:30:19

Tom Dyess" < XXXX@XXXXX.COM > wrote in message news:<PcMPd.5274$ XXXX@XXXXX.COM >...

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
 
 
 

OO programming - illumination? - whoopsie

Post by kjc » Sat, 19 Feb 2005 01:46:43

ans Bezemer wrote:
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.




 
 
 

OO programming - illumination? - whoopsie

Post by Oscar kin » Sat, 19 Feb 2005 02:19:31


That's not the issue here: OO is just another way of looking at the same
types of problems you can solve with "traditional" programming.



Very true. But with the availability of more and more menory, many feel
that memory efficiency is not that important anymore. Especially if you
note that while it is more efficient to model numbers as bytes, words,
etc. in terms of space, it is not in terms of processor efficiency: it
uses 32 bits exclusively, which is twice the size of a word.

Why is OO used then? Because it makes modelling and design easier.
Especially for complex problems. The result has not the smallest
footprint, not the fastest execution, but is _good_ _enough_.

However, large systems can be created faster, and that _saves_ _money_.
And in the end, it's the euros/dollars/<insert your currency here>
allocated by beancounters that determine what is being used.


--
Oscar Kind http://www.yqcomputer.com/
Software Developer for contact information, see website

PGP Key fingerprint: 91F3 6C72 F465 5E98 C246 61D9 2C32 8E24 097B B4E2
 
 
 

OO programming - illumination? - whoopsie

Post by Thomas Gag » Sat, 19 Feb 2005 03:52:19


<snip>

I think everyone's taking Hans' post too seriously. I don't think he meant it
that way. In the end he basically ended up suggesting FORTH and Assembly are
all that's required. I'm surprised he stopped when he did and didn't suggest
that a little microcode is all anyone needs since that's where all the action
is. Anything above microcode is unnecessary fluff. If the hardware weren't
so restricting we would be able to assemble bits ourselves into groups however
large we needed them without requiring those arbitrary 8, 16, 32, and 64-bit
restrictions.

A little early for April Fools' Day, but this newsgroup is always in need of a
little levity, however dry or masked.
 
 
 

OO programming - illumination? - whoopsie

Post by Lee Fesper » Sat, 19 Feb 2005 08:25:25


I snipped most of your comments but without prejudice. I do appreciate your thoughts.

I, too, am bothered by the hype surrounding OO. It is an amalgam of techniques that have
been used successfully for a long time. In fact, Forth was one the first languages to
effectively combine data and behavior with its BUILDS/DOES (and earlier) constructs. OO
is no silver bullet, but it is an excellent technique ... I would call it the best
modern programming facility by far.

I truly love Forth and have done some major development in the language including doing
my own port to an oddball architecture. I learned a lot from Forth but am dismayed by
its lack of traction in the mainstream. IOW, it's not often a practical solution in the
real world.


I'm afraid you're behind the times. Java is very efficient because of the amazing
strides made in runtime compiling/optimization. Alignment is not a consideration; Java
doesn't even let you know if two members are stored adjacently. The compiler is free to
use the most efficient organization.

I also really love Assembler and C. I've probably written far more assembly language
systems than you will ever comtemplate. I would have no problem going back to those
languages to develop systems (actually, I have, since I'm currently working on an ODBC
driver). However, I also know I can produce more understandable/maintainable/bug-free
systems in Java with greater ease.

I understand your stance that you want control and can handle it. I just don't see it as
valid these days, in the general case. It's a waste of development resources. My first
programming was all in machine code, because I didn't want to cede any control to the
assembler. I'm much smarter now ;^)

--
Lee Fe *** an, FFE Software, Inc. ( http://www.yqcomputer.com/ )
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS ( http://www.yqcomputer.com/ )
 
 
 

OO programming - illumination? - whoopsie

Post by Reply74718 » Sat, 19 Feb 2005 09:51:25


...

The formula SMP MPP FORTH VLIW didn't have a name like F21, B16, C18
...
But was/is 16-bit instruction ( with an optional provision
for a packed 5-bit set , ARM similar but more like model from Inmos
Transputer F code instrustion with 31 (0,reserved) dynamic local
methods. )

PLEASE WRITE 100,000 PAGES OF IBM DEFENSE DOCUMENTATION THAT
EXHAUST ALL SUB-ITERATIONS OF THE COUPLE HUNDERED I SENT THEM.
 
 
 

OO programming - illumination? - whoopsie

Post by Andreas Kl » Sat, 19 Feb 2005 10:22:18


Sorry, but Hans view is just right. an object oriented view of the
model is not the only one. I prefere the simplest possible one - and the
object oriented view by far isn't the simplest one. OO modeling
ends in myriads of classes and methods, only manageable with highly
sophisticated browsers. the last 10 years I have developed large
Smalltalk and Java applications. Smalltalk is fun, Java isn't.
since performance was sometime an issue I had rewritten some
applications in C. those rewrites were an order of magnitude
smaller and three orders of magnitude faster. not that JIT
compilers in Smalltalk (or even in Java) will produce slow code
- it's just the oposite.

As Hans mentioned, applications written in Forth become even simpler.
Complexity from high to low: Smalltalk -> C -> Forth.
at least IMO
 
 
 

OO programming - illumination? - whoopsie

Post by Andreas Kl » Sat, 19 Feb 2005 10:35:31


this is simply _not_ true. I have seen too many evidences against this
hypothesis.


wrong again. if developers want to be competitive they have
to learn keeping things simple. but in the UML/CASE and OO
world this just isn't possible. too many self produced problems.
IT becomes the costumer.
 
 
 

OO programming - illumination? - whoopsie

Post by Bernd Pays » Sat, 19 Feb 2005 18:53:21


There's no real surprise here. All early industries are known to have huge
internal costs, and little external ones. The cotton industry in Manchester
had 95% internal costs (steam engines, cotton mills, spinneries, automatic
looms, etc.), most of that machine costs, not direct manpower costs. The
machine costs certainly were manpower costs, too, but externalized manpower
(someone had to build the machines, dig out the coal and so on). Over the
time, the internal friction is removed, and the internal costs drop. ATM, I
think the cotton industry is dominated by external costs at the sales side.

Now, the cotton industry had 200 years to mature, the IT industry didn't.
Perhaps it's also paying not enough to the sales channel. "Keep it simple"
often has problems to sell, and "Keep it compatible" is easier to sell.
With "Keep it compatible", you accumulate a huge legacy, and you have to
pay the price for that.

But most of the time, the IT industry implements complexity for it's own
sake. Complexity seems to be a selling point - "we have XXX, YYY, and ZZZ",
without questioning if all that is necessary. "OOP" is just another of
those selling points, due to the hype around it. Sometimes it's necessary,
sometimes it isn't. It's no silver bullet, but it has something to offer.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.yqcomputer.com/ ~paysan/
 
 
 

OO programming - illumination? - whoopsie

Post by Oscar kin » Sat, 19 Feb 2005 19:16:49


Please enlighten me with examples then. I'd like to correct myself if I'm
wrong, but I need something to replace my current knowledge with.

Also, were the correct techniques being used? Using OO to implement a
process centric solution, for example, is a mistake. As is using a procedural
approach to implement a data centric solution.



Keeping things simple is the most difficult thing by far (IMHO). This is
not related to the specific technique used, although some techniques make
is easier to keep things simple. For administrative systems (my area of
expertise), I find OO does this.

This does not negate the fact however, that developers only work on stuff
as a hobby, or what they get paid for. And for this last part, a developer
has no final authority. He only has as much influence as his manager gives
him, which hopefully increases by his/her skills in making things simple.

However, if a manager has the idea that OO makes life easiest (even if it's
misplaced), then that's what is being used.


--
Oscar Kind http://www.yqcomputer.com/
Software Developer for contact information, see website

PGP Key fingerprint: 91F3 6C72 F465 5E98 C246 61D9 2C32 8E24 097B B4E2
 
 
 

OO programming - illumination? - whoopsie

Post by hansof » Sat, 19 Feb 2005 19:27:31

I think everyone's taking Hans' post too seriously. I don't think he
meant it
that way."

I've taken a few quotes from previous posts. First, I want to debunk
the myth that this was just flame-bait. Ok, it was a little over the
top, true, but certainly no flame-bait.. And I wasn't kidding either..

"Sorry, but Hans view is just right. an object oriented view of the
model is not the only one. I prefere the simplest possible one - and
the
object oriented view by far isn't the simplest one. OO modeling
ends in myriads of classes and methods, only manageable with highly
sophisticated browsers."

Right, that is my experience too. And I'm sick and tired of trying to
cram a simple problem into a flawed paradigm. What most people seem to
forget is that OO is a _programming_technique_, not a "one fits all"
model. I use OO techniques in my programs too if I want (or need) to
do abstraction. Yes, in C. You can easily do that. X was written that
way and Axel-Tobias Schreiner wrote a whole
book on that subject in 1993.

Sometimes things are not simpler than they are. This little piece of
code parses a textfile. Tell me where OO helps. Tell the file it has
to parse and rewrite itself? What does that help? This thing is only
70 lines (including comment).

: Field> bl parse-word ; ( -- a n)
: Fields>> 0 do Field> 2drop loop ; ( n --)
: Lines>> 0 do refill drop loop ; ( n --)

: GetCard ( --)
2 Fields>> Field> Card place \ skip two fields, get card
number
2 Fields>> Field> Phone place \ skip two fields, get phone
number
3 Lines>> \ skip three lines
;

"I, too, am bothered by the hype surrounding OO. It is an amalgam of
techniques that have been used successfully for a long time. In fact,
Forth was one the first languages to effectively combine data and
behavior with its BUILDS/DOES (and earlier) constructs. OO is no
silver bullet, but it is an excellent technique ... I would call it
the best modern programming facility by far."

But even that can be taken too far. When very complex datatypes are
developed you sometimes find yourself wondering what this thingy does
again.. Sometimes I rather prefer to write a word that does an
explicit conversion, just to remind myself I took the address of a
CREATEd item and converted it to something much more complex.

OO can be useful in some instances, but most of the time it is too
limited and horrifying designs emerge to to make it fit. Lego stones
(Forth) are much more convenient. If it fits, you can slam them
together and let the data pass by itself. Even distinct datatypes
don't help much, except add more conversion. If you want easily
maintainable code, factor and make small routines and small programs.
If you need monstrous amounts of code to write a single function,
routine or program you're doing something wrong. Let systems
communicate, don't try to cram all and everything in a single program.

Wording is very important. I've shown more than once that you can tell
the computer a story while actually writing Forth code.

"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."

Someone doesn't know to much about biology,
 
 
 

OO programming - illumination? - whoopsie

Post by Doug Hoffm » Sun, 20 Feb 2005 07:38:22


You might not want to lump most everyone who uses some object
techniques into that category. Especially in a Forth forum
where OOP is used as an *extension* to Forth, not as a *replacement*
for Forth.




Make up your mind. First you say you use OOP if you want and
then you slam it. ?? Give it a rest guy. I don't think there
is quite the amount of "hype" over OOP as you suggest. At
least not in Forth circles. Why does this topic bother you?

Choose your tool and program in peace.

Regards,

-Doug
 
 
 

OO programming - illumination? - whoopsie

Post by Andreas Kl » Mon, 21 Feb 2005 09:56:31

scar kind wrote:

there is no enlightenment at all. just experience:

1. project starts out with a framework (say JSP/J2EE)
2. JSP/J2EE seems too complicated so as a next step a
new framework would be developed which of course didn't
replace the other one.
3. A company wide architecture will be released which
ends in a new couple of libraries - on top of the
second framework.
4. now real requirement come in this play - which of
course doesn't fit (well) in those frameworks and architectures.
so we have to work around and hope that we get
those requirements running. but at this time we
have to deal with so many problems - released only
by 'framework developers' and 'senior architects'

well, with all that stuff we need about three weeks to
develop an new simple HTML Form.
to start the application it needs some hours and 16GB
of RAM. Response time approx. 3 min.

I have seen the exact same approach on a couple
of very big customers in Swiss and Germany.

My Solution:
Simple Web Server (essentialy HTTP protocol handler)
written in C.200 lines of code written in two hours.
Application written in C, very sharp, only real needed
requirement included. no dynamic behavior. written in
some weeks. 10000 lines of C code. (compared by 150000
lines of Java code). 512 MB Ram (compared by 16GB).


believe it or not.
most time spent is not development, it's in understanding
of the problem domain. once one has grasped the requirement,
implementation is easy. Now some hints
-> minimize runtime exceptions (out of memory, of
disk space, TCP errors etc.)
-> minimize the use of frameworks, the minimum is zero
-> avoid implementing hooks for future extensions
-> use a straight implementation for the real problem (business
problem).
-> don't avoid thinking.

... and so on


the problem I see (nearly every day) is that peoples are more
interested in writing techincally correct and pretty OO code
than in solving the real problem. as I mentioned above, this
will end in myriads of classes and methods, by far too oversized
for given problems. well I see, is much more fun to play
the technical game.

one question:
how many classes / methods are needed to convert a currency
into another ?


sorry again. if software development becomes too expensive, managers
decide to outsource them, for example to india - no joke !
and anyway, those peoples do exact the same job, only three times
cheaper.

best wishes
Andreas Klimas

 
 
 

OO programming - illumination? - whoopsie

Post by hansof » Tue, 22 Feb 2005 21:25:30


Fortunately. FYI, I didn't start this topic. I'm just giving my
reaction under the first amendement. ;-)

No, I use OOP as a technique. Like lookup tables, calculation, and any
other programming technique or algorithm you can think of. That
doesn't mean I find every problem suitable to be solved by using OOP.
In other words, I got nothing against OOP, I just don't find it the
right paradigm for EVERY problem:

this->add (this->value);

Is simply less clear and evident than:

a += a;

Or even:

a dup @ swap +!

When making money, it is not always up to me to choose my tool. And
working around the limitations or making procedural interfaces around
OOP just plain gets me down. I wanna do something useful with my time.
Even when working.

Hans