Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #14317 > unrolled thread

Re: Teaching kids to program (in Java)

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 20:23 -0400
    Re: Teaching kids to program (in Java) Martin Gregorie <martin@address-in-sig.invalid> - 2012-05-06 12:22 +0000
      Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-05-06 11:36 -0400
      Re: Teaching kids to program (in Java) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-05-06 17:10 +0000
    Re: Teaching kids to program (in Java) Gene Wirchenko <genew@ocis.net> - 2012-05-07 09:43 -0700
      Re: Teaching kids to program (in Java) Martin Gregorie <martin@address-in-sig.invalid> - 2012-05-07 18:17 +0000

#14317 — Re: Teaching kids to program (in Java)

On 4/20/2012 4:30 PM, Gene Wirchenko wrote:
> On Fri, 20 Apr 2012 12:43:42 -0700 (PDT), Lew<lewbloch@gmail.com>
> wrote:
>> Gene Wirchenko wrote:
>>> Arved Sandstrom wrote:
>>>
>>> [snip]
>>>
>>>> I'm with Arne on this one. I expect programmers using a language to at
>>>> least thoroughly understand the datatypes for a language. Granted,
>>>> leading zeros are a pretty crappy prefix choice, which is why a lot of
>>>> languages use something else, but a diligent _learning_programmer should
>>>> have discovered this crappy choice when reading about literals.
>>>
>>>        Odd.  You are agreeing with ME.
>>
>> Then you and Arne are in agreement.
>>
>> Leading zeroes to represent octal values weren't added to the C language family
>   "without notice" at all, but with abundant notice. Arne is simply
> saying that one must learn the programming language if one wishes to
> use it. This includes reading the documentation, wherein such notice
> is offered.
>
>       Not abundant notice if it has been missed by so many.

If you search programming fora for problems relating to:
- max int values
- integer division
- FP inaccuracy
- octal
then I think you will see that octal is not a common problem compared
to other language features.

>> Computer programming uses all sorts of terms and notations in ways different
>   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.

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

Arne

[toc] | [next] | [standalone]

#14335

On Sat, 05 May 2012 20:23:45 -0400, Arne Vajhøj wrote:

> If you search programming fora for problems relating to:
> - max int values 
> - integer division
> - FP inaccuracy
> - octal then I think
> you will see that octal is not a common problem compared to other
> language features.
>
I've always out that down to hardware changes. Way back when machines 
using 6 bit ISO characters (ICL 1900 mainframes, Elliott scientific 
boxes) I used to use octal all the time and didn't recall ever meeting 
hex, which I first noticed after the switch to byte-oriented 
architectures. I think that made sense: the 1900 used a 24 bit work that 
split into 4 6-bit characters so octal works well for bit representations 
of both words and characters. Hex would be far less useful.

OTOH Octal is a bad fit with a byte-oriented architecture for exactly 
thew same reasons.

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.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#14336

On 5/6/2012 8:22 AM, Martin Gregorie wrote:
> On Sat, 05 May 2012 20:23:45 -0400, Arne Vajhøj wrote:
>> If you search programming fora for problems relating to:
>> - max int values
>> - integer division
>> - FP inaccuracy
>> - octal then I think
>> you will see that octal is not a common problem compared to other
>> language features.
>>
> I've always out that down to hardware changes. Way back when machines
> using 6 bit ISO characters (ICL 1900 mainframes, Elliott scientific
> boxes) I used to use octal all the time and didn't recall ever meeting
> hex, which I first noticed after the switch to byte-oriented
> architectures. I think that made sense: the 1900 used a 24 bit work that
> split into 4 6-bit characters so octal works well for bit representations
> of both words and characters. Hex would be far less useful.

Same with CDC NOS.

> OTOH Octal is a bad fit with a byte-oriented architecture for exactly
> thew same reasons.
>
> 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.

True.

But the history is still there.

Arne

[toc] | [prev] | [next] | [standalone]

#14340

Martin Gregorie <martin@address-in-sig.invalid> wrote:

(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

[toc] | [prev] | [next] | [standalone]

#14363

On Sat, 05 May 2012 20:23:45 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 4/20/2012 4:30 PM, Gene Wirchenko wrote:
>> On Fri, 20 Apr 2012 12:43:42 -0700 (PDT), Lew<lewbloch@gmail.com>
>> wrote:

[snip]

>>> Computer programming uses all sorts of terms and notations in ways different
>>   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

[toc] | [prev] | [next] | [standalone]

#14376

On Mon, 07 May 2012 09:43:31 -0700, Gene Wirchenko wrote:

> 
>      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.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web