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

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

Teaching kids to program (in Java)

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

Contents

  Teaching kids to program (in Java) Mark <i@dontgetlotsofspamanymore.invalid> - 2012-04-12 09:12 +0100
    Re: Teaching kids to program (in Java) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-12 08:28 +0000
    Re: Teaching kids to program (in Java) Roedy Green <see_website@mindprod.com.invalid> - 2012-04-12 04:36 -0700
      Re: Teaching kids to program (in Java) David Lamb <dalamb@cs.queensu.ca> - 2012-04-12 09:47 -0400
      Re: Teaching kids to program (in Java) Lew <noone@lewscanon.com> - 2012-04-12 07:42 -0700
        Re: Teaching kids to program (in Java) Roedy Green <see_website@mindprod.com.invalid> - 2012-04-12 19:41 -0700
        Re: Teaching kids to program (in Java) Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-13 21:22 -0300
      Re: Teaching kids to program (in Java) Mark <i@dontgetlotsofspamanymore.invalid> - 2012-04-16 13:53 +0100
    Re: Teaching kids to program (in Java) David Lamb <dalamb@cs.queensu.ca> - 2012-04-12 13:09 -0400
      Re: Teaching kids to program (in Java) David Lamb <dalamb@cs.queensu.ca> - 2012-04-12 13:28 -0400
      Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-04-12 19:16 -0400
        Re: Teaching kids to program (in Java) David Lamb <dalamb@cs.queensu.ca> - 2012-04-12 20:36 -0400
          Re: Teaching kids to program (in Java) Roedy Green <see_website@mindprod.com.invalid> - 2012-04-12 19:55 -0700
        Re: Teaching kids to program (in Java) Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-04-13 05:03 -0500
          Re: Teaching kids to program (in Java) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-13 10:14 +0000
            Re: Teaching kids to program (in Java) Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-04-13 09:27 -0500
              Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-04-13 20:42 -0400
                Re: Teaching kids to program (in Java) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-14 02:08 +0000
                  Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 20:13 -0400
                    Re: Teaching kids to program (in Java) Martin Gregorie <martin@address-in-sig.invalid> - 2012-05-06 12:06 +0000
                      Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-05-06 11:38 -0400
          Re: Teaching kids to program (in Java) Rui Maciel <rui.maciel@gmail.com> - 2012-04-13 14:06 +0100
            Re: Teaching kids to program (in Java) Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-04-13 09:07 -0500
              Re: Teaching kids to program (in Java) Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-04-13 09:53 -0500
              Re: Teaching kids to program (in Java) Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-04-13 10:55 -0500
            Re: Teaching kids to program (in Java) Gene Wirchenko <genew@ocis.net> - 2012-04-13 08:39 -0700
              Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-04-13 20:47 -0400
                Re: Teaching kids to program (in Java) Gene Wirchenko <genew@ocis.net> - 2012-04-15 20:05 -0700
                  Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-04-17 22:11 -0400
                    Re: Teaching kids to program (in Java) Gene Wirchenko <genew@ocis.net> - 2012-04-17 19:57 -0700
                      Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-04-18 19:20 -0400
                        Re: Teaching kids to program (in Java) Gene Wirchenko <genew@ocis.net> - 2012-04-18 18:03 -0700
                          Re: Teaching kids to program (in Java) Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-04-19 20:15 -0300
                            Re: Teaching kids to program (in Java) Gene Wirchenko <genew@ocis.net> - 2012-04-19 20:08 -0700
                              Re: Teaching kids to program (in Java) Lew <lewbloch@gmail.com> - 2012-04-20 12:43 -0700
                                Re: Teaching kids to program (in Java) Patricia Shanahan <pats@acm.org> - 2012-04-20 12:58 -0700
                                Re: Teaching kids to program (in Java) Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-04-20 15:20 -0500
                                Re: Teaching kids to program (in Java) Gene Wirchenko <genew@ocis.net> - 2012-04-20 13:30 -0700
                                  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
                          Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 20:18 -0400
            Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-04-13 20:44 -0400
          Re: Teaching kids to program (in Java) Arne Vajhøj <arne@vajhoej.dk> - 2012-04-13 20:38 -0400
          Re: Teaching kids to program (in Java) Gunter Herrmann <notformail0106@earthlink.net> - 2012-04-16 15:32 -0400
      Re: Teaching kids to program (in Java) Roedy Green <see_website@mindprod.com.invalid> - 2012-04-12 19:44 -0700
    Re: Teaching kids to program (in Java) Patricia Shanahan <pats@acm.org> - 2012-04-13 17:59 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#14337

On 5/6/2012 8:06 AM, Martin Gregorie wrote:
> 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.

It is certainly very different from older languages.

But many newer languages seems to have taken similar routes.

Arne

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

