Re: Eu vs perl

new topic     » goto parent     » topic index » view thread      » older message » newer message

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

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu