What's wrong with HelloWorld.Java 181
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."
Introduce JUnit as a means of grading (Score:4, Interesting)
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.
teaching OOP first may not be the way to go (Score:2, Interesting)
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 (Score:2, Interesting)
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 (Score:1, Interesting)
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:Introduce JUnit as a means of grading (Score:2, Interesting)
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).
Re:Java != OOP, C++ != OOP (Score:5, Interesting)
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".
(oop.ismad.com)
Use this program in classes (Score:2, Interesting)
BlueJ [bluej.org]
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 (Score:3, Interesting)
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 (Score:3, Interesting)
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 (Score:3, Interesting)
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 (Score:3, Interesting)
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
Survey question for OOP fans (Score:3, Interesting)
I get different answers when I ask OOP fans what specificly are the (alleged) benefits of OOP. Most can be divided into one of these two:
1. Easier to "grok". Enables one to get their mind around complex projects and models.
2. Makes software more "change-friendly" - fewer code points have to be searched and/or changed when a new change request comes along.
I did not include "reuse" because it seems to be falling out of favor as a selling point of OOP.
If I can narrow it down, then perhaps I can figure out why OO fans seem to like what seems to be a messy, convoluted, bloated, and fragile paradigm to me.
I would appreciate your vote. Thanks.
P.S. Please state your primary domain (business, systems software, factory automation, embedded, etc.) if possible.