Re: Eu vs perl
Irv Mullins wrote:
>I found this posted on the perl.porters-gw newsgroup. The
>answer is by none other than Larry Wall himself. Anybody
>beg to differ with him?
*Raises hand.*
I'm responding in part because I *like* Euphoria,
but mostly because I think it's been given a really
bad presentation here...
>simon at brecon.co.uk writes:
>: As seen on today's Freshmeat:
>:
>: Euphoria Programming Language v2.2 for Linux, 32-bit Windows and
>: 32-bit extended DOS. It is simple, flexible, and easy to learn and
>: outperforms all popular interpreted languages.
>: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>--Begin Wall's reply:
>
>Primarily on sieve benchmarks, which of course are terribly representative
>of typical Perl processing. And I do mean terribly...
Hmmm... "primarily on sieve benchmarks". As in, not really
with other benchmarks, such as "typical Perl processing."
Well, since no code or example to support this was given,
I guess I'll have to take your word for it.
>(Of course, you have to expect some level of verbosity from a language
>with a name as long as that. The author of Euphoria obviously doesn't
>carry the gene for carpal tunnel...)
Forgive me, but this is almost pathetic. Let's ignore the fact
that the base for the comment (the length of 'Euphoria') is
just plain silly. Just because one language requires English-
like wording (with clear syntax that, for the most part,
builds on that concept) for its commands, that makes it bad?
You'd think we needed to type "ADD A-VAR TO B-VAR GIVING C-VAR"
to do a simple addition. This "reason" for disliking the
language sounds suspect to me, especially considering that
further on down you seem to want people to think more like
humans than computers (and we all know Perl is infinitely
more human-readable than Euphoria...)
>: but for an interpreted language, it's damned quick.
>
>It's quicker on that problem for several reasons. One, it has integer
>declarations. (You should try the perl with a "use integer".) Two, it
>doesn't really have any strings to speak of, just numeric arrays that
>it pretends are strings. (It's basically a toy language, as far as I'm
>concerned.)
??? Numeric arrays that it pretends are strings? Hmm...
lemme see... strings... numeric arrays... um, I take it
you don't do much C programming? (And just for the
record, since Euphoria manipulates text as sequences
rather than with optimized string routines, is this
really a point one should raise to try to explain away
the speed of the code?)
>Three, it cheats--it looks to me like it steals a bit from
>each integer cell for something else, perhaps to tell whether it's an
>object pointer instead. That'd be equivalent to us using one bit of an
>SV* to say that it's really an integer instead. (I'm guessing this
>from the documented range of integers, which is -1073741824 to
>+1073741823.)
While I can see why someone might prefer to use a full
32 bits and still get integer performance, how on earth
is this cheating? If anything, it's a credit to Rob's
particular implementation of the language (and the fact
that this can be done, without harming the data, says
a lot too.)
>Another reason their interpreter is fast is because it's tuned for
>one architecture.
Oh brother... you know, you could just write a Perl
interpreter optimized for Intels and compare against that.
If the user is using the Intel platform how is this a problem?
>There are a number of shortcomings in Euphoria from the Perl
>programmer's perspective, not the least of which is the traditional
>comp sci mindset of minimalism.
Traditional? Ooookay... (I suppose RISC chips are
traditional as well, just because they couldn't
cram 1000 instructions onto the first integrated
circuit...)
>Which leads to the attitude that
>programmers should think like computers, not like humans.
???!!! Ignoring the actual idea that Euphoria causes
this (addressed above), I'd like to ask how a
minimalist approach causes it?
Oh wait, I see... you must be a northern Native American.
You're equating human thought with the many synonyms in
human language, such as the dozens (hundreds?) of unique
names that you use for types of snow and shades of white.
Huh? What's that? You DON'T use dozens of words to mean
'snow' or 'white'? Oh, well then I guess the analogy is
shot...
>I'm not saying Euphoria isn't good at what it's good at, but
>it's just not good at much of anything that Perl is good at.
If by 'good' you only refer to comparable execution speed,
this statement has been rendered false by this entire example.
(This isn't to say Perl isn't 'better' at some things.
But again, you only seem to be refering to execution speed,
and even then the statement in it's broad sense is false.)
>it now runs 60% faster than your version, which means it should now
>outrun the Euphoria example. It's also a fifth the size, though of
>course the Euphoria example does globbing for you too. That might take
>another line of Perl. Oh, and I didn't put in the logic for a grand
>total at the end, but that's just another few lines. On the other
>hand, the Euphoria program has to pull in another 489 lines of include
>files to do what it does, so it's really a 598 line program.
??? I suppose when tallying the size of a C program,
you include the code in stdio.h...
(Psst: most people looking at this probably are only
concerned with lines *written*, not lines included in
a standard library or imbedded in the interpreter
binary.)
>Why do language designers persist in thinking that simple languages
>produce simple solutions?
Judging from this, I'd say you've completely misunderstood
the entire point of minimalism, and of many "simple
languages" in general.
> All it does is sweep the complexity of the
>problem under someone else's carpet. They're making the same mistake
>as the Rexx folks.
So, because Euphoria has no built-in (or standard library
function) to peform matrix multiplaction, or to download a
web page, or to send Aunt May an email, that indicates a
mistake?
Hey, maybe this APL idea should be pursued a bit further.
Did you design it? Maybe PL/1? No, come on, be honest. 
>Their web page says, "Just say NO to complicated languages." I say, "Just
>say no to complicated solutions."
Well, if you want all your solutions pre-packaged, and the
applications using those pre-packaged functions to lack the
speed/readability/etc. benefits of Euphoria, more power to you.
It's all a trade off, although as Euphoria's platform base
diversifies, and certain 'kinks' are addressed, I think the
advantages will become overwhelming.
>: But no source.
>
>That is one of the biggest shortcomings. In fact, that's a killer.
>It would appear that for most people, Euphoria is just a temporary
>mental state.
Yeah, it's a killer... which is why all those closed-
source C compilers out there (ala Microsoft) are losing
market share so rapidly.
>P.P.S. I suppose we could make Perl run even faster if we do like
>Euphoria and only distribute binaries for Intel CPUs. Then we could
>write it all in 386 assembly... 
Why don't you? My word, it sounds like you're trying
to make platform optimization a bad thing...
If you feel Perl is superior for certain needs, that's
great. Euphoria's not perfect; it has faults. But to
present Euphoria as an inferior alternative for all Perl
users, especially when such presentation only seems based
on a inadequate knowledge of the language and a personal
dislike of it and the principles it's based on, is just
plain dirty.
Rod Jackson
rodjackson at bigfoot.com
P.S. No, I don't mind having this forwarded....
|
Not Categorized, Please Help
|
|
