Re: DiskBrowser Software - Work In Progress

To: Bill Buckels
On Sat, 20 Sep 2008 05:23:04 -0500, Bill Buckels wrote:

The Mind plays its own strange tricks when writing in BASIC (as well as any
programming language:) Regardless, combining multiple statements on the same
line degrades the readability of any program regardless of language.

Sometimes readability isn't important. Sometime executable size and
speed is more important.

Back in the '80's when I moved away from BASIC with line numbers to compiled
BASIC with sub-routines and functions, it had long become my personal
preference to avoid using semi-colons because I absolutely hated needing to
decipher one-liners.

BASIC programmers use colons. C programmers were the ones with all the
semi-colons. At least in BASIC, colons are optional but in C they are
required at the end of almost every command. :-)

Deciphering one-liners is easy seeing as there is no branching at all.
It is simply one command executed after another.

By that time I already wrote my BASIC programs (as well
as my C and ASM programs, and all my other programs) first in Wordstar in
non-document (text) mode, then in a programmer's editor. The program was
first written in its entirety then tested and polished and not just thrown
together in a haphazard manner.

Every program starts in a "haphazard manner" and is then sorted out by
subsequent rewrites and debugging.

Personally, I prefer to debug small sections of code at a time rather
than the entire thing at once.

I also commented my code, and followed standards, planned my programs, and
polished the finished work before sharing it. Readability was a big issue
with me and still is.

Comments and readability are important if you are planning on sharing
your source code and also to help yourself if you end up going back to
the code after a long time. With Applesoft, there is nothing stopping
you from keeping a nicely formatted and commented source code listing
with single statements per line while having the version you actually
execute have multiple statements per line. See below for reasons why
you might want multiple statements per line.

However, having mellowed a little with age, I now begrudgingly acknowledge
that non-career programmers who write in BASIC with line numbers and use
semi-colons and write programs ad-hoc and add lines and statements as an
after-thought have a right to create unreadable spaghetti-code.

Everyone has the right to write their code the way they want including
what language they want to program in. Line numbers, multiple
statements per line, ad-hoc programming, unreadable source and spaghetti
code are not limited to just BASIC. A lot of the C source I've seen has
been hard to read not because of the style the programmer used but
because the statements are cryptic.

FOR I = 1 TO 10
statements
NEXT I

makes more sense to me than:

for(i=1; i =< 10; i++) {
statements;
}

To make matters worse, if there is only one statement after the C
version of the FOR command, you don't need the { and } to enclose it so
there is no visible indication that it is connected to the FOR statement
other than it being the next line in the source.

Not to mention that it is also easier to type in the BASIC version as
you don't need to hit shift at all unlike the C code which needs shift
to produce the (, <, ), { or }. :-)

They are victims of the computer manuals and the computer manufacturers like
Apple, IBM, and cbm who used semi-colons to save paper when listing example
programs, and who by literally setting nothing but bad examples created a
worldwide monkey-see-monkey-do epidemic of sloppy unreadable code.

There were sometime other reasons to put multiple statements on one line
and it didn't necessarily make the programs sloppy or unreadable. One
reason is to save typing because it would be a lot less typing to
separate each of a bunch of commands with a colon rather than separating
each of those commands with enter followed by a 1 to 5 digit number.

Programmers who use multi-line statements where they do not add to the
readability of a program should be pitied and not scolded. But then I am
sure that others feel the same way about career programmers who feel
strongly about the minutae of style and standards:)

There are reasons to put multiple statements on one line. One reason is
to save memory. When you are talking about an interpreted language like
Applesoft, every line number takes two bytes of memory and has a two
byte pointer to the next line. So if I write some code to initialize
some variables and the screen like this:

10 TEXT
20 HOME
30 D$ = CHR$(4)
40 F$ = "TESTFILE"
50 R% = 1
60 MR% = 100

This will take 12 bytes for the line numbers and 12 bytes for the next
line pointers which totals 24 bytes but if I rewrite it like this:

10 TEXT : HOME : D$ = CHR$(4) : F$ = "TESTFILE" : R% = 1 : MR% = 100

Only 2 bytes are used for the line number and only 2 bytes are used for
the next line pointer and I've only added 5 bytes with colons for a
total of 9 bytes which means I've just saved 15 bytes of memory.

Another problem with lots of line numbers in Applesoft is the more
numbers there are the longer a GOSUB command will take to find the line
number to execute. When Applesoft encounters a GOSUB it starts at the
first line of the program and checks to see if the line number is the
same as the GOSUB command's. If it isn't, it continues to the next line
and keeps checking until it finds a match or errors out when it runs out
of line numbers to check.

A common way to speed up execution of frequently used subroutines was to
put a GOTO as the first line of the program to jump over all your GOSUB
subroutines so that they could have low line numbers and be found
quicker.

Let's just say that I share the same personal preference and strongly agree
with you. Your preference would seem to be a good one.

At present, for my Windows programming, I use a structured and compiled
BASIC so I only use single statements per line. The language supports
putting multiple statements on one line using a colon to separate them
but I never use it because it is a compiled language and the source and
executable are completely separate. This line:

A = 1 : B = 2

would compile to the exact same thing as these two lines:

A = 1
B = 2

and I find it easier to find where I set the B variable if it isn't
after another statement.

Applesoft is another story, though.
.

Relevant Pages

  • Re: UML Question (Object <-> ObjectFinder?)
    ... It also seems to me that the formality of one's language ... >the problem space one is defining constraints on behavior sequencing ... >> emulate the computing environment of those languages. ... Any language that can execute has some underlying assumptions about ...
    (comp.object)
  • Re: OS Threads behavior
    ... > might run at higher priorities than your threads. ... >>I care about it, since I need it, "This answer is so famelies in Microsoft ... >> heavy tools in this language, the language does not support Hardware ... it's the OS the one who decide which thread to execute. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Stylistic note on loops
    ... happen due to violating some stylistic rule, ... multiple statements, they can put them back in. ... terms of readability and screen space) save more than the effort needed to ... well, more specifically, about language style and debating over language ...
    (comp.lang.java.programmer)
  • Re: An Observation
    ... there is a problem) is that CHAR doesn't always execute. ... In a reasonable language, it should be clear which "noun" an "adjective" like CHAR modifies, and the syntactic relationship shouldn't change depending on some implicit state. ... So when newbies encounter Forth, they get stuck on elaborate stack gymnastics. ...
    (comp.lang.forth)
  • Language for ubiquitous computing
    ... I am writing to know your views on a language that can support ... 8/16/32 bit embedded platform or a high end PC/Server platform. ... for diverse h/w platforms and s/w on it to cooperatively execute tasks ... We also need some advice on the bytecode to C compilation - especially ...
    (comp.compilers)