Why doesn't JavaScript have a goto command?

[electrician]

Perl has it, Basic has it, Fortran has it. What is so difficult about
creating a goto command for JavaScript. Just set up a label and say go
to it.

[web.dev]

el*********@electrician.com wrote:

Perl has it, Basic has it, Fortran has it. What is so difficult about
creating a goto command for JavaScript. Just set up a label and say go
to it.

Javascript does indeed have a "goto" keyword but is just a reserved
keyword.

It is not the matter of difficulty of implementation but rather the use
of "goto" statements that generally leans towards spaghetti code. And
yes, it can also be argued that very conservative use of the statement
can be helpful at times.

Here's a very classic article:

title: Go To Statement Considered Harmful
url: http://www.acm.org/classics/oct95/

[Matt Kruse]

el*********@electrician.com wrote:

Perl has it, Basic has it, Fortran has it. What is so difficult about
creating a goto command for JavaScript. Just set up a label and say
go to it.

There is no logcal need for goto.

The lack of goto forces you to think of the correct way to solve your
problem, rather than relying on spaghetti code :)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Noozer]

<el*********@electrician.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...

Perl has it, Basic has it, Fortran has it. What is so difficult about
creating a goto command for JavaScript. Just set up a label and say go
to it.

Because, if you need to use a GOTO, then you are doing something wrong.

[Jonas Raoni]

Noozer wrote:

<el*********@electrician.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...

Perl has it, Basic has it, Fortran has it. What is so difficult about
creating a goto command for JavaScript. Just set up a label and say go
to it.

Because, if you need to use a GOTO, then you are doing something wrong.

Not at all, sometimes you have to get out of two loops and with a goto
you can achieve this easily, goto is a reserved word, but JavaScript
has labels.

while(confirm("ok?"))
MyLabel:
while(1)
while(1)
break MyLabel;
--
Jonas Raoni Soares Silva
http://www.jsfromhell.com

[Tony]

Noozer wrote:

<el*********@electrician.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...

Perl has it, Basic has it, Fortran has it. What is so difficult about
creating a goto command for JavaScript. Just set up a label and say go
to it.

Because, if you need to use a GOTO, then you are doing something wrong.

Ever program in Assembly?

[electrician]

<There is no logcal need for goto.

The lack of goto forces you to think of the correct way to solve your
problem, rather than relying on spaghetti code :)

So what about those of us that like programming in spaghetti code? Who
are you or the creators of JavaScript to force me to use their
programming concepts? I like Goto and want it and have worked for
hours to try something else when goto would have saved me precious
time. This is another example of academia forcing us to use useless
non productive time to preserve some higher than thou intellectual crap.

[Zif]

el*********@electrician.com wrote:

<There is no logcal need for goto.

The lack of goto forces you to think of the correct way to solve your
problem, rather than relying on spaghetti code :)
So what about those of us that like programming in spaghetti code? Who
are you or the creators of JavaScript to force me to use their
programming concepts?
Someone has a gun at your head, forcing you to use JavaScript? Heck, you
must be one gun programmer.

You can't even be bothered to publish web pages that accommodate
browsers other than IE, why should anyone care about your opinion?

I like Goto and want it and have worked for
hours to try something else when goto would have saved me precious
time. This is another example of academia forcing us to use useless
non productive time to preserve some higher than thou intellectual crap.

But you'd like to force them to implement goto because you want them
too? Because it fits with your concept of programming learned where?
What substantive argument can you provide to show that goto is of any
benefit to JavaScript?

Your 'calculator'[1] stands as a public record of your programming
ability. Claiming ignorance of standards and design principles as a
virtue does not make it so. Did you fix the errors that were pointed
out to you?
1.
<URL:http://groups.google.co.uk/group/comp.lang.javascript/browse_frm/thread/3b545c991e656da6/4355f865f033ecbe?q=How+do+you+stop+a+javascript+pr ogram%3F&rnum=1#4355f865f033ecbe>

--
Zif

[RobG]

Jonas Raoni wrote:

Noozer wrote:

<el*********@electrician.com> wrote in message
news:11**********************@i39g2000cwa.google groups.com...

Perl has it, Basic has it, Fortran has it. What is so difficult about
creating a goto command for JavaScript. Just set up a label and say go
to it.

Because, if you need to use a GOTO, then you are doing something wrong.

Not at all, sometimes you have to get out of two loops and with a goto
you can achieve this easily, goto is a reserved word, but JavaScript
has labels.

while(confirm("ok?"))
MyLabel:
while(1)
while(1)
break MyLabel;

That is not the typical use of goto. A better pseudo-code example would be:

while (...){
if (...) {
goto foo;
} else if (...) {
goto bar;
}
}

foo: { }
bar: { }

But you can achieve the same result without using goto.

goto is long dead. If you want to support it's revival, present a
scenario where it is required, or where it is significantly more
efficient than existing methods.
--
Rob

[Jonas Raoni]

RobG wrote:

Jonas Raoni wrote:
That is not the typical use of goto. A better pseudo-code example would
be:

