Hacker News new | ask | show | jobs
by susam 44 days ago
I remember dBASE IV from my childhood days when my father, who had no computer background, was required to take computer training by his workplace. My father and his colleagues were given free evening computer lessons by their company, taught by the same teachers who used to teach us, the kids, computers in our school.

After their first class, he brought home a fat dBASE IV manual. Since I was very interested in computer books, I read a good portion of it even though I had never touched dBASE in my life. I would daydream of all the little forms, queries, reports and labels I could make with dBASE. But I never got to touch dBASE in my life. We kids used to get LOGO lessons instead in school.

One day my father came back from his evening lesson mildly distressed about something he had learnt. He said they were being taught loops but in the loop there was an equation that seemed just plain wrong. It was:

  i = i + 1
How could that be a valid equation? How could i ever equal i + 1? He mentioned that he had asked the teacher about it and from what I could gather, my teacher and my father were talking past each other. The teacher probably tried explaining that it was not an equation but an instruction instead, whereas my father continued to interpret i = i + 1 as an equation due to the algebra he was so familiar with. It sort of held up the class for a while.

The teacher asked my father's name, perhaps so that he could talk to him separately later. But when he learnt my father's name, he realised that his son, me, went to the same school where he taught. So he told my father, 'When you get back home, ask your son about i = i + 1. He will explain it to you better than I am able to.'

And indeed I was able to explain it to him pretty well. I was eight or nine years old back then. And that was probably the first thing I taught my father!

5 comments

Perhaps this is why BASIC originally used LET in the form LET X = X + 1, to imply a calculation rather than equality.
The = for assignment is FORTRAN’s fault. In the beginning there was no equality, just assignment, and FORTRAN (being just a FORmula TRANslator after all) made the somewhat dubious decision to use = for that (punch card space being sparse and symbols limited and all).

When FORTRAN gained equality it went for .EQ. out of practicality and necessity. Many others followed suit but used the somewhat more pleasant == instead of .EQ..

But it didn’t have to happen that way. ALGOL decided to stick close to mathematical tradition:

= for equality

:= for assignment ("definition")

While x := x + 1 is still not clean mathematical notation, I think it wouldn’t have riled up OP’s father as much. If he’d squinted enough, he might even have been able to see little indices below the x’s there.

> ALGOL decided to stick close to mathematical tradition

And now we have all 3 in Python (=, ==, and :=) which makes me sad.

Splitting = and := in python is very intentional though, It makes writing bugs like this impossible:

    if is_logged_in=True:
        allow_access()
I've got... opinions on the way python separates statements and expressions, but there's some real benefits to it too.
Splitting = and := is intentional, but not for the reason you stated. We could have used := for all assignments from the beginning:

    is_logged_in := True
or

    if is_logged_in := True:
I agree that this would require blurring the statement/expression distinction. You can still do that in a weird way, by disguising your assignment as an expression. This is valid:

    (is_logged_in := True)
The reason it was done that way because := was an afterthought, and making it the assignment operator would have introduced a breaking incompatibility. That lead to having 3 different symbols for 2 use cases (assignment and comparison).
except if := was the default then accidentally typing ":=" instead of "==" would be the easy bug to make.

:= was bolted on after of course, and I think that was a mistake, but no one asked me, nor do I expect anyone to ;P

A rumor I heard was that

  x := 4
was chosen because it looks similar to

  x ⇐ 4
That is indeed the case in Smalltalk.

The Xerox keyboards had the support for ⇐, with its workstation OSes being all graphical based.

When Smalltalk grew beyond Xerox PARC walls, ⇐ turned into :=

You can see this in the original Xerox PARC documents and books for Smalltalk.

