RE: To Rev or not to Rev + OOP TAOO tech

[MisterX]

> [x'ed]
>  You are free to define "words" 
> that implement an OO environment if you choose.  You could 
> even create Rev using this as the lower level "P code", or an 
> operating system for that matter.
> 
> Dennis

I like your way of saying it... 

That's exactly what I've done with xtalk in TAOO, XOS, ObjX, 
the Referencer stacks,... all these years!

As Richard said, Object based... Do i need polymorphism? Nope,
i can handle it myself much better! Do i need inheritance? I
can force it anytime, anyway i want. Do I need object structures?
I got cards with the most complex and visual structures you 
could ever ask for from a textual IDE! 

If you really want to dwelve into OOPs, there's a huge field
of CS advanced books on the matter from language design to
process architecture to compiler stuff, etc... I tried it
all and none, really, none was the bible except maybe all in
part. You name the language, i checked it out. Even scriptX.

Great stuff, but can it be faster for development?

In the real world, you have to process objects for clients. 

FileMaker is the best for most business purposes - all in one.
The hell, the finder/Explorer + any text editor will do too! 

It's a matter of seeing the "objects"... Filemaker will make
the sums and reports while in the hell you do it yourself!

Realistically, RunRev, can do it without any intervention in
the best cases. Filemaker will cough, cough... OK, Applescripts
can help. But it's not a totally Filemaker only thing then...

Single points of failures are to be minimized!
And RunRev can do it all... 
But does it scale up? Not unless you have a real strategy or
optimum "fixed" object structure/code... That's always true
and that's when objects are less important...

If speed or graphics were not a problem sometimes, RunRev could
do it all actually... 

But thanks to externals that's quickly bridged between any
low-end or new-to-come APIs of the OS, anything is 
possible! And Chipp is one the best examples here I might add.

Was it done it OPP? Does it matter? In the end, it's it does it
business on it's objects the right way. Can I access it's 
objects? Can I modify them? :) Objects...

90% thinking, 10% scripting - that's how I see it!
Remember that 90% thinking = 1/1000 the 10% scripting in time!

So now im coming to the conclusion of the TAOO environment and
got a really really sweet set of tools. The OOP in it is like 
you said: a question of wording... After you get the hang of 
the wording (nothing hard!), and your libraries work with it, 
you'll see that things start to work by themselves! Usually 
with just a one-liner ;)

So if you are interested in an object called TAOO with a frame-
work of objects in objects without any need of fancy object.obj
notation... Let me know, i got it down to a science/slang now ;)

We all know there's always a trade off ;)

No joke. What can it do for you? Choose a [meaninful] verb...
It will find the object and function for it. It's programming
language/ide/file format independent too and anything you add to it becomes
part of the whole! So you see, after 15 years (or more) it's been gathering
quite a lot of skills... And any GUI is possible in terms of objects...

More importantly, and in relation to "a picture is worth a 1000 words",
visual objects in TAOO have a wording to them that makes them "aware"
(Jean-Claude Van Dam style ;)... That's the key to making the system work
not just as a oop-library but also as a "live" visual oop environment. 

So the Visual Object language is another place where I've put in a lot of
"evolution" - which someone mistook for "bug-fixing". I did and got a lots
more in return than expected and each version is less bugs all across the
TAOO script-nation! The language works with the controls via all types of
front/back or stackinuse scripts depending on the "object" layers. 

Now running on both Rev and MC too including all N2O tools ;)

The event Hierarchy is managed both locally and globally. The hierarchical
layers are like objects in objects. Or templates in objects, and vice versa.
There's no limits that I know of others than IDE over-loading. It works for
my new GM (called GIM - Graphical Interface Manager). There's always an
easier solution when it comes down to that like object-layer masters
(frontscript or backscript), managers(backscript or stackinuse), agents
(palette or stackinuse), etc 

For example, take a TAOO object "contact" which is just a group with a bunch
fields as Contact databases contain. It could be data from a file, db, sql,
or in cards, it doesn't matter. This Contact object, can be copy-pasted into
any other stack's object background and add "contact" features to the said
application! That's the relativism and relationalism of objects in the Art
of Objects - there isn't any - it's all there is!

