Recommendations for an online Introduction to programming using Java

[Chris Riesbeck]

1st) the name is not related to the meaning of the class
(most severe)
2nd) it does not start with an upper-case letter
3rd) it contains a comma

The quality assessments of beginners and experts often
differ. A beginner senses whether the learning process
triggered by reading a book makes him feel good, and will
not always recognize it when he learns something that is
wrong. When the book tells the beginner: »You can name a
class any way you like as long as the name sounds really
cool, for example, try funny fruit names.«, a young beginner
might actually like this stance. Possibly, he will continue
to read this book, while he would have stopped reading a
more boring book even though it is more correct in technical
terms. So, the funny book with the mistakes might actually
make him learn more (some of which is wrong).

I certainly agree with the need to engage and not intimidate the
beginner. Knowing when to lie to students is an important part of
teaching. One of the things that led me into math and then computer
science was when a high school teacher misled me about what was already
known about the square root of -1.

But the part of me that reads college student code sees all these
programmers who believe names don't matter, when they probably matter
more than anything else. So somewhere down the line, before they release
code into the wild, it'd be nice if someone told them you write code for
people to read, not just computers.

 

[marianne.paradiso]

There are tons of books here: http://it-ebooks.info/book/2595/

I'm sure you'll find something suitable for your daughter.

 

[Jukka Lahtinen]

The comma was punctuation for the sentence (as mandated by the grammar

But you wrote it inside the quotation marks, so it looked like part of
the name.

 

[Lars Enderin]

2013-12-20 12:04, Jukka Lahtinen skrev:

But you wrote it inside the quotation marks, so it looked like part of
the name.

Americans tend to put sentence delimiters before a closing ", but I
thought that it did not apply to commas. Anyway, it's a confusing
practice and certainly not applicable to program text.

 

[Roedy Green]

I would like to get them started with Java,
but Google has 9.5 million hits for: "Introduction to
programming in Java"

I would try the Oracle Java tutorials.

After that, he might find my site useful.

For example if he wanted to use a button, he could look
at http://mindprod.com/jgloss/jbutton.html

And he would see a short, complete program using it and "gotchas"
(tips of the unexpected). You can do that for all sorts of the common
classes.

Tutorials are great to get started, but are not good for reference.
The official docs are a bit daunting for novices. My stuff fits in
the middle.

 

[Stefan Ram]

String aString = "Hello world;"

In my own tutorials, I strive to be as close to the original
as possible, so I have searched and read a C tutorial by
Brian W. Kernighan from 1974. And therein, the famous
programs is written as:

main( ) {
printf("hello, world");
}

That is: »hello, world« is written all in lowercase, it has
a comma, but no punctuation at its end. So, in my own
tutorials I write it just like this.

BTW: I have started to translate my German language Java
tutorial into English. So far, I have translated about 1 %:
The very first lesson with the »hello, world« program:

http://www.purl.org/stefan_ram/pub/hello_world_java

 

[Arne Vajhøj]

1st) the name is not related to the meaning of the class
(most severe)
2nd) it does not start with an upper-case letter
3rd) it contains a comma

The quality assessments of beginners and experts often
differ. A beginner senses whether the learning process
triggered by reading a book makes him feel good, and will
not always recognize it when he learns something that is
wrong. When the book tells the beginner: »You can name a
class any way you like as long as the name sounds really
cool, for example, try funny fruit names.«, a young beginner
might actually like this stance. Possibly, he will continue
to read this book, while he would have stopped reading a
more boring book even though it is more correct in technical
terms. So, the funny book with the mistakes might actually
make him learn more (some of which is wrong).

There is a German Java programming book, whose name I
forgot, that uses class and variable names like »Jacob« and
«Sophia«. While experts criticise this, some readers
(beginners) say that it helps them to understand that these
are names the programmer can assign as he likes it,
setting them clearly apart from keywords like »return«,
marking them as /names/.

I completely agree.

And that is why I recommended a book by an author that is good at
writing introductory programming books over a book by an author
that is a true expert in Java.

That said then I would consider it best to stick to normal
convention case of names. It is not a subject that requires a
lot of knowledge to understand.

Arne

 

[Arved Sandstrom]

1st) the name is not related to the meaning of the class
(most severe)
2nd) it does not start with an upper-case letter
3rd) it contains a comma

