Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!transfer!lectroid!jjmhome!smds!rh From: rh@smds.UUCP (Richard Harter) Newsgroups: comp.lang.misc Subject: Re: What does an anti-perl look like Summary: Sundry comments Message-ID: <565@smds.UUCP> Date: 18 Jun 91 06:58:32 GMT References: <16867@helios.TAMU.EDU> <1991Jun05.013632.3198@convex.com> <798@cwi.UUCP> Organization: SMDS Inc., Concord, MA Lines: 85 In article <798@cwi.UUCP>, alan@cwi.UUCP (Alan Wright ) writes: > In article <552@smds.UUCP>, rh@smds.UUCP (Richard Harter) writes: > 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. Well, yes, that is generally the case. > 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. Particular as deadlines grow closer. :-) I think you are right -- the gain I see is that a well designed "higher level" language is easier to write -- line for line of code -- than a traditional compiled 3GL because irrelevant considerations (for the purpose of the code) do not intrude themselves. To give a typical example from C, quite often the most natural way to implement an algorithm is to use pointers into data structures. The pointers have to all be declared and initialized. While this is simple enough it is overhead. I take it as a maxim that any language which does not provide automatic dynamic storage which you do not have to manage is not really satisfactory. > > 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). This is not what I had in mind. You were trying to do something different. What I was thinking of more on the lines of fiddling with minor features and adding gadgets. If you look at the major languages you seen quite different underlying concepts of what the languages are about. Compare, for example, FORTRAN, COBOL, lisp, apl, forth, SNOBOL, and eiffel. You are talking whole different modes of thinking here. My point is that there is a great tendency to elaborate on the mode of thinking that one is famliar with. One, in effect, rewrites C with one's particular pet peeves removed. > > 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. At this point we have settled for parsing at run time (but parsing is very cheap.) This is a one time cost since procedures, once parsed, remain available in parsed form for re-execution. Perhaps later. > 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? Just so. The general notion is that you can create execution frames on the fly which have persistence but which are decoupled. An execution frame is sort of like a light weight process; however from the viewpoint of the OS the execution frames are all part of the same process. From a 3GL program you can start up (or resume) an execution frame which can, in turn suspend itself and pass control (and data) back to the calling program. You can also link 3GL routines into the execution frame via an interface which makes them look like Lakota commands and intrinsic functions. [3GL is an overstatement -- the interface understands C and the interpreter is written in C.] The interpreter expects that there is an underlying shell language that you can pass commands to which is anything that it doesn't recognize as being a Lakota command. The real difference between REXX and Lakota (in this regard) is that there isn't a natural underlying OS such as VM/CMS that Lakota is tied to. (Although AREXX for the Amiga apparently is a happy combination.) The objective here is to be able to have multiple pieces of functionality working together within a common environment. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.