Hello

I am going through a sequence of frustrating experiences learning
programming and it doesn't seem to end. I am learning Java. I have
been writing programs in the following way : I write 2 - 3 classes in
one file, then I write one more class in the same file which uses
objects of the other classes. I compile the program with the class
name of this lasst class. I wasn't aware taht when you compile, there
will result separate .class files in the same directory for each of
the classes defined within the single program file as above. I got to
know this accidentally, as I tried to run a jar file created by using
the name of the 3rd class - the one which has the main and uses
objects of the other classes. It gave a compiler error as it couldn't
find the other classes, which weren't packaged in the jar.

My question is hopw does one learn things like one program file - will
compile to several separate class files. It is given in some books but
not in all.How many will remember to use the dir command after the
javac to see this? And will you register that there are 3 files after
the dir. You'll be ina hurry to try the java interpreter on the .class
I have referred Java 2 Complete Reference by Schildt. I basically went
through the book cover to cover reading, didn't make sense typing in
from the book, I just went through the concepts, and now I'm doing a
project. I've done some C before so this is not my fisrt language. How
does one learn thse fundamentals.

Grumple

grumple wrote:
> 
.... snip ...
>
> I have referred Java 2 Complete Reference by Schildt. I basically
> went through the book cover to cover reading, didn't make sense
> typing in from the book, I just went through the concepts, and
> now I'm doing a project. I've done some C before so this is not
> my fisrt language. How does one learn thse fundamentals.

Probably not from that book.  Schildts C books are monumental
examples of misinformation, and I see no reason why Java should
improve his grasp.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

On Wed, 18 Feb 2004, grumple wrote:

> Hello
>
> I am going through a sequence of frustrating experiences learning
> programming and it doesn't seem to end. I am learning Java. I have
> been writing programs in the following way : I write 2 - 3 classes in
> one file, then I write one more class in the same file which uses
> objects of the other classes. I compile the program with the class
> name of this lasst class. I wasn't aware taht when you compile, there
> will result separate .class files in the same directory for each of
> the classes defined within the single program file as above. I got to
> know this accidentally, as I tried to run a jar file created by using
> the name of the 3rd class - the one which has the main and uses
> objects of the other classes. It gave a compiler error as it couldn't
> find the other classes, which weren't packaged in the jar.
>
> My question is hopw does one learn things like one program file - will
> compile to several separate class files. It is given in some books but
> not in all.How many will remember to use the dir command after the
> javac to see this? And will you register that there are 3 files after
> the dir. You'll be ina hurry to try the java interpreter on the .class
> I have referred Java 2 Complete Reference by Schildt. I basically went
> through the book cover to cover reading, didn't make sense typing in
> from the book, I just went through the concepts, and now I'm doing a
> project. I've done some C before so this is not my fisrt language. How
> does one learn thse fundamentals.

Herbert Schildt says things very well. Unfortunately, he often says the
wrong things really well. You might want to get a book written by someone
else.

Additionally, when you are developing there are multiple things to learn
but any given book will only talk about one of them. You need to learn the
syntax of the Java programming language. You need to learn the tool you
are using to turn .java files into .class or .jar files. You need to learn
project management (often this is defined by the tool you pick).

Bottom line, if something is not clear in a generic Java book, see if
there is documentation or a newsgroup that deals with your implementation.
You will definitely need two sources of help (possibly more). One for the
language itself (is there a comp.lang.java?) and one for your specific
implmentation (are you use the SDK, VisualAge Java, Microsoft J++ (which
is not really Java) or something else). You might also have situations
like you are using a command line implementation like the SDK and a GUI
front-end like Eclipse. In this case you might need three places to get
help.

If it is free you will be responsible for coordinating the different
'parts' of the language.

-- 
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vice.president@whitehouse.gov

grumple wrote:

> My question is hopw does one learn things...

You gotten some good answers.  Just some random thoughts from me...

Learn how to learn!
===================
We don't seem (at least in the USA) to teach *learning* anymore.
We teach a lot of specific subjects, but how often do young people
(or old people like me :-) get instruction on the process of How
To Learn.

