RE: Wiki for and at Euphoria
- Posted by Cuvier Christian <christian.cuvier at insee.fr> Sep 04, 2006
- 610 views
> 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