Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Teaching kids to program (in Java)

Reply
Thread Tools

Teaching kids to program (in Java)

 
 
Arved Sandstrom
Guest
Posts: n/a
 
      04-19-2012
On 12-04-18 10:03 PM, Gene Wirchenko wrote:
> On Wed, 18 Apr 2012 19:20:30 -0400, Arne Vajh°j <(E-Mail Removed)>
> wrote:
>
>> On 4/17/2012 10:57 PM, Gene Wirchenko wrote:

>
> [snip]
>
>>> I really do not like gotchas. They can waste a lot of time. I
>>> really do not like the attitude of "Oh, well!" about them either.

>>
>> I can not see a big difference between that and knowing that
>> an integer starting with zero is being interpreted as
>> being in octal.

>
> I can. One reads about datatypes for a language, and the first
> thing that comes to mind is what values is it a collection of. Then,
> comes operations.
>
> One does not expect common things to be redefined without notice.
> That is what the octal notation does. There is also a good reason for
> using leading zeroes (alignment).
>
>> One need to know the tool one uses.

>
> Certainly.
>
> Sincerely,
>
> Gene Wirchenko


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.

AHS
--
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg
 
Reply With Quote
 
 
 
 
Gene Wirchenko
Guest
Posts: n/a
 
      04-20-2012
On Thu, 19 Apr 2012 20:15:26 -0300, Arved Sandstrom
<(E-Mail Removed)> 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.

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      04-20-2012
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.

Computer programming uses all sorts of terms and notations in ways different from ordinary usage ("method", "call", "object", "integer", "%", "@"). Itis 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.

--
Lew
 
Reply With Quote
 
Gene Wirchenko
Guest
Posts: n/a
 
      04-20-2012
On Fri, 20 Apr 2012 12:43:42 -0700 (PDT), Lew <(E-Mail Removed)>
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. It is a
violation of the Law of Least Astonishment.

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

If I were considering breaking with general practice on
something, perhaps, I should reconsider or document it very well.

At various times, I have had (and continue to have) considerable
difficulties with various features of various programming languages,
not because any given feature is all that difficult, but because of
the difficulty, if not impossibility, of getting a clear statement of
how the feature works. You know that programmers tend to not like
documenting, right?

I wind up having to guess, document the results, refine, and
repeat. This is very slow.

Gratuitous changing of behaviour is a gotcha. Gotchas waste
time.

Sincerely,

Gene Wirchenko
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      05-06-2012
On 4/13/2012 10:08 PM, glen herrmannsfeldt wrote:
> Arne Vajh°j<(E-Mail Removed)> wrote:
>
> (snip, someone wrote)
>>>>> In my not particularly humble opinion, Java is too crufty to make for
>>>>> a good _introductory_ language. There are too many old sins and too
>>>>> many idiosyncrasies in the language that are likely to confuse or
>>>>> stump someone who doesn't already know how to program.

>
> (snip, then I wrote)
>>>> Compared to what?

>
> (and also wrote)
>>>> How about Fortran or C?

>
>>> It's been too long since I worked with Fortran and I don't know
>>> anything about the modern Fortrans, so I can't say. Possibly for
>>> students who already works with matrices in math, but I suspect that
>>> for those cases Matlab (or something similar) would be a better match.

>
> My first language, mostly, was IBM Fortran IV, Fortran 66 with some
> useful extensions. Much has been added since, including the most
> recent 2008 standard. Fortran 66 is relatively simple, but with
> some strange features left from earlier systems. Still, I didn't
> have much trouble learning it during the summer before 9th grade.
> (The IBM reference manual was my 8th grade graduation present.)


I started with Fortran V aka 77.

Still a simple language and maybe even easier to learn than IV/66.

>>> I think the core language of C is small enough that it might work
>>> well, as long as the course is targetting low-level hardware (such as
>>> an Arduino board) rather than desktop I/O.

>
>> C is rather simple.

>
> It is, but you have to understand pointers earlier than with
> most other languages.


True.

>> But explaining what is going on with incorrect programs
>> is not so fun.

>
> Well, many languages have that problem, in many strange ways.


But languages that allow memory overwrites can be really nasty.

>> Medium size language with huge standard library.

>
>> I would say less quirks than most languages.

>
> The library is big, but with a small subset you can do the usual
> things that beginning programmers need to do.


java.lang, java.io and java.util could bring one a good
step forward.

Arne


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      05-06-2012
On 4/18/2012 9:03 PM, Gene Wirchenko wrote:
> On Wed, 18 Apr 2012 19:20:30 -0400, Arne Vajh°j<(E-Mail Removed)>
> wrote:
>> On 4/17/2012 10:57 PM, Gene Wirchenko wrote:


>>>> Most people know what an integer is, but when they switch to
>>>> a (traditional) programming language, then the definition is
>>>> suddenly different. And so is the behavior of concepts like
>>>> add and multiply.
>>> Behaviour of datatypes should be a very basic part of using them.
>>> How else do you know which one to select? (If instructing, I would
>>> define the datatype. "An int can hold an integer value in the range
>>> of<low> to<high>. If you try to assign a value outisde of this
>>> range, then<result>." and so on.)
>>> I really do not like gotchas. They can waste a lot of time. I
>>> really do not like the attitude of "Oh, well!" about them either.

>>
>> I can not see a big difference between that and knowing that
>> an integer starting with zero is being interpreted as
>> being in octal.

>
> I can. One reads about datatypes for a language, and the first
> thing that comes to mind is what values is it a collection of. Then,
> comes operations.
>
> One does not expect common things to be redefined without notice.
> That is what the octal notation does. There is also a good reason for
> using leading zeroes (alignment).


Usually the section before or after "data types" is called
"literals". Not a good idea to skip that.

And a lot easier to understand than "behavior of data types", which
is frequently not even mentioned in a beginner book.

Arne

 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      05-06-2012
On 4/20/2012 4:30 PM, Gene Wirchenko wrote:
> On Fri, 20 Apr 2012 12:43:42 -0700 (PDT), Lew<(E-Mail Removed)>
> 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
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      05-06-2012
On Sat, 05 May 2012 20:13:54 -0400, Arne Vajh├Şj wrote:

> On 4/13/2012 10:08 PM, glen herrmannsfeldt wrote:
>>
>> The library is big, but with a small subset you can do the usual things
>> that beginning programmers need to do.

>
> java.lang, java.io and java.util could bring one a good step forward.
>

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.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
Martin Gregorie
Guest
Posts: n/a
 
      05-06-2012
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 |
 
Reply With Quote
 
Arne Vajh├Şj
Guest
Posts: n/a
 
      05-06-2012
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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Teach your kids to program Lawrence D'Oliveiro NZ Computing 0 01-28-2008 08:05 AM
Looking for a program to run on XP to remotely watch what my kids are doing, something like a keylogger. TIA!! Tory Brown Computer Security 45 06-05-2005 03:44 PM
self teaching WAN ; driving me back out into the garden to plant peas; frustrated . Barrett Bonden Cisco 5 04-07-2005 04:09 AM
Self teaching, cannot lock database file Michael Powell ASP .Net 2 03-29-2005 03:34 PM
Teaching resources VisionSet Java 2 10-07-2004 07:22 AM



Advertisments