I've released a part of it in a secret place of MonsieurX
Those interested... You know what to do.

And it's proudly made in RunRev! ;)

Cheers
Xavier
--
http:/

Re: Rev & OOP

[Pierre Sahores]

Rob,
Le 1 mai 05, à 17:11, Rob Cozens a écrit :
But when a programmer says, "Your programming platform isn't worth 
evaluating because it does not support [the latest concept] as taught 
at universities.", that gives me a strong indication the person 
doesn't know what he is talking about or isn't interested in looking 
closer.
... Full agreed and in about what we can "learn" in the universities 
and engeenier schools, it's always good to remember that the most 
usefull is never in the courses nor books. Why ?, just because the 
professors are mainly waiting between five to teen years before 
introducing new production state concepts and solutions in their 
presentations, just because they don't like to defend unconfirmed ways, 
even the best ones as long a the market and the time did'nt make them 
"academical safe"...

--
Bien cordialement, Pierre Sahores
100, rue de Paris
F - 77140 Nemours
[EMAIL PROTECTED]
[EMAIL PROTECTED]
GSM:   +33 6 03 95 77 70
Pro:  +33 1 64 45 05 33
Fax:  +33 1 64 45 05 33

WEB/VoD/ACID-DB services over IP
"Mutualiser les deltas de productivité"
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev & OOP

[Rob Cozens]

