Is there a programming language that is combination of PythonandBasic?

[Chris Jones]

On Sun, Apr 19, 2009 at 04:35:27AM EDT, Hendrik van Rooyen wrote:
>  Brian Blais   wrote:
> 
> >On Apr 18, 2009, at 5:44 , Hendrik van Rooyen wrote:

> >>to untangle some spaghetti code.  He did not mention if the
> >>spaghetti was actually doing it's job, bug free, which IMO is the
> >>only rational test for the quality of a piece of code, because it is
> >>the reason for its existence.  The aesthetics are, like all
> >>aesthetics, a matter of opinion.

> >Actually, I strongly disagree with this statement.  In my experience,
> >there has been very very few pieces of  code that I've written that I
> >hadn't wanted to *modify* at some point: extend it to a new set of
> >circumstances,  cover a different case, change the output, etc...
> >The quality of a piece of code is not just if it works right  now,
> >but if you can reasonably extend it for the future.  

+1 .. obfuscated code never remains bug-free for long.

> Your experience is different from mine - in what I mostly do, which is
> struggling around in embedded assembler, by the time the thing "works"
> it is stable, and I very seldom have to go back to fiddle with it. 

Intellectually, assembler programming is the less demanding since its
level of abstraction does not go any further than mapping a few binary
numbers to a small set of usually well-chosen mnemonics. 

Unless it features a powerful macro-language that lets the apprentice
create his own high-level patois on top of the assembler, that is.

> On the other hand, I understand what you are talking about, but I
> think that the origen of the frustration that one feels when having to
> battle with some old code, is actually inside oneself - the code is
> the same, but I have changed, and I am no longer the same as I was
> when I wrote it.

> >I toyed with Perl for a year or so, but couldn't give it my full
> >attention.  As a result, every few weeks when I wanted to modify what
> >I wrote, I had to re-learn the code all over again because the syntax
> >was so terse.  The same is true for the typical use of a goto: you
> >have to relearn the program, because the flow jumps around.  It's not
> >just about aesthetics, but about being able to work with a piece of
> >code.

> In my defense of the goto, I would like to make clear that I do not
> support its use to produce spaghetti.  In general, muddled thinking,
> coupled with expediency, is what I think are the true precursors of
> spaghetti code.  The goto is an innocent tool that can be used for
> good or evil.

How true.

At least goto's have the merit of naming their target.

I have dealt with C code built on the original author's partiality for
200-line+ nested loops where it looked like every other line or so was
either a "break" or a "continue", goto's without the name that don't
clearly state where they are going.

Thank goodness he was not familiar with setjmp/longjmp.

:-)

CJ