Re: Eu vs perl
- Posted by Everett Williams <rett at GVTC.COM> Dec 07, 1999
- 369 views
Irv Mullins wrote: >From: Raude Riwal <RAUDER at THMULTI.COM> > > >> I can answer one SHORT thing on this thread: >> Take a lambda user. >> give him Half an hour the euphoria documentation. >> give him Half an hour to read the perl documentation. >> ask him to write a program. >> with euphoria he does the job. >> with perl he gets out to drink a guinness. > >OK, I agree, Perl does have that _one_ advantage... >but the code only begins to make sense after 3 or 4 Guinnesses. > >Irv Which proves that the Perl coder had no taste to begin with...Guiness?! The one thing that is made crystal clear by the examples offered is that Euphoria is highly readable while performing at a similar level to Perl. Any mildly experienced programmer could read the Euphoria example without any reference to any documentation. If I am any sample, the same cannot be said for the Perl code. The objection about includes as opposed to compiler embed is a performance issue at best and a complete canard at worst. The availability of some of the functionality that Perl has by whatever means is probably the only really valid issue here. Standard libraries for what IMHO are standard functionalities in this modern world are not an option, but a necessity. Clean calls to external functionality where there are no standard libraries are a workable stand-in. Portability taken as a whole is approaching necessity in this world of fragmenting OS and hardware standards. Perl has met these requirements and so has progressed despite it's manifest ugliness. I cannot believe that given anything close to equal facilities that Euphoria would not swiftly displace Perl or almost any other language that I have seen. The one blind spot that would trip this little scenario is the doctrinaire, silly attitude toward string functionality. As we approach a fully real-time, interactive world, the strings that form the languages that we use for normal, everyday interaction with each other will also become the interface for our interaction with our machines. Any language that cannot deal comfortably - naturally - intuitively with this reality will fall into disuse. What is so almost amusing is that the language itself, Euphoria, is most effective in providing understandable strings for the interface between machine and programmer. If this approach could be extended to string functionality in dealing with the data that is handled by these programs, no limits would be found to the use of this language. I am sure that any Euphorian solution to string handling will be in the oh so delicate terms of Mr. Wall "verbose". But, with a little thought, this can be kept to a minimum while retaining the readability and overall efficiency of Euphoria. A little verbosity would be oh so preferrable to the delimiter soup represented by Mr. Wall's Perl samples. For example, a simple overloading of present operators can account quite effectively for most of the simplest needs and is actually already in place if strings were a recognized, enforced data type. Everett L.(Rett) Williams rett at gvtc.com