Question for Java Gurus

[Galen Boyer]

Put another way - in the early stages of learning a language or
library, there are a lot of facts to pick up. A good ide hides
some of that complexity. You will need to learn it eventually,
which is why I also get them using ANT fairly quickly, but I
want their first Java efforts to be pointed at the classes and
what that means, rather than at the mechanics. Let an IDE make
those mechanics easier during the early stages, so that they
stay focussed not on code, but on solving their problems with
it.

The only problem I see with this approach is that you've set the
expectation that they won't need to know it. Alot of them will
spend the rest of their programming lives staying away from the
guts because their first taste was with something that "just
worked". Why should I have to do that work? Then, in the middle
of a development effort, their IDE craps out, doesn't support
something, the admin guy is on vacation, ... and they are SOL.

Sort of like most java programmers I run across that code against
databases. Somebody at a beginning java class spouted "Database
Independence" and three years into their career, they still can't
code a "group by", and the "Database Independence" translated to
"Database Ignorance".

 

[Galen Boyer]

I suspect that the difference lies in how fundamental we
think those concepts are. [...]

This is analogous to java programmers thinking they can code
database applications without understanding the underlying
database. Oh, I'm sorry, the JVM is the only world one needs
to know.

Well, I'm sure you won't be surprised to find that I disagree.

What we're talking about in this case are two different ways to
provide the same information to the JVM. One is rather more
convenient because it makes use of both persistent knowledge
about the subject matter (which JAR files and classes
correspond to which libraries) and GUI interfaces (adding
things to a list rather than redefining an environment
variable). The other works, but is rather arcane.

No, its different, but setting an environmental variable is not
an arcane operation, especially for a programmer.

And we're talking about an educational environment: which
things should be taught.

How to program involves understanding the environment as well as
the language. The best programming teacher I ever had was an
author of a compiler. He not only taught us how to program but
what was going on as the compile translated what we wrote to what
it could understand.

The motivations for teaching a concept are (a) how relevant it
is to the teaching goal, and (b) how necessary it is for the
student to make progress.

It isn't progress if the programmer is completely dependent on a
tool or some admin guy to set up his environment for him.

Clearly, setting the CLASSPATH environment variable is neither
the point of teaching programming, nor necessary to succeed in
Java programming, assuming you have the right tools.

Look at your assumption and you see your flaw.

The choice of setting PATH and CLASSPATH versus using an
integrated environment is relevant to neither functionality nor
any other characteristic of the result of programming.

Understanding one's environment is expected, so it should be
taught. Just because there are tools around that might make it
so you don't have to perform that operation doesn't mean those
operations are now, somehow, arcane and don't need to be
understood.

That's clearly different from a database, where the information
model of the database, its performance characteristics, and its
features have a direct impact on the software development
process.

Man, I can't believe you don't think there are performance
characteristics of the JVM.

 

[Ryan Stewart]

I must be missing something here. It seems to me that, if students are
constantly running into problems with the details of command-line Java
tools (such as classpath and the like), then it would be best if they
didn't use those command-line Java tools. You seem to conclude the
opposite; that they should face them head-on and overcome their
difficulties.

Others have made some good replies, so I'll be short. I wasn't talking about
people running into classpath issues while doing command line work. I'm
talking about the multitude that have classpath issues and don't even know
what the word "classpath" means because their IDE has been shielding them
from it. Whatever your opinions otherwise, you must acknowledge that the
Java classpath is at the very core of how Java works, that it must be set
properly in one way or another for *any* Java-based application to work, and
that a programmer that knows about it is better able to diagnose
NoClassDefFoundErrors than one that doesn't.

 

[Galen Boyer]

you must acknowledge that the Java classpath is at the very
core of how Java works, that it must be set properly in one way
or another for *any* Java-based application to work, and that a
programmer that knows about it is better able to diagnose
NoClassDefFoundErrors than one that doesn't.

But, based on what they are saying, all you need is a proper
tool. If you get that error, you should just find a new
IDE. But, wait a minute, isn't downloading from the web an arcane
operation?

 

[Bradley E. Rintoul]

On Tue, 18 May 2004, (e-mail address removed) wrote:


This is analogous to java programmers thinking they can code
database applications without understanding the underlying
database. Oh, I'm sorry, the JVM is the only world one needs to
know.

Man, talk about a broad stroke! "java programmers" know nothing about databases!

Oh I'm sorry, *you're world* must be the only world one needs to know.

 

[Galen Boyer]