The quality assessments of beginners and experts often
differ. A beginner senses whether the learning process
triggered by reading a book makes him feel good, and will
not always recognize it when he learns something that is
wrong. When the book tells the beginner: »You can name a
class any way you like as long as the name sounds really
cool, for example, try funny fruit names.«, a young beginner
might actually like this stance. Possibly, he will continue
to read this book, while he would have stopped reading a
more boring book even though it is more correct in technical
terms. So, the funny book with the mistakes might actually
make him learn more (some of which is wrong).

There is a German Java programming book, whose name I
forgot, that uses class and variable names like »Jacob« and
«Sophia«. While experts criticise this, some readers
(beginners) say that it helps them to understand that these
are names the programmer can assign as he likes it,
setting them clearly apart from keywords like »return«,
marking them as /names/.

I'm not aware of great recent introductory Java programming books,
except for advanced topics: you appreciate Bloch and Goetz when you've
already learned Java. That Herb Schildt wrote a book about Java bothers
me: his books on C and C++ were awful. But judging by the publishing
press he is an authority on C, C++, C# and Java. I'll be less harsh
about the Deitels: they are merely mediocre.

The original O'Reilly books about Java were the best. I've still got my
'96 edition of "Java In a Nutshell" by Flanagan on my shelf.

AHS

 

[Arne Vajhøj]

I'm not aware of great recent introductory Java programming books,
except for advanced topics: you appreciate Bloch and Goetz when you've
already learned Java. That Herb Schildt wrote a book about Java bothers
me: his books on C and C++ were awful. But judging by the publishing
press he is an authority on C, C++, C# and Java. I'll be less harsh
about the Deitels: they are merely mediocre.

All the C and C++ experts agree that Schildt's books are awful.

But in most cases that just means that they are awful at teaching
beginners how to program.

A few quotes from Feather:

<quote>
A proper understanding of the terms "implementation-defined",
"undefined", and "unspecified", and of the differences between them, is
essential to understanding the limits that the standard puts on the
programmer and the implementor. Unfortunately, the differences are not
explained at all, and the book leaves me wondering why the different
terms are used at all.
</quote>

<quote>
## An unsigned integer expression cannot overflow. This is because
## there is no way to represent such an overflow as an unsigned
## quantity.

More nonsense. An implementation either does or doesn't have a way to
represent overflow - usually integers don't, while floating point may or
may not (some systems have INFINITY values that effectively indicate
overflow). However, an unsigned integer expression cannot overflow
because the standard says so - the choice was made that unsigned integer
arithmetic is done modulo some base (UINT_MAX+1 for unsigned int,
ULONG_MAX+1 for unsigned long). There is no magic about this; it was an
arbitrary decision by the authors of the standard.
</quote>

A few quote from Seebs:

<quote>
As bits are shifted off one end, zeroes are brought in the other
end. (In the case of a signed, negative integer, a right shift will
cause a 1 to be brought in so that the sign bit is preserved.)

Clear, lucid, but not actually true. What happens when you right-shift a
signed, negative number, is "implementation-defined" (C99, 6.5.7,
paragraph 5); that is to say, the implementation has to document what
happens. While the behavior Schildt describes is one of the common
choices, other systems have been known to shift in zeroes. There may be
other behaviors out there. This ties in somewhat with Schildt's comments
about the use of two's complement representations, where the behavior he
describes is common but not actually required.
</quote>

<quote>
If stream is associated with a file opened for writing, a call to
fflush() causes the contents of the output buffer to be physically
written to the file. The file remains open.

There's a couple of questionable bits here, although they're arcane
enough that you might reasonably call them nitpicks.

Streams in C can be opened for reading, writing, or "update"—both
reading and writing. You can safely use fflush() on an update stream
only if the most recent operation on it was not a read (writes or seeks,
for instance, are allowed). Schildt misses that distinction, although I
simply can't tell whether he fails to point out that you can sometimes
flush an update stream, or fails to point out that you sometimes can't
flush an update stream.
More perniciously, it's worth pointing out that fflush() does not
cause the contents of the output buffer to be physically written to the
file. It causes the contents of the output buffer to be delivered to the
host operating environment, which may well have additional layers of
buffering. On most modern systems, this could result in the file living
in an operating-system level write cache for seconds or minutes, or for
that matter, living in a cache on the disk drive's internal
microcontroller for some time. (That "16MB cache!" you see advertised on
hard drive packaging is, in many cases, not something the C
implementation can force to be flushed out to the physical platters.)
</quote>

All very correct.

But absolutely non-suitable for a beginner that wants to learn C.

Arne