Hacker News Reader

Comment by tinalumfoil | Hacker News Reader

Although I learned to program past when it was popular, I can't shake the feeling that BASIC is the best way to teach programming. The basis of any computer is the sequential execution of instructions, and it's this model of computation that informs things like algorithmic complexity or Turing completeness. Even if teaching BASIC wasn't possible, I would still prefer to see a subset of x86 assembly taught than something ridiculous like "a simpler C" which obscures the core functionality of a computer with abstractions, without teaching a practical language.

View on HN

These days the sequential execution of instructions is a convenient lie at most.

BASIC is one way. But you can also start with 'How to Design Programs' approach and start with Racket (http://www.ccs.neu.edu/home/matthias/HtDP2e/Draft/index.html).

> sequential execution of instructions is a convenient lie at most

Could you expand? Obviously some processors reorder instructions and try to do things in parallel, although this isn't true everywhere and the model of sequential instructions is still valid.

Instruction reordering, branch prediction, speculative execution, and optimizing compilers would all be examples of details that are abstracted over by the model of sequential instructions.

"Lie" might be too strong of a word, but "simplification" would be accurate. And sometimes that abstraction is leaky.

Not to anyone working in BASIC.

And probably more importantly, they're implementation details: you can't feed a modern processor out of order instructions, the entire system is built and optimised to efficiently execute sequential programs (but possibly several of them concurrently).

Depends on the BASIC. Some varieties are compiled and have modern optimizations.

> And probably more importantly, they're implementation details

Well, right, programming languages are abstractions built on top of the actual implementation.

Yes, BASIC is an abstraction that hides eg instruction re-ordering. But if you are working with abstractions anyway, then imperative programming loses that claim to a privileged position.

The funny thing about BASIC is that it's MUCH closer to assembler (and, by extension, the logic of the CPU) than any other language. It gets a lot of flak for GOTO's and the like, but that's how you control logic flow in assembly. C is an abstraction that allows you to avoid control statements like GOTO and every higher level language just abstracts more away from you (memory management, static variables, strongly typed variables, etc)

>The funny thing about BASIC is that it's MUCH closer to assembler (and, by extension, the logic of the CPU) than any other language.

I agree that flow control with GOTOs, GOSUB and CALL is the closest to assembler, as well as line numbers slightly resemble how you place machine language code in memory (sequentially), however there are things in which BASIC (the classic line-number basic) deviates significantly:

1. Memory management is automatic in BASIC; in particular strings; string variables have automatic memory management; they can grow or shrink with no problem, you don't need to manage the memory.

2. The only way of allocating memory in basic is when you DIM an array; and then this memory block can't be FREE'd, because there's no "free" instuction, nor the option to DIM another array in the same memory location. (Typical BASIC gives no pointer manipulation facilities).

3. BASIC is often implemented as a strongly typed language. Even the syntax requires differentiating strings from numeric variables by virtue of the first character ($). There's no option to do declare a (void * ) variable and thus operate with total freedom from type checks, as it's possible in C. C is notoriously weakly typed, just as machine language is!

4. BASIC data types are higher level: Strings aren't really a data type in K&R C language -- what you have is character arrays that with some functions can be interpreted as null-terminated strings. Then you have integers and floats whose length (bit-width) or sign (unsigned, signed) you can't specify at all in BASIC.

There's also another significant deviation, if only for theorical considerations:

5. Machine language is arguably homoiconic: It is concerned with manipulating binary data (words), yet the language itself is made of such data (words). So machine language allows, for example, writing self-modifying code, code introspection, etc. BASIC is far from homoiconic.

I, personally, find C much closer to machine language (and thus, Assembler) than BASIC, for the reasons above, basically: manual memory management (via pointers), weakly typed and optionally untyped (via void* pointers and implicit casts), and it is geared towards manipulating data in the format that the CPU likes to (i.e. 32 or 64-bit integers, floats supported directly by the CPU, etc.)

Most "modern" (as in, late 80s on) BASIC dialects let you REDIM or ERASE an array.

Yep, for example Turbo Basic.

Yes, but my reply is to a person who advocates BASIC as closer to assembly language. In this context, "BASIC" ought to be understood as Ye Olde Line-Number, Unstructured programming, BASIC, not the well featured, structured programming Turbo Basic or Quick Basic...

... which, by the way, i enjoyed using a lot when I was a kid.

BASIC is pretty good. I went from that to 6502, then to 680x0 and then to C (then to FORTRAN and then right back to C). I had a fair number of co-workers (years later, you know, when I had a job) who struggled more than a little bit with pointers. They said that they never got them. I re-read K&R to refresh my memory as to the clarity of the author's exposition on the topic and found it crystal clear. I suspect that if I hadn't gone through assembly first, I might have had problems with pointers too?

It might be snobbery, but it seems as if amongst computer programmers, there are those who "get" pointers, and those who do not. For whatever reason - I surely have not figured out how to explain pointers to those who do not "get" them. But I have found that this divide does simplify the software developer interviewing process down to only a couple of short technical questions.

I knew some C before taking an assembly language class (and I'm young enough that assembly never came up as a thing to learn before hitting higher-level languages). I understood pointers (mostly), but the concept was still a little confusing, and I'd have to consider the correct syntax every time I needed to use them.

Years later, I started doing things like writing an NES emulator and reading disassemblies of DOS games. Function calls, their relation to the stack, and pointers in general became much clearer after having contact with that much assembly.

> I surely have not figured out how to explain pointers to those who do not "get" them.

Makes me think about the difference between the data being represented and the method of representation. Sure, an exe's a binary, but it's also a data file if I choose to interpret it that way.

Had precisely the same experience except it was for an Apple II project instead of NES emulation. Turned me into one of those a-holes who think everyone should start with assembly if they want to learn C.

I think there at least needs to be more instruction about how the language is implemented. I feel like I learned the use of the stack in function calls and the difference between stack and heap variables disturbingly late.

I found programming in C on a very small device with primitive memory management made that distinction abundantly clear. Heap variables are the ones that leak memory!

Heh, it’s slightly ironic you use the sequential programming model as the basis for modern computing when that’s less true each year, both at the language and the instruction level. A better way to term it would be interleaving data dependencies and computation.

Heh, in some ways llvm ssa is the closest you get to a natural programming language for the modern processor.

Reply on news.ycombinator.com