Do we have educational IDEs?

[Thomas G. Marshall]

Dale King coughed up:

Very bad idea. Using the command line tools requires you to understand
concepts that you don't have the proper frame of reference to
understand until you get a good footing in the language. Try
explaining what a class path is when the person doesn't even
understand what a class is. Everyone should learn the command line
tools, BUT not until you know the language.

That IMO is entirely backwards.

A new user of java absolutely /needs/ to "learn the ropes" of how to get the
shipped compiler to work. For the most part they learn how to just get it
going using a tutorial, and then they learn the ins and outs of /why/.

They do not need to fully understand what a class is to get a classpath to
work. Furthermore, learning how to control (not understand) a classpath is
something they're going to need to understand sooner or later, so it might
as well be something they are confronted with early on.

Usually, when teaching a new language, I (or everyone else I know who has
taught anything), starts off with how to get something akin to the hello
world example to run. Even when I teach folks with an IDE, I go through the
steps needed to configure, compile and run a HW app.

And I /want/ them to use the editor, compiler, JVM, and documentation html
separately, so that they can have a better chance at understand what goes on
within an IDE.

Geez Dale, what happened? All of your posts dropped out of the sky all at
once.

....[rip]...



--
Puzzle: You are given a deck of cards all face down
except for 10 cards mixed in which are face up.
If you are in a pitch black room, how do you divide
the deck into two piles (may be uneven) that each
contain the same number of face-up cards?
Answer (rot13): Sebz naljurer va gur qrpx, qrny bhg
gra pneqf naq syvc gurz bire.

 

[Thomas G. Marshall]

(e-mail address removed) coughed up:

Dale King wrote:
....[rip]...

BlueJ is definitely the right choice for learning the language.

As I said, BlueJ is fine choice for some folks (especially if the
focus is OOP). Whether it's "definitely the right choice" depends on
the context. A basic text editor and command line are easy to explain,
easy to learn, and are skills that are, for the most part,
programming language independent.

Yes, and even /if/ BlueJ is the end-all answer to teaching java and OOP in
general, I /still/ would want the user to feel as if he understands /how to
use/ the java sdk as shipped. IDE's just remove the user too far from the
nitty gritty, particularly IDE's that remove the concept of the file and
just allow you to create classes.



--
Puzzle: You are given a deck of cards all face down
except for 10 cards mixed in which are face up.
If you are in a pitch black room, how do you divide
the deck into two piles (may be uneven) that each
contain the same number of face-up cards?
Answer (rot13): Sebz naljurer va gur qrpx, qrny bhg
gra pneqf naq syvc gurz bire.

 

[Dale King]

Dale King coughed up:




That IMO is entirely backwards.

A new user of java absolutely /needs/ to "learn the ropes" of how to get the
shipped compiler to work.

Why? Why try to teach them something that they will not grasp and just
gets in the way of learning the language.

For the most part they learn how to just get it
going using a tutorial, and then they learn the ins and outs of /why/.

And in my experience they don't learn the why even later. They are given
a formula for compiling and running without learning the why. When
something goes wrong the have no way of figuring out how to fix it. They
will get frustrated and often they will develop what I would call
superstitions since they don't understand. In other words since they
don't understand they will often come up with their own why that doesn't
necessarily agree with reality.

They do not need to fully understand what a class is to get a classpath to
work. Furthermore, learning how to control (not understand) a classpath is
something they're going to need to understand sooner or later, so it might
as well be something they are confronted with early on.

A agree they'll need to understand it, but I disagree with the sooner.
They should learn the language to get the foundations for understanding it.

Usually, when teaching a new language, I (or everyone else I know who has
taught anything), starts off with how to get something akin to the hello
world example to run. Even when I teach folks with an IDE, I go through the
steps needed to configure, compile and run a HW app.

The plethora of posts in these groups from helpless newbies trying to
get hello world to run pretty much proves that your statements are wrong.