while (...){
if (...) {
goto foo;
} else if (...) {
goto bar;
}
}

foo: { }
bar: { }
Sure, this is a better example of a goto, but JavaScript has not the
goto statement:

alert(goto = 1);

There's just the label, which is similar to a goto, but just works
together with break and continue.
But you can achieve the same result without using goto.
Sure :)
goto is long dead. If you want to support it's revival, present a
scenario where it is required, or where it is significantly more
efficient than existing methods.

One day you'll need to exit from a two nested loop, in this day you'll
see that a label is useful for something.

I've used the label something around two times, sure I could avoid it,
but it would require extra checking in the inner loop, in this specific
situation I'm all for the labels ;]
--
Now with alcohol <URL:http://youtube.com/watch?v=lnQTZxqxc10> =X
Jonas Raoni Soares Silva
http://www.jsfromhell.com

[Richard Cornford]

el*********@electrician.com wrote:

Matt Kruse wrote:

There is no logcal need for goto.

The lack of goto forces you to think of the correct way to
solve your problem, rather than relying on spaghetti code :)

So what about those of us that like programming in spaghetti
code?

You should not be employed in commercial code development, because you
will be needlessly imposing ongoing costs on anyone you work for.
Who are you or the creators of JavaScript to force me to
use their programming concepts?
How can anyone be forcing you to write javascript at all? But if you
choose to (for reasons of expedience or whatever) it makes more sense to
learn to use the language as it is rather than wishing it was another
throwback to the 1960s.
I like Goto and want it and have worked for
hours to try something else when goto would
have saved me precious time.
The odds are very good that whatever you are trying to do can be simply
done with the constructs javascript already has.
This is another example of academia forcing us to use
useless non productive time to preserve some higher than
thou intellectual crap.

You will find that no new languages will have - goto -, because it
turned out to be a source of considerably more problems than it solved.
Recognising when something is a bad idea and stopping doing it is not
only the preserve of academia. But you are the one wasting time railing
against the way things are instead of learning to cope. That is not very
practical of you.

Richard.

[Tony]

Lee wrote:

Tony said:

Noozer wrote:

<el*********@electrician.com> wrote in message
news:11**********************@i39g2000cwa.googl egroups.com...
Perl has it, Basic has it, Fortran has it. What is so difficult about
creating a goto command for JavaScript. Just set up a label and say go
to it.
Because, if you need to use a GOTO, then you are doing something wrong.

Ever program in Assembly?

These days, I think it qualifies as "doing something wrong".

lol

[electrician]

<<You should not be employed in commercial code development, because
you
will be needlessly imposing ongoing costs on anyone you work for. >>

I work for myself. If I had to hire elite JavaScript programmers that
insist on not using goto I would be out of business.
Yet several of my JavaScript programs are practical and solve very
complicated linear programming models in the electrical field where I
am an expert.
I want a goto statement, because it would make my programming life
easier. I like to spend my time on subject issues, not programming
issues.

<<How can anyone be forcing you to write javascript at all? But if you
choose to (for reasons of expedience or whatever) it makes more sense
to
learn to use the language as it is rather than wishing it was another
throwback to the 1960s.>>

I used the older languges quite efficiently before JavaScript came
along, and I often used goto.
I really do think I will be looking at Visual Basic Script. If it has
a goto I may just goto vbscript and give MS even further credit for out
doing Sun.

I like Goto and want it and have worked for
hours to try something else when goto would
have saved me precious time.

<<The odds are very good that whatever you are trying to do can be
simply
done with the constructs javascript already has.>>

No way! Fortran still has goto and has for longer than most JavaScript
programmers have been alive.
This is another example of academia forcing us to use
useless non productive time to preserve some higher than
thou intellectual crap.

<<You will find that no new languages will have - goto -, because it
turned out to be a source of considerably more problems than it solved.

Recognising when something is a bad idea and stopping doing it is not
only the preserve of academia. But you are the one wasting time railing

against the way things are instead of learning to cope. That is not
very
practical of you.
Richard. >>

And I suppose Perl is not a Modern Language? Perl has a goto.
Furthermore, I really wonder how many of the "modern" JavaScript
programmers know iota about Fortran IV.

[Zif]

el*********@electrician.com wrote:

<<You should not be employed in commercial code development, because
you
will be needlessly imposing ongoing costs on anyone you work for. >>

I work for myself. If I had to hire elite JavaScript programmers that
insist on not using goto I would be out of business.
Insisting on using a language feature that doesn't exist may have made
it difficult to hire any programmer, much less an 'elite'.

Yet several of my JavaScript programs are practical and solve very
complicated linear programming models in the electrical field where I
am an expert.
But your programs have bugs, how practical is that?

I want a goto statement, because it would make my programming life
easier. I like to spend my time on subject issues, not programming
issues.
Obviously you have little time for programming. You don't have time to
fix obvious bugs in your programs and you don't bother to program for
any browser other than IE.

<<How can anyone be forcing you to write javascript at all? But if you
choose to (for reasons of expedience or whatever) it makes more sense
to
learn to use the language as it is rather than wishing it was another
throwback to the 1960s.>>