#13518

Leif Roar Moldskred 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.
> 
> (Why isn't the first element of an array at position 1? 

The term "array" refers to a collection of objects which were allocated in a 
continuous memory segment.  A reference to an array points to the first 
object of the array.  The array index represents the offset with regards to 
the first element.  So, index 0 means a zero offset from the first object of 
the array (i.e., address of first object in the array), index 1 refers to 
the object which is 1 object size after the first object (address of first 
object + 1 object size), array 2 is two objects, and so on.

This isn't an "old sin" or an idiosyncrasy.  It's exactly what the 
programmer intends to do.  If the programmer isn't aware of that then it 
isn't a shortcoming of the programmer language; it reflects a lack of 
understanding regarding what he is doing and what he is trying to do.  And 
this does not mean that the language doesn't make for a good introductory 
language.


> What's the difference between int and Integer? 

The former is a primitive, while the latter is a reference to an object of 
type Integer.  This is covered in any introductory tutorial.


> Why doesn't System.out.println(
> "Value: " + 01234 ) work? 

Why do you believe it doesn't work?  You've used an octal integer literal to 
express the value of an integer number.  You get exactly what you asked for.


> Why do I get a NullPointerException on the
> line "System.out.println( factorial( inputValue ) );"? 

You have to be a bit clearer with that, as you haven't defined inputValue or 
factorial().


> What is a Null Pointer, anyway?)

I don't believe it is reasonable to accuse any programming language of being 
"too crufty to make for a good introductory language" if the only problem 
which has been pointed out boils down to ignorance regarding how to use that 
programming language.  No programming language, no matter how appropriate it 
might be as an introductory language, enables you to write any code without 
first learning how to do it.


Rui Maciel

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

#13520

Rui Maciel <rui.maciel@gmail.com> wrote:
> Leif Roar Moldskred wrote:
> 
> The term "array" refers to a collection of objects which were allocated in a 
> continuous memory segment. A reference to an array points to the first 
> object of the array.  

That is true for C. Neither is true for Java. Zero-based arrrays makes
sense in C, where array access just pointer arithmics by another
name. It makes no sense at all in Java, and Java only does it this way
because it was unthinkingly copied over from C along with the syntax.

You'll never see a mathematican refer to the 0th element of an array
or vector. Zero-based arrays most certainly are an idiosyncrasy of
programming languages -- which sometimes, such as for C, makes
sense. For a programming language that does arrays right, look to Ada.
 
>> What's the difference between int and Integer? 
> 
> The former is a primitive, while the latter is a reference to an object of 
> type Integer.  This is covered in any introductory tutorial.

Of course it is -- any Java programmer needs to know this difference
to a t. But it's needless confusion when trying to teach introductory
_programming_ as opposed to introductory Java. You're trying to get
people to understand the concepts of a variable and a type; you don't
need to complicate it with implementation details and corner cases.

>
> Why do you believe it doesn't work?  You've used an octal integer literal to 
> express the value of an integer number.  You get exactly what you asked for.

Again, the context is trying to teach programming to beginners. You
really don't want to take a ten minute break to explain what an octal
number is, why and when someone would use them and why someone was
stupid enough to use leading zeroes as a mark for them in Java.

> 
>> Why do I get a NullPointerException on the
>> line "System.out.println( factorial( inputValue ) );"? 
> 
> You have to be a bit clearer with that, as you haven't defined inputValue or 
> factorial().

There's only one situation where a NullPointerException would occur on
that line, and to someone who doesn't already understand what's going
on it's going to be intensly frustrating and confusing.

> I don't believe it is reasonable to accuse any programming language of being 
> "too crufty to make for a good introductory language" if the only problem 
> which has been pointed out boils down to ignorance regarding how to use that 
> programming language.  No programming language, no matter how appropriate it 
> might be as an introductory language, enables you to write any code without 
> first learning how to do it.

Actually, that's exactly what good introductory language should let
you do, as far as possible. You shouldn't have to learn _everything_
about the language before you're able to do _something_ in it. Of
course, Java isn't at the point where you have to learn and understand
_everything_ before you can program in it, but it's further along
towards "evertyhing" than other languagues.

In an ideal introductory language, the things you don't know (yet)
shouldn't get in the way of you applying what you've already
learnt. Java has too many corners you can trip over if you don't know
they are there, for it to be a good example of such a language.

-- 
Leif Roar Moldskred

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

#13523

Leif Roar Moldskred <leifm@dimnakorr.com> wrote:
>
> There's only one situation where a NullPointerException would occur on
> that line, and to someone who doesn't already understand what's going
> on it's going to be intensly frustrating and confusing.

Actually, come to think of it, there's two other situations where that 
line would cause a NullPointerException. The case I was thinking of,
though, isn't caused by the System.out.println() call.

