Why Python is like BASIC (and why this is a good thing)

[David Lees]

I have read through this thread and have a few historical comments on
BASIC.
First, the original BASIC circa 1964, which ran on a GE-235 based time
sharing system
was compiled, not interpreted.  So was its successor which ran on a
GE-635 about 2 years
later.  It was a very fast compiler, so that it had the feel of an
interpreter,
but the execution time was better than the interpreters of the day.  It
was much later,
70's I guess, that DEC and later Mr. Gates created interpreted versions
of BASIC.

Second, BASIC was intended from the very start (by Kurtz and Kemeney, it
inventor)
to be used as a teaching language for everyone; College students and
high schools students
In fact if my failing memory serves :) they had an NSF grant which put
those old ASR-33
and KSR-35 teletypes online at high schools using the old 110 baud
acoustic modems.
I have noticed (purely subjective) that people trained in computer
science
tend to look down at BASIC.  If the quote from Edsger Dijkstra is real,
it just
confirms some of the snottyness by CS types. Dartmouth had a time-shared
version of
Algol-60 also available, which was not used particularily heavily.

Third, as pointed out in this thread, BASIC has been wildly successful
if judged by
usage.  It replaced FORTRAN (or was it FORTRAN II, I forget) for
teaching computer
literacy to Dartmouth undergrads.

Fourth (not a pun) little piece of historical trivia.  The original
BASIC evolved as a language and splintered
all over the place.  One of the excellent things I see in Python is the
tight control
of the language evolution.  In the year that I have been intermittently
using Python
I have seen nice improvements in the language, but it is great to see
public discussion
and thought about what will break when changes are made.

Enough rambling.

David Lees


Robin Munn wrote:
> 
> Reading the first few chapters of _How to Think Like a Computer
> Scientist_ (http://www.ibiblio.org/obp/thinkCSpy/ for those who haven't
> heard of this book), I was struck by how Python resembles BASIC in some
> ways that make it a very good language for teaching:
> 
> * Interpreted, so there's immediate feedback. Students can just type
>   'python' at the command prompt and start coding, receiving *immediate*
>   feedback on the effects of what they type.
> 
> * Non-scary assignment and output statements. In fact, Python and
>   BASIC's output statments look identical. "Print" is a natural choice
>   for ease of understanding. Using sys.stdout.write can come later, once
>   students begin to realize that they don't always *want* a newline or
>   space appended to their output.
> 
> * No need to declare variables. Use them and they are immediately
>   created for you, ex nihilo.
> 
> All three of these things make for a very low barrier-to-entry for
> people who've never done any programming before. I'm sure there are
> other similarities as well, that maybe someone else will point out. Of
> course, Python goes beyond BASIC in many ways:
> 
> * NO LINE NUMBERS! Enough said.
> 
> * Rich control-flow statements. Of course, this is available in more
>   modern versions of BASIC, but back when I was first learning to
>   program (at age six, using BASIC), all I had was conditional GOTO. You
>   know, IF condition GOTO line-number. Or, for the advanced students,
>   IF condition GOSUB line-number (I never did understand the necessity
>   for that kind of statement until well after I'd stopped using BASIC
>   entirely and moved to more "modern" languages like... Pascal).
> 
> * Batteries included. This is the big one, which makes Python more than
>   just a toy language suitable for learning. The richness of the
>   standard library makes Python incredibly useful, and I for one would
>   like to see it continue to grow. I understand the concern that people
>   developing Python-based programs for distribution would like their
>   users to be able to run a 100k script without downloading a 10M
>   distribution, but I don't want to see that cause a reduction in the
>   standard library. Instead, we could make make two Python
>   distributions, a "full" install containing everything and a "lite"
>   install containing only the interpreter and maybe -- *maybe* -- a
>   couple of essential modules like os and sys. Then people developing
>   Python programs like, say, a pygame-based game, could distribute a
>   single package containing the "Python lite" distribution, their own
>   code, and any other modules their code depended on -- all in one
>   easy-for-the-end-used-to-install package.
> 
> Anyhow, I hope this helps develop some ideas.
> 
> --
> Robin Munn
> rmunn at pobox.com