I used the older languges quite efficiently before JavaScript came
along, and I often used goto.
I really do think I will be looking at Visual Basic Script.
Please do - your pages only work in IE anyway. Your programs contain
bugs and errors, the more their distribution is restricted the better.

I really do think I will be looking at Visual Basic Script. If it has
a goto I may just goto vbscript and give MS even further credit for out
doing Sun.
Sun? They own the JavaScript trademark, their involvement in the
development of JavaScript has been minimal. Or are you getting confused
with Java? Java doesn't have goto either.
[...]
<<The odds are very good that whatever you are trying to do can be
simply
done with the constructs javascript already has.>>

No way! Fortran still has goto and has for longer than most JavaScript
programmers have been alive.
FORTRAN must keep goto for backwards compatibility, the fact that it
continues in the language does not indicate that it is essential for all
programming languages.

Here's an article written in 1968 titled "Go To Statement Considered
Harmful":

<URL:http://www.acm.org/classics/oct95/>

About the author:
<URL:http://www.cs.utexas.edu/~EWD/>

[...]
And I suppose Perl is not a Modern Language? Perl has a goto.
Furthermore, I really wonder how many of the "modern" JavaScript
programmers know iota about Fortran IV.

You have previously said that you don't need to learn anything about
standards or design principles to write JavaScript programs, why should
your opinion on any programming subject be taken seriously?

Perl was first released (version 1.0) in 1987, so it is almost as old as
Windows. FORTRAN IV was released in 1966. Is the age of an idea the
sole criterion for whether it is better than some other idea?

Has there never been a new idea that was better than an old idea? Maybe
Newton saw further because while standing on the shoulders of giants he
kept his eyes shut tight.

--
Zif

[Voodoochile]

I work for myself. If I had to hire elite JavaScript programmers that
insist on not using goto I would be out of business.
Yet several of my JavaScript programs are practical and solve very
complicated linear programming models in the electrical field where I
am an expert.
I want a goto statement, because it would make my programming life
easier. I like to spend my time on subject issues, not programming
issues.
Ive just got to chime in here. Im also a self taught programmer (for
the past 12 years), and I also used to be an electrician (which turned
out to be a huge benefit when it comes to debugging and QA, by the
way).

At first I had no small amount of sympathy for you, in the calculator
thread; you ran head first into a bunch of egos. But now you come back
for more, and Im not sure why you expected anything different, unless
thats what youre looking for...

The thing is, a programming language is just a tool like any other; a
hammer, an EMT/Rigid bender, the law, a fork, spoken languages, shoe
horns...all tools. Which tool you use and how you use it depends on
what it is you want to do.

As was allready pointed out, goto is not used much anymore because of
the problems that arise when it is abused. I know you work relatively
alone and run a small site, but the reality is its not with programmers
like you in mind that language features are decided upon. The vast
majority of software is developed by groups and teams of developers,
many of whom never see each other, so features that tend to be abused
and thus make a language unreadable by anyone coming along later
usually get frowned upon. With the advent of the web, scalability is
also a huge concern; your app may run fine on the desktop with one
user, but collapse when 200k people all access it at once.

Havent you ever gone into a panel and wondered "What the hell was this
moron doing? Its going to take me forever to straighten this out" as
you look at the 220 feeds and dont see brown yellow or orange anywhere?
Kinda like that. Doesnt it piss you off when the guys who did the new
construction obviously didnt give a rats ass about the guys who had to
come along and make repairs/maintain things later on? (Can you say
Union Labor?)

If you had to run, oh, half inch EMT from one side of a room to
another, the walls being 10 feet apart - you cant go accross, only
around - that means two 90s...do you also complain that you have to put
a box in between? I mean, its only 20 feet, what a waste of your time,
right? But there are reasons ~why~ you have to put a box between, arent
there? What would you say to an impatient helper who said screw it and
bent and strapped the run with no box in the middle? (Id say YOU pull
the damn wire, then make him rip it out and put in the box). Also to
the point, why are you supposed to put a loop in the wire in the box?
Is it so you can do your job faster, or is it so the guys who open it
up later on can do theirs safer?

My long winded point is that there are many many priorities being
balanced in the evolution of any programming language. Its not all
about initial dev time, its about future maintenance time, scalability,
learning curve, etc etc etc. And languages ~do~ evolve; goto is just
proving to be unfit for survival. Personally I hate it with a passion,
but then Ive spent a lot of time in the past as a maintenance
programmer. ;) Its dissappearance is just Darwinism as far as Im
concerned.
This is another example of academia forcing us to use
useless non productive time to preserve some higher than
thou intellectual crap.

While Im not going to argue with you that those ducks are in the sky
oftentimes, in this case I think youre shooting the old man standing
next to you with a hellava lot of salt shot. Dont let youre anger at
the pomposity, self importance and pretension you find here prompt you
to write code that in the future may bite you in the ass.

Eric

[Tim Streater]

In article <11**********************@j33g2000cwa.googlegroups .com>,
el*********@electrician.com wrote:

<There is no logcal need for goto.

The lack of goto forces you to think of the correct way to solve your
problem, rather than relying on spaghetti code :)

So what about those of us that like programming in spaghetti code? Who
are you or the creators of JavaScript to force me to use their
programming concepts? I like Goto and want it and have worked for
hours to try something else when goto would have saved me precious
time. This is another example of academia forcing us to use useless
non productive time to preserve some higher than thou intellectual crap.

You are a fathead, aren't you (as we saw in your other thread). The goto
leads to unmaintainable spaghetti code, and as was pointed out in the
other thread, it becomes untestable too, so you can't guarantee its
gonna work properly in all conditions.

FORTRAN has a goto, he says. Sure - and I stopped using FORTRASH in 1978
- and that's also the last time I used a goto statement.

You need to get it into your thick skull that this has nothing to do
with "academia". It's called engineering. I want my software to:

1) work
2) be maintainable
3) be extendable

Spending some time making it properly structured and clean ("designing"
it might be the pompous academic word to use here snoot snoot) will pay
dividends down the road.

I once spent several hours working through some "spaghetti" code only to
find the klod had used a Fortran computed goto to implement subroutine
calls. So several pages of code could suddenly be condensed into perhaps
half a page. Buggered if I'm ever going to do THAT again.

-- tim

[Tim Streater]

In article <du*******************@news.demon.co.uk>,
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote:

el*********@electrician.com wrote:

I like Goto and want it and have worked for
hours to try something else when goto would
have saved me precious time.

The odds are very good that whatever you are trying to do can be simply
done with the constructs javascript already has.

Not just "very good", Richard. An odds-on certainty, a shoe-in, the only
horse in the race with four legs, etc etc.

-- tim

[Tim Streater]

In article <11**********************@i39g2000cwa.googlegroups .com>,
el*********@electrician.com wrote:

<<You will find that no new languages will have - goto -, because it
turned out to be a source of considerably more problems than it solved. And I suppose Perl is not a Modern Language? Perl has a goto.
Furthermore, I really wonder how many of the "modern" JavaScript
programmers know iota about Fortran IV.

I once (mid '70s) had to maintain a compiler written in FORTRAN by an
"academic", and indeed to port it to another platform. This turned out
to be quite easy because although he had used the goto (as FORTRAN IV
lacks features), the author had been careful about it - no spaghetti. He
had written it like an engineer would. So places where the FORTRAN
dialects differed between the two machines were limited and clear. This
exercise was at the end of a 10-year period writing in FORTRAN - I
gratefully abandoned it as soon as better languages came on the scene.

-- tim

[VK]

el*********@electrician.com wrote:

So what about those of us that like programming in spaghetti code? Who
are you or the creators of JavaScript to force me to use their
programming concepts? I like Goto and want it and have worked for
hours to try something else when goto would have saved me precious
time. This is another example of academia forcing us to use useless
non productive time to preserve some higher than thou intellectual crap.

<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function demo() {
OUTER: while(true) {
INNER: while(true) {
var msg = 'Do I need to learn JavaScript better and go get some
life?';
var ans = window.prompt(msg, 'Yes');
if (ans.toLowerCase() != 'yes') {continue INNER} else {break OUTER};
}
}
}
</script>
</head>

<body onload="demo()">

</body>
</html>

[bgulian]

Matt Kruse wrote:

There is no logcal need for goto.

The lack of goto forces you to think of the correct way to solve your
problem, rather than relying on spaghetti code :)

Mostly true. Being fairly new to javascript, there may always be a
better way than goto. In C++ however, we often run into this (pseudo
javascript):

for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
goto globalError;
while (this_is_happening)
{
//something goes wrong
goto globalError;
}
}
//something goes wrong
goto globalError
}

globalError:
Something went wrong.
Now, you could use exceptions to achieve the same thing but exceptions
are painful in C++ as they may or may not get bubbled up to your
handler. Are they better in javascript? Barring exceptions though,
the abscence of goto means you must communicate the error to each level
of the nested loop. Worse than spaghetti code, in my opinion.

Bob Gulian

[Dr John Stockton]

JRS: In article <11**********************@j52g2000cwj.googlegroups .com>
, dated Tue, 7 Mar 2006 13:48:44 remote, seen in
news:comp.lang.javascript, Jonas Raoni <jo********@gmail.com> posted :

Noozer wrote:

<el*********@electrician.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...

Perl has it, Basic has it, Fortran has it. What is so difficult about
creating a goto command for JavaScript. Just set up a label and say go
to it.

Because, if you need to use a GOTO, then you are doing something wrong.

Not at all, sometimes you have to get out of two loops and with a goto
you can achieve this easily, goto is a reserved word, but JavaScript
has labels.

while(confirm("ok?"))
MyLabel:
while(1)
while(1)
break MyLabel;

But I see no 'goto' there.

When available, 'goto' always allows a jump from anywhere to anywhere
remotely reasonable; but 'break label' is only for jumping out of [more
than 1] enclosing loop. Those who write 'goto' do not mean 'break
label'.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Lasse Reichstein Nielsen]