You might want to spend some time and thought in developing your
learning ability.  Think about what works for you.  Do you learn
well from books or from classes, for instance.  Do you take notes,
and if so, are they effective (okay, show of hands: how many of
you have looked at notes you took in some class and not been able
to make head nor tail of them?).

I've learned, for instance, that I learn best in the morning (after
a good night's sleep) and I learn best from books.  I don't learn
well from a computer screen, though, so I've learned to kill trees
and *print* the interesting things I find on the web.

Programmers have to learn ALL THE TIME!
=======================================
You might as well get good at learning, because if you're going to
be a programmer, IT NEVER STOPS.  There never comes a time when you
have "learned your job".  I learned as much last year as I did the
very first year <mumble> years ago.

So, again, get that learning muscle in good shape!

Be Patient with Yourself!
=========================
Learning anything complicated takes time.  Some say it takes about
ten years to become truly "expert" in something.  So understand
that it won't happen overnight.

It Does Get Better
==================
The more you learn, the more you have to help you learn new things.
After you've learned half a dozen languages or so, learning new
ones gets easier, because you only need to learn the new bits--
much of your existing knowledge will be useful.

As a trivial example, once you've learned about if/elseif/else,
learning that part of a new language just involves learning how
that language does something you already understand.


HTH,
-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude <Chris@Sonnack.com> wrote in message news:<40339721.207696D0@Sonnack.com>...
> grumple wrote:
> 
> > My question is hopw does one learn things...
> 
> You gotten some good answers.  Just some random thoughts from me...

[snip some good random thoughts]

> It Does Get Better
> ==================
> The more you learn, the more you have to help you learn new things.
> After you've learned half a dozen languages or so, learning new
> ones gets easier, because you only need to learn the new bits--
> much of your existing knowledge will be useful.
> 
> As a trivial example, once you've learned about if/elseif/else,
> learning that part of a new language just involves learning how
> that language does something you already understand.

There seems to be a 'critical mass' in learning to program that
describes the point at which you no longer need to spend much time
learning how, for instance, a conditional construct works in a new
language.  It speeds up learning, more importantly allowing the new
programmer to go beyond 'learning programming' towards 'learning how
to apply programming to things'.

Of course, such critical mass can also lead to stumbling over
something rather different like prolog or lisp, if one is very used to
the c / pascal / basic kinds of language.

In article <ab7b29fc.0402180145.9eaf54d@posting.google.com>, forgoogle2003@yahoo.co.in (grumple) wrote:
>My question is hopw does one learn things like one program file - will
>compile to several separate class files. It is given in some books but
>not in all.How many will remember to use the dir command after the
>javac to see this? And will you register that there are 3 files after
>the dir. You'll be ina hurry to try the java interpreter on the .class
>I have referred Java 2 Complete Reference by Schildt. I basically went
>through the book cover to cover reading, didn't make sense typing in
>from the book, I just went through the concepts, and now I'm doing a
>project. I've done some C before so this is not my fisrt language. How
>does one learn thse fundamentals.

Your subject says it all - long, tearful experience.

Programming is a craft, you learn by doing.  Books are helpful, but you 
should not expect to learn programming from books.

- Gerry Quinn

gswork wrote:

> There seems to be a 'critical mass' in learning to program that
> describes the point at which you no longer need to spend much time
> learning how, for instance, a conditional construct works in a new
> language.

This made me think of a related phenomina that most programmers I
ask say they know well.

As you work on a non-trivial program, the code size and functionality
space grow.  But at some point, you begin to truly understand the
real shape of the problem and THEN the code size begins to actually
shrink (while functionality space continues to grow).  What seems to
have happened at that point is that you're "in control" of the code
and are making it ever more effective and efficient.

To a large extent, this is what makes me think of programming as
"sculpting".

> Of course, such critical mass can also lead to stumbling over
> something rather different like prolog or lisp, if one is very 
> used to the c / pascal / basic kinds of language.

