Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!orion.oac.uci.edu!ucivax!cwi!alan
From: alan@cwi.UUCP (Alan Wright )
Newsgroups: comp.lang.misc
Subject: Re: What does an anti-perl look like
Message-ID: <798@cwi.UUCP>
Date: 16 Jun 91 16:37:16 GMT
References: <16867@helios.TAMU.EDU> <1991Jun05.013632.3198@convex.com> <552@smds.UUCP>
Organization: CaseWare, Inc., Costa Mesa, CA
Lines: 101

In article <552@smds.UUCP>, rh@smds.UUCP (Richard Harter) writes:
> 
> Well, we are sort of on the gray edge here -- Lakota is proprietary to SMDS.
> I am a principal in SMDS.  We are using it internally; at some point it
> may be marketed at a nominal price consistent with financial reality.  At

You may find that the best you can do prior to some large following
developing is to literally give your language away. Further, the
prevailing attitude is that it must be available in source form.

> There is much to what you say.  Actually, even without the hardware speedup
> factor it makes sense.

I agree, I just think some of the traditional performance-related objections
to interpretive languages are now less relevant. 

> In most applications most of the execution time is
> spent in a small percentage of the code.  Write that 5-10% in C or whatever.
> It is my contention that a good high-level interpreted language is several
> times more expressive than a traditional 3GL.  Grant me a factor of 5, i.e.
> it takes 5 times as much 3GL code to do what you can do in the interpreter.
> A good high level interpreter should run about 2-3 times slower than the
> equivalent 3GL code.  For example:  suppose you have an application that
> has 100,000 lines of 3GL code.  10,000 lines accounts for 90% of the CPU
> usage; 90,000 accounts for 10%.  Replace the 90,000 by 18,000 lines of
> interpreted code.  The result is a program that has 28,000 lines of code
> and runs 10-20% slower.  The development time drops sharply.  These are
> reasonable tradeoffs.

I agree with your reasoning here, but my experience shows that not only
do you achieve higher productivity via such languages, that you also
tend to implement more generality, flexibility, and other such
qualities with the more expressive language. I suspect that a general
rule here is that the more code a programmer has to write, the more
corners (s)he will tend to cut. 

> However my point was really that it is not so simple to develop a general
> language that is a signifigant improvement on what is already available.

It is not simple to successfully popularize one, but it is NOT difficult
for many of us to try. I suppose it may be a lot like writing a hit song.
It is difficult to predict what features will have strong appeal. 

> There is a psychological trap involved, a tendency to say "I use and
> like X, but it could be a lot better so I am going to create my own
> language Y."  The result is X with a bunch of extra miscellaneous features.

Not necessarily. For example, there is really no resemblance between
Perl and Accent. The reason for this is that Perl was designed for
one niche (system administration?), while our needs were somewhat
different (production CASE software prototyping and development). 

> > 	- declarations and strong type checking
> > 	- functions, modules, and classes
> > 	- remote function calls (as easy as local calls)
> > 	- high-level (i.e. dynamic) first class data structures:
> > 	  (strings, arrays, tables, composites
> > 	- table keys can be any data type (just as values can)
> > 	- more palatable syntax (derived from C, Pascal, and others)
> > 	- portable source and object code

I forgot one:
		- simple API for graphical user interfaces (for X, Sunview, ...)

> > In short, we added what we thought were good software engingeering
> > features, so that we could write production code (and in large quantity). 
> 
> That's a fairly impressive collection of features.  It reads like a full
> blown modern OOL.

Our notion of classes is not well enough developed to qualify as a
real OO language. This is actually more a matter of how we limited
our present implementation than a syntactic issue. 

> I gather from your comments about a compile-phase for
> Perl at runtime that you can parse an accent program in advance and execute
> off of a representation of the parsed program.  Is this correct?

Yes. Parse once, execute multiple.... Also, we can deliver one object code
for all of our platforms.

> > languages to test various combinations of features. (Yes, I am aware of
> > Icon, Python, Rexx, and others, but I don't like any of them).
> > This technology is still far from providing the final solution, so we
> > need to keep trying!
> 
> I am curious.  Why don't you like them?

I should rephrase: I don't feel they are well suited for my
applications.  I could provide an analysis of each, but instead let me
just say that the set of features we ultimately put into Accent were
some of the features I wanted.  I think you'll find that each of these
other languages (let me add Scheme, Smalltalk, ABC, TCL) really was
designed with a different use in mind, or is missing some key feature,
or has some critical misfeature. (No vendor support is a critical
misfeature.)

Now, back to the topic of Lakota. I remember seeing something you posted
in the past which suggested to me that Lakota was perhaps more like a
REXX than a Perl. What I remember is something about controlling the
interactions among a set of subordinate tool processes. Is this correct?