"bg*****@gmail.com" <bg*****@gmail.com> writes:

Mostly true. Being fairly new to javascript, there may always be a
better way than goto. In C++ however, we often run into this (pseudo
javascript):

for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
goto globalError;
while (this_is_happening)
{
//something goes wrong
goto globalError;
}
}
//something goes wrong
goto globalError
}

globalError:
Something went wrong.
The better way in this case is a labeled break:

outerloop:
for (i=0; i < limit; i++) {
for (j=0;j < jlimit; j++) {
//something goes wrong
break outerloop;
while (this_is_happening)
{
//something goes wrong
break outerloop;
}
}
//something goes wrong
break outerloop;
}
It uses nothing but the break feature, the general idiom for breaking
out of a loop early. The label is only there to allow you to identify
the loop to break out of if it is not the closes enclosing one, the
break is the same.
Now, you could use exceptions to achieve the same thing but exceptions
are painful in C++ as they may or may not get bubbled up to your
handler.
Don't know exceptions in C++.
Are they better in javascript?
They are fairly simplistic in Javascript. There are no exceptions
classes/types, so you can throw any value, and a catch catches
all exceptions.
Barring exceptions though, the abscence of goto means you must
communicate the error to each level of the nested loop. Worse than
spaghetti code, in my opinion.

I'm not sure where labeled break was first introduced. It existed in
Ada, and is in most recent languages like Java, Javascript and C#.
It's conceptually much nicer than the otherwise equivalent "goto
label just after loop"

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Dr John Stockton]

JRS: In article <11**********************@z34g2000cwc.googlegroups .com>
, dated Wed, 8 Mar 2006 07:56:00 remote, seen in
news:comp.lang.javascript, bg*****@gmail.com <bg*****@gmail.com> posted
:

Being fairly new to javascript, there may always be a
better way than goto. In C++ however, we often run into this (pseudo
javascript):

for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
goto globalError;
while (this_is_happening)
{
//something goes wrong
goto globalError;
}
}
//something goes wrong
goto globalError
}

globalError:
Something went wrong.
Now, you could use exceptions to achieve the same thing but exceptions
are painful in C++ as they may or may not get bubbled up to your
handler. Are they better in javascript? Barring exceptions though,
the abscence of goto means you must communicate the error to each level
of the nested loop. Worse than spaghetti code, in my opinion.

No "must" about it; put both loops in a function, return false for error
and true for success, and test that return result. You could, I expect,
upgrade your C that way too.

Perhaps there is or should be a Web page on obvious constructs and
appropriate codings.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Richard Cornford]

el*********@electrician.com wrote:

Richard Cornford wrote:

You should not be employed in commercial code development,
because you will be needlessly imposing ongoing costs on
anyone you work for.
I work for myself.

You programming colleagues will be pleased to hear that ;)
If I had to hire elite JavaScript programmers
that insist on not using goto I would be out of business.
Last week you were claming your business to be so successful that you
didn't need to worry about supporting more than default configurations
of one browser, this week it is so marginal that you cannot afford to
employ people who have the skill you perceive as necessary (i.e. the
ability to write javascript).
Yet several of my JavaScript programs are practical and
solve very complicated linear programming models in the
electrical field where I am an expert.
I assume that is "solve" in the sense of 'behave as expected when
minimally tested with acceptable inputs', given how easily RobG found
bugs with non-expected input.