Smalltalk was (and still is, since I gave up) a challenge, because
the tutorial I had jumped from ultra-trivial to non-trivial and
I lacked the patience to work out on my own how you went from just
typing in expressions to building a working full program (in fairness
to Smalltalk, at the time I was just idly dabbling, and I liked the
language, so it's filed for future reference).

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude <Chris@Sonnack.com> wrote in message news:<4035071F.77BB67A2@Sonnack.com>...
> ... But at some point, you begin to truly understand the
> real shape of the problem and THEN the code size begins to actually
> shrink (while functionality space continues to grow)....
> 
> To a large extent, this is what makes me think of programming as
> "sculpting".

Yes!!

I would encourage programmers to learn to type fast and plan
to throw away a lot of code; not because it's "bad" code, but
because it can be made *better*.

Sometimes a programmer will set out to create the concise system
that "can do overything" from scratch, but it may be made unwieldy
by features that turn out to be unneccessary.  Better to make good
implementions for specific cases the user wants, and look to "sculpt"
them into common routines after they're working.

If I can be forgiven for plugging my Website, Yet One More Time,
I touch on this briefly at
http://freepages.genealogy.rootsweb.com/~jamesdow/Tech/lesson5.htm#a3
" Simplicity may require retyping working code. "

James

Programmer Dude <Chris@Sonnack.com> wrote in message news:<4035071F.77BB67A2@Sonnack.com>...
> gswork wrote:
> 
> > There seems to be a 'critical mass' in learning to program that
> > describes the point at which you no longer need to spend much time
> > learning how, for instance, a conditional construct works in a new
> > language.
> 
> This made me think of a related phenomina that most programmers I
> ask say they know well.
> 
> As you work on a non-trivial program, the code size and functionality
> space grow.  But at some point, you begin to truly understand the
> real shape of the problem and THEN the code size begins to actually
> shrink (while functionality space continues to grow).  What seems to
> have happened at that point is that you're "in control" of the code
> and are making it ever more effective and efficient.
> 
> To a large extent, this is what makes me think of programming as
> "sculpting".

What an excellent comparison! 

> > Of course, such critical mass can also lead to stumbling over
> > something rather different like prolog or lisp, if one is very 
> > used to the c / pascal / basic kinds of language.
> 
> Smalltalk was (and still is, since I gave up) a challenge, because
> the tutorial I had jumped from ultra-trivial to non-trivial and
> I lacked the patience to work out on my own how you went from just
> typing in expressions to building a working full program (in fairness
> to Smalltalk, at the time I was just idly dabbling, and I liked the
> language, so it's filed for future reference).

I had this experience, perhaps with even less perserverance , with
IIRC dolphin smalltalk.  The expressions things was cool, but moving
on from there did appear to be quite a leap and so, quite a
commitment.  Moving 'sideways', e.g. from pascal to c, is less
demanding

gswork wrote:

>> Smalltalk was (and still is, since I gave up) a challenge, because
>> the tutorial I had jumped from ultra-trivial to non-trivial and
>> I lacked the patience to work out on my own how you went from just
>> typing in expressions to building a working full program (in
>> fairness to Smalltalk, at the time I was just idly dabbling, and I
>> liked the language, so it's filed for future reference).
> 
> I had this experience, perhaps with even less perserverance , with
> IIRC dolphin smalltalk.  The expressions things was cool, but moving
> on from there did appear to be quite a leap and so, quite a
> commitment.

Now I don't feel so bad!  Was Dolphin in my case as well.  (-:

The interesting thing--talking about the sculpting metaphor--is
that Smalltalkers (from what I gathered during a few months of
lurking in the comp.lang.smalltalk) very much work in that mode.
Even the IDE--which I believe is a defined part of the language--
is heavily "sculpted" by the programmer.

Which, as you might imagine, can be an issue if you sit down at
a co-worker's Smalltalk!


> Moving 'sideways', e.g. from pascal to c, is less demanding

Sure.  They're both flavors of Algol.  (-:

Which is exactly why it's good to learn languages like Lisp and ST.
They take you pretty far outside that Algol mindset.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude <Chris@Sonnack.com> writes:

> gswork wrote:
>
>>> Smalltalk was (and still is, since I gave up) a challenge, because
>>> the tutorial I had jumped from ultra-trivial to non-trivial and
>>> I lacked the patience to work out on my own how you went from just
>>> typing in expressions to building a working full program (in
>>> fairness to Smalltalk, at the time I was just idly dabbling, and I
>>> liked the language, so it's filed for future reference).
>> 
>> I had this experience, perhaps with even less perserverance , with
>> IIRC dolphin smalltalk.  The expressions things was cool, but moving
>> on from there did appear to be quite a leap and so, quite a
>> commitment.
>
> Now I don't feel so bad!  Was Dolphin in my case as well.  (-:
>
> The interesting thing--talking about the sculpting metaphor--is
> that Smalltalkers (from what I gathered during a few months of
> lurking in the comp.lang.smalltalk) very much work in that mode.
> Even the IDE--which I believe is a defined part of the language--
> is heavily "sculpted" by the programmer.
>

In fact, one might say a reasonable explanation of how one does
construct a program in Smalltalk is that one modifies the IDE until it
is running the program.  Then you're done. :-)

Anyone truly interested in learning how to use Dolphin ought to
consider reading Ted Bracht's _The Dolphin Smalltalk Companion_, which
does a good job of explaining the MVP framework at the heart of
Dolphin (by way of showing how to develop a sample application).  That
and read comp.lang.smalltalk.dolphin which is full of helpful people.
As I've said before, I think that Dolphin is a great match for (but by
no means limited to) the type of applications that VB is meant for.

All that said, I still prefer Lisp. :-)

-- 
Howard Ding
<hading@hading.dnsalias.com>

"Howard Ding " wrote:

> In fact, one might say a reasonable explanation of how one does
> construct a program in Smalltalk is that one modifies the IDE
> until it is running the program.  Then you're done. :-)

Yeah, so I hear!

> Anyone truly interested in learning how to use Dolphin ought to
> consider reading Ted Bracht's _The Dolphin Smalltalk Companion_,

Thanks for the recommendation!!  I very much want to return to
Smalltalk.  (I consider not knowing more about it a flaw.)

> All that said, I still prefer Lisp. :-)

Between the two, I'd pick Lisp, too.

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

Programmer Dude <Chris@Sonnack.com> writes:

>
> Yeah, so I hear!
>
>> Anyone truly interested in learning how to use Dolphin ought to
>> consider reading Ted Bracht's _The Dolphin Smalltalk Companion_,
>
> Thanks for the recommendation!!  I very much want to return to
> Smalltalk.  (I consider not knowing more about it a flaw.)
>

The only thing to watch out for is that there are a few small typos
and so on which aren't necessarily obvious.  There's a companion
website that has corrections and of course the newsgroup.  Plus I
think there's source code for everything in the book that works (one
problem I remember was when the book had omitted a needed method or
something like that that could be tracked down that way).  And the
book is based on Dolphin 4 whereas Object Arts is now on Dolphin 5 and
nearly to Dolphin 6.  Still, all in all a good way to get with making
Dolphin apps.

-- 
Howard Ding
<hading@hading.dnsalias.com>

Hi,

I was asked to check out the jar utility. I went to the java.sun.com
website and it gave 4 options in a table

jar cf jar-file include-file(s) - to create jar files
jar tf - to list, then jar xf - to extract., then finally java -jar
jar-file - to execute an application in a jar file. There are options
like 'v' for verbose, 'm' for manifest. My boss asked me to look up
more on this tool. My question is once you've tried the above 4
options which takes a jiffy, what more to try, how to play with this
tool or any tool in general. I'm not able to get the dynamics.

Thanks
Grumple


gerryq@indigo.ie (Gerry Quinn) wrote in message news:<R%0Zb.3588$rb.59461@news.indigo.ie>...
> 
> Your subject says it all - long, tearful experience.
> 
> Programming is a craft, you learn by doing.  Books are helpful, but you 
> should not expect to learn programming from books.
> 
> - Gerry Quinn