And with something like BlueJ the the steps take about 30 seconds to
explain. You want to compile hit the compile button, etc.

And I /want/ them to use the editor, compiler, JVM, and documentation html
separately, so that they can have a better chance at understand what goes on
within an IDE.

Don't see how that gives them any advantage.

Geez Dale, what happened? All of your posts dropped out of the sky all at
once.

I can only connect to my newsserver from home, so I download the groups
and work offline and when I connect back up they all get sent.

 

[Dale King]

There are some educators that feel using a debugger can be detrimental to
learning good programming techniques in school. Here is what one very
respected author has to say.

<http://www.skylit.com/javamethods/nodebugger.html>

There are also those that claim the earth is flat. Doesn't mean they're
right.

A debugger is invaluable for letting a newbie see what is happening. You
can teach polymorphism, but how much better to also show him that when I
step into this method it actually goes to the subclass' method not the
superclass, etc.

 

[Dale King]

(e-mail address removed) coughed up:

Dale King wrote:

....[rip]...

BlueJ is definitely the right choice for learning the language.

As I said, BlueJ is fine choice for some folks (especially if the
focus is OOP). Whether it's "definitely the right choice" depends on
the context. A basic text editor and command line are easy to explain,

Not as easy as BlueJ.

How to invoke the compiler and run the program are definitely NOT progr.
lang. independent.

Yes, and even /if/ BlueJ is the end-all answer to teaching java and OOP in
general, I /still/ would want the user to feel as if he understands /how to
use/ the java sdk as shipped. IDE's just remove the user too far from the
nitty gritty, particularly IDE's that remove the concept of the file and
just allow you to create classes.

No one has claimed that BlueJ would make them understand how to use the
SDK. How to use the SDK has to be taught as well. The issue is that it
is best to teach it after learning the language and learning the
language is best done using tools that remove those nitty-gritty details
that they won't understand.

 

[Dale King]

Put the file in the current directory and type.

% javac HelloWorld.java
% java HelloWorld

Could you clarify why this is such a bad idea? How is this conceptually
more difficult than using an IDE?

Just take a sampling of posts in comp.lang.java.help and see how often
someone has trouble doing just that. Some common problems:

- Is the JDK/bin in the path?
- Do you have a classpath set that doesn't include the current directory.
- People often type java HelloWorld.class which presents non-intuitive
error message.
- Imagine if the student finds some code and wants to try to run it
using this technique. Except that the file has a package statement in
it. I pity the poor person trying to get that to work with only the
knowledge you have given him.
- Eventually you need to start using packages which is much more
complicated. You will have to give him new instructions which will seem
to contradict what you gave him before.
- You probably eventually need to use other libraries. E.g. class
situations often have their own set of utility classes to hide some
nitty gritty details of the Java API. Once again you have to change the
directions for building.

I could go on, but I think that is a good list.

 

[Thomas G. Marshall]

Dale King coughed up:

Just take a sampling of posts in comp.lang.java.help and see how often
someone has trouble doing just that. Some common problems:

- Is the JDK/bin in the path?
- Do you have a classpath set that doesn't include the current
directory. - People often type java HelloWorld.class which presents
non-intuitive
error message.
- Imagine if the student finds some code and wants to try to run it
using this technique. Except that the file has a package statement in
it. I pity the poor person trying to get that to work with only the
knowledge you have given him.
- Eventually you need to start using packages which is much more
complicated. You will have to give him new instructions which will
seem to contradict what you gave him before.
- You probably eventually need to use other libraries. E.g. class
situations often have their own set of utility classes to hide some
nitty gritty details of the Java API. Once again you have to change
the directions for building.

I could go on, but I think that is a good list.

.....which IMO doesn't make a point one way or another. I could show you a
huge list of people asking about the language itself, which would equally
make no point.

 

[Thomas G. Marshall]

Dale King coughed up:

Why? Why try to teach them something that they will not grasp and just
gets in the way of learning the language.

