Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!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: <796@cwi.UUCP> Date: 13 Jun 91 17:40:01 GMT References: <16867@helios.TAMU.EDU> <1991Jun05.013632.3198@convex.com> <541@smds.UUCP> Organization: CaseWare, Inc., Costa Mesa, CA Lines: 82 In article <541@smds.UUCP>, rh@smds.UUCP (Richard Harter) writes: > Most of the articles on the ap thread have expired here; in particular I missed > the original article that sparked the exchanges. Byron, I gather, dislikes > the style of Perl and would like, so to speak, an anti-Perl, even if he has > to write it himself. This is really a lang.misc topic, so I've added that > as a group. 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. > 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.... > like Perl there are a number of perfectly reasonable alternatives, among > them TCL, Python, and Icon. There is also Lakota, which I am a principal ... and we sell one called Accent. (Actually, it comes bundled with another product.) > developer. [Apologies to all who fuss about people talking about their > own work duly made. My justification is that I want to talk about the > language design issues, which are of general interest to those who are > interested in language design issues.] ditto. 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). > 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). Initial development of such a language can be done in only a few months. If there is much interest in the result, then the additional work to polish and distribute the language is justified. The key issue here is how to generate interest. We would probably give away Accent if people wanted it, but new languages seem to be responded to with nothing but negativity and criticism. I think there is plenty of room for many more very-high-level languages, which do not require substantial learning to use effectively. Languages like Perl, Accent, and perhaps Lakota only take hours or days to learn thoroughly, and thus pay for this effort very quickly. 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! 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 worng with discussing it at length in this forum.