Man, talk about a broad stroke! "java programmers" know
nothing about databases!

Oh I'm sorry, *you're world* must be the only world one needs
to know.

Nope. Met quite a few java programmers that are quite good at db
work. Understand what they are good at and that there are major
differences between the platforms. But I've met far more that
think it is a black box and they should be able to treat it that
way.

 

[Joona I Palaste]

Bradley E. Rintoul <[email protected]> scribbled the following

Man, talk about a broad stroke! "java programmers" know nothing about databases!

Oh I'm sorry, *you're world* must be the only world one needs to know.

If I understand Galen right, he said that not all Java programmers
know how to code databases. You then take this to mean that no Java
programmer knows anything about databases.
Oh I'm sorry, all Java programmers are 100% exact clones of each
other.

 

[Chris Uppal]

And we're talking about an educational environment: which things should
be taught. The motivations for teaching a concept are (a) how relevant
it is to the teaching goal, and (b) how necessary it is for the student
to make progress. Clearly, setting the CLASSPATH environment variable
is neither the point of teaching programming, nor necessary to succeed
in Java programming, assuming you have the right tools. The choice of
setting PATH and CLASSPATH versus using an integrated environment is
relevant to neither functionality nor any other characteristic of the
result of programming.

I can see your logic, but I find it unconvincing.

The problem is that (in my experience with Java IDEs) getting the relevant
settings right is at least as difficult as it is in a command-line environment.
And that's a problem -- in a command line env, the beginning programmer is
seeing the issues clearly separated out from other issues. He or she can see
where the classfiles are being generated, can change directories and re-run the
java command, and so on. I.e. he or she is getting a chance to learn the
abstract concepts of "locating classfiles" in a way that doesn't mix in a load
of other issues.

In a typical IDE, in my experience, the same problems of locating stuff arise,
but the "solution" is buried in ISE settings, and arcane (unless you already
understand the concepts) library lists. All the would-be programmer is going
to learn is how to treat a /specific/ IDE as a black box and a magical recipe
to "make it work" -- not a valuable learning experience.

OK, that's exaggerating slightly, but not much, and only to make the point
clear.

-- chris

 

[Chris Uppal]

I still have to disagree. The fact that people have misconceptions or
are not fully informed about available IDEs does not make ignoring the
most appropriate solutions good advice.

Fair enough. But | think my POV can be expressed by considering the
hypothetical, but IMO quite plausible, response of an imaginary newcomer to
Java (not a newcomer to programming, which is a different population).

"Hmm, I'm told that BlueJ is good to start with."
....checks www.bluej.org...
"Ah, this is a tool for beginners -- I'm no beginner,
I don't need hand-holding, I want the Real Meat!
BlueJ is like <insert IDE here>, only cut down
for beginners, so I'll use <insert IDE here> instead
of wasting time with a toy"

I hope it's obvious that I /don't/ think BlueJ is a cut-down IDE, or a toy, but
I can see how I might have thought that if I'd been starting out in Java today
(with years of C++ behind me).

BlueJ has downloads of about 40,000 a months and is used for teaching
at least at 500 universities and training institutions around the
world - that is a large enough user base to make some reasonably
confident statements about it.

That's very impressive!