One thing that is certain is that your programs will die with you,
because anyone seeing your spaghetti code is likely to prefer to
re-write from scratch rather than commit themselves to the burden of
attempting ongoing maintenance (unless you can find someone particularly
masochistic, or who doesn't know any better themselves).
I want a goto statement, because it would make my programming
life easier.
Only in he sense that it would allow you to carry on 'programming'
without learning to do without goto. But learning to program without
goto is what would actually make your programming life easier. And I say
that as someone who first learnt programming in the days when BASIC had
a number for every line and goto was virtually the only way of jumping
about in a program. I stopped using goto in BASIC with the first version
that had subroutines and found the results considerably easier to code
and maintain.

I quite liked the mental challenge of trying to maintain a consistent
mental model of code written in early BASIC. The more complex the code
gets the bigger the challenge, but the unfortunate reality is that the
human capacity to comprehend complexity is limited and once you go
beyond 2,000 - 4,000 statements the ability to perceive the whole system
in code terms is exceeded, and spaghetti code just degenerates into an
unmanageable mess, getting more chaotic with every addition.

It is dealing with the limited human ability to comprehend complexity
that has forced programming languages to evolve, and they have evolved
in a way reduces large interdependent programs into autonomous units
that are simple enough to comprehend (and vigorously test) in isolation,
and shifts the challenge of comprehending the system up a level (or two)
to the interactions between those now abstracted units.

The intellectual challenge of comprehending 2000 lines of spaghetti
BASIC filled with goto statements transforms into the challenge of
comprehending the architectural and design aspects of the
interrelationships between a few hundreds of objects implemented with
60,000 lines of code. And is, in the end, a more rewarding application
of the intellect and orders of magnitude more productive.

The strategies that make the big, complex, systems manageable make the
smaller programs, that can be implemented in 2000 odd lines of code,
relatively simple. And that is what makes your programming life easier
in the long run.
I like to spend my time on subject issues, not programming
issues.
You are unlikely to appreciate how much time you have wasted on
modifying/maintaining spaghetti code until you have learnt to write
non-spaghetti code (as you will not get to work on code written by
others while you work for yourself and will not employ real
programmers), so you are not really in a position to judge what
proportion of their time is spent on "subject issues" rather than
programming issues by professional programmers.

<How can anyone be forcing you to write javascript at all?
But if you choose to (for reasons of expedience or whatever)
it makes more sense to learn to use the language as it is
rather than wishing it was another throwback to the 1960s.

I used the older languges quite efficiently before JavaScript
came along,

Where is your benchmark for "quite efficiently"? You have not been
working alongside other programmers so how do you know that what your
perceive as efficient is not horribly inefficient by comparison?
and I often used goto.
I really do think I will be looking at Visual Basic Script.
If it has a goto I may just goto vbscript and give MS even
further credit for out doing Sun.
If that is what you want to do, do so. It would be solving the wrong
problem but if you insist upon fixating on an imagined need to use goto
you won't make any more progress with javascript.

I like Goto and want it and have worked for
hours to try something else when goto would
have saved me precious time.

The odds are very good that whatever you are trying
to do can be simply done with the constructs javascript
already has.

No way!

No way? Are you saying that it is impossible to program without goto?
That would mean that all of that code written in Java, javascript and a
host of other recent languages (not to mention older languages that
retain goto but where it would never be used by competent programmers)
doesn't actually work. I think someone would have noticed that by now
and said something.
Fortran still has goto and has for longer than most
JavaScript programmers have been alive.
The vast majority of javascript programmers are older than the language
is, many will be younger than Fortran. But a programming language being
old is not in itself a good thing, lessons have been learnt from what
has gone before, and one of the drawbacks of the older languages that
have been updated is that they tend to retain features for no reason
other than backwards compatibility, while new languages get to ditch the
dross entirely.

This is another example of academia forcing us to use
useless non productive time to preserve some higher than
thou intellectual crap.

You will find that no new languages will have - goto -,
because it turned out to be a source of considerably more
problems than it solved.

Recognising when something is a bad idea and stopping doing it
is not only the preserve of academia. But you are the one
wasting time railing against the way things are instead of
learning to cope. That is not very practical of you.

<snip>
And I suppose Perl is not a Modern Language?
No not really, but I said "new languages" anyway.
Perl has a goto.
C++ has goto as well, though you wouldn't expect to see it being used
often, if at all.
Furthermore, I really wonder how many of the "modern"
JavaScript programmers know iota about Fortran IV.

I very much doubt that any 'modern' javascript programmers know how to
set the switches and wire the plugs on an ENIAC, but I don't anticipate
any of them suffering for the lack of that 'skill'.

Richard.

[Randy Webb]

Dr John Stockton said the following on 3/8/2006 5:04 PM:

Perhaps there is or should be a Web page on obvious constructs and
appropriate codings.

There are. Below are at least two of them.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[sam.partington]

bg*****@gmail.com wrote:
(snip)

for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
goto globalError;
while (this_is_happening)
{
//something goes wrong
goto globalError;
}
}
//something goes wrong
goto globalError
}

globalError:
Something went wrong.
Now, you could use exceptions to achieve the same thing but exceptions
are painful in C++ as they may or may not get bubbled up to your
handler. Are they better in javascript? Barring exceptions though,
the abscence of goto means you must communicate the error to each level
of the nested loop. Worse than spaghetti code, in my opinion.

(snip)

No! Absolutely no! This is absolutely the wrong way to do this in C++
or javascript.

Exceptions are not painful in C++, there is no "may or may not" get
bubbled. They WILL propagate. The above code is even less appropiate
in C++ than it is in javascript.

I can think of several ways to solve the above problem :

1. Use exceptions - this is the best way.

2. Break down the complex three level loops into smaller well defined
functions, or use algorithms.

3. If you absolutely can't use exceptions add an error condition into
the loop condition expression -- its not that hard, and its a lot
clearer in intent *.

4. If you are using error codes you can even return a failure error
code in the inner loop. In javascript any resources will be cleaned up
by garbage collection, in C++ your destructors will handle it.

Seriously, if you're writing C++ code like this you need to read up on
some modern C++ style. Try effective C++ by Scott Mayers for starters.

Sam

[bgulian]

sa************@gmail.com wrote:

No! Absolutely no! This is absolutely the wrong way to do this in C++
or javascript...
Thanks to LRN for furthuring a constructive discussion with real code
and an elegant way to solve the problem I stated. Thanks to the rest
of you for the grandstanding, ego polishing, and the usual entertaining
stuff that once in a while imparts some great knowledge. You actually
made me have some sympathy for the spaghetti coding electician.
Seriously, if you're writing C++ code like this you need to read up on
some modern C++ style.

