RE: Wiki for and at Euphoria

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

> Date: Sun, 3 Sep 2006 10:57:39 -0500
> From: "Kat" <kat12 at coosahs.net>
> Subject: Re: Wiki for and at Euphoria
> 
> 
> > posted by: Jeremy Peterson <ptl99 at hotmail.com>
> > 
> > It sounds like a good addition to the site to me.  
> > 
> > All we need is for Derek and Vincent and a few others to say that it
> > will totally ruin Eu's future and Rob will have it up and 
> running in a
> > day or two :).
> 
> Ok, i'll chime in then: the php msg board was implicated in bringing 
> down Karl's Bach site. I prefer the email listserv and existing web 
> archive.
> 
> Kat
> 
> http://www.davar.net/PROGRAM/EXTRACTS/GO-TO.HTM
> 
> 

Wikis are attractive, granted. But who will migrate the ton of existing
knowledge currently scattered in the archive to a wiki? 

About the bottom link:

My own experience with goto is that, when you start coding something, they
are simpler to use.

As you go ahead and the program has a larger number of flow paths, you
always wind up having to know where most every label is reached from. Hence,
the gotos start being complemented with flags to tell about this, which have
to be maintained in a consistent state, raising the number of bugs and
maintenance costs (time is a cost) significantly.

This is why I tend to prefer using the specialised structure constructs in
the first place. Once you have used a goto, changing the organisation of
your code becomes much harder. 

It is not necessary to abolish it. goto is very useful when you fine tune
some code for performance. Well, wait, that was true on older processors.
Modern pipelined chips are optimised for linear (possibly out of order)
execution, and jumping around can cause a penalty that greatly offsets the
performance gains you thought you achieved. Branch prediction is fine, but
does it reallly help enough? I am not quite sure.

Some kinds of program, mostly those who run finite state machines, would
seem to benefit from goto. This is specially true when the routine calls are
implemented throug hthe stack, of course. But all languages don't do that,
among which Euphoria (if I correctly read a comment in execute.e). And only
Intel processors have stacks if I remember correctly.

To sum it up, I think more structured constructs are useful, sorely needed
in Eu, and will be implemented more efficiently than goto because they can
be implemented differently according to the target architecture, and use
parallelism, stackless routine calls, hyperthreading, etc as appropriate and
available.

goto is good in assembly language. I am not sure it is that good in a
structured language. I'm sure it is harmful in a large program ith complex,
varied flow paths. The reasons are different, as elaborated above.

CChris

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

Search



Quick Links

User menu

Not signed in.

Misc Menu