It /doesn't/ get in the way! Learning the tools is important.

And in my experience they don't learn the why even later. They are
given a formula for compiling and running without learning the why. When
something goes wrong the have no way of figuring out how to fix it.
They will get frustrated and often they will develop what I would call
superstitions since they don't understand.

EXACTLY! Which is WHY they need to understand it and have it properly
taught to them in the first place.

Look, when a user gets a message that says something to the effect of "can't
find HelloWorld.main()", it would be nice if he was at least half confident
that his environment was correct!

In other words since they
don't understand they will often come up with their own why that
doesn't necessarily agree with reality.


A agree they'll need to understand it, but I disagree with the sooner.
They should learn the language to get the foundations for
understanding it.

The plethora of posts in these groups from helpless newbies trying to
get hello world to run pretty much proves that your statements are
wrong.

Again, those statements say *nothing* to your argument, and don't prove
anything one way or the other.

By its very nature in usenet you are *not* seeing all the people who don't
have a problem getting it to work.

Posts like the following are rare:

Subject: Hey guys, got HelloWorld working with no problem
Body: That's all I wanted to say

But they are (obviously) rare because people tend to post once they have
issues, not if they don't!

 

[Bill Tschumy]

There are also those that claim the earth is flat. Doesn't mean they're
right.

So now anyone who disagrees with you is the equivalent of a "flat earther"?

The issue is not cut and dry (IMO). My point is some instructors think
debuggers are a hinderance at the early stages of learning to program.

A debugger is invaluable for letting a newbie see what is happening. You
can teach polymorphism, but how much better to also show him that when I
step into this method it actually goes to the subclass' method not the
superclass, etc.

It is also another thing to get in the way.

 

[Lee Fesperman]

The issue is not cut and dry (IMO). My point is some instructors think
debuggers are a hinderance at the early stages of learning to program.

My experience is that they are a hinderance in the later stages, after learning to
program. It can inhibit better general understanding of the code. Look at your code
first to find a problem before jumping to a debugger.

 

[Andrew McDonagh]

My experience is that they are a hinderance in the later stages, after learning to
program. It can inhibit better general understanding of the code. Look at your code
first to find a problem before jumping to a debugger.

better yet, use write a (failing) unit test first and then make it pass
(i.e. TDD). Then you never (well 99.9% of the time) have to use the
debugger.

 

[Thomas G. Marshall]

Bill Tschumy coughed up:

....[rip]...

The issue is not cut and dry (IMO). My point is some instructors
think debuggers are a hinderance at the early stages of learning to
program.

IME there is a *lot* for a newbie to gain by learning debugging without a
debugger. You get to learn clever ways around things, and how to subtly
alter the code (even if only to add a println()) to have it tell you want is
wrong.

 

[Kevin McMurtrie]

"Thomas G. Marshall"

Bill Tschumy coughed up:

...[rip]...

The issue is not cut and dry (IMO). My point is some instructors
think debuggers are a hinderance at the early stages of learning to
program.

IME there is a *lot* for a newbie to gain by learning debugging without a
debugger. You get to learn clever ways around things, and how to subtly
alter the code (even if only to add a println()) to have it tell you want is
wrong.

A lot of coders could gain enormous performance improvements if they
took a look at what they were really executing rather than falling into
a routine of writing the same garbage over and over again because they
know it eventually produces the right answer. println() only tells you
what you want to see, not what you need to see.

 

[Thomas G. Marshall]

Kevin McMurtrie coughed up:

"Thomas G. Marshall"

Bill Tschumy coughed up:

...[rip]...

The issue is not cut and dry (IMO). My point is some instructors
think debuggers are a hinderance at the early stages of learning to
program.

IME there is a *lot* for a newbie to gain by learning debugging
without a debugger. You get to learn clever ways around things, and
how to subtly alter the code (even if only to add a println()) to
have it tell you want is wrong.