I exampled a code construct that have encountered many times in my code
and other people's code. I am trying to find a way that is better. LRN
gave me one.

Bob Gulian

[sam.partington]

bg*****@gmail.com wrote:

Seriously, if you're writing C++ code like this you need to read up on
some modern C++ style.

I exampled a code construct that have encountered many times in my code
and other people's code. I am trying to find a way that is better. LRN
gave me one.

Look sorry, I didn't want to start a flame war, the thing that annoyed
me was the comment about C++ exceptions being buggy, which is simply
not true, and you made no effort to back up the statement with a
reference or examples.

This has all been covered before, for every new language that comes
along, PHP for example :

http://www.procata.com/blog/archives...9/goto-in-php/

In fact is has become satirical in its use :

http://www.entrian.com/goto/

Its not just an academical holier-than-thou thing, its a prejudice that
has been built up by developers in lots of languages after years of
experience of debugging and maitaining complicated code.

I did offer 4 alternatives to your posted code, here are two of them
spelt out of course they are a bit artificial. The benefits of the
exceptions method being :

- You can't ignore the error.
- You don't need to litter all your functions with return codes.
- Errors can propagate from the lowest level small helper functions
right up to the caller who can do something useful with the error.
- The caller can decide at what level to handle the error.
- The larger the app, the more beneficial using exceptions becomes.

1.
try
{
for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
throw err_code_1;
while (this_is_happening)
{
//something goes wrong
throw err_code_2;
}
}
//something goes wrong
throw err_code_3;
}
}
catch (err)
{
document.write("An Error Occurred: " + err);
}

(or better yet, let the error propagate to the caller, who can
probably do something more useful)
2.
function do_it()
{
for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
return err_code_1;
while (this_is_happening)
{
//something goes wrong
return err_code_2;
}
}
//something goes wrong
return err_code_3;
}
return 0;
}

var err = do_it();
if (err)
{
// whatever
}

[Tim Streater]

In article <11**********************@z34g2000cwc.googlegroups .com>,
sa************@gmail.com wrote:

bg*****@gmail.com wrote:

Seriously, if you're writing C++ code like this you need to read up on
some modern C++ style.

I exampled a code construct that have encountered many times in my code
and other people's code. I am trying to find a way that is better. LRN
gave me one.

Look sorry, I didn't want to start a flame war, the thing that annoyed
me was the comment about C++ exceptions being buggy, which is simply
not true, and you made no effort to back up the statement with a
reference or examples.

This has all been covered before, for every new language that comes
along, PHP for example :

http://www.procata.com/blog/archives...9/goto-in-php/

In fact is has become satirical in its use :

http://www.entrian.com/goto/

Its not just an academical holier-than-thou thing, its a prejudice that
has been built up by developers in lots of languages after years of
experience of debugging and maitaining complicated code.

[...]

Of course its also true that I can write FORTRAN in any language. By
which I mean that any language can be abused and have spaghetti written
in it, goto or not.

I suspect Mr Electrician would complain more about Pascal even though it
has goto, than other languages. The fact it didn't have a return
statement made me abandon it very quickly. In the end I just put a dummy
statement with label 999 at the end of every procedure and goto'ed there
when I needed to return.

-- tim

[VK]

Tim Streater wrote:

I suspect Mr Electrician would complain more about Pascal even though it
has goto, than other languages. The fact it didn't have a return
statement made me abandon it very quickly. In the end I just put a dummy
statement with label 999 at the end of every procedure and goto'ed there
when I needed to return.

I say Sinclair Basic on ZX Spectrum rules - after all this time! GBasic
was not so bad neither - but nothing close to the first one. Starting
with QBasic things started to go to the OOP Hell - and there they are
now :-(

:-D

[Tony]

Richard Cornford wrote:

Fortran still has goto and has for longer than most
JavaScript programmers have been alive.

The vast majority of javascript programmers are older than the language
is, many will be younger than Fortran. But a programming language being
old is not in itself a good thing, lessons have been learnt from what
has gone before, and one of the drawbacks of the older languages that
have been updated is that they tend to retain features for no reason
other than backwards compatibility, while new languages get to ditch the
dross entirely.

Well, I learned on Fortran & Cobol, as well as BASIC. I haven't had a
need to use GOTO for many years, now - pretty much since I started
playing with Pascal, prior to the introduction of C.
BTW - I wonder how the electrician feels about people who wire their
homes themselves, instead of hiring a qualified & competent expert to do it?

[bgulian]

sa************@gmail.com wrote:

bg*****@gmail.com wrote: ..
1.
try
{
for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
throw err_code_1;
while (this_is_happening)
{
//something goes wrong
throw err_code_2;
}
}
//something goes wrong
throw err_code_3;
}
}
catch (err)
{
document.write("An Error Occurred: " + err);
}

