Is there a programming language that is combination of Python andBasic?

Mensanator mensanator at aol.com
Sat Apr 18 14:41:04 EDT 2009


On Apr 18, 4:44 am, "Hendrik van Rooyen" <m... at microcorp.co.za> wrote:
> "baykus" <b...... at gmail.com> wrote:
> > I guess I did not articulate myself well enough. I was just looking
> > for a toy to play around. I never suggested that Python+Basic would be
> > better than Python and everyone should use it. Python is Python and
> > Basic is Basic. I am not comparing them at all. I understand the
> > merits of Python but that does not mean I can play with ideas?
>
> Apparently this is not allowed by the CS thought police.
>
> The reasoning is based on an Argument from Authority,
> namely the Dijkstra link.
>
> Now it looks to me when I read that article, that the jump
> is deprecated because it leads to code that is difficult to
> understand, which was based on the difficulty that Dijkstra
> had to construct a "co-ordinate system" for storing the state
> of a program at any given line of code.  This was done
> without giving any reason as to why this should be important,
> or even desirable, except towards the end where he wanted to
> define instances in time when a count could conceivably be
> off by one, and he asserted without proof that having jumps
> in the code makes this more difficult.  Even if this assertion
> were to be provably true, it does not really follow that jumps
> should be banned, but merely that one runs such a risk if one
> were to use them.  Now to some minds, this "difficulty" may
> not be a difficulty at all:
>
> Processors and interrupt service routines are storing the state
> of multiple programmes at arbitrary points in the code, even
> as I type - and every one of those programmes include jumps.
> It is a non - issue.
>
> Mensanator had the same complaint based on difficulty
> earlier in this thread, when he described how he struggled
> 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.  

Oh, the bugs were there, alright. But they tended to be very
subtle, so much so the original author must not have noticed them.
For instance, a players AGILITY attribute affected the player's
probability of hitting the monster he was attacking. This AGILITY
attribute was altered by the quality of the player's armor, heavier
plate armor being more adverse than light leather armor.

In most situations, the adjustment is made once at the start of
the game. Rarely is armor donned or removed during the course
of the game. But it does happen in some games. I wrote one
in which the player is captured and whatever armor he started
the game with is taken away and part of his quest, in aggition to
finding his way out of the dungeon, is to recover all the
artifacts he entered the game with (which are hidden throughout
to encourage wandering all over the layout).

One of the symptoms of the spaghetti code's jumping around instead
of doing subroutine returns was failure of the armor algorithm to
properly adjust the AGILITY when armor is removed. The result was
that AGILITY was only ever adjusted downwards, and never restored
if it was taken off. If the player then subsequently donned it again,
AGILITY would be further reduced.

The same type of subtlty occured with monster COURAGE. Any monster
(including the friendly ones who fought on your side) that didn't
have a COURAGE rating of 100 was supposed to flee the room if a
certain level of damage was taken. Again, because of goto screwups,
such behaviour was rarely seen. Once corrected, it happened quite
frequently, so much so that it affected the overall game itself.

With the entire dynamic of the game beig very different, desingers
estimates on how many monsters to place in a given scenario were
all incorrect.

> The aesthetics are, like all aesthetics, a matter of opinion.

Game design isn't just a matter of aesthetics.

>
> I do not agree with the reasoning that effectively says:
> "If it is difficult to comprehend, it must be wrong"

A programmer once said to me "Why should I run it, I know
how it works, I wrote it."

My reply: "You only THINK you know how it works. _I_, on
the other hand, ACTUALLY know how it works because I've
run it."

>
> If this were to be a tenet, then using the pickle module
> should be forbidden too, as it is a complex piece of
> code that (to me at least) is not easily understood on a
> first read-through.
>
> So does that mean I must stop using pickles?
>
> All Strength to Arnaud for his goto code!
> I am looking forward to the gosub and return.
> :-)
>
> - Hendrik




More information about the Python-list mailing list