A lot of coders could gain enormous performance improvements if they
took a look at what they were really executing rather than falling
into a routine of writing the same garbage over and over again
because they know it eventually produces the right answer. println()
only tells you what you want to see, not what you need to see.

No, println tells you what you ask it to tell you, just like a debugger
tells you what you ask it to tell you.

 

[Timon Hinrichs]

Kevin McMurtrie coughed up:

Bill Tschumy coughed up:

...[rip]...


The issue is not cut and dry (IMO). My point is some instructors
think debuggers are a hinderance at the early stages of learning to
program.


IME there is a *lot* for a newbie to gain by learning debugging
without a debugger. You get to learn clever ways around things, and
how to subtly alter the code (even if only to add a println()) to
have it tell you want is wrong.

A lot of coders could gain enormous performance improvements if they
took a look at what they were really executing rather than falling
into a routine of writing the same garbage over and over again
because they know it eventually produces the right answer. println()
only tells you what you want to see, not what you need to see.

No, println tells you what you ask it to tell you, just like a debugger
tells you what you ask it to tell you.

Well, no the debugger tells you more than you ask. The debugger of
eclipse shows you all local and global variables. The println() -
Statement shows you what you asked at all.

But I havent found a debugger at BlueJ and the another starting IDE. To
debug is very simple in a forward programm. If you use more than one
Thread it getting more complex.
A newbie will start to debug when he learned the language and switched
the IDE.
That is what my prof said to me when I asked him about debugging. He
told me that not so many people debug as many people use println().
println() is the most used debug statement. Is that right? I like to
debug more then to use println().

 

[Bill Tschumy]

My experience is that they are a hinderance in the later stages, after
learning to
program. It can inhibit better general understanding of the code. Look at
your code
first to find a problem before jumping to a debugger.

With Java, I'll agree with you. I never use a debugger in Java. The kinds
of problems where debuggers are most useful to me (pointer arithmetic, array
bounds overruns) just don't happen in Java. Well, I guess array bounds
problems do happen, but you are immediately told what the problem is.

In almost all cases, give me a few printlns in Java and I will be happy.
When I did lots of C programming, debuggers would save my life.

 

[Lee Fesperman]

With Java, I'll agree with you. I never use a debugger in Java. The kinds
of problems where debuggers are most useful to me (pointer arithmetic, array
bounds overruns) just don't happen in Java. Well, I guess array bounds
problems do happen, but you are immediately told what the problem is.

In almost all cases, give me a few printlns in Java and I will be happy.
When I did lots of C programming, debuggers would save my life.

Yep, I've never used a debugger with Java, just println and a special thread profiler
once.

I used a debugger with C/C++ but only for very special cases. I recently wrote a major
API in C with no debugger.

My first experience with debuggers was in assembly language. We found that developers in
the group were too dependent on the debugger. They were virtually building their
programs in the debugger, producing horrible looking code.

 

[Thomas G. Marshall]

Timon Hinrichs coughed up:

Kevin McMurtrie coughed up:

"Thomas G. Marshall"


Bill Tschumy coughed up:

...[rip]...


The issue is not cut and dry (IMO). My point is some instructors
think debuggers are a hinderance at the early stages of learning
to program.


IME there is a *lot* for a newbie to gain by learning debugging
without a debugger. You get to learn clever ways around things,
and how to subtly alter the code (even if only to add a println())
to have it tell you want is wrong.

A lot of coders could gain enormous performance improvements if they
took a look at what they were really executing rather than falling
into a routine of writing the same garbage over and over again
because they know it eventually produces the right answer. println()
only tells you what you want to see, not what you need to
see.

No, println tells you what you ask it to tell you, just like a
debugger tells you what you ask it to tell you.

Well, no the debugger tells you more than you ask. The debugger of
eclipse shows you all local and global variables. The println() -
Statement shows you what you asked at all.

That's far too simplistic. The debugger shows you whatever local and global
variables you ask for. Same as the println. Even if the debugger were to
show you everything all the time without you even having to press a single
button, the mere fact that you are using the debugger is asking.

