| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 36.1 | Kee, Epitool, Qsl, Vaxflavors everythink but lisp | ITGATE::TOGNAZZI | | Thu Nov 10 1988 18:17 | 36 |
| Hi.
I think that with OO AI you mean FRAME.
Sure the customer dont like nexpert because is not a frame system.
I try to answere you:
Trellis/Owl is a research project, is pure OO programming.
PCL is just a set of file that you can find in LISP$EXAMPLES
CLOS will be the standard for OO on lisp enviroment.
At the moment nothing of this could help you.
The possibilities are:
KEE on vax common lisp, (now is available)
EPITOOL
QSL.
KEE and EPITOOL are well known, QSL is 3rd part product (QUINARY).
QSL is just an extention of common lisp (SOME PACKAGE)
that give you a frame system with OO programming (method),
ACtive value, rules (back and forw) and the meta
knownledge representation.
Actualy I'm using QSL in a project based on OO.
For the end of the year will`be ported under decwindow.
At a lower level (JUST OO) you can think about VAXflavors.
Bye Dario Tognazzi
|
| 36.2 | qsl 2 | ISTG::KELLY | grasshopper | Fri Nov 11 1988 21:50 | 15 |
| Greetings,
I'd also recommend you take a gander at Dario's QSL.
We were skeptical about it when it was first mentioned as appropriate for
one of our international projects (AITC, AIFellowship project on hydrocarbon
exploration with an Italian customer). But Dario did a fine job on the project.
The expert system was effusively well-received by the customer. And, from what
I can discern, QSL seems to be worth a look. My impression is that it is a
little slow, so, if that is your customer's objection to Nexpert, QSL may not
be a suitable replacement. But anything non-real-time (e.g., not on-line
process control or FX trading) may be a good use for it.
Dikk
|
| 36.3 | completing the list | SUOAI::SCHLUETER | manfred schlueter | Mon Nov 14 1988 16:32 | 41 |
| Hi Rene,
Concerning OO, we should mention some other tools running on VAX:
- KC (Knowledge Craft), one of the biggest tools I have ever seen.
CRL is a subset of KC ( functional programming, object-
oriented programming and graphical user interface)
incorporating everything you could desire.(notesfile HOW::CRL)
- Mercury, perhaps the next generation of XPS-Tools. (I'm just
working with it) The fastest CLOS implementation on VAX.
10 times faster than everything else. Own implementation
of MetaClass concept. This concept is still missing in CLOS
and one of the reasons why Stefik and Bobrow are still working
on CLOS.
- PCL as there is no documentation, I tried to use the specification
of CLOS and my intuition. Hard work!!
- CLOS Someone in the Lisp developement group ( Cooper?) should have
the actual version of CLOS, but as I mentioned: no MetaClass
concept available.(notes file AIAG::CLOS)
Flavors There are at least two implementations running on Vax:
VaxFlavors and AI-Flavors ( second one is a Third party product).
A year ago I worked with VaxFlavors: nice and simple tool,
sources are available. ( entry 321.* and 558.* in the Lisp
notesfile)
ART Yeah! Even ART incorporates OO-programming. Is still available
but running on LUCID-Lisp.
SMALLTALK As far as I know, there exists a Smalltalk-80 implementation
for Vaxstations. The work was done by an norwegian university.
Unfortunatedly I don't remember the name. Have to search it in
my brain ( Only on request!)
Greets
Manfred
|
| 36.4 | Some notes on Mercury... | HERON::ROACH | TANSTAAFL ! | Thu Nov 17 1988 10:09 | 94 |
| Although I haven't touched it yet, I have been doing some research
on Mercury from AIT. Here's some bulleted notes that I took while
interviewing Mike Stock, president of AIT, the other day on the
phone; (my comments after)
o FAST and EXTENSABLE were Mikes bottom line comments. Believes
that you can prototype AND deliver a very large system in Mercury
without significant performance degradation or reaching fuctional
limits of tool. Says engineering projections show that it can handle
a 20K object, 20K rule system alright.
o conforms 100% to the CLOS standard as it stands now (almost
finalised) and will conform to it in future if it should change.
Has built in production engine that reasons over CLOS structure;
forward, back, mix. Engine built on proprietary algorithms that
he claims are most efficient in existence.
o part of speed of execution is due to their own storage management
system which minimizes the need for garbage collection. Claims that
the only garbage around is that which is created by the VAX LISP
compiler.
o fully integrated into VMS. Contains all of the VAX LISP primitives
including UIS (DECwindows when available), workstation style
presentation manager. Interfaces directly into rDB and talks SQL.
Callout to external routines is done via VAX LISP callout. You define
the external routine as a symbol and include it anywhere (method,
LHS, RHS, etc.).
o link to rDB very strong. They use rDB as a stable storage system
for working memory. They build an rDB on the fly with the system
and keep everything in there. They only cache recently used data
in memory. Claims that this also contributes to exceptional
performance. Also claims to layer nicely on top of existing databases.
o claims it to be the first and only 3rd generation AI tool with
Lisp, Prolog, ops, etc as first generation and KEE, ART, KC, etc.
as second generation.
o claims that support will not be as big an issue as it is with
NEXPERT because existing code is very stable. Says that there are
bugs but it would take someone 3 or 4 months of experience to get
to the point where they could find a bug.
o price for base development system is $21K/CPU. $32K with training
and documentation. $3k/CPU delivery environment. Volume discounts
up to 40-50%.
o says product is being ported to ULTRIX and will be fully supported
in spring 89.
o promises NEXPERT-like developer front-end by Jan 89.
My Comments
***********************************************************************
If you know Mike Stock, you know that he is a very motivating kind
of individual and one hell of a good salesman! Mike also enjoys
a very good reputation within the DEC AITC. I immediately got very
excited by the sounds of the tool but wanted some feedback from
others. Called around to a variety of people who either have touched
it or have attended demo's, training classes or seminars on it.
Here's some of the feedback:
o not complete yet. AIT focused on the delivery and functionality
aspects of the tool, so developer interface is still a bit primitive.
However, the heart of the tool seems very solid and looks as if
it can meet its claims of moving a prototype to large full blown
system.
o if new front-end meets AIT's claims as well as the core of the
system, the tool will be spectacular.
o very powerful LHS
o speed of pop-up menu's under UIS very impressive. Show's they
have good engineers building the product.
o best integration of an AI tool into VAX/VMS environment of any
AI tool on the market today.
o "...if Mike Stock says he'll provide something, I can put it in the
bank! I've put Mike to the test 100 times in the past and he has
come through 100 for me...". This is a quote from a man who managed
a project in the critical path of the first VMS release.
My thoughts right now are optimistic. I think that it is worth more
looking at. I am sold on the "concept" of a tool that is designed
with the delivered system in mind, not just on a sexy developers
front end. Am REAL interested in the promise that its being moved
to ULTRIX. Would appreciate any feedback on this tool; Manfred???
pat
|
| 36.5 | impressive product! | SUOAI::SCHLUETER | manfred schlueter | Fri Nov 18 1988 09:52 | 41 |
| Some remarks on your note, Pat:
- Mercury doesn't support the full CLOS standard. Due to Mike's maxime
'runtime environment has to be very fast' they changed some features
of CLOS without loosing any functionality CLOS provides.
Nevertheless they are supporting CLOS to 98-99%!!!!
- There is no backward chaining mechanism in Mercury! And it may be hard
for a user to introduce one. Due to the 'private algorithms' they
are using in the Production Engine (PE) you'll never have the chance
to force the Engine, to do backward reasoning. The PE is based on
MOS (Mercury Object System) but the documentation in that point
is 21 (!) lines long.
- The runtime is really very very fast! Impressive! On the other side
the developement environment is slow: Defining a class via Def-Class
takes on my machine (MicroVax II) between 5 to 10 seconds! But as Pat
mentioned already they are working very hard on the developement environment
and Mike will ship the next week release (V0.7) with a 10 times
faster developement time ( and thats necessary).
- The support I'm getting from AIT is magnificient. Nearly daily contacts!
- I like these build-in features like the Presentation Manager (PM) who
automatically produces Forms, Menus, Scroll-Bars and Dialog-Boxes for
the application data structures. There is nothing equivalent in Nexpert!
The only thing I'm missing are facilities to browse my topologies.
Or the build-in RDB access! Great!
- I'll not hope that they will deliver a Nexpert like developer interface.
Terrible! Anyone out there who likes Nexpert? Noone ,great! I would like
to see the more Xerox (Interlisp-D workstation) oriented interface with
all this recursive callable debuggers, editors and evaluators.
Overall impression: great!
If you want to get more precise information on Mercury (flyers etc.)
don't hesitate to send me your mail.
Manfred
|
| 36.6 | more infos | SUOAI::SCHLUETER | manfred schlueter | Fri Nov 18 1988 15:08 | 8 |
| Just had a telephone call with George Yates, Dir. of Engineering,
AIT.
He claims, that backward reasoning is due to some errors a hidden
feature in Mercury, but will be visible in Version 1.0, the first
official release of Mercury.
Manfred
|
| 36.7 | more and more infos | CESARE::EANDI | | Tue Nov 29 1988 11:39 | 14 |
|
Could you pls tell me how can I get any documentation on MERCURY?
AIT contact person(s) name(s) will be appreciated as well.
I've been very impressed by Pat and Manfred's comments and feedbacks
and would enjoy to have a look inside.
Thanks,
Antonella
|
| 36.8 | ait | ISTG::KELLY | grasshopper | Wed Nov 30 1988 22:50 | 21 |
|
Greetings,
Mike Stock has an account on ISTG::STOCK which may be
the easiest way to reach him, as he bounces from place to place
constantly.
I agree that the engineers hacking the tool appear to
be first-rate. But I've had some customers complain to me that Mike
has a gift for hyperbole, so you might want to tread carefully.
Also, if you intend to use Mercury with customers, they
had better be completely Lisp-fluent before touching Mercury
(one peon's opinion there). AIT seems to have done their tool
development in the opposite manner from Neuron Data. ND spent a
lot of effort of the development interface first and has only gradually
built up engine capabilities. AIT has banged out the engine and
interface abilities first and seems to be leaving the development
interface rough for now.
Dikk
|
| 36.9 | merc impressions | ISTG::KELLY | grasshopper | Thu Dec 01 1988 20:25 | 81 |
|
Greetings,
I just spent a couple days with AIT folks learning about and banging
on Mercury: their expert system development tool. Some impressions follow.
{These are my impressions alone. I speak for no one else and represent no group
in making these comments.}
1) People
I was very impressed with the 3 programmers/developers/teachers of Mercury
that I dealt with. They were all sharp, talented hackers and excellent teachers.
They know the tool inside out, are confident of its abilities, are receptive
to suggestions and comments about its performance, and I Would trust them to
support any product they sold.
2) Lisp As Sine Qua Non
As Mercury stands now, I would not use it with any of my customers because
the folks I work with are fresh out of language training classes. A user of
Mercury would have to be completely and entirely lisp-fluent to write one rule
or create one object.
Mercury's developers seemed to imply that this was their original intent
in building the tool, and that the developer's interface Will come later. They
see Nexpert, for example, as a beautiful developers' interface with a slow
cantankerous limited engine. They see Mercury as a seasoned lisp-or-OO
developer's notion of paradise.
3) Code Volume
Mercury is really Lisp raised to the Nth power. And, as such, can be
a little code-heavy. It's not verbose (e.g, Cobol). It just requires a lot of
overhead rules to establish the linkages between, say, rules and objects, or
rules and forms used to present user questions and accept answers.
4) Integration/Hybridization
One of Mercury's claims to fame is easy integration (along with
performance). It does seem to be easily integratable. (Linkage requirements are
specified in the body of the Lisp code: e.g., includes of external files,
constructors and defined functions of external objects, etc.). "Easy", of
course, is a relative term. But I would say Mercury is easier to link to
databases,etc than OPS, Lisp, or Prolog and, perhaps, a little easier than
Nexpert.
5)Look-and-Feel
Mercury looks and feels, to me, like KEE's earliest version from 6 years
ago: like Lisp with an attitude.
Mercury rules are almost identical to OPS rules in their morphology and
function, except that Merc rules can handle disjunction as well as conjunction.
But essentially everything good you can say about Merc rules you can also say
about OPS rules. So its rules are not the reason to buy the tool.
Mercury's symptom-cause tables look like the ones in Martin Rooney's UDS
diagnostic shell. I think Martin's are far easier to add/change/modify and they
include features that Merc's doesn't. But Mercury is a broader tool in its
applicability.
The creation of objects is done in Lisp code (as is practically everything
else). Window menus seem to be used only to display/add instantiations to slots,
not to create the slots themselves.
6) General impressions:
- If you like Lisp and OO programming, you will wet yourself when you see
Mercury.
- I wouldn't use it, in its present state, for From-Scratch development with
relatively naive expert system builders because I think the new KEs would
give up in discouragement before they had written one rule.
- However, if you work in an internal lisp-environment ex-sys development
organization and intend to give your internal customer only executables,
then Mercury is something you should look at, especially if the folks in
your group are crackerjackhacks already.
- I see Nexpert as a tool which is easy to get started with, but difficult
to work with when you advance to big systems and hairy applications.
I see Mercury as just the opposite: tough for a beginner (I'd say, one year
of Lisp coding experience mandatory), but probably very powerful on complex
systems. (However, Mercury is, as far as I can tell, untested on large
systems.)
- Mercury looks as if it has huge potential. It seems to me to be a tool
still under development, but might be worth a look for people with Object
Oriented projects in mind (e.g., group technology in manufacturing) and
a lisp background.
Dikk
|
| 36.10 | ULTRIX version ? | YIPPEE::TARANTOLA | Quod scripsi, scripsi | Fri Dec 02 1988 19:49 | 7 |
| Dikk,
do you believe it is possible to ask for an ULTRIX version ?
It should be nearly straightforward, shouldn't it?
-Carlo
|
| 36.11 | careful | ISTG::KELLY | grasshopper | Fri Dec 02 1988 20:52 | 25 |
|
Greetings,
It might be possible to ask AIT to work on any type of
enhancement/extension you want. My impression is that Mercury is
still being developed, not really a full-blast tool yet. And they
seem to be testing the waters by showing the tool to folks and then
asking for suggestions. I'd write to ISTG::STOCK for information
or to offer suggestions (but I'd believe about half of what he says).
Caveats:
- You need 70Meg ! to fit the tool on your system (an RD54
and part of an RD53). It won't fit on the standard uVaxGPX
with 2 RD53s.
- The only demo I've seen to demonstrate the tool's touted high
performance involves running one single rule 2000 times and checking
the CPU time used. I wish I could get away with showing one-rule-demos.
Not sure how the tool would do out in the rough world on real problems
and not sure anyone else knows either.
- I have seen Mercury integrate from Lisp to outside of Lisp, but have
never seen it being called from outside into the Lisp code (you
might want to ask about that - may be a potential problem).
dikk
|
| 36.12 | Good points. | YIPPEE::TARANTOLA | Quod scripsi, scripsi | Fri Dec 02 1988 21:30 | 9 |
| > - You need 70Meg ! to fit the tool on your system (an RD54
> and part of an RD53). It won't fit on the standard uVaxGPX
> with 2 RD53s.
Hhmm...interesting:
To have a full-blast tool or to have a blasted GPX...this is the
question :-}.
-Carlo
|
| 36.13 | Joviality! | YIPPEE::FITZGIBBON | Joe Fitzgibbon EAITC Valbonne | Sat Dec 03 1988 10:43 | 7 |
|
Carlo,
A less mercurial attitude to the effective use of your GPX would
be appropriate.
J.
|
| 36.14 | ULTRIX and Call-in promises | HERON::ROACH | TANSTAAFL ! | Wed Dec 07 1988 15:58 | 14 |
| On the ULTRIX issue...
Mike tells me that they plan to have a SUPPORTED version for ULTRIX
by next spring.
On the call- in issue...
Mike tells me that as soon as VAX LISP supports call-in, so will
Mercury. Doesn't V3 of VAX LISP have a limited call-in capaability;
call-back or something like this?
Just a messanger....
pat
|
| 36.15 | Trellis | LARVAE::TURNER | Mark Turner * DTN 849-3429 * SPYDER::TURNER | Sun Dec 11 1988 12:42 | 40 |
| Here's the latest information I have on the availability of Trellis.
If you haven't run into Trellis before, it's a high-level OO tool which
has been under development in the U.S. for some time. It's a powerful
tool which, like many others of its type, eats VAXes. Running it on a
small machine wouldn't be a good idea; performance can be poor. Details
on a minimum configuration could be had from the people below.
Mark
************************************************************
<<< PBSVAX::SYS$SYSDEVICE:[NOTES$LIBRARY]TRELLIS.NOTE;1 >>>
-< Trellis/Owl language and Trellis programming environment >-
================================================================================
Note 53.1 Customer Kits ?? 1 of 1
COPA::CABANYA 17 lines 26-OCT-1988 15:43
-< not a product yet! >-
--------------------------------------------------------------------------------
Currently we are in the process of doing a market survey with Trellis/
Owl. We have customers (outside of DEC) who are willing to sign
a license in exchange for giving us information on their reaction
to Trellis/Owl. These licenses are for a 6 month period and NO
WAY implies that Trellis/Owl will become a product. These
installations will not be supported if bugs are found, we will,
of course, do our best to help the customer but are under no obligation
to do so.
If you feel that your customer would be interested in this type
of arrangement, please contact either myself or Mitch Perlitch
(CURIE::PERLITCH) for the licenses and other documentation.
Thanks.
mary
|
| 36.16 | Trellis - Europe | KETJE::HAENTJENS | Beware of Counterfeit | Tue Dec 13 1988 16:14 | 13 |
| From: LOVADA::SCHERRER, On: 13-Dec-1988, To: KETJE::HAENTJENS.
I'm handling the European Distribution of OWL/TRELLIS.
Currently, we have a process to handle ACADEMIC/RESEARCH requests. I'm
working with LEGAL to have a COMMERCIAL loan agreement: this will take
another month.
I hope to be able by end of January 1989 to ship OWL/TRELLIS to COMMERCIAL
institution.
Best regards, Patrick
|
| 36.17 | Found more on Mercury | HERON::ROACH | TANSTAAFL ! | Thu May 25 1989 18:41 | 64 |
| <<< CREDIT::$222$DUA16:[NOTES$LIBRARY]EXPERT.NOTE;1 >>>
-< Expert Systems >-
================================================================================
Note 152.0 Comments on MERCURY from AIT? 2 replies
SELECT::CHUM "KEs do it by the RULE..." 16 lines 3-APR-1989 17:43
--------------------------------------------------------------------------------
I am currently evaluating the ES tool MERCURY by Artificial
Intelligence Technologies, Inc. (AIT). It is claimed (by AIT,
of course) to be "The FIRST tool for LARGE SCALE Knowledge base
systems".
Has any KEs out there built any LARGE SCALE KBS successfully with
this tool?
I have recently went to a 3 days training course at AIT and found
tool very clummsy, unstable, and inefficient. They also "polluted"
(in my opinion) Common Lisp with extremely strong typing and called
it MLISP.
Does anyone has any positive experience with Mercury?
All comments appreciated!!!
================================================================================
Note 152.1 Comments on MERCURY from AIT? 1 of 2
SELECT::KELLY "grasshopper" 22 lines 10-APR-1989 14:45
-< blah >-
--------------------------------------------------------------------------------
Greetings,
To me, Mercury looks like the opposite of Nexpert in terms of interface.
Nexpert has a beautiful front end, but is so krufty in its inference
mechanisms and inheritance strategies that it's difficult to use
when the kbase gets big. You end up whacking out these moby twisted
kluges if you build a big system.
But Mercury seems to have an overdeveloped back-end, with no front end
at all. You have to be lisp-fluent just to get into it. That's
no problem for hacks, but new KEs would pull all their hair out
before they'd done a single inference.
However, Nexpert, at least, has been used for some interesting applications.
It does have a track record.
Mercury is raw. If ANY real applications using it existed, I'm sure
AIT would be showing them. But they're not. The only demo I've seen
from them involved running the same rule 2000 times to demonstrate
performance. Wish I could write one rule demos. Would make life
a lot easier.
================================================================================
Note 152.2 Comments on MERCURY from AIT? 2 of 2
SELECT::CHUM "KEs do it by the RULE..." 10 lines 11-APR-1989 09:22
-< be patient??? >-
--------------------------------------------------------------------------------
You have echoed my sentiment on Mercury! I think with the talents
they got at AIT, they can probably whip out new and better versions
one after another. They also need some interesting applications
for track record.
... grasshopper, remember what the High Priest in Shao-Lin Temple
said to you when you were a kid learning Kungfu there?...
"..... in due time, grasshopper, in due time, ......"
|
| 36.18 | fyi | HERON::BUCHANAN | Andrew @vbo DTN 828-5805 | Fri May 26 1989 13:20 | 317 |
|
Date: 17-May-1989 10:00am BST
From: Jean-Claude MONNEY @GEO
MONNEY AT GVA01A1 @EHQMTS @GEO
Dept: Systems Marketing Europe
Tel No: DTN: 821-4055
Subject: Partyline on object-oriented technology
*********************************************************************
*********** COMPANY CONFIDENTIAL *** FOR INTERNAL USE ONLY **********
*********************************************************************
DIGITAL PARTYLINE ON OBJECT-ORIENTED PROGRAMMING AND TECHNOLOGY
We are receiving many press inquiries about object-oriented
programming, object management, and the entire field of
object-oriented technology. Digital is very active in this field and
we need to communicate our messages effectively.
A group of vendors lead by Hewlett-Packard and Data General recently
established an industry consortium called the "Object Management
Group" (OMG). Announced on April 19, the group is promoting the
object-management facility in HP's "New Wave" software system.
Members include Prime, Sun, Unisys, 3Com, and Philips. Many other
industry groups and standards organizations are working with
object-oriented technology.
The following partyline statement explains Digital's role in
object-oriented technology and our response to the new OMG.
*********************************************************************
Q: What is object-oriented technology? How does it work?
A: "Object-oriented" is a term applied to many types of software
products and technologies. It is a promising field that Digital and
many other companies are developing actively.
Some people use the term "object-oriented" to refer to anything that
deals with data in an abstract way. Others use the term
"object-oriented" to refer specifically to programming languages,
databases, and tools that fully support the "object-oriented
methodology."
Essentially, object-oriented technology is a way of organizing
information so that information structures are easier to work with.
It makes the development and maintenance of complex applications
easier.
Q: What is the focus of the new Object Management Group (OMG)? Will
Digital join the group?
A: You should really speak to someone in OMG to get their perspective
on the group's charter and focus. Digital is currently evaluating the
group to decide if, how, and when we may participate in their work.
At this point, the primary focus of OMG seems to be application
integration. Digital has been working in this area of technology for
quite some time. Last year, we announced our endorsement of the
Atherton Technology specification for an Integrated Project Support
Environment (IPSE) in the CASE area. In addition, we are involved in
the CAD Framework Initiative, a group focused on integrating
computer-aided design tools. Also, we have announced a Compound
Document Architecture (CDA) that addresses an important part of the
application integration question. Several other industry groups are
working on multivendor application integration, as well.
Digital is committed to providing the tools necessary for our
customers and independent software vendors (ISVs) to integrate
applications effectively.
Q: What's the distinction between object-oriented graphics, compound
document systems, and object-oriented programming?
A: When the term "object-oriented" is applied to graphic systems, it
usually means that graphic elements can be manipulated at an abstract
level. End users of object-oriented graphic systems usually interact
through a graphical user interface.
When the term "object-oriented" is applied to compound document
systems, it often means the ability to deal with graphics, text, and
spreadsheets BOTH as elements of the document AND as independent
entities that can be manipulated in their own unique ways.
When the term "object-oriented" is applied to application or tool
integration, it usually refers to the ability to encapsulate a whole
application so that parts of the interface to that application can be
understood by other software sets without having to understand the
internal workings of the specific application.
Q: We often hear about "object-oriented programming." What does that
term mean?
A: The term "object-oriented" describes a programming methodology
that organizes data and code into objects to simplify application
design and maintenance. In this sense, object-oriented can be thought
of as a step beyond structured programming. Where structured
programming makes software development easier by creating a
methodology of segmenting the application into parts and coding those
parts independently, object-oriented defines how to do the
segmentation.
"Object-oriented" also refers to a set of software development
capabilities (programming languages, development tools, databases,
etc.) that support the object-oriented methodology and are used in
general application development. Examples of object-oriented
languages might include systems such as SMALLTALK and C++.
Object-oriented databases are being developed by many different
vendors at this time. Tools and other object-oriented component such
as database front-end tools are also being developed in many places
today.
Q: HP and Digital are both members of the Open Software Foundation.
Will this new OMG drive a wedge into OSF or force it into competing
camps?
A: Not at all. All OSF members come to the foundation with different
ideas and different approaches. This diversity allows OSF to choose
the best environment possible, based on a careful evaluation of
technological merit. We are certainly committed to the OSF process
and to open systems. If OSF adopts a particular piece of technology,
we will integrate it into our open systems environment. We are
committed to making our ULTRIX operating systems 100 percent
compliant with the OSF specifications.
Q: Is object-oriented technology available now?
A: Tools for developing software that use object-oriented methods are
just starting to find acceptance, particularly in the area of
production software. SMALLTALK, one of the oldest and best-known
object-oriented languages, never really generated a large following
for production software development. C++, new programming tools,
object-oriented databases, and other object-oriented tools are just
now becoming viable.
The marketplace is exerting a tremendous demand for object-oriented
technology today. Object-oriented languages and databases will soon
be applied in a variety of complex application areas, including
computer-aided design (CAD), computer-aided manufacturing (CAM),
computer-aided software engineering (CASE), finance, and so forth.
In addition, many people believe that user productivity will increase
if applications can work together better. For this reason, many
vendors are looking for ways to apply object-oriented techniques to
the problems of application integration.
Many user interfaces, such as DECwindows and OSF/Motif, use
"object-oriented" methods, as do the specific applications that build
on those interfaces. Onscreen widgets, such as scroll bars and
buttons, can be considered "objects" because they combine programming
code and data to represent a useful "thing." End users interact with
these widgets to work more productively.
Q: What is Digital doing in the area of object-oriented systems?
A: Digital is applying object-oriented techniques in a wide range of
areas. We have used them to create tools that we use internally to
design and manufacture our systems. In addition, many of the products
we are currently selling have strong foundations in object-oriented
technology. Our Compound Document Architecture and DECwindows
environment both employ object-oriented methods.
Beyond that, we have conducted a number of advanced research projects
in the area of object-oriented systems for many years. The Trellis
system is one of the most impressive and well-known projects we've
undertaken at Digital. Trellis is an object-oriented language and
programming environment that was designed and developed by our
Corporate Research Group. Begun about seven years ago, Trellis was
created in an effort to improve the productivity of people involved
with the design, development, and maintenance of large, complex
applications. That problem led our researchers to use object-oriented
techniques as part of the solution.
Q: What is Trellis? Isn't it just an advanced research project?
A: Trellis was conceived in our Advanced Research Group. It is
currently available to our customers at no charge for use on any
VAX/VMS workstation. The current license restricts Trellis to
non-commercial use. We ask only that Trellis users share their
experiences with Digital so we can understand how the technology may
be applied in the future.
Trellis has been demonstrated at a number of tradeshows and DECUS
user meetings. It has been very enthusiastically received by the
industry and many technical papers have been published on the system.
Q: Does Trellis compete with C++, SMALLTALK, or any other
object-oriented language?
A: First of all, since Trellis is not currently a "product," it is
not competing with anything. To understand where the Trellis system
fits in the spectrum of object-oriented systems, consider an analogy
to current programming languages, databases, and tools.
Today, in addition to traditional databases and programming
languages, many developers are using fourth-generation languages for
rapid application development and for creating programs that require
high-level facilities and tight integration to a database. This type
of system (fourth-generation language) does not replace traditional
programming languages, nor does it compete with them. It complements
them. Trellis is analogous to a 4GL in the field of object-oriented
programming. One would still use a programming language, such as C++,
for many programming tasks.
Q: Can you tell me anything more about Trellis? Why did Digital name
it that?
A: The reason we named the system "Trellis" is because it is
essentially a framework upon which one can build libraries and
applications. Part of the Trellis system is a type of library -- that
is, a library of object types that can be reused in the development
of applications.
One could envision extending these libraries to include any
application-specific functionality that's required. For instance,
DECwindows, PHIGS, PDES (a mechanical design standard), and so forth,
could all be implemented as object-type libraries that could be made
available for reuse in any application development.
Q: What kind of customers will use object-oriented systems to solve
real business problems?
A: Object oriented systems are best suited for complex applications
that must be maintained and enhanced over relatively long periods of
time. Object-oriented systems are not limited to any particular
application area. Digital is already seeing customer interest in the
areas of CAD, CAM, CASE, manufacturing, finance, and banking.
Q: Will the advent of object-oriented technology force Digital to
dramatically change its software offerings?
A: No. We've been working in this area for more than a decade.
Object-oriented technology has been around for a long time. Previous
experimental implementations were all very revolutionary, but those
implementations didn't integrate with existing systems. There was no
clear path to preserve existing investments in hardware and software.
Now the industry is taking a much more pragmatic view. We're
interested not only in elegant technology, but also how best to use
it. As already said, we have a large number of products and internal
development programs that use object-oriented technology to one
degree or another.
*********************************************************************
[Note: The section below provides a more in-depth, technical
explanation of object-oriented technology.]
Q: What is an "object"?
A: An object is a computer representation of some "thing," such as a
doorknob, a set of information, or a component of some design.
Object-oriented technology provides an elegant way to define the
relationships between sets of information.
Each object is defined by its
o Conceptual state -- the data values associated with an object.
For example, the "state" of a circle object might include its color
and size.
o Behavior -- the set of functions that can operate on an object.
For instance, the "behavior" of a graphics object might include
rotate, scale, and invert.
o Identity -- a means of referencing the individual presence of
particular object in a field of many objects. For example, in a
graphic image there may be many circles. However, each circle is
unique and each has its own identity. This identity would remain
constant even if some of the object's attributes change.
Taken together, these defining characteristics represent the
"interface" or user view of an object. An important fact of
object-oriented systems is that this external view is separate from
the internal implementation of the object. Therefore, programs and
people can work with objects without having to know how they're
implemented. This "encapsulation" feature of object-oriented
technology helps minimize the interdependencies within applications,
making them easier to maintain over time.
Q: What does the term "object type" mean in the world of
object-oriented technology?
A: Objects are defined as being of particular "types." Every object
of a specific type has the same behavior. In other words, it can be
used in the same way. For example, an application might define an
object type "circle" and a single drawing may contain many instances
of the type "circle."
All the operations (actions) that are defined by the type "circle"
are available for every circle. This means that each circle in the
drawing may have a different internal state. For example, one circle
may be blue, another green. One circle may be shaded and another not.
Yet, they are all fall in the "object type" called "circle."
Q: What does the term "inheritance" mean in the world of
object-oriented technology?
A: The term "inheritance" refers to the relationship between object
types. For example, the object type "circle" may be a subtype of an
object called "closed curves," which in turn may be a subtype of an
object type called "shapes."
In an inheritance scheme such as this, a user may see an operation
called "rotate" defined for any object of type "shape." The user
would simply tell the computer system to "rotate" a particular object
and the computer system would execute the appropriate rotate
operation that that particular object type. For example, the system
would rotate a square in one way, a circle in another way.
While this may seem difficult to understand, the ability to deal with
objects at this abstract level actually makes application development
much simpler.
(end)
|