What's wrong with HelloWorld.Java

prostoalex writes: "Daniel H. Steinberg posted an article on O'Reailly's OnJava.com discussing the difficulties and current problems with introductory Java in the classroom. The textbooks used in colleges are mostly the rewrites of C/C++ textbooks and thus start with HelloWorld program without really dwelling on object-oriented nature of Java and why it is important. In a nutshell, OOP even nowadays is treated as somewhat innovative concept in the classroom, mainly because of educators, who were taught C. Hence links and description of Rethinking CS101 Project."

Comments

Introduce JUnit as a means of grading

[jefflinwood]

In my intro to CS class, we used a test harness to determine whether or not our code worked correctly. This was a C++ class on the Mac, though.

JUnit could be used to create a test harness that "plugs" into the code the students write. The professor or TA could define an interface that the students have to implement.

I think beginning computer science for majors is backwards, anyway. Intro to engineering classes at CMU for freshmen were all taught as practical, hands-on, applied courses that focused on real problems. My civil engineering class built bridges, visited dams, and visited construction sites. My chemical engineering class analyzed actual plant failures (things that go boom!) to determine what mistakes the engineers made. My intro to cs class was all theory, with one interesting project where we added AI into a 2D simulation. There wasn't a lot of practical information to take away from the class at the end of the year beyond a "Learning C++" book.

Re:Introduce JUnit as a means of grading

[HaiLHaiL]

Computer Science is not about finding solutions to real world problems. Well, at least not like engineering is.

It is a science which studies the possibilities of computing--not a field of engineering. (Though strangely at Marquette, almost all the computer engineering classes are taken from the comp sci dept.)

The idea of comp sci 101 is to give you the building blocks on which to build theory. This usually involves basic computer architecture and programming in whatever language is currently seen as standard or best (or paid to be taught).

teaching OOP first may not be the way to go

[Anonymous Coward]

A lot of texts on OOP say that people new to programming learn OOP very quickly and naturally, and that teaching them OOP first is the way to go.

This may not be true.

I have recently taught programming to a few people. They were new to programming, and were honestly interested in it.

I have tried the approach of teaching OOP first. They didn't get it. Then I tried to avoid the OO part, and teach them some programming, but using objects. This also didn't work very well.

After this, I switched from Java to a simpler, structured language: PHP. Things worked a lot better, they seemed to understand the procedural paradigm naturally and very quickly.

After a few months of teaching PHP, I tried to teach Java again. This also worked a lot better than my first attempt, as they groked objects more easily.

After this experience, I belive that "teach OOP first" is not the way to go.

I think the proper way to teach programming is:

- Teach them a structured/procedural language. Drill into them the loops, if, switch, functions, parameter passing, etc. Teach very basic algorithms.

- Make them do some real work using the new language.

- Teach them OOP, using an OO language.

If the first thing you teach is OOP programming, people won't understand the need for classes and objects. They will seem like useless abstractions.

Also, people who are not accustomed to the way computers work don't understand a lot of things in OOP, as they miss a lot of context.

If you teach them the much simpler structured programming, they will grok OOP easily.

There is a third path: teach structured programming first, but in an OO language. I belive this can be done, but not in Java. In Java, everything in the library is an object, so you can't avoid lots of objects and object syntax.

Another issue is that it is important (IMHO) to teach people a productive programming language, so they can see real, useful results quickly. PHP is good for this purpose.

Teach libraries first

[Anonymous Coward]

To really understand a language, one should learn the standard libraries first. The book Accelerated C++ takes this approach. Stroustrup advocates this method of teaching a language. The wrong way to teach a language is to exhaustively teach syntax.

Of course syntax is important, but one should not be forced to become a language lawyer before useful tasks can be accomplished. By emphasizing a language's standard libraries, you learn the "philosophy" of the language as well as its syntax. And in the end you can do useful things with the language, and do it correctly within the philosophical context of the language. You avoid the such common problems as using a C++ compiler to write what in reality amount to C programs.

OO is for wankers

[Anonymous Coward]

Computers don't "think" in objects.
Why should the program or programmer do ?
I've seen enormous amounts of crap code created under the banner of OO.
Those who cannot think in simple procedures shouldn't be programmers at all.

Re:Java != OOP, C++ != OOP

[Tablizer]

Designing, or better yet, THINKING in OO terms is not something that happens overnight. This is precisely also the reason as to why 90% of large, pure OO projects either fail or start to degenerate into something that needs revamping every so often, only because the programmers who built the application did not take the time to properly analyze the problem and come up with the most natural solution possible. A natural solution is possible, but only at the hands of professionals, who understand what OO is all about

A fitting excerpt from my anti-OO webpage:

OOP technology has generated more confusion than almost any other computer technology. For example, many OOP "experts" claim that most companies are either not using OOP properly, or are not taking advantage of OOP. Experts also say that there is a long learning curve before many people grasp the power of OOP; that its benefits can't really be taught, at least not understood, from a book. It has almost become like Particle Physics, in which only a small elite group appears to understand it properly, and everybody else needs years of meditation and practice.....

Ironically, OOP is sometimes billed as "better fitting the way people think". Years of meditation and study to learn how to "think naturally"? I am thinking of setting up a $60-per-hour consultancy to teach sports fans to drink beer and belch in order to "optimize their recreational satisfaction".

....Further, there is a lack of consistency in modeling techniques by OOP celebrities. Methodology-of-the-week is commonplace. The lack of consistency makes it tough to make any generalizations about how OOP goes about modeling useful business applications. An OOP consultant may have to be well-versed in dozens of OO methodologies to be able to walk into a shop and perform any useful work any time soon.

(oop.ismad.com)

Use this program in classes

[doc modulo]

If you want to teach students how to program in an OO way in Java. You can use this program:

BlueJ

Teachers can start teaching objects and classes from the beginning. They don't have to tell students:

"Just write down: public static void main (String args[]) { } And don't ask me about it until later".

it wouldn't run some of my home-made classes, but then I didn't read the manual :P

Smalltalk

[booch]

Thinking that OO is hard is just plain wrong. The main problem with the way OOP is taught is that the commonly used languages mix both OOP and non-OOP procedural elements. Constantly switching between the 2 doesn't allow the student to "get" the OOP part very easily.

The answer is to use something like Smalltalk, where everything is OO. In early testing, the Smalltalk developers found that it was *easier* to teach Smalltalk to beginners than procedural languages, because people are already familiar with doing things to objects in the real world. Whereas it takes a certain way of thinking to come up with step-by-step manipulations of abstract data structures.

Computation-as-interaction is a bad idea

[p3d0]

I don't like the idea they present of computation as interaction, rather than computation as calculation. Computation-as-calculation views a program as having a specific, well-defined job to do, with a beginning and an end. This makes it much easier to reason about what the program does, and whether it does it properly: you can inspect the outputs for a given set of inputs and make sure the calculation produced the right result.

Clearly not everything can be done this way, but I think the idea to throw in the towel and model everything as interacting processes is a huge mistake. This is especially true of concurrency, which is thrown into programs in a haphazard way these days with no particular benefit.

Re:Java != OOP, C++ != OOP

[Anonymous Brave Guy]

Where is this grand evidence that OOP is objectively better?

As I've pointed out before, it's in the collective experience of legions of software developers. If they didn't -- at least subjectively -- feel that the OO approach suited them better, they wouldn't use/adovcate it. And what feels better to you is often the best approach for you to take. There are an awful lot of people putting their money where their mouth is on this one, and they're still doing it decades later. It's hard to believe that they're all wrong on everything after all this time.

You may not personally have seen any benefits from OO, and you may personally have seen benefits from a relational approach. As I've also pointed out before, and by your own admission, your experience comes from a very narrow field of programming, to which one approach seems much better suited. It's not surprising that you find that approach superior. OTOH, you are yourself falling for the "too wide a brush" problem of which you accuse others elsewhere in this thread. Those of us who work in diverse areas of programming have often found OO to be at least as natural as, or more natural than, a purely procedural approach. We also acknowledge that it has its flaws -- and there are plenty -- but many of these can be avoided if you use a tool that doesn't insist on a purely OO approach (and frequently one that ignores half of OO as well, such as certain popular mainstream programming languages today).

OOD Key Concepts

[hackus]

This is my rant on the subject. You don't have to agree, but it comes from a guy writing software since he was 10 years old, who is now very old and crusty by comparison. This is what experience has taught me, perhaps your mileage will vary.

OOD, without risking and sounding like those "experts" is no silver bullet for software design. But it is a sound evolutionary advance in Software Engineering techniques. Yes, I do agree, that the OLDER generation, is more inclined towards Structured Design before implementing OOD/OOP techniques. However, I disagree that it is because that is the only thing we have been taught or have been teaching. Thats complete bonk.

Everyone in this field advances with the times. I would suggest, if it seems that way, the older generation, simply realizes what OOD/OOP is and what it ISN'T, and use OOD/OOP where appropriate in building software.

