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 Message-ID: <552@smds.UUCP> Date: 14 Jun 91 07:34:50 GMT References: <16867@helios.TAMU.EDU> <1991Jun05.013632.3198@convex.com> <796@cwi.UUCP> Organization: SMDS Inc., Concord, MA Lines: 118 In article <796@cwi.UUCP>, alan@cwi.UUCP (Alan Wright ) writes: I am going to address the following PS first: > P.S. Richard, I would like to hear more about Lakota. In case you are not > going to sell it for profit, I see nothing wrong with discussing it at > length in this forum. 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 present anyone reading this who wants a beta site copy can get it for the asking. In view of this, the usual Usenet caveats are relevant. My view is that it is permissable and valid to discuss Lakota in the context of language design issues, e.g. "I took this path and made these decisions for these reasons". That seems to me be fair and legitimate; my interest is in discussing what should and shouldn't be in languages and what they are good for. If people disagree, I'll hold my peace. > In article <541@smds.UUCP>, rh@smds.UUCP (Richard Harter) writes: .... > I also missed the beginning of this thread, but I would like to know what > Byron (or anyone else) has in mind for an anti-Perl. By the by, I'm not knocking Perl; that was Byron. > > Byron, you don't want to do it. It's more work to develop a language than > > one might imagine, particularly if it is to be a good one. If you don't > I have to disagree. I think more people should be experimenting with more > languages of this general flavor. These very high-level interpreted > languages become more usable and more practical as hardware gets faster > and faster. Of course, it would be helpful if one has a source of funding > or some guaranteed revenue from the result.... There is much to what you say. Actually, even without the hardware speedup factor it makes sense. 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. 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. 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. .... > ... and we sell one called Accent. (Actually, it comes bundled with another > product.) > Our background is as follows: > Some three years ago, we used Perl to prototype a product. When we shifted > to developing the production verson, we decided we still wanted to use > a very-high-level interpreted language with dynamic strings, arrays, tables, > etc.... We did not want to use Perl, because we didn't want the compile > phase at runtime, nor could we deliver source code. So we designed and > implemented Accent, which has the following substantial differences from > Perl: > - 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 > 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. 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? > > The main point I would like to make is that it is not such a simple thing > > to design and implement a language, particularly one which is to have > > strong string manipulation capabilities. > Could you elaborate on this (especially on why you think string > manipulation is a significant problem). That was somewhat of an overstatement on part that was conditioned by the particular issues that I was trying to address. If you are in a typed language with string variables you can do quite nicely with the usual collection of string manipulation utilities and operators if you are only concerned with strings as the content of variables. However if you permit the dynamic creation of variable (and procedure) names things get interesting. If one is going to allow multiple levels of substitution and the inclusion of arbitrary characters one has to be fairly careful. > To sum up, I would like to see more variations on the Perl theme. More > 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? -- 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.