Use Jesus Christ

cpu16x1832_at_wmconnect.com
Date: 03/05/05 

Date: 5 Mar 2005 05:43:56 -0800

Juha Laiho wrote:
> Followups set to comp.object; apologies for disturbing
comp.lang.forth
> readers, but this seems to have a sideline into that direction as
well.
>
>
> I've been trying my hand in programming Java for a while now, but
have
> failed to see the "big" difference of what is procedural and what is
OO
> programming until very recently (or this is how I currently feel).
I'm
> inviting comments on whether or not I finally have the correct idea.
My
> background is mostly from procedural languages with or without
objects
> (mostly C, perl), but I've occasionally tried to understand Smalltalk
> as well as Forth. In Java I've mostly been limited to server-side
Java
> (servlets, with an occasional touch of EJBs).
>
> Now, to the thought that occurred to me: in Java, much of the code is
> actually not real OO code, but procerdural code that utilises
objects.
> Still, it would in many places be possible to write Java in more
rigid
> OO fashion. This'd explain my perplexion in not seeing that much
> difference with what I consider "good" perl code and with Java.
>
> Contrasting Java with Smalltalk: in Java, it seems common to write
> methods to very procedural form (no return values on methods, lots
> of branching constructs). With Smalltalk, it seems that pretty much
> all methods have made some selection on which object type to return.
> Additionally, methods tend to be very short (esp. comparing to some
Java
> servlet code I've seen).
>
> The Smalltalk style appears to me to be build on very long
(Contrasting
> to Java) message chains, which begin by building some new object,
then
> doing numerous pieces of small-scale processing on that object (and
in
> the end perhaps/often returning a completely different object than
was
> originally created). I think I've seen a reference to
"message-passing
> OO" somewhere.
>
> What I often see with Java is that a single statement contains just
> a single method call - and for the cases where the method returns
> something, the return value is stored to a variable, to be used
> perhaps once or twice later on. So, in many cases, code very similar
> to the Smalltalk messaging would be possible, but is not done. This
> is the issue that seems odd to me; is this just a cultural issue
> (Java programmers largely having a strong background in procedural
> programming, and the paradigm shift is not happening), or are there
> technical issues somewhere in the history of Java?
>
> Further, in the Smalltalk code it seems that actual branches are not
> very common, instead behaviour differences come from very heavy use
of
> polymorphism (which seems to be much less often used in Java). Again,
> is this just a culture issue? Or is the whole issue that the Java
code
> I've seen is just procedurally written crap - that in "real life"
(for
> some value thereof..) Java code resembles much more my representation
of
> Smalltalk?
>
> So, summarizing; what I feel is non-OO in the way I see Java code
written:
> - many methods written to return no value (void)
> - if/else constructs used instead of object polymorphism to achieve
> differences in program behaviour
> - a lot of avoidable local variables used (references to which could
then
> be accidentally leaked somewhere, and thus be ineligible for
garbage
> collection)
>
> This still leaves me to think about the need of exceptions in OO
code:
> I think exceptions have their place, but are often misused in Java.
> My experience with Smalltalk doesn't yet cover exception use, so
cannot
> make any comparisions on this (does Smalltalk even have exceptions?).
>
> ... and a further question: is "message-passing OO" as used in
Smalltalk
> the only form of object-oriented programming, or are there other
variants
> of "pure OO" (as in "not tainted by procedural programming")?
>
>
> Finally to the sideline to Forth. I seem to see strong resemblance of
> Forth idea of threading small pieces of code to modify a set of data
> to the Smalltalk object-message style of programming -- just that the
> "raw" data of the Forth program is presented as objects in Smalltalk.
> Am I just seeing ghosts here, or do these two share some conceptual
> similarity?
>
>
> And thanks goes to anyone for shedding any light on this all-too-long
> rambling - but I seriously need handholding to get my thoughts on
this
> to any sensible shape.
> --
> Wolf a.k.a. Juha Laiho Espoo, Finland
> (GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M
V
> PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++
y++++
> "...cancel my subscription to the resurrection!" (Jim Morrison)

From: cpu16x1...@wmconnect.com
Newsgroups: comp.lang.java.programmer
Subject: OO programming - illumination!
Date: 18 Feb 2005 19:06:38 -0800
Organization: http://groups.google.com
Lines: 70
Message-ID: <1108782398.029450.175250@c13g2000cwb.googlegroups.com>
References: <culmrd$d7e$1@ichaos.ichaos-int>
   <PcMPd.5274$u16.806@bignews6.bellsouth.net>
   <eaef3280.0502170830.b3bd93a@posting.google.com>
   <R66dnZIiVvlFeonfRVn-sw@wideopenwest.com>
   <eaef3280.0502180227.5361a645@posting.google.com>
   <1108766302.602474.22130@o13g2000cwo.googlegroups.com>
NNTP-Posting-Host: 172.209.102.108
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1108782403 29338 127.0.0.1 (19 Feb 2005
03:06:43 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sat, 19 Feb 2005 03:06:43 +0000 (UTC)
User-Agent: G2/0.2
Complaints-To: groups-abuse@google.com
Injection-Info: c13g2000cwb.googlegroups.com;
posting-host=172.209.102.108;
   posting-account=mJIrpg0AAAAp0nv7cjiDmTX72QF9L9Zf

Doug Hoffman wrote:
> Hans Bezemer wrote:
>
> > What most people seem to forget is that OO is a
> > _programming_technique_, not a "one fits all"
> > model.
>
> 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.
>
>
>
> > 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.
>
> 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

WARNING: Failure to perform the following instructions
may lead to misunderstanding,

Maybe start simple,

Reply7471859...@wmconnect.com wrote:
>
> OO ( program development) example,
>
> Tire object,
> Road object,
> Adhesion property negotiated between Tire and Road object.
>
>
> Regards,
>
> Mark A. Washburn
>
> ---
>
> In comp.lang.forth the OT subject line should read as
>
> OO programming - illumination!
>
>
> Keep learning C/Java/Scheme, also.

Then, continue your search using the following view

http://groups.google.com/groups?q=group:comp.*+insubject:oo+insubject:programming+insubject:illumination&start=0&scoring=d&hl=en&lr=&ie=UTF-8&safe=off&num=100&as_drrb=b&as_mind=1&as_minm=1&as_miny=1981&as_maxd=31&as_maxm=12&as_maxy=2005&filter=0

Regards, 

---
From: cpu16x1...@wmconnect.com
Newsgroups: comp.lang.forth
Subject: Re: Use Jesus Christ
Date: 22 Aug 2004 09:26:30 -0700
Organization: http://groups.google.com
Lines: 110
Message-ID: <d860a178.0408220826.361373fb@posting.google.com>
References: <ce0bd25d.0406160352.382f658f@posting.google.com>
<4fbeeb5a.0406201739.6a470c66@posting.google.com>
<4fbeeb5a.0406231423.696e8d3c@posting.google.com>
<ce0bd25d.0406231925.5563d0a5@posting.google.com>
<4fbeeb5a.0406241452.44122252@posting.google.com>
<d860a178.0407201505.4e5f3ea1@posting.google.com>
<d860a178.0408071702.2b20bec7@posting.google.com>
<10hb1bh6qs4krd9@news.supernews.com>
NNTP-Posting-Host: 172.133.30.84
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1093191991 12037 127.0.0.1 (22 Aug 2004
16:26:31 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sun, 22 Aug 2004 16:26:31 +0000 (UTC)
Sunday, August 22nd, 2004
8:16am
FORTH is an Object Oriented Language ( OOL)
Object Oriented Design ( OOD) is simply picturing in your mind /the
objects comprising a model of VARIABLEs, /dynamic attributes/ or
messages.
For example, VARIABLEs of a /car pavement adhesion/ problem maybe
imagined thru the objects and dynamic messages, and modeled using
VARIABLEs or meta-variables for /dynamic attribute characteristics/.
Object oriented design is a mental picture of objects and messages.
TIRE <-> ADHESION VARIABLE <-> ROAD
( NEWBIES, write a word or phrase, on a piece of blank white paper,
Then write more words or phrases. Circle words and phrases that fall
into similar groups.  Draw lines between the circled groups ( of
words/phrases).) and indicate negotiated messages, communications or
VARIABLEs shared between object groups.
( ADVANCED NEWBIES, consider building an object oriented software
model using mainly FORTH's CREATE and DOES>, ( or learning a UML
modeling tool, HDL, Scheme, or maybe consider study of the open source
Java Ptolemy II modeling environment. (
http://ptolemy.eecs.berkeley.edu/ptolemyII/index.htm )))
FORTH is bottom-up closure oriented, the meta-variables used in
originally defining an object oriented model of problem's
computability may become concrete as FORTH VARIABLE terms.
A meta-variable is a sub-problem term or a high level attribute that
is comprised of some number of definitions of sub-problems (
sub-VARIABLEs) ( however, /until/ a program IS reading and writing RAM
thru machine code, a program IS NOT using the actual VARIABLEs, maybe
only using object oriented problem mapping meta-variables.) ( a good
programming language permits the developer to design or model the
software either top-down ( non-closures) or bottom-up ( closures), as
most programming languages like FORTH, Java or Scheme do.)
CREATE, DOES>, DEFER and VARIABLE may be used for a top-down /object
oriented/ FORTH programming technique.
In this spirit/sense of /bare metal/ object oriented programming, a
genuine real de-facto VARIABLE is a /machine code object/, a fact very
well known with c.l.f community.  Yup, plain old ANSI FORTH /is/ OO
out-of-the-box, simply CREATE your objects.
For Scheme people, you may think of CAR as the execution token ( or xt
as abbreviated in ANSI language X3J14 documentation), CDR is /most
like/ >BODY , HOWEVER, many sub-definitions of >BODY are possible.
The >BODY address operation can be defined in machine code as an " >R
EXIT " sequence within an ANSI FORTH /interpreter/ for developing an
object oriented Scheme interpreter ( within ANSI FORTH), but I haven't
fully tested this.
FORTH is a real-time computable object oriented language ( with
machine level expression of VARIABLEs and an object oriented
dictionary.)
VLIW machine code continues to be strong as my best machine code level
model of Java or Scheme objects. FAULT-TOLERANT SMP MPP FORTH VLIW
uses a three-stack plus return stack model,  where two stacks extend
the basic and traditional machine code FORTH model with two indexing
stacks, X and Y.
FAULT-TOLERANT, in my usage, is a characteristic for super
super-scalability.
My dual bus architecture is somewhat flexible with internal dual-bus (
VLIW?), circuit design, HOWEVER, Level 3 fault tolerance must be fully
specified at the dual bus level, /specifically/, level three design
work is finished before non fault tolerant design.
Level 0, Non fault-tolerant.
Level 1, provides redundancy of SMP MPP processor resources, software
selected.
Level 2, uses some software for SMP MPP re-synchronization and TRUE
state recovery
level 3, Fully automatic hardware error correction
( thru redundant circuit) ( my $$$ design uses a four way redundancy,
externally signaled as RED/YELLOW/GREEN state of /any/ SMP MPP
dual-bus array processor )
( and two memory models, currently,
  1)  four SMP local memories for an Intel dynamic model and,
  2)  sixty four SMP local memories for an IBM static model. )
I guesstimated an Intel and IBM joint prototype project in 1996 at
fifty million dollars.
Today, costs may be exceeding five billion dollars.  ( Do not blame
any one of the computer chip email to Bill Gates thru
presid...@whithouse.gov)  ( BS for a computer chip. Although, maybe,
my research and design work is significantly my property, ( to publish
without any warranty whatsoever), the computer chip is not mine.   The
computer chip is mostly a simple, common and basic logic, like a
patent of the automobile /wheel/)
Your time,
your money,
you rule.
May the best chip win.  ( SMP MPP FORTH of another name brand) ( is a
/who/ product?)
Regards,
11:24am

Relevant Pages