First of all, OOD/OOP builds heavily on Structured Design techniques. (i.e. Building software using ADT definitions and the 4 foundation sequences of computer science: statement, do-while, while-do, if then else, case or selector statement.) That is, a properly built OOD will embody in every one of its object interfaces, methods which are built using sound Structured Design methods. So it is a Myth that OOD/OOP gets rid of Structured Design techniques. In FACT, those who write POOR OOD/OOP's are those that have not mastered the 4 constructs of computer science and the ADT that goes along with Structured Design.

OOD does not a attempt to do away with Structured Design, it complements it by organizing Data AND Code in such a way that further increases the resulting code abstract properties. (i.e. it allows the resulting algorithms to be expressed in a way that makes said code even more reusable through inheritance for example. OOD is therefore impossible to implement without Structured Design.)

The resulting code is far more abstract, and therefore generalized to be more reusable, and therefore, theoretically, more reliable. (i.e. Code that is used over and over again becomes more reliable over time, and is an extensible property of the life cycle of software. Although structured design allows you to reuse code through simple function calls, OOD/OOP takes it one step further and allows function calls and data representation to be generalized as a functional unit.)

It has been pointed out, with good reason, that Java is a language which can help enforce good OO programming. However, it is not required and for example through the use of static methods, one can build Java code without using OOD/OOP techniques of any kind if one decides to do so.

This is important: OOD because of its abstract properties, (primarily the use of inheritance) can be used to create software patterns that lend themselves to creating certain types of software.

Certain types of software that benefit greatly from OOD/OOP implementations are for example, User Interfaces. Why? It is obvious. User interfaces are built using repeatable patterns themsleves application after application. (File, Edit, View, Window, etc.), at thier most basic level.

When an implementation in and of itself such as the building of a GUI, for example, has a clear pattern itself, OOD/OOP methods can get a great deal more mileage out of simplyfying and building code. This creates a better implementation of a GUI than just a Structured Design approach alone can provide.

With that said. You are probably thinking, what sorts of things is OOD/OOP NOT good at, and in fact SHOULD NOT be used. This is the part that gets controversial and you will decide, without knowing it, which camp you fall into by reading the next paragraph. :-)

Well, abstraction, which through inheritance in OOD, while it provides excellent reusability in the context of building software, does not always result in the most effective implementation. By an effective implementation, I mean most efficient. :-)

So what am I saying? Well, I am saying that you sacrifice some efficiency to gain the increased code reliiability that inheritance provides in OOD by compartmentalizing code AND data within an object vs Structured Design, which cannot do this through the use of simply an ADT and function/procedure calls.

(i.e. You can never directly modify data in context of a classic OOD/OOP, you have to overlap or build a middle man, as it where, to modify any data you declare private through the use of accessor methods.)

Althouh this enforces and corrects some deficiencies in Structured Design, it makes the program arguably slower to execute.

In the context of building, say an Operating System, for example, OOD/OOP is not the way to go if you want a highly speedy and effective OS implementation.

If you want such speed you invariable have to give up inheritance, and the benefits it provides, and resort to Structure Design principles only, to build your OS. (i.e. ALL function calls and procedures DIRECTLY access the data structures of the OS through passing parameters to functions or procedures, there by eliminating the middle man as above.)

Which, is not so bad, really. OS's and components of OS's such as kernels, etc...are designed to be speedy, as they should be.

So, my view on the topic is that OOD/OOP is best suited on top of the OS, vs IN the OS design.

Not everyone agrees with that, and that is fine.

Why? Well, because many argue that the sacrifice in speed is justified in the complexity of building a OS kernel, and that the reliability gained through the extensive use of OOD/OOP techniques in building the OS kernel for example, yields a better OS.

Which is not something to be taken likely if your OS is charged with the responsibility to keep systems software on the space shuttle for example working with the fewest number of defects, and human lives riding on what the OS may or may not do next.

On the other side, like I said, you have me and others who believe that OS should be very small and very fast, and that OOD/OOP shouldn't be used and that the realibility sacrificed is acceptable.

So, that is just one aspect of when and where and why OOD/OOP should and should not be used. But as you can see, it is far from cut and dried, and primarily is once based on IMPLEMENTATION and engineering REQUIREMENTS, not on methodology.

Which is how the real world works.

For the most part, which drives 90% of the disagreements is the fact that many people see OOD/OOP being a generalized approach to solving ALL problems, and not a specialized addition to Structured Design techniques, suitable for SOME problems, not ALL problems.

I personally, obviously, feel that OOD/OOP is NOT a generalized programming methodology for ALL cases.

However, some of my friends feel very differently, and we have a good discussion on the topic wherever we go when we start discussing OOD/OOP.

Things can get pretty heated, and most patrons at the local 3am diner wonder what all the screaming is about, particularly the buzz words. :-)

Hack