Teaching kids to program (in Java)

[Arne Vajhøj]

java.lang and java.util are fine, but java.io has always struck me as
needlessly quirky. Coming, as I did, from an assembler/C/Algol/COBOL
background it was by far the most difficult part of Java to get my head
round.

It is certainly very different from older languages.

But many newer languages seems to have taken similar routes.

Arne

 

[glen herrmannsfeldt]

(snip)

So, back when C was specified, it made sense to have both hex and octal
bit representations because it was being used on both byte and word
oriented hardware (didn't some early DEC kit use word and character
lengths that were multiples of 3 rather than 4?) but now, with the
almost universal adoption of byte-oriented architectures there's
little reason, other than historic, to use octal notation.

Before VAX, everything DEC was octal. There were machines with 12
bit and 36 bit words. The PDP-11 used 16 bits, but the instruction
fields were divided up such that octal made them more readable.
Much of the PDP-11 software uses Radix 50, which is actually
base 40 because the 50 is in octal. (Three characters per word.)

With VAX, they went hex, though octal was still supported.

Stories are that DEC published a calendar with the dates in hex
in the year before VAX was released. Instruction fields are in
multiples of four bits. The DUMP commands prints ASCII and hex.
(The hex going right to left, so that little endian values can
be read correctly.)

-- glen

 

[Gene Wirchenko]

[snip]

from ordinary usage ("method", "call", "object", "integer", "%",
"@"). It is incumbent upon one learning a programming language to
learn the specific semantics and syntax, and complaints that it is
unlike other languages (programming or otherwise) are feckless.

Quite true. Learning those terms is part of the basics of
programming. How a particular language does something is not.

If I were to create a programming language, it would be
reasonable for me to expect that people would know what "method",
"call", etc. mean. It would not be so for something idiosyncratic to
my language.

That seems to be a rather arbitrary division.

Not at all. Here is how to tell the difference:

"method" and "call" are ordinary terms of the industry. If I
come up with a term for something, it might become a term of the
industry, but it certainly will not be at first.

Do you know what the term "Turing chart" means? I made it up
years ago. It refers to a particular representation of a finite state
automaton. It is rather obviously on the other side of the divide
from "method" and "call".

If you look at languages weighted after current use, then I think you
will see that octal constants are used more than call keyword.

No, I can not remember the last time I saw production code with
deliberately-used octal constants. In fact, I do not think that I
have ever seen code with the leading zero octal constant (except as a
documentation example or as an example of this problem).

From time to time, I do see call statements (or their
equivalent). I will be seeing more and more. The call statement in
T-SQL is execute, and that is used quite a bit.

Sincerely,

Gene Wirchenko

 

[Martin Gregorie]

No, I can not remember the last time I saw production code with
deliberately-used octal constants. In fact, I do not think that I have
ever seen code with the leading zero octal constant (except as a
documentation example or as an example of this problem).

Me neither, at least not since I last used an ICL 1900, which would be
back in the late 1970s.

From time to time, I do see call statements (or their
equivalent). I will be seeing more and more. The call statement in
T-SQL is execute, and that is used quite a bit.

Its quite a common verb in COBOL too. Used every time an external
subroutine is run. CALL "that-subroutine" USING PARAM-1 PARAM-2.