[Bluej-discuss] bluej-discuss Digest, Vol 53, Issue 28
Bryan J. Higgs
bryanhiggs at yahoo.com
Sat Dec 1 02:30:44 GMT 2007
>>>RE: I'm toying with the idea of Javascript as an intro, though. Any
thoughts?
This caught my eye, and I apologize if the following is a little
off-topic (and a little long..) . However, it might be of interest.
I am just coming to the end of a semester teaching a Web Development
class which includes a significant topic on JavaScript, and during which
I have spent a lot of time learning JavaScript more thoroughly than
beforehand.
I also teach Java. I have taught an introductory class using BlueJ
(which I like a lot), but I mostly teach Java at the more advanced level
up to graduate level -- to give you an idea, I use the Core Java books
(Vol 1 & Vol 2) by Cay Horstmann, et. al..
I have read some people say how much easier JavaScript is (to learn?)
than is Java. I beg to differ. Significantly differ!
Admittedly, I came to JavaScript after learning Java, and my background
is mostly in the "more formal", more strongly typed languages. My
progression was from FORTRAN to PL/I to Bliss (anyone heard of that?) to
C to C++ to Java, with some diversions into Pascal and a little Ada,
COBOL (as little as possible). However, I taught a course in Perl some
years ago, and am trying to find time to learn the newer, "scripting"
languages -- specifically Python and Ruby. So much to learn, so little
time!
Why do I think that JavaScript is not easy to learn/understand? A
number of reasons:
* There is more than one JavaScript environment -- the most common
is within a browser, but there are also others. Each one will
have its own different 'global object' (Window is the global
object in a browser environment).
* The scoping of variables in JavaScript is, IMHO, harder to
understand than in Java. I believe that beginners would be easily
confused.
* There are a number of areas that are important in JavaScript:
o Core JavaScript
o Browser Object Model
o Document Object Model
o Events
o Exception Handling
o Data Access (XMLHttpRequest, aka Ajax)
Of course, you don't have to teach all of these areas, and you
wouldn't if you were just teaching JavaScript outside of a browser
environment.
You might be planning to use the Rhino environment
(http://www.mozilla.org/rhino/), which is now availalble in the
standard J2SE 6.0/1.6 version of Java
(http://www.onjava.com/pub/a/onjava/2006/04/26/mustang-meets-rhino-java-se-6-scripting.html).
However, there is also Jython (a version of Python written in Java,
and able to coexist with Java --
http://www.jython.org/Project/index.html) that I suspect would be a
much better choice. The visual programming environment Alice
(http://www.cmu.edu/corporate/news/2007/features/alice.shtml) is
written in Jython, and I hear of at least one book that uses Python
as a beginning programming language
(http://www.amazon.com/Introduction-Computing-Programming-Multimedia-Approach/dp/0131176552);
I don't know J/Python yet, so can't express any authorative opinion
on it.
* Standard JavaScript does not have the ability to access files (a
security restriction in browsers). Perhaps the Rhino version can
use Java I/O (I have to investigate Rhino a little more), but that
seems to be too much of a grafted on solution to be a good choice
for early learners.
* There are a number of different versions of JavaScript: Netscape's
(original) JavaScript (now continued by Mozilla), Microsoft's
JScript, Opera has their own version, and no doubt so does Apple's
Safari. There's the ECMAScript standard, but it only standardizes
the Core module. They are not compatible with each other, in
often very subtle ways, and different versions of each exist,
depending on which browser you're running. In short, the browser
wars have contributed to a complete mess in so many places, and
JavaScript is one of them.
* Documentation on JavaScript is not good. There are lots of books
out there, but I haven't been impressed by most of the ones I've
seen. There are too many 'cookbooks', and not enough that give a
sound foundation. Flanagan's 'JavaScript: The Definitive Guide'
(http://www.oreilly.com/catalog/jscript5/) is very good, but
definitely not for the faint of heart,and it still doesn't go far
enough in some areas to answer some of my questions. I like
Peter-Paul Koch's book (http://www.quirksmode.org/), but that's
really for someone who already has a good background in
programming (and probably some understanding already of
JavaScript). Incidentally, PPK's book is a good reference for how
incompatible JavaScript versions are! I don't know of any
JavaScript books that don't focus on the browser (and most
appropriately so).
* Development tools for JavaScript are at a very primitive stage.
Both Mozilla and Microsoft have JavaScript debuggers, but in
neither case have I found them to be in any way intuitive. I have
mostly debugged using alert boxes, which seems to be a fairly
standard approach. That is very frustrating, and in my opinion
not something to expect of beginners.
For those who don't know, Google, in their Web Toolkit
(http://code.google.com/webtoolkit/) took a novel approach: They
recognized two realities: 1) There was no good JavaScript
development environment, and 2) JavaScript is notoriously
incompatible across different versions in different browsers. So,
they decided to do their development in Java, and wrote a Java
(subset) to JavaScript translator, plus a JavaScript library to
abstract away the browser/ JavaScript version incompatibilities.
They have been very successful with this approach!
* JavaScript, as used at a simple level is (mostly) procedural, but,
at least in the browser environment, it still has objects and
corresponding variable scopes. If you try to delve into its
prototype-based object model, you rapidly discover that it is most
unlike C++ or Java class-style objects, especially when you try to
learn how it does inheritance. I'm still struggling to try to
understand that, and I'm no stranger to either C++ or Java
inheritance.
I think that beginners (not to mention teachers) would struggle to
use JavaScript to teach OOP. I'm not saying that it's impossible
-- there are some very talented teachers out there. However, I
think that there are so many other, superior languages available.
Please don't misinterpret what I'm saying: JavaScript is a very
interesting language that provides a very dynamic environment. And
because of the current Ajax craze (in part started by Google's web-based
apps), JavaScript is currently pretty hot.
However, as a language to use to teach beginning programming, for all of
the above reasons, I don't think that it passes muster.
I hope this is in some way helpful in your choice...
Regards
Bryan
TJ Evert wrote:
> > From: "Lon Levy" <lxl at oregon.k12.wi.us <mailto:lxl at oregon.k12.wi.us>>
> > My AP students are required to have had or be in their second year
> of algebra. This is not a "strong background in math", but it does
> mean a couple of things: My AP students have to understand what a
> function is and what a composite function is. My AP students need to
> have a reasonable understanding of Order of Operations (and I really
> want to kill My Dear Aunt Sally). My AP students need to have an
> introduction to proofs, which is being taught less and less as time
> passes. I find myself making up for more and more geometry in my
> Introduction to Computer Science (pre-AP) course every year.
>
> It's funny you bring up geometry - That was the "main" subject I
> taught - AP CS was just an elective. I used geometry as a
> continued theme in my class: "size" variables, "area" methods,
> "Shape" classes, drawing "Shape" objects with applets, and even a
> "Scalable" interface. It worked out quite nicely.
>
> Not to quibble, but I would consider the above to be "a strong
> foundation in math".
>
>
> > From: "Lon Levy"
> > There are a few bizarre things about Java that make it much easier
> to start with a simpler language ... In Java, methods return a value
> except that sometimes there is something that is neither an object nor
> a primitive listed as the return type: void. That is confusing. You
> can't instantiate void. Like null, it is a serious breach of the
> object oriented paradigm. Primitives are also a breach of OOP. To
> learn more about this, if it is of interest to you, check out the
> information on www.teach-scheme.org <http://www.teach-scheme.org/>,
> which includes links to a free on-line text.
>
> I checked out Scheme - intriguing, but sadly, I've never thought I had
> the "luxury" of starting another language. I feel so pressed for time
> by the end of the year. I'm toying with the idea of Javascript as an
> intro, though. Any thoughts?
>
> As for methods, it's less confusing if you approach it from a (for
> lack of a better word) "historical" view point.
> 1. methods (functions, sub-routines, etc.) are a just word for
> "containers of code"
> 2. they can return values
> 3. if they don't, they are "void"
> 4. if they act on objects, they don't have to be static
>
>
> > From: "Lon Levy"
> > I started teaching AP Pascal and have taught AP C++ and AP Java.
> The needs are not the same today as they were in the halcyon days of
> Pascal.
>
> I disagree - the need is exacly the same: pass the AP exam...
>
>
> > From: "Lon Levy"
> >I spend three quarters of a school year on very simple functional
> programming. In DrScheme, my students learn recursion (loops wait
> until fourth quarter), lists, trees, structures, searching and
> sorting, data unions, and more. They learn all of that with fewer
> syntax rules than are necessary to do a traditional Hello World in
> Java. (I don't teach Hello World).
>
> You taught *all* that without creating a class, using a "main" method
> or calling "System.out.print()"? Impressive...
>
>
> > From: Michael K?lling <M.Kolling at kent.ac.uk
> <mailto:M.Kolling at kent.ac.uk>>
> > Understanding this is not easy, and thus changing between one and the
> > other is not easy. We are not doing our students a favour by requiring
> > them to swap between these two models early (because it requires them
> > to fully understand this, which many people don't).
>
> I think this point is really where this discussion is centered - the
> idea of "two models". I get the feeling that "objects-first"
> proponents view the debate as "geo-centric" (procedures) vs
> "heliocentric" (OOP). It's as though they have to overturn a whole
> paradigm (and 50 years of programming exercises, lessons, insight, ...).
>
> Object-oriented programing is, like th heloicentric model, *right*, in
> that it's where we (ultimately) want all our students to get. But we
> all still "think" that the sun rises. No matter how many times you
> draw a solar system, it's simpler and often easier to just refer to
> the stars and planets "moving" though the sky. I've never seen an
> astronomer worry about confusing a class by "switching between the two
> models" because while we all know which is the best from a "global"
> perspective (think "top-down" design) it's just easier to work in the
> "local" one (implementing methods). The latter is also easier to
> introduce...
>
>
> > > I strongly believe that students learn best what they've studied
> > > longest.
> >
> > I perfectly agree with you on that. That's why, if we want them to
> > learn OO, we should teach them OO longest (i.e. from the start).
> >
> > > I think we're probably both in agreement when I say that procedural
> > > topics are the hardest part of a 1st-year Java class.
> >
> > No, I don't agree at all. Object interactions are harder.
>
>
> More subtle, perhaps. Tracing values in method calls is hard - thank
> God for Jelliot!
>
> I think it's easier to discuss these issues when "armed" with a strong
> foundation in data types, variable scope, passing values to variables,
> etc. All this can happen quiet early in "historical" programming".
>
>
> > > I think you'd also agree there's no way of really getting around
> > > teaching procedueal topics.
>
> > I think what you really mean here is is not procedural programming in
> > the sense of the structuring paradigm, but just subroutine calling
> > with parameters and return values. That's an element of many
> > paradigms, and needs to be taught. But in a context that does not
> > require students to later un-learn and restructure the overall
> > understanding of structuring the program.
>
> I guess so - C++'s "functions" were the probably most appropriate
> name. I guess my point is that writing static methods (like
> Fibonacci(n) or GCD(x, y) ) help more in writing object methods more
> than the other way around.
>
>
> > I think what is ultimately behind this is a very strong tendency of
> > teachers to teach in the exact order in which they themselves have
> > learned. This somehow becomes the "natural order" and the only way to
> > "proper understanding" of programming.
>
> Ah, the "Fuddy Duddy" argument. Procedures-first in certainly not the
> only (or neccessarily best) way to teach Java. But it's ceratinly
> viable. This whole debate started on whether a "main compile" method
> should be a feature. So the questions isn't "What's the best way to
> teach programming?" It's "What will help students learn Java?"
>
> Regardless when it happens, student will have to evaluate procedures.
> As trendy as it may be to rail against text output, when you have to
> run a proceedule 50 times to figure out why it (doesn't) work, a "main
> compile" method makes procedure evaluation faster and therefore easier
> to learn. It's a simple as that.
>
>
> > I agree, we should start with the basics. But that's not procedures,
> > that's assignment and goto. Procedures were just tacked on later.
>
> Because "goto" is not in the language (for good reason) I think
> "history" has shown us why goto was a painful (but very useful) step
> along the way. It's an important lesson, though, and I'm sure if we
> could "look into" any repetition-structure, we'd find "goto" embedded
> into the machine code.
>
>
> > But wait, assignment is a radically modern, new invention: where we
> really
> > should start is with load and store into/from registers. Ahh no:
> > that's really a too high level abstraction: we need to understand how
> > memory works first. Let's start with flip flops. But no, that really
> > assumes too much: I actually think that we should start with gates. No
> > atoms, actually.
>
> Remember "new math"? You may not - I'm not too sure it caught on
> outside of the US. Teachers were trying to get 6 year-olds to do their
> math problems in base-7 to "free their minds". Ironically, it was
> intended to teach kids binary to help them learn about logic gates and
> flip flops...
>
> It was abandoned, of course. Soon after, calculators were introduced
> in grade schools to "ease the transition". Meanwhile, the rest of the
> world did their long-division and we've seen where all the programming
> jobs have gone. I'm just ranting, now...
>
> The point is low-level "rigor" is essential to master later,
> higher-order concepts. But perhaps it's just a matter of taste
> .
>
> > Now, I (and, I assume, you) don't really want to start with atoms.
>
> Not unless you mean LISP! Actually, many texts start with bits, Bytes,
> hex, and ACSII. It makes typecasting primitives and colors a breeze...
>
>
> > So then people start making these choices defining what are acceptable
> > black boxes, and what really needs to be understood first before being
> > allowed on to higher abstraction levels. Okay, so we draw a line. The
> > real question then is: where do we draw that line? What are the
> > acceptable black boxes?
>
> Fair enough. My answer would be "Whatever get's students writing
> *useful* programs fastest." I'll admit, that's a pretty subjective
> criteria, but after the novelty of writing code fades away, what
> can students program in the first few weeks that they wouldn't be able
> to on their own?
>
> I have to do some hand-waving in the beginning on what classes and
> objects are.
> It's fun to get to games like "SevenGuesses" (to guess a number from 1
> to 100 - great into to binary sorting), "palindromeTest()" to
> introduce Strings as "arrays", or novelties like "bottlesOfBeer()" or
> animation for loops . It's a computer's abiltiy to run repetative
> tasks that makes it truly useful.
>
>
> > I have had that conversation with quite a few different people over
> > time. My impression: Where people draw this line is mainly a function
> > of their age. It is, in fact, a direct function of how they themselves
> > started to learn about programming.
> >
> > Everything I had to learn is obviously required knowledge for a proper
> > understanding of programming, and those bits that I don't really
> > properly know about are obviously not needed. The pedagogical decision
> > becomes a the result of the year-of-birth lottery.
> >
> > I'd like to argue that, yes, we have to draw the line somewhere, but
> > we have to make the choice where to draw it based on pedagogical
> > considerations, not on personal history.
>
> A bit unfair, I think...
>
>
> > And I do find it easier to teach student about objects first, and
> > about methods in the context of object behaviour implementation, when
> > my goal is to end up with an understanding of OO.
>
> An understanding of OO has never been the problem. OO is the "easy"
> part (especially with nice tools like BlueJ). Sure, there are some
> fine points, but those are rarely the ones my students struggle with.
> It's nitty-gritty, *procedural* things like how trace though a
> recursive function, "shuffle" the elements of an array, or evaluate
> the logic of TicTacToe. It's also the "obvious" things we teachers
> have long since mastered, like formatting code, documentation, or
> basic spelling.
>
> *These* are the things we should be debating - features like:
> 1) folding-code
> 2) drag-and-drop structure templates (like in Alice)
> 3) simpler code-formatting tools ("hard" tabs instead of spaces?)
>
> and the aforementioned "execute main" keystroke command (I guess I'll
> just have to write a script in VB...)
>
> As fun as this has all been, we should all be focusing on these last
> points.
>
> Thanks,
> TJ
> ------------------------------------------------------------------------
>
> _______________________________________________
> mailing list bluej-discuss at bluej.org
> To unsubscribe or change your preferences, go to
> http://lists.bluej.org/mailman/listinfo/bluej-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.bluej.org/pipermail/bluej-discuss/attachments/20071130/a7c2c740/attachment-0001.html
More information about the bluej-discuss
mailing list