-- 
Leif Roar Moldskred

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

#13527

On 4/13/2012 9:07 AM, Leif Roar Moldskred wrote:
> You'll never see a mathematican refer to the 0th element of an array
> or vector. Zero-based arrays most certainly are an idiosyncrasy of
> programming languages -- which sometimes, such as for C, makes
> sense. For a programming language that does arrays right, look to Ada.

I see lots of references to things like x_0 in mathematics. It really 
comes down to "is 0 the first natural number or is 1 the first natural 
number?" Edgar Dijkstra (I believe) once laid out his opinion of array 
indexing and arrived at the conclusion that 0 <= i < n is the most 
natural way to do for-loop-iteration, so array indexing should start at 
0 and not 1. The argumentation, IIRC, boils down roughly as follows:
1. [start, start + length) is the most natural bound
2. Length should be a simple expression, i.e., n
3. Using (<=, <) as your pair of comparison most clearly indicates the 
use of [a, b) notation
4. Thus, start <= i < start + n is the appropriate notation.
5. When the start is the beginning of the array, start + n should just be n
6. So start should be 0, and we get 0 <= i < n

There are occasionally places where 1-based indexing makes more sense 
(array-based heap notations are a particularly well-known example), but 
I'm not sure that giving programmers the ability to choose array bounds 
is the best option.

Also, FWIW, the convention of 1 being the "first" number isn't totally 
universal: the Mayans started from 0. And they were arguably the best 
mathematicians of their time.

>> I don't believe it is reasonable to accuse any programming language of being
>> "too crufty to make for a good introductory language" if the only problem
>> which has been pointed out boils down to ignorance regarding how to use that
>> programming language.  No programming language, no matter how appropriate it
>> might be as an introductory language, enables you to write any code without
>> first learning how to do it.

So we should start by teaching everyone APL, right? :-)

The problem is that discussing a basic Hello World in Java requires, at 
a minimum, handwaving the public class HelloWorld, the public static 
void main, System.out.println, and the entire compilation procedure. If 
you don't handwave, you have to give a lengthy amount of time to 
explaining how object-oriented programming works before you can begin 
discussing programming. You also very quickly get to bugaboos with 
explicit typing, doing I/O (reading from stdin is surprisingly 
complicated in Java), collections (generics is complicated enough for 
seasoned programmers; for those just starting a few weeks ago, it's an 
imposing cliff).

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

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

#13526

On Fri, 13 Apr 2012 14:06:28 +0100, Rui Maciel <rui.maciel@gmail.com>
wrote:

>Leif Roar Moldskred wrote:

[snip]

>> Why doesn't System.out.println(
>> "Value: " + 01234 ) work? 
>
>Why do you believe it doesn't work?  You've used an octal integer literal to 
>express the value of an integer number.  You get exactly what you asked for.

     No, he got exactly what the language spec says he should get.

     It is not obvious to anyone who has not run across it before what
is happening in this case.  Leading zeroes are used in the RW, and
never mean octal (that I have ever seen).

[snip]

Sincerely,

Gene Wirchenko

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

#13536

On 4/13/2012 11:39 AM, Gene Wirchenko wrote:
> On Fri, 13 Apr 2012 14:06:28 +0100, Rui Maciel<rui.maciel@gmail.com>
> wrote:
>> Leif Roar Moldskred wrote:
>>> Why doesn't System.out.println(
>>> "Value: " + 01234 ) work?
>>
>> Why do you believe it doesn't work?  You've used an octal integer literal to
>> express the value of an integer number.  You get exactly what you asked for.
>
>       No, he got exactly what the language spec says he should get.
>
>       It is not obvious to anyone who has not run across it before what
> is happening in this case.  Leading zeroes are used in the RW, and
> never mean octal (that I have ever seen).

But can you find a programming language that does not require
learning some concept that is not used outside programming.

I doubt it.

Arne

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

#13570

On Fri, 13 Apr 2012 20:47:36 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 4/13/2012 11:39 AM, Gene Wirchenko wrote:

[snip]

>>       It is not obvious to anyone who has not run across it before what
>> is happening in this case.  Leading zeroes are used in the RW, and
>> never mean octal (that I have ever seen).
>
>But can you find a programming language that does not require
>learning some concept that is not used outside programming.
>
>I doubt it.

     Not the point.  The leading-zero octal issue is that something
that appears mundane actually has a special meaning.  I have seen
various ways for numeric literals to be represented in code, and
almost all of them have some weird characters to clue one in.
Examples:
          =F'100'     /360 & /370 Assembler fullword integer
          1234H       Z-80 assembler hexadecimal constant
          0x1234      C's hexadecimal representation

     If I had not heard of the leading-zero octal gotcha and someone