We headed down this particular semantic argument because this utterance:

Kevin McMurtrie:
println() only tells you what you want to
see, not what you need to see

which IMO is wrong on so many levels. First of all, println() does /not/
tell you what you /want/ to see: it would tell you the values of something,
which are things that you may or may not want to see or even expect to see.
Secondly, it's the /process/ of learning how to use println() such that you
get meaningful information. Third, a debugger hardly shows you what you
"need to see" either, unless you also learn how to use it, just as you would
learn to use println().

Println() debugging is not just a handy skill. It is often a /required/
skill. There are many times I've come across a MT race condition that "goes
away" the moment a debugger is used. Furthermore, there exist also similar
situations where the bug is latched to the current time (in real time) and
therefore the problem is not reproducible once the code has been halted at a
breakpoint.


....[rip]...

 

[Patricia Shanahan]

With Java, I'll agree with you. I never use a debugger
in Java. The kinds of problems where debuggers are most
useful to me (pointer arithmetic, array bounds overruns)
just don't happen in Java. Well, I guess array bounds
problems do happen, but you are immediately told what the
problem is.

In almost all cases, give me a few printlns in Java and I
will be happy. When I did lots of C programming,
debuggers would save my life.

I disagree with the emphasis on general understanding,
unless that is an independent objective. Most of a large
program will be completely irrelevant to any given bug. Why
read 100,000 lines to find the 100 lines that matter? It's
often much more efficient to first understand the bug, by
collecting data about it.

I don't see why the choice of language should affect the
choice between inserted debug code and a debugger at all.
They each have limitations.

For example, printouts only show you the data you knew you
wanted before the run started. That is not much of a
handicap if the failure occurs in the first few minutes of a
known test case. If you have to wait a few hours, or even
days, for a failure a debugger's ability to view additional
data based on what has been found, without rerunning,
becomes invaluable.

On the other hand, I can construct far more complicated
filtering and decision making using inserted debug code than
any debugger I've ever used would support. For example, you
can ask what happened the last hundred times a line of code
was executed, without producing output for the previous
million executions.

Of course, in most cases either works, and the choice is a
matter of taste and what is most convenient.

Patricia

 

[Thomas G. Marshall]

Patricia Shanahan coughed up:

I disagree with the emphasis on general understanding,
unless that is an independent objective. Most of a large
program will be completely irrelevant to any given bug. Why
read 100,000 lines to find the 100 lines that matter? It's
often much more efficient to first understand the bug, by
collecting data about it.

I don't see why the choice of language should affect the
choice between inserted debug code and a debugger at all.
They each have limitations.

For example, printouts only show you the data you knew you
wanted before the run started.

In both the println() and debugger case, you see a variable, and then ask
for it's value.

A good debugger however will allow you to command:

Stop the moment this variable is altered, and show
me who does it.

And println() will allow you to garner information in the manner you mention
below, but also to garner information that might not exist at all in a
debugging context, as I mention elsethread, regarding MT race conditions and
the like.

That is not much of a
handicap if the failure occurs in the first few minutes of a
known test case. If you have to wait a few hours, or even
days, for a failure a debugger's ability to view additional
data based on what has been found, without rerunning,
becomes invaluable.
Sure.


On the other hand, I can construct far more complicated
filtering and decision making using inserted debug code than
any debugger I've ever used would support. For example, you
can ask what happened the last hundred times a line of code
was executed, without producing output for the previous
million executions.

Of course, in most cases either works,
most

and the choice is a
matter of taste and what is most convenient.

....for those of us who /know/ what we're doing. The question is in what
order is it best to teach newcommers to the language, possibly newcommers to
programming in general:

1. editor / javac / java
2. IDE
OR
1. IDE
2. editor / javac / java

(and therefore this argument has contorted to...)

1. println()
2. debugger
OR
1. debugger
2. println()

I think that both sides are starting to talk past each other.