In some of the draft versions of ASCII the positions currently taken by underscore and caret were left arrow and up arrow respectively. As late as 1985 I used terminals (LanparScope) the supported the older draft.
All Commodore machines also uses the older ASCII standards, (in addition to filling out the full 8 bit range with various graphics). It’s usually referred to as “PETSCII”, from the original Commodore “PET” series, but PETSCII was also used in the vastly more popular Commodore 64 (and 128) home computers.
But why? := is perfectly understandable and established notation for definition. You don't get closer assignment without resorting to esoteric notation?
Why not <= then? I'd expect both < and = to be available.
Probably because '<=' is very easily read as "less or equal"? (unless you are joking, of course)
I would prefer

x is 5

x is x + 5

But x isn’t x + 5. If anything, it should be “x becomes x + 5”.
Ok. How about

Set x to x + 5

That’s pretty much COBOL syntax: https://www.ibm.com/docs/en/debug-for-zos/17.0.x?topic=comma...

Except that COBOL doesn’t allow an arithmetic expression there, so you have to write

    COMPUTE X = X + 5.
instead. ;)
I would prefer

X is 5

X is x + 5

How do you feel about ADD 5 TO X GIVING X?

I kid, of course, but "X is x + 5" brings Prolog to mind with all the unification and bidirectionality that implies.

> ADD 5 TO X GIVING X

Grammatically, this would not change X. "...GIVING X" would just return X. Since it's part of the same statement, it seems it should ignore the "ADD 5 TO X" part.

Now, if you'd like to place the result into X, I suggest "ADD 5 TO X" would suffice as the entire statement.

Think that was just to make the parser understand it was an assignment without having to do any lookahead. There was also possibly ambiguous stuff with equality and assingment as they both used =.
As kids we had the same debate because we were taught algebra before BASIC, and naturally tried to interpret it mathematically. Fortunately, sometimes a kid can explain it better to other kids than an adult, and that was the case.
Some of my earliest programming exposure was a dBASE IV book my dad had for work, though it was some time before I put any of it into action. At that time I was reading manuals like fiction, only slowly realizing that I could actually use some of it with our computer.
I had the same problem. Sometime in 1982. at age 11, I started working through a BASIC book and an Apple II computer. I was perplexed: what is this?

  10 X = X + 1
  20 Y = Y - X
If the computer is meant to solve two equations here, why not start with an example that has solutions??!
It’s a pity your father’s perspective didn’t prevail. We’d all be using better programming languages now.
It's a notational issue. IIRC Pascal used := for assignment and = for equality testing.

Where this becomes extremely Rorsarch is the spectrum between "notation is absolutely critical: there is only one correct representation of programs in people's heads and we have to match that exactly" vs. "all program text is ultimately syntactic sugar and programmers will just adapt to whatever". History tells us that the C choice of = for assignment and == for equality testing won, but of course that's not a choice in a vacuum and it's tied up with a thousand other choices.

If you have no concept of destructive manipulation of variables, because all the variables you have ever known were the ones in math, you will still read := as equals.
I think parent was alluding to mutability.
Yes! In lazy but immutable languages like Haskell, it is totally fine to refer to the value itself during definition. This is really the same idea that a recursive function can refer to itself during definition. It’s common to define a variable for the infinite list of prime numbers, where the definition requires the list of prime numbers itself.

    primes = 2 : sieve primes [3..]
    sieve (p:ps) xs = let (h, t) = span (< p*p) xs in h ++ sieve ps (filter (\n -> rem n p > 0) t)
Here `primes` is a variable that refers to itself in its definition (called corecursion), and `sieve` is a recursive function.
While I'm a big fan of immutable design, it makes some algorithms much more expensive and ultimately DRAM is mutable. And the example we're talking about could be a loop counter!
A tail-recursive loop handles loops just fine, and is just as efficient. This is a perfect example of the misconceptions that mutable-first programming languages have caused.

> ultimately DRAM is mutable

Ultimately the CPU executes machine code, but I don’t see you directly writing that. You’re cherry-picking to defend an indefensible position.

No parent should have to learn from their child about the abuses computer people have done to mathematical notation.
This tells a lot of about your dad - he must be an amazing person, so he was ready to learn something from his kid. Not everyone would be able to admit that 9 y.o. can teach him something :)