told me about it, it sounds that silly that I would want some proof. 

Sincerely,

Gene Wirchenko

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

#13626

On 4/15/2012 11:05 PM, Gene Wirchenko wrote:
> On Fri, 13 Apr 2012 20:47:36 -0400, Arne Vajhøj<arne@vajhoej.dk>
> wrote:
>> On 4/13/2012 11:39 AM, Gene Wirchenko wrote:
>>>        It is not obvious to anyone who has not run across it before what
>>> is happening in this case.  Leading zeroes are used in the RW, and
>>> never mean octal (that I have ever seen).
>>
>> But can you find a programming language that does not require
>> learning some concept that is not used outside programming.
>>
>> I doubt it.
>
>       Not the point.  The leading-zero octal issue is that something
> that appears mundane actually has a special meaning.

But it is not particular special. All languages has that
type of constructs.

One of the more common is probably that there is a max value
for an integer.

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.

Arne

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

#13629

On Tue, 17 Apr 2012 22:11:31 -0400, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 4/15/2012 11:05 PM, Gene Wirchenko wrote:
>> On Fri, 13 Apr 2012 20:47:36 -0400, Arne Vajhøj<arne@vajhoej.dk>
>> wrote:
>>> On 4/13/2012 11:39 AM, Gene Wirchenko wrote:
>>>>        It is not obvious to anyone who has not run across it before what
>>>> is happening in this case.  Leading zeroes are used in the RW, and
>>>> never mean octal (that I have ever seen).
>>>
>>> But can you find a programming language that does not require
>>> learning some concept that is not used outside programming.
>>>
>>> I doubt it.
>>
>>       Not the point.  The leading-zero octal issue is that something
>> that appears mundane actually has a special meaning.
>
>But it is not particular special. All languages has that
>type of constructs.

     That is a particularly nasty one since many languages have
"warnings" (delimiters) of some sort.

>One of the more common is probably that there is a max value
>for an integer.

     Not a surprise if you learn about datatypes.

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

Sincerely,

Gene Wirchenko

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

#13651

On 4/17/2012 10:57 PM, Gene Wirchenko wrote:
> On Tue, 17 Apr 2012 22:11:31 -0400, Arne Vajhøj<arne@vajhoej.dk>
> wrote:
>
>> On 4/15/2012 11:05 PM, Gene Wirchenko wrote:
>>> On Fri, 13 Apr 2012 20:47:36 -0400, Arne Vajhøj<arne@vajhoej.dk>
>>> wrote:
>>>> On 4/13/2012 11:39 AM, Gene Wirchenko wrote:
>>>>>         It is not obvious to anyone who has not run across it before what
>>>>> is happening in this case.  Leading zeroes are used in the RW, and
>>>>> never mean octal (that I have ever seen).
>>>>
>>>> But can you find a programming language that does not require
>>>> learning some concept that is not used outside programming.
>>>>
>>>> I doubt it.
>>>
>>>        Not the point.  The leading-zero octal issue is that something
>>> that appears mundane actually has a special meaning.
>>
>> But it is not particular special. All languages has that
>> type of constructs.
>
>       That is a particularly nasty one since many languages have
> "warnings" (delimiters) of some sort.
>
>> One of the more common is probably that there is a max value
>> for an integer.
>
>       Not a surprise if you learn about datatypes.
>
>> 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.

One need to know the tool one uses.

Arne

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

#13652

On Wed, 18 Apr 2012 19:20:30 -0400, Arne Vajhøj <arne@vajhoej.dk>
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

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

#13663

On 12-04-18 10:03 PM, Gene Wirchenko wrote:
> On Wed, 18 Apr 2012 19:20:30 -0400, Arne Vajhøj <arne@vajhoej.dk>
> 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

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

#13676

On Thu, 19 Apr 2012 20:15:26 -0300, Arved Sandstrom
<asandstrom3minus1@eastlink.ca> 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

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

#13708

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", "%", "@"). 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.

-- 
Lew

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

#13710

On 4/20/2012 12:43 PM, Lew 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.
>
> 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.
>

Remember this thread is about teaching kids to program. Shouldn't a
certain amount of fecklessness be expected and planned for?

Patricia

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

#13713

Lew <lewbloch@gmail.com> wrote:

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

If you're going to program in Java, then obviously you have to learn
Java as it is, warts and all. If you're just going to learn the
fundamentals of _how to program_ in general, then there's no reason to
learn anything about Java if there are cleaner, less quirky (but not
necessarily equally powerful or expressive) languages that are easier
to teach and presents fewer pitfalls to the student instead. As it
happens, there is.

-- 
Leif Roar Moldskred

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

#13714

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

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

#14317

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] | [prev] | [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]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web