Re: Euphoria features
jiri babor wrote:
>Everett L.(Rett) Williams wrote:
>
>>Building the pieces for peeking and poking is so foreign to
>>Euphoria's intent.
>
>Everett, it's extremely difficult not to be sarcastic when confronted
>with such definitive statements, such deep insights, especially
>considering your limited experience with the language.
Sarcasm, from you, I will take...even if ill founded.
>>At least, inline assembler is highly efficient and isolatable to the
>>scope of a procedure. The inline assembler can be made more readable
>>and efficient by giving it access to Euphoria variables local to the
>>procedure. It also avoids call overhead where efficiency is the major
>>goal. It's final advantage is, that it is explicit.
>
>First of all, we haven't got it. And I will probably spend the rest of
>the night awake, puzzled how assembly code is more readable and / or
>more explicit (!) than a bunch of peeks and pokes. If you want any
>number of examples of horribly inefficient assembly, written by mere
>dabblers, just ask - I wrote some of them.
And I a few thousand more. What I meant was that given explicit named
data structures describing bits, bytes and double bytes as well as words,
inline assembler, where necessary for efficiency can refer to existing
named data items rather than machine addresses. With those data
structures available, the majority of those peeks and pokes would become
unnecessary.
>Your 'portability' tack is likely to impress only the very impressionable.
>I am not one them. If you want portability, switch / go back to C.
It seems that Rob is among the impressionable because he is porting the
language to the Linux environment. I kinda thought that opened up the
subject of portability as a legitimate item for discussion.
>(BTW I do not understand why the vast majority of this congregation
>seems to hate C so much. Ignorance? (this will make me even more >popular..)
>After all, it is a remarkably simple, elegant language, a bit too
>terse for my taste, but with very few flaws and still unsurpassed for
>its power in the right hands. And it all started way back in the early
>seventies and is still going strong. - Please notice, I am not
>including C++, a monstrosity, I believe *no one* completely understands,
>not even its parents).
Agreed and agreed...except for that part about C being a simple and
elegant language. I'd have to hold that one at arms length...at least in
comparison to Euphoria. C's flaws are in style rather than substance.
It is, as you say, powerful and portable...and I would add stable,
efficient, and highly optimized to that group of compliments. I got involved
in a proposed port of C to some logic composed of AMD bit-slice
hardware in the early 80's.
>Enough! Stop! - Sorry. jiri
If by "stop" you mean quit advocating a future that I think is attainable
with very little real effort...never. You are certainly free to ignore any posts
that I make, though I would hope that you would not do that. When it
comes to things like goto, I will go down with the ship on that one. Goto
is an abomination that has cost me more hours than almost any single
item that I can think of. Ralf, callow youth, has probably never seen a
14,000 line assembler program that had to be split into two or more pieces
to be handled by most of the editors of it's time(1974). It should never
have existed, but it did, and it was not in my power to change that fact.
Since branching in 360 assembler does not have too many structured
forms outside of BALR, goto was the rule there and is the rule in
most assemblers. One can design structured branches with macros and
I did, but there was no standard, generally available set of macros that
accomplished that goal...the objection being that they slowed things
down. Never mind old ghouls and ghosties. I have not seen any language
that goto improved unless it had no mechanism for otherwise controlling
flow(early EasyTreve). Even that, since it was seldom used for programs
longer than 100 lines(and could generate complete, selective reports in
that span) was not particularly difficult to control with If's, especially if
one spent a few seconds considering how to structure the If's before
starting to code.
Too the future,
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