Yes, you're right. The above is actually the best way to do it. I
have been wary of exceptions because, at least at one time, lower
levels of exception handling (like in 3rd party libraries) did not
bubble up to my code if the library caught the exception and did not
propagate (throw) it. It made using them a guessing game so even
though they were useful at a local level, it didn't seem worth it for
commecial apps that use a lot of 3rd party apps. Not to mention that on
Windows there has been, until recently, two models of exception
handling to furthur confuse developers.
(or better yet, let the error propagate to the caller, who can
probably do something more useful)
2.
function do_it()
{
for (i=0; i < limit; i++)
{
for (j=0;j < jlimit; j++)
{
//something goes wrong
return err_code_1;
while (this_is_happening)
{
//something goes wrong
return err_code_2;
}
}
//something goes wrong
return err_code_3;
}
return 0;
}

var err = do_it();
if (err)
{
// whatever
}

Well, this is a design issue. Would there even be a relevant error
code if some minute mathematical calculation of an inner loop went
astray? And even if there were, what if you wanted the error message
to use values of all the variables in do_it()? You'd have to pass them
back too, as a collection object or something.

In any case, thanks for replying. For the case I presented, using a
javascript exception is the best route.
Bob Gulian

[VK]

bg*****@gmail.com wrote:

I have been wary of exceptions because, at least at one time, lower
levels of exception handling (like in 3rd party libraries) did not
bubble up to my code if the library caught the exception and did not
propagate (throw) it. It made using them a guessing game so even
though they were useful at a local level, it didn't seem worth it for
commecial apps that use a lot of 3rd party apps.

AFAIK that's the whole idea of exceptions (?). You ready to catch it:-
if you know what to do with the caught stuff, you deal with it without
bothering layers atop of you:- if it's not your cap of tea then you
re-throw it in hope that there is an interested catcher atop.

SomeObject throws Exception1, Exeption2

silently presumes

SomeObject "deals" Exception3, ExeptionN

[Richard]

GOTO was replaced by methods, functions, and classes when programming
languages saw that it was more efficent to build libraries that could be
imported into any project. OOP, Object Oriented Programming, takes using
redunant code and simplifies it by creating an object. This object can
then be called anytime throughout the program the same was as you would
use a GOTO statement. Unlike a GOTO statement the code can that is being
called can reside in outside of the program calling it. When I used GOTO
statements in Basic if I found a function I liked I had to copy and
paste it to another program to be usefull. Also, objects are loaded into
memory once and called when needed and then the garbage collector cleans
the memory when it is no longer needed. A GOTO statement will load into
memory each time it is called making it ineffienct for larger programs
that require large amounts of memory to produce results.

An example of an object would be like creating an apple. You have the
framework for it; red skin, the shape, core, etc.. You use one object to
create a whole bushel even thought they are located on different spots
on the screen they still only access one part of the memory.

*** Sent via Developersdex http://www.developersdex.com ***

[sam.partington]

bg*****@gmail.com wrote:

Yes, you're right. The above is actually the best way to do it. I
have been wary of exceptions because, at least at one time, lower
levels of exception handling (like in 3rd party libraries) did not
bubble up to my code if the library caught the exception and did not
propagate (throw) it. It made using them a guessing game so even
though they were useful at a local level, it didn't seem worth it for
commecial apps that use a lot of 3rd party apps. Not to mention that on
Windows there has been, until recently, two models of exception
handling to furthur confuse developers.
We've only recently started to discover the true benefits of
exceptions. Until recently we used them only as local library specific
exceptions. And our older projects still do. It can be a pain
translating exception types from one library to another, or from
exception to error codes, or vice versa.

In your case, if the third party library did silently catch the
exception, and not notify the caller at all then it seems to be a
design error on the libraries part. Not that assigning blame helps
when you're trying to solve the issue!

But with more recent projects we've used them as part of an application
wide error handling strategy, and it has made our code (which is used
on an embedded device) considerably simpler, with a fraction of the
number of if() {} else {} ... constructs.

But of course exceptions are no panacea and yes it can be a pain when
third party libs throw different types and you need to translate
between them.
Well, this is a design issue. Would there even be a relevant error
code if some minute mathematical calculation of an inner loop went
astray? And even if there were, what if you wanted the error message
to use values of all the variables in do_it()? You'd have to pass them
back too, as a collection object or something.
Tricky one yes. In C++ I'd handle the first one as a derived class of a
more generic mathematical exception class. If the caller cared what
type of exception occurred it could catch that specifically, or if it
didn't care catch the general mathematical case.

I don't know how I'd map that to a javascript design. I guess you could
add sub error code properties to the exception type. Something like

function Error(code)
{
this.code = code;
}

function ErrorWithSubCode(code, subcode)
{
this.code = code;
this.subcode = subcode;
}

For the second problem yes I suppose you'd have to throw a collection
at the end of the loop, which is a bit messy. But then you don't need
the goto anyway because you want the loop to continue until you've
tried all combinations, and completed your list of errors. I'd still
probably use an exception for the inner most loop though, with the guts
of the code taken out into a different function.
In any case, thanks for replying. For the case I presented, using a
javascript exception is the best route.

I'm glad we are agreed with each other. Sorry for being on my high
horse.

sam