It makes it somewhat puzzling (I'm not being snide here) that it doesn't get
mentioned more. I downloaded the latest version yesterday (40,001 downloads
now ;-) and played with it for a couple of hours. Not a real test by any
means, but I liked what I found. I'm quite likely to /use/ it for real code
too. (I have some reservations about the editors handling of tabs and spaces,
but I assume I can fettle that somehow). I wonder if the "problem" with BlueJ
getting mindshare is that it isn't obvious that it /can/ be used for real code,
so people use it for a while, and then think they /have/ to graduate to a
"real" IDE to do real work. It obviously isn't suitable (the UI design) for
handling large numbers of classes in a package -- but I'm not sure that large
numbers of classes /should/ be in one package... Other than that I found the
simplicity and absence of "fluff" appealing and effective.

One thing I noticed is that BlueJ doesn't foreground the notion of package --
it puts stuff in the default package for instance. I can see that
simplification is highly desirable for beginning (and perhaps not too talented)
programmers -- a programming class as part of a normal school curriculum for
example. But it isn't really appropriate for anyone who is already a
programmer, and who wants to start Java -- the package concept is just too
central to Java to be glossed-over. it took me some time to find how to put
code into packages in BlueJ, and the process is more than a little tedious
(error message telling me I have to create a package first instead of giving me
the option to create one, not possible to move a class into a package from the
UI -- drag-n-drop say -- you have to enter a package statement in the editor,
no option to create a package for a project at the same time as the project
itself, etc). I suggest an option to make BlueJ more package-friendly (similar
to the way JUnit support can be activated). Perhaps too, an option to switch
to a less hand-holding set of templates. The idea being that a user can at
some /appropriate/ time (maybe straightaway, maybe never) switch BlueJ into a
mode that is more suited to serious programming, and thus postpone the day when
he or she has to start coping with the complexities of Eclipse, etc.

I'm not trying to suggest that you should position BlueJ as anything but an
educational IDE. But if I'm right in suspecting that people don't recommend
BlueJ because their memory of it is as something they had to graduate from
before the could be a "real" programmer, then a few /optional/ tweaks to the UI
might help you gain mindshare in the "pro" community.

Or maybe the community is just too obsessed with complexity...

I think, essentially, we are on the same wavelength here.

So it seems. I think I shall add BlueJ to my recitation of the "standard
advice" from now on.

-- chris

 

[Chris Uppal]

I disagree - I think that general advice is incorrect in many cases. A
good ide like IDE or Eclipse can help a student stay focussed on
objects, rather than syntax.

I don't agree with this in general, but I think I've already made my point as
clearly as I can.

I just wanted to reply to a couple of specifics.

Learning javac, directories, jar files and command syntax, and the like
can be useful, and will be important to a student eventually.

I take it as starting point that command line, directories, and files are
understood. If that's not the case then it's something that has to be fixed
independently of, and before, learning Java.

Jar files now, are something else. I think that I'd recommend ignoring them
entirely as an "advanced" topic that is not needed (and indeed hinders) basic
understanding. I'd suggest to any beginner, experienced programmer or not,
that (if they aren't using BlueJ ;-) they set their classpath to point to /one/
directory, and that they compile with the options to put the output into that
directory always (use a shell script to compile). That's how I started out
(though it took me some time to work out that that was a good way of working
because there's no guidance on how to keep things /simple/ in the Java world,
complexity-obsessed as it is). It's surprising just how very effective that
settup is. I'm still using essentially the same thing now...

To me, you learn best by doing. Thus, the best way to learn how to
write decent classes is to write some, and then go through a critique.
I would rather they spend much of their early time thinking about the
result, rather than the process of getting there.

I don't entirely agree. I think the best way (or an important part of it) to
learn how to write decent classes is to interact with their instances. Yes, I
agree that practise in writing *lots* of classes is a very, very, good thing,
and of course the value of critique (if it's available) is inestimable. But if
you haven't worked in an environment where you are always in touch with your
objects, then you probably don't realise how enlightening that experience is.
Of course, running from the command-line isn't "being in touch with the
objects" either but at least the tools don't get in the way.

Put another way - in the early stages of learning a language or library,
there are a lot of facts to pick up. A good ide hides some of that
complexity. You will need to learn it eventually, which is why I also
get them using ANT fairly quickly, but I want their first Java efforts
to be pointed at the classes and what that means, rather than at the
mechanics. Let an IDE make those mechanics easier during the early
stages, so that they stay focussed not on code, but on solving their
problems with it.

But -- with the exception of BlueJ -- I just don't agree that the current crop
of IDEs do that. They /could/, but they don't. They just give you another
layer of complexity, another tool to learn, and another distraction from the
task at hand.

I guess we just disagree ;-)

-- chris

 

[Chris Smith]

Others have made some good replies, so I'll be short.

That's okay. I much prefer your reply to the insulting rhetoric coming
from Galen.

I wasn't talking about
people running into classpath issues while doing command line work. I'm
talking about the multitude that have classpath issues and don't even know
what the word "classpath" means because their IDE has been shielding them
from it.

Okay, in which case it's clear that their environment is impeding their
success at learning Java. At that point, it's necessary to either teach
how to use it or choose a different tool. Of course, I'm not advocating
switching tools; that has an inherent cost so that it's best to probably
plow ahead and teach the student how to locate their third-party classes
in whatever environment has been chosen. And I'm all for choosing an
environment that's conducive to learning and understanding; and that's
more likely to be the command line than it is to be Eclipse, for
example.

But I don't think it *has* to be the command line. BlueJ is very
promising in terms of making things work without dealing with classpath
issues.

Whatever your opinions otherwise, you must acknowledge that the
Java classpath is at the very core of how Java works, that it must be set
properly in one way or another for *any* Java-based application to work, and
that a programmer that knows about it is better able to diagnose
NoClassDefFoundErrors than one that doesn't.

You see, I don't acknowledge that. The classpath falls into the realm
of "making your tools work". In the context of teaching computer
programming, that's a negligible space of education. The classpath is a
fundamental concept of neither programming in general nor the Java
programming language. The JVM spec, for example, suggests the classpath
as one possible implementation of locating Java classes, but in no way
requires its use. The only reason it seems any more sensible to call
CLASSPATH a core part of Java than, for example, calling some specific
method of location C's angle-bracket includes a core part of C, is that
Java virtual machines happen to implement it a little more consistently.

On top of that, in practice few Java developers need to deal with
classpath issues in their regular line of work. Probably the vast
majority of Java code is written in a servlet or EJB environment, in
which there are other ways of providing references to third-party
libraries (e.g., WEB-INF/lib), and use of the classpath in the invoking
JVM is terribly poor form and non-portable. Applets can't reasonably
use the classpath. The majority of application code, which is the major
remaining bit, ought to be deployed as executable JAR images or Java
WebStart applications, in which case the standard mechanisms for setting
classpath are ignored entirely.

IMHO, the only possible justification for teaching the classpath to
programming students is that they might need to deal with it in order to
see the immediate results of their work in simple test code. If they
can see the results of their work otherwise without incurring other
negative consequences, then why bother?

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

[a lot of stuff]

I don't find it promising to engage in this conversation, given your
insulting tone and your preference to pick out ways to mock me by
misconstruing my comments instead of actually reading what I said.

Best of luck,

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Ryan Stewart]

That's okay. I much prefer your reply to the insulting rhetoric coming
from Galen.


Okay, in which case it's clear that their environment is impeding their
success at learning Java. At that point, it's necessary to either teach
how to use it or choose a different tool. Of course, I'm not advocating
switching tools; that has an inherent cost so that it's best to probably
plow ahead and teach the student how to locate their third-party classes
in whatever environment has been chosen. And I'm all for choosing an
environment that's conducive to learning and understanding; and that's
more likely to be the command line than it is to be Eclipse, for
example.

But I don't think it *has* to be the command line. BlueJ is very
promising in terms of making things work without dealing with classpath
issues.

I think we're seeing eye to eye here now.

You see, I don't acknowledge that. The classpath falls into the realm
of "making your tools work". In the context of teaching computer
programming, that's a negligible space of education. The classpath is a
fundamental concept of neither programming in general nor the Java
programming language. The JVM spec, for example, suggests the classpath
as one possible implementation of locating Java classes, but in no way
requires its use. The only reason it seems any more sensible to call
CLASSPATH a core part of Java than, for example, calling some specific
method of location C's angle-bracket includes a core part of C, is that
Java virtual machines happen to implement it a little more consistently.

On top of that, in practice few Java developers need to deal with
classpath issues in their regular line of work. Probably the vast
majority of Java code is written in a servlet or EJB environment, in
which there are other ways of providing references to third-party
libraries (e.g., WEB-INF/lib), and use of the classpath in the invoking
JVM is terribly poor form and non-portable. Applets can't reasonably
use the classpath. The majority of application code, which is the major
remaining bit, ought to be deployed as executable JAR images or Java
WebStart applications, in which case the standard mechanisms for setting
classpath are ignored entirely.

IMHO, the only possible justification for teaching the classpath to
programming students is that they might need to deal with it in order to
see the immediate results of their work in simple test code. If they
can see the results of their work otherwise without incurring other
negative consequences, then why bother?

I see where you're coming from, but still can't entirely agree. Whether
you're developing webapps or applets or whatever doesn't matter at all. You
still have to compile into class files, and for that the compiler has to
know where to go to get the details of the pertinent classes. However your
IDE chooses to implement it, it's essentially the classpath. I've seen a
fair bit of confusion among new programmers using NetBeans about "why class
X can't see class Y". (The NetBeans classpath includes any directory or JAR
that's "mounted".)

 

[Chris Smith]

I see where you're coming from, but still can't entirely agree. Whether
you're developing webapps or applets or whatever doesn't matter at all. You
still have to compile into class files, and for that the compiler has to
know where to go to get the details of the pertinent classes. However your
IDE chooses to implement it, it's essentially the classpath. I've seen a
fair bit of confusion among new programmers using NetBeans about "why class
X can't see class Y". (The NetBeans classpath includes any directory or JAR
that's "mounted".)

Let's draw a distinction (and it's an important one, in my view) between
the general concept that a compiler and application need to be told the
location of their code, and the specific mechanism of doing so.
Certainly students need to be taught that they have to specify the
location of their code to development tools. But it's the mechanism of
doing so in the command-line tools that I don't think of as a core
educational goal.