At 08:11 AM 5/1/2005, I wrote:
I would be VERY leary of anyone who responds to a real-world situation 
with a classroom response.
Likewise a military response.
:{`)
Rob 

___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev & OOP

[Rob Cozens]

Hi Dan,
So I would agree that the programmer who rejected Revolution out of hand 
without digging more deeply into the advantages it offers and shares with 
OO environments was hasty and ill-advised (and probably, as you say, more 
interested in eliminating alternatives than in finding the correct one). 
But to dismiss OO out of hand is, IMNSHO, equally short-sighted. As you so 
rightly say, the two big concerns are programmer productivity and code 
maintainability. And in those respects, Transcript is awfully hard to beat.
When categorizing OOP as the "buzz concept de jour", it is not my intention 
to dismiss it out of hand, nor to downplay the value of its underlying 
concepts.  To the degree that xTalk incorporates OOP capabilities, that's a 
good thing, me thinks.

But when a programmer says, "Your programming platform isn't worth 
evaluating because it does not support [the latest concept] as taught at 
universities.", that gives me a strong indication the person doesn't know 
what he is talking about or isn't interested in looking closer.

In my 30+ years of programming, I have seen many trends and concepts arise 
and later be replaced others.  Many seem to thrive in the theoretical world 
but are still not implemented in the real world to any major extent when 
the theorists move on to something new.

And often concepts come full circle:
Single-user systems were made multi-user.
Single computer, multi-user systems were replaced by networked single-user 
systems.
Networked single-user systems were replaced by client/server systems, 
returning control of dbs & files to a single computer and application.

Distributed processing was a buzz concept at one time.  Maybe one or two of 
the clients I have worked with over the years might have had a use for it; 
nobody else I've worked with could care less.

In my senior year of college I took Public Administration Case Studies, in 
which the descripion of a problem or situation was read to the class and 
each person described how she would approach it.  Without knowing anything 
about a person, I could classify him as student, military, or practicing 
administrator based on his response:

*  Student:  "Do what the textbook says."
*  Military:  "What's the problem?  Order somebody to do something."
*  Administrator: [Anything other that two responses above.]
I don't believe these viewpoints differ much based on subject matter, and I 
would be VERY leary of anyone who responds to a real-world situation with a 
classroom response.

Rob Cozens CCW
Serendipity Software Company
"And I, which was two fooles, do so grow three;
 Who are a little wise, the best fooles bee."
 from "The Triple Foole" by John Donne (1572-1631) 

___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev & OOP

[Mark Wieder]

Dan-

Saturday, April 30, 2005, 11:31:09 AM, you wrote:

DS> world around me in terms of objects. From a programming perspective, I
DS> find myself always more comfortable dealing with objects in the sense
DS> in which Smalltalk and Java (and decidedly NOT C++) think about them.

I'm in agreement with everything you said there (and I'm quite shocked
to hear myself say something like that) except for the following:

OOPness in java and in C++ is very much in the same "sense" if you're
actually programming C++ as C++ and not as "a better C". I, on the
other hand, have too much baggage of years of C programming behind me
to do this properly. Java forces this on you while C++ lets it slide.

Now, having said that and still having the floor, there are some
elements of OOP in transcript as it is today: message inheritance is
done right, even though you can't subclass objects (I'd *love* to be
able to do that); polymorphism can, of course, be applied to any
language - it's just a matter of how much work a given language
requires to implement it; encapsulation is... well... you can fake it
with custom properties.

...and I'm really taken with the eclipse IDE, especially with the
jUnit plugin.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Rev & OOP

[Dan Shafer]

Oh, darn. I was sort of hoping this thread would fizzle out. Then you 
had to throw down a gauntlet, Rob, and you know how I am about 
gauntlets (and, for that matter, things littering the landscape like 
thrown gauntlets)

I spent MANY years training and conditioning myself to think about the 
world around me in terms of objects. From a programming perspective, I 
find myself always more comfortable dealing with objects in the sense 
in which Smalltalk and Java (and decidedly NOT C++) think about them. 
OOP languages and OODBMS tools have *always* been more productive for 
me than procedural and relational models because once I trained myself 
to "think in objects," those approaches felt -- and were -- unnatural 
to me.

Far from being the "buzz concept du jour," OOP has been around, viable 
and in many places on the globe an all-but-inviolate standard for more 
than 30 years.

Now, that is not to say or suggest that every programming language that 
isn't strict OOP isn't usable or useful. Far from it. I use Revolution 
and Transcript because, even though it's not an OO environment, it is 
what I refer to in my books as "object-LIKE." That is, it represents 
enough of an accommodation of the key ideas of object orientation to be 
usable and useful on medium-sized, single-programmer projects involving 
non-object data. But I must say that if I had a choice of using an 
equivalent development environment that was syntactically as clean as 
Transcript or Smalltalk or Python and gave me the advantages of 
Revolution (cross-platform delivery while developing on my platform of 
choice, true stand-alone creation, great widget library, transparent 
database access), I'd switch in a New York nanosecond. The truth is, no 
such tool exists yet.

So I would agree that the programmer who rejected Revolution out of 
hand without digging more deeply into the advantages it offers and 
shares with OO environments was hasty and ill-advised (and probably, as 
you say, more interested in eliminating alternatives than in finding 
the correct one). But to dismiss OO out of hand is, IMNSHO, equally 
short-sighted. As you so rightly say, the two big concerns are 
programmer productivity and code maintainability. And in those 
respects, Transcript is awfully hard to beat.

FWIW.
On Apr 30, 2005, at 7:21 AM, Rob Cozens wrote:
IMF(oole's)O, the programmer who ruled out RunRev as a development 
platform on the basis of it not being a true OOP language was simply 
looking for a reason to pan it rather than do the kind of in depth 
analysis required to properly evaluate its potential.

The bottom lines for software development are real-world productivity 
and code maintainability, not compliance with the "buzz concept de 
jour".

Rob Cozens CCW
Serendipity Software Company
~~
Dan Shafer, Co-Chair
RevConWest '05
June 17-18, 2005, Monterey, California
http://www.altuit.com/webs/altuit/RevConWest
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution

Rev & OOP

[Rob Cozens]

Hi All,
I deleted the original message with the intention of passing on this [dare 
I say it, Heather] philosophical question; but a voice inside me keeps 
saying, "I won't let you concentrate until you respond", so:

IMF(oole's)O, the programmer who ruled out RunRev as a development platform 
on the basis of it not being a true OOP language was simply looking for a 
reason to pan it rather than do the kind of in depth analysis required to 
properly evaluate its potential.

The bottom lines for software development are real-world productivity and 
code maintainability, not compliance with the "buzz concept de jour".

Rob Cozens CCW
Serendipity Software Company
"And I, which was two fooles, do so grow three;
 Who are a little wise, the best fooles bee."
 from "The Triple Foole" by John Donne (1572-1631)
___
use-revolution mailing list
use-revolution@lists.runrev.com
http://lists.runrev.com/mailman/listinfo/use-revolution