Jump to content
IGNORED

Line Numbers Considered Harmful


kisrael

Recommended Posts

Bonus points to anyone who caught the reference in the title without reading the article...

 

I definately don't want to tell people what they must do, but it's a historical issue; there's a famous quote by cranky old Dijkstra:

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

And I think he's mostly talking about line numbers (He also wrote the famous Go To Statement Considered Harmful.)

 

Now I think he's full of crap, but I despite their retro-feel, I think people, especially newbies, should be made aware that 0.2 Batari BASIC lets you program without line numbers, and there are some excellent advantages (with a small number of minor disadvantages) to doing so.

 

Advantages to No Line Numbers:

* Much, MUCH easier to insert new code, no tedious renumbering by hand

* No counting by tens, hoping there's enough room

* You can remove a line without scanning the rest of your code to ensure there are no GOTOs try to jump to it.

* You can give chunks of code meaningful labels. You can add in text labels anywhere, whether it's a seperate subroutine , goto location, or just a section of your main loop (you can label parts of a main loop with REM statements, but "goto moveplayer" doesn't need a REM to tell you what it's up to, unlike "goto 1200")

* One of batari BASIC's stated purposes is to help people ramp up to assembly programming, and assembly uses no line numbers. Many parts of writing in bB resemble coding ASM in macros, and removing line numbers helps that connection.

* Come to think of it, higher level languages don't use line numbers either, so it's worse traning for programming at lower levels as well as higher levels

* All these things mean it should be muche easier for someone to examine your code and see what it's up to--including your future self.

 

Advantages to Line Numbers:

* Keepin' it real with that ol'-school 8-bit numba flava!

* It's slightly easier to give "code patches" -- I made a suggestion for F-4, and I have to admit giving lines with line numbers was easier than saying "insert this line after this other line" to make sure the code ended up in the right place in the flow

* Some folks find it a bit easier to "order" their thoughts.

* Right now with quirks in the bB code parser it might be easier to make lines that choke the parser (like a line consisting of nothing but a space)

 

But since the initial release was line numbers only, and since old school BASIC was stuck like that, I'm really worried that people won't see how much easier learning to live without line numbers can be.

 

On a similar note, USE THE DIM STATEMENT TO GIVE YOUR VARIABLES MEANINGFUL NAMES! "A this, Q and R that"...ugh! "dim buttonIsUp=u" means you can say "if buttonisUp = 1" which is much clearer than "if u=1"

 

Batari, I know you prefer to code using line #s but maybe we could consider including both a line #d and a no-line-# version of sample.bas in the documentation? If/when I get to coding some tutorials, I'm going to try to set people down the path of a line number free existence.

 

I think the code to NECG Drumma is an ok-ish example of life with labels for code blocks and variables rather than line #s and A-Z. It's never easy to read someone else's code (especially if they're lazy about comments, ahem) but I'm confident that 6 months from now I'll be more able to figure out what this code is up to than I would be if it were written old-school.

Link to comment
Share on other sites

Eh, I may switch to labels after Solar Plexus, but I'm definitely not rewriting its code to take advantage of them. I was given the impression early on that Batari BASIC could ONLY handle numbers rather than labels.

 

As for Dijkstra (I'd pronounce it "Dick-stra"), I'd like to see how he reacted to Logo, the fad programming language of the early 1980's. Who needs the relative versatility and ease of use of BASIC when you can steer around a turtle with a piece of chalk stuck up its butt?

 

JR

Link to comment
Share on other sites

It's not that line numbers are 'bad', its just that they aren't necessary. What they are really is an ordering specification and also a label. You don't need the ordering, as thats provided structurally in the text itself, and if you have a general capability to put a label on a line ( for use with goto ) then you don't need mandatory labels on every line.

 

Goto's are not bad, when used correctly. The only really warranted use, in a language that has other basic control structures, is to provide error jumps out of deep conditionals. If the language has exception throw/catch, then there is no reason at all to ever use a goto.

Link to comment
Share on other sites

Yeah, I also would avoid line numbers like the plague. They make it difficult to move code around and are completely unnecessary if you are able to use labels. It's been a long time since I've had to use a language (BASIC or otherwise) that required me to put numbers in front of each line. I suggest for anyone starting out with Batari's BASIC to avoid them at all costs!

 

..Al

Link to comment
Share on other sites

In programming the 2600, don't you need to use a lot of JMP's since JSR's will eat into your 128 bytes of RAM? Isn't this why a lot of the Activision games have a spaghetti structure to the code? I have heard that you have to unlearn all the rules of good programming with the 2600. Or is a JMP not exactly the same as a GOTO?

Link to comment
Share on other sites

Its pretty much the same...but assembler doesn't have sophisticated control structures such as if/then/else, while, case, function calls, etc., and so the use of JMP is very much justified and in fact necessary.

 

As far as 'unlearning rules of code', you are forced into that by the very extreme conditions in the 2600 environment. There's no point in trying to complain about code structure if your pretty little program doesn't fit.

Edited by danwinslow
Link to comment
Share on other sites

In programming the 2600, don't you need to use a lot of JMP's since JSR's will eat into your 128 bytes of RAM?  Isn't this why a lot of the Activision games have a spaghetti structure to the code?  I have heard that you have to unlearn all the rules of good programming with the 2600.  Or is a JMP not exactly the same as a GOTO?

897074[/snapback]

Yes, JSR's do use some RAM, but you can use them in bB as long as you don't nest them too deep. Three levels deep, I think, is the current limit. A JMP is exactly the same as a goto in bB.

Link to comment
Share on other sites

* It's slightly easier to give "code patches" -- I made a suggestion for F-4, and I have to admit giving lines with line numbers was easier than saying "insert this line after this other line" to make sure the code ended up in the right place in the flow

It was also either here to say "Error in line 20" for instance. I think the next version will need to echo the whole line.
* Right now with quirks in the bB code parser it might be easier to make lines that choke the parser (like a line consisting of nothing but a space)

I think I've got a working preprocessor/tokenizer in lex now, so this should go away.

 

* crosses fingers

 

Batari, I know you prefer to code using line #s but maybe we could consider including both a line #d and a no-line-# version of sample.bas in the documentation? If/when I get to coding some tutorials, I'm going to try to set people down the path of a line number free existence. 

\

896951[/snapback]

I'll probably write an actual game sometime - I think it's becoming terribly ironic that the sample is still the most complicated program I've written in my own language :ponder:

Link to comment
Share on other sites

* It's slightly easier to give "code patches" -- I made a suggestion for F-4, and I have to admit giving lines with line numbers was easier than saying "insert this line after this other line" to make sure the code ended up in the right place in the flow

It was also either here to say "Error in line 20" for instance. I think the next version will need to echo the whole line.

If the code does not contain line numbers, I would include the number of the line in the file that the error occurred on. This is what most compilers do, and it's trivial to jump to a specific line number in most editors (especially any editors geared towards programming). Echoing the whole line is also useful, but having a line number that I can jump directly to is much more useful. :)

 

..Al

Link to comment
Share on other sites

* It's slightly easier to give "code patches" -- I made a suggestion for F-4, and I have to admit giving lines with line numbers was easier than saying "insert this line after this other line" to make sure the code ended up in the right place in the flow

It was also either here to say "Error in line 20" for instance. I think the next version will need to echo the whole line.

If the code does not contain line numbers, I would include the number of the line in the file that the error occurred on. This is what most compilers do, and it's trivial to jump to a specific line number in most editors (especially any editors geared towards programming). Echoing the whole line is also useful, but having a line number that I can jump directly to is much more useful. :)

897094[/snapback]

Makes sense... Currently it doesn't count lines in the file - I'll try to change this so it can output something more meaningful. I'll also have to change the lex preprocessor around since it currently eats blank lines and so the line count isn't properly preserved.

Link to comment
Share on other sites

Eh, I may switch to labels after Solar Plexus, but I'm definitely not rewriting its code to take advantage of them.  I was given the impression early on that Batari BASIC could ONLY handle numbers rather than labels.

0.1 that's true, but 0.2 was a big leap ahead in turns of no line numbers, code labels, variable labels, and white space parsing.

 

As for Dijkstra (I'd pronounce it "Dick-stra"), I'd like to see how he reacted to Logo, the fad programming language of the early 1980's.  Who needs the relative versatility and ease of use of BASIC when you can steer around a turtle with a piece of chalk stuck up its butt?

Well, having a little bit of history makes it a bit more pallatable.

He wrote that in 1975, and it was probably a bit tongue-in-cheek. The culture wasn't BASIC on cheap computers most families could afford, it was being taught in colleges as a starter language. And for most of the same reasons I suggest for bB, it is not a great thing to form people's minds around.

 

Re: Logo....I dunno if you know, but Logo is essentially the well-respected (if usually very academic) language "Lisp" minus the parentheses and plus the turtle. One respected guy, Paul Graham, wrote what became stores.yahoo.com in Lisp, and he feels it gives him this weird edge.

 

But really, the difference between Logo vs BASIC that you mention actually parallels the relationship between Lisp vs C/C++ and Java; the former feel like toys or school languages, the latter feels like the languages to get "real stuff" done in. BUT THAT'S USUALLY NOT BECAUSE OF THE LANGUAGE ITSELF, really -- it's because of the libraries of functions provided. BASICs tended to have things to draw directly to screen, read input in real time often, and make sounds and what not. Logo had...the damn turtle. It's those functions that give BASIC its "ease and versatilty", but Logo had some better ideas...the idea of making a library of functions you can call is quite powerful, and makes easier to edit programs that the line number prison of old school BASIC.

 

 

Goto's are not bad, when used correctly. The only really warranted use, in a language that has other basic control structures, is to provide error jumps out of deep conditionals. If the language has exception throw/catch, then there is no reason at all to ever use a goto.

 

Actually the article I linked to excuses assembly in terms of GOTO:

I became convinced that the go to statement should be abolished from all "higher level" programming languages (i.e. everything except, perhaps, plain machine code)

 

In terms of programming 2600, usually you have one big old GOTO for a main loop, and then I tend to use it as a way of getting things done. I actually shunned JSRs because of the RAM and my perception of performance issues, and even minimized JMPs, and was surprised to see source code listings of "real atari programs" back in the day where the main loop was a big sequence of JSRs.

Link to comment
Share on other sites

I actually shunned JSRs because of the RAM and my perception of performance issues, and even minimized JMPs, and was surprised to see source code listings of "real atari programs" back in the day where the main loop was a big sequence of JSRs.

897300[/snapback]

 

Well, some programs end up using much less than 128 bytes, in which case one enjoys such luxiries, and some programs end up using more than 128 bytes, in which case one pinches out RAM usage anywhere one can, even doing things like using one-bit flags to indicate which of two places called a routine.

 

My SuperCharger minigame actually ended up with an unbelievable amount of ZP-RAM left over; until today (when I traded a boatload of ZP-RAM for a few bytes of code) I had almost 64 bytes of ZP-RAM left. It is funny some of the tradeoffs that one makes in such circumstances. For example, my code had a few 'lda $F000,y" instructions, so I used two bytes of RAM to hold the constant $F000 so I could use "LDA (f0ptr),y" instead. Took two bytes of code to hold the constant, and saved a byte of code each time it was used.

 

If I need to free up two more bytes of code space, I have a couple of 4-byte tables I could move to RAM, thus saving a byte off the reference to each.

Link to comment
Share on other sites

I'll come right out and say it : LOGO blows. So does Lisp, but at least you can actually write programs in Lisp, if you are masochistic enough. Forth is for engineer nerds who think FORTRAN 77 is too high level, Smalltalk is for liberal flannel wearing publishing geeks, Java is for abstraction wonks who like to make up phrases using odd words like 'facade' to describe perfectly ordinary comp sci stuff from 30 years ago that they have just now 'reinvented', C++ is for overly caffeinated control freaks who will argue for hours about inheritance and then go write it in crappy C syntax anyways when nobody is looking, assembler is for wierd ninja-geeks who sit around in dark rooms mumbling about cycles, straight C is for power tripping egomaniacal maniacs who would rather spend twenty hours rewriting ALL of your code BECAUSE YOU DID IT WRONG rather than spend an hour learning to use something somebody else wrote, Pascal is for teachers who flunked out of English class but still wanted to pretend to be superior.

 

And Basic? Basic? BASIC?

 

Basic is for the rest of you.

Link to comment
Share on other sites

Heheh...nice rant, mind if I use it on my blog? ( http://kisrael.com/ )

 

As for logo...the Atari 8bits had an EXCELLENT version, with 4 turtles and a lot of audio/visual stuff. Oh, and the turtles looked like turtles, not triangles...a little too cutesy, but it let me make some fun virtual acquriums (plus you could set up daemons to react to collisions and stuff...very cool for the time.)

Link to comment
Share on other sites

I'll come right out and say it : LOGO blows. So does Lisp, but at least you can actually write programs in Lisp, if you are masochistic enough. Forth is for engineer nerds who think FORTRAN 77 is too high level, Smalltalk is for liberal flannel wearing publishing geeks, Java is for abstraction wonks who like to make up phrases using odd words like 'facade' to describe perfectly ordinary comp sci stuff from 30 years ago that they have just now 'reinvented', C++ is for overly caffeinated control freaks who will argue for hours about inheritance and then go write it in crappy C syntax anyways when nobody is looking, assembler is for wierd ninja-geeks who sit around in dark rooms mumbling about cycles, straight C is for power tripping egomaniacal maniacs who would rather spend twenty hours rewriting ALL of your code BECAUSE YOU DID IT WRONG rather than spend an hour learning to use something somebody else wrote, Pascal is for teachers who flunked out of English class but still wanted to pretend to be superior.

 

And Basic? Basic? BASIC? 

 

Basic is for the rest of you.

897568[/snapback]

Where does COBOL, Visual Basic, Java fit in all this?

Link to comment
Share on other sites

They all blow too.

 

Actually, I took care of Java already. Visual Basic is a mutated form of Basic produced by dissolving Sinclair ZX81's in exotic chemicals in vats in Microsoft headquarters and is thus cool. COBOL? Thats for boring people who just want to sit around and like, make money.

Link to comment
Share on other sites

They all blow too.

 

Actually, I took care of Java already. Visual Basic is a mutated form of Basic produced by dissolving Sinclair ZX81's in exotic chemicals in vats in Microsoft headquarters and is thus cool. COBOL? Thats for boring people who just want to sit around and like, make money.

897666[/snapback]

COBOL? man I haven't heard that language in years. I even took it in college back in the 80's.

Link to comment
Share on other sites

Here's some others I have worked with :

 

PL/1

JOVIAL

ALGOL

SNOBOL ( really )

MUMPS

ADA

GMAP

BCPL

 

 

200 geek points if you know what any of these acronyms stand for, without googling. 100,000 GP if you know them all.

897733[/snapback]

Dude, you're hardcore!

I think PL/1 is just "Programming Language One". (Actually I think that's what the "L" is in most of those) And I know a bit about the others, like ADA was the department of defense thing.

 

And COBOL was great for makin' money right around Y2K...

 

Anyway, I'm reposting your rant on my site, attributed of course....hope that's ok....

Link to comment
Share on other sites

Here's some others I have worked with :

PL/1

JOVIAL

ALGOL

SNOBOL ( really )

MUMPS

ADA

GMAP

BCPL

897733[/snapback]

 

Most people here have probably seen this already, but there is a languages timeline which shows what happened to all of these languages. For example, BCPL became B and then C. Perhaps we should ask to get batari basic added to the lineup :)

 

Chris

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...