Clearly, that mechanism differs in practice depending on the environment
and tools, as I explained before. Yes you need to specify the location
of code in all cases, but in my experience more people are tripped up by
the mechanism of doing that, rather than by the need to do it in the
first place.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Ryan Stewart]

Let's draw a distinction (and it's an important one, in my view) between
the general concept that a compiler and application need to be told the
location of their code, and the specific mechanism of doing so.
Certainly students need to be taught that they have to specify the
location of their code to development tools. But it's the mechanism of
doing so in the command-line tools that I don't think of as a core
educational goal.

Clearly, that mechanism differs in practice depending on the environment
and tools, as I explained before. Yes you need to specify the location
of code in all cases, but in my experience more people are tripped up by
the mechanism of doing that, rather than by the need to do it in the
first place.

Still, how do IDE's compile code? They call javac, just as you would from
the command line. You just don't see it happening. This is why some people
(including myself) recommend doing a little compiling on your own, just so
you can see what's going on behind the scenes and have a frame of reference
for what the IDE is actually doing. As for the classpath setting itself, any
IDE or J2EE container I've ever seen passes a classpath to javac.exe and/or
java.exe. Your development and runtime environments don't matter. The
classpath must always be there unless, as you said earlier, you're using
some odd compiler that decides to implement it differently. But then it
would just be the same thing under a different name, I think.

 

[Chris Smith]

Still, how do IDE's compile code? They call javac, just as you would from
the command line. You just don't see it happening.

Sometimes that's true. On the other hand, I use Eclipse, which contains
its own compiler and doesn't use javac at all. I'm not aware of any
ability to use Eclipse's compiler from the command line, and I doubt
there exists code to parse a "-classpath" command line option or to read
the CLASSPATH environment variable from within Eclipse.

So you say:

unless, as you said earlier, you're using
some odd compiler that decides to implement it differently. But then it
would just be the same thing under a different name, I think.

As for whether Eclipse's compiler works in a similar way, there are
perspectives from which it does, and perspectives from which it doesn't.
It certainly offers the same basic choices (add a JAR file or a
directory of classes) at its core, and there are *some* of the same
problems that could trip people up (for example, I could see someone
accidentally adding a directory to an Eclipse user library configuration
and expecting all the JAR files in that library to be added), but there
are others that simply don't apply (such as whether to use ; or : as a
path separator, or most importantly where to set an environment variable
in your specific operating system so that it's consistently available).

Given that Eclipse is probably one of the most commonly used Java
compilers out there, I don't think it's quite fair to characterize non-
classpath implementations of compilers as a fringe case. Instead, it
makes sense to admit that the mechanism of locating code is pretty much
unspecified, and that some tool sets use CLASSPATH as their
implementation because it's the only suggestion provided by the (non-
normative section of the) specification. It then makes sense to treat
the characteristic of calling javac behind the scenes as an
implementation detail... one that might or might not be there, and that
could be easily changed in the future without changing the expected
behavior of the environment.

Speaking of virtual machines, you have an initially stronger argument in
that most common virtual machines use something like CLASSPATH (except
that some third-party implementations lack Sun's rt.jar special case, so
you have to locate the system classes and include them in the CLASSPATH-
equivalent mechanism, so there are still differences). Except that this
is exactly when non-application code (such as servlets, applets,
midlets, etc.) and applications packaged as executable JAR files start
to be an exception, so that worrying about classpath is largely limited
to applications distributed as a bundle of loose class files.

This is why some people
(including myself) recommend doing a little compiling on your own, just so
you can see what's going on behind the scenes and have a frame of reference
for what the IDE is actually doing.

But this is assuming that the IDE is using javac as its compiler, and/or
that you're running your code as an application.

I certainly don't mean to overstate my case. I don't want to encourage
new developers to grab Eclipse, or any other environment that adds too
much complexity to be easily used. I just think a sort of cult
following has grown around the advice to avoid IDEs when learning, and
it reflects unfairly on options like BlueJ, which is designed for
learning and does an excellent job of it; or on simple environments like
JCreator, for that matter, which is simple enough to help Java students
without adding extra matters to confuse things.

Simply put, although I think many IDEs get in the way of learning, I
don't think that'd true even remotely because they save you from
CLASSPATH hassles. CLASSPATH hassles are the opposite of good education
in programming, not its goal, and any way you can find to avoid them is
progress.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[javac]

I can agree with you on all but your third point. I would like to say a
majority, but I'll limit it to "a whole lot" of the newbs that come through
the groups (not mailing lists, btw) are having problems related to either
classpath or directory structure. If everyone took the time to at least
write their "Hello World" program in a text editor and compile and run it at
the command line, I suspect we'd all be better off.

i'm happy with the command-line stuff i *already* know. however, i've
yet to use a class path. i'm ok with vi/pico/choose your poison. in
fact, i'd happily muck around in those.

i'm on a mac (the one with the hemisphere base and swivel screen) at
an internet cafe. having no idea how to use fetch, i spent five
minutes finding the console to use ftp the old-school way.

once you know how to burn a cd-rom with the command line, for example,
it's easy. however, as a newbie, i still have no idea how to compile
a java program. i don't want to mess around with settings, just hit
compile foo.java + extraneous switches/whatever.

i'm waiting for "head first java" to arrive from the library so i can
take a closer look at this. learning command line stuff from scratch
(say, from windowsXP) would probably confuse people.

(e-mail address removed)

 

[Michael K?lling]

Still, how do IDE's compile code? They call javac, just as you would from
the command line. You just don't see it happening. This is why some people
(including myself) recommend doing a little compiling on your own, just so
you can see what's going on behind the scenes and have a frame of reference
for what the IDE is actually doing.

I fail to see how typing "javac ..." compared to clicking a "Compile"
button enlightens you any more about what is going on "behind the
scenes".

How are you doing "compiling on your own" when invoking the compiler
via a text command, but not when you invoke it via a button? The
difference is completely arbitrary. It is as if I argure that you only
do it properly when you type in the raw ASCII codes for the
invocation...

The question here seems to be the exact line people draw between
accepted abstraction and "magic that keeps you dumb". The problem is
that the real criteria people use to draw this line usually is: the
way I have learned it myself is the only real way to do it.

I have talked to many people who argued that students need to learn
assembly language first to properly understand what they are doing (of
course these are usually the people who themsleves started with
assembly language), others argue that everyone should at least know
how the compiler works (those are the ones that ...), and others argue
that you need to learn procedural programming before you can
understand OO (those are the ones -- you get the idea).

Arguing that invoking a compiler with a text based commend is better
(more "doing it on your own") is in the same spirit, me thinks.

Cheers,

Michael

 

[Andrew Thompson]

I fail to see how typing "javac ..." compared to clicking a "Compile"
button enlightens you any more about what is going on "behind the
scenes".

It's not in the 'javac', it's in the '...'. ;-)

Knowing how to set those parameters and
the effect that they have, then enables
you to configure most IDE's to do more
subtle things than can otherwise be
achieved by 'clicking a button'.

 

[Mohun Biswas]

I have talked to many people who argued that students need to learn
assembly language first to properly understand what they are doing (of
course these are usually the people who themsleves started with
assembly language), others argue that everyone should at least know
how the compiler works (those are the ones that ...), and others argue
that you need to learn procedural programming before you can
understand OO (those are the ones -- you get the idea).

I think it would be more fair to suggest that the metric such people are
using is "the lowest level you MIGHT have to drop down to". I didn't
start with assembly language, for instance, so your thesis doesn't apply
to me. But I *am* stymied on a project right now by my lack of assembly
experience (I need to overwrite some stack pointers and haven't found
the time yet to go groveling around learning the assembly stuff). That's
a legitimate case where I have to drop down to a level I wouldn't
normally have to.

By the same token, people who argue that you should learn your way
around outside the GUI are afraid that some day you'll need to do
something the GUI/IDE doesn't handle for you. Or that you'll need to
work around a bug in the IDE. Using Windows for analogy, I cannot count
the number of times some GUI has let me down and I had to straighten out
the problem by going to a command-line tool, or direct to the registry,
or whatever. And since the GUI never tells you what config file or
registry entry it's modifying under the surface, it's a classic case of
"magic that keeps you dumb". And I've used plenty of other tools whose
GUI's either (a) have bugs requiring you to bypass them at times or (b)
only cover some fraction of the functionality available in the
underlying engine.

Bottom line, when IDE's work so reliably and cover all possible use
cases, the learn-the-command-line people will fade away. But that hasn't
happened yet.