Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What's wrong with HelloWorld.Java

timothy posted more than 12 years ago | from the skipping-around dept.

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."

cancel ×

181 comments

Sorry! There are no comments related to the filter you selected.

Java != OOP, C++ != OOP (5, Insightful)

BalkanBoy (201243) | more than 12 years ago | (#4123932)

People can never get this through their heads. OOP is _not_ about what language you use or what tool you use that more or less will or can facilitate OO programming. OOA&D (e.g. object oriented analysis and design) is not about mastering Java or C++, it is about mastering a new style, a new paradigm of thinking. This is precisely when Java or C++ is taught by "old skool" K&R C people who hate the thought of anything resembling OO (and I wont mention how many are of those out there... too many, rest assured) it looks like Java or C++ is C wrapped in objects. The usefulness of the paradigm is reduced and de-emphasized if the proper train of thought is not employed when analyzing solutions in an object oriented fashion.

One has to be able to perceive problems in terms of objects. This may at a glance seem easy - our world is composed of objects, but when you start getting into more abstract concepts, e.g. trying to write OS's in a fully OO manner (akin to what BeOS was) , or other more complex applications like the entire JFC (for instance), then OOA&D does not seem so easy!

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 (and it is least about WHAT LANGUAGE you use), who have experience in 'seeing' the world, or higher concepts through OO eyes and who are able to delimit, with crisp boundaries every concept/object available to them or as stated in the specifications by the customer and MOST importantly establish the PROPER relationships between those objects!

Design patterns and such go a LONG way toward getting this objective, but one cannot fathom using or applying design patterns if he doesn't understand what OO design and analysis means, and without a shitload of experience to use toward this goal. True OO thinking is almost like a lithmus test of how good a programmer, or better said, an ANALYST, an ANALYTICAL person, or your ANALYTICAL skills are... In OO, 80% of the time or thereabouts is spend on analysis and design, 20% on the mechanics of writing the code. Then, and only then, will you be able to pull OO projects successfully through completion.

And no, I'm not talking about your school/academic projects, I'm talking about large scale projects with possibly millions of lines of code where understanding the ESSENCE of the OO paradigm will either make or break a project and make it usable and extendable for a long time or make it a piece of crap that will never see the light of day...

Most people shy away from OO or misunderstand it because they've never even read a book about OO either, such as the OO 'bible' by Rumbaugh/Premerlani "OO modeling and design using OMT", or some of Fowler's books on analysis, patterns, or Gamma's book on design patterns...

Someone once said - pimpin' ain't E-Z! Well, neither is OO!

Re:Java != OOP, C++ != OOP (2, Insightful)

PS3117 (603310) | more than 12 years ago | (#4124087)

The generation of code is the small (critically important, but small) part of development. The "game" is in the head, or more precisely the mind of the developer. Teaching someone to write code effectively is not a terribly daunting prospect. However, teaching someone to think, much much more complicated. In contribution to this difficulty the education system here in the USA is not geared towards excellence, it is geared towards the average, the everyday. Just an opinion, feel free to flame away, but the so termed fuzzy subjects such as art and music teach students to see not what is there, but what isn't, and more importantly what could be. There are a great many technicians out there who generate code, but virtuosity in any endeavor is art as much as science or technology, it is seeing, feeling. I had the privalege of speaking at my daughter's school on career day and when asked what I did, my response was, I build models. I build models of business process or at the moment engineering processes. In short what we do as developers is model behavior. I have maintained for years that the only way to get good at development is not education, it's scars, scars earned in the trenches getting beaten on by cranky code, twitchy servers and managers who haven't got a clue. The same is true for OO, get into it up to your neck, get it into your pores think it breathe it read it discuss it beat it to death. Then you can become a prophet in the wilderness of software development and have managers look at you like you're something to the left of a cultist. Balkanboy is right it's not easy, but "It's the hard that makes it great. If it was easy anyone could do it." (paraphrased from "A League of Their Own"

Re:Java != OOP, C++ != OOP (2)

oliverthered (187439) | more than 12 years ago | (#4125708)

'is not geared towards excellence, it is geared towards the average'

Well in my experiances the average is deamed to be excellence, if you in any different, off the wall or excel but not in a way that fits the average is is not usualy considered to be 'constructive' in the education system.

Just a bit on OOP so as not to be off topic,

You can write C in and object orientated way even though there is no real language support for objects in C.

the old jpeg library was written like this, and I believe GTK is written this way (why they don't use C++ i'll never know?)

One way to teach OOP is to get some spagettie and get the 'class' to refactor the code(aided and abbeted by the teacher!) not only does this teach OOP but it teaches the reasons why OOP is good.

If i wanted a spelling critique I would have posted this comment on /.

Re:Java != OOP, C++ != OOP (5, Interesting)

Tablizer (95088) | more than 12 years ago | (#4124764)

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)

Smalltalk (3, Interesting)

booch (4157) | more than 12 years ago | (#4126438)

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.

Re:Smalltalk (2)

Tablizer (95088) | more than 12 years ago | (#4128425)

(* 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. *)

I have heard this claim from Smalltalk fans before, but the "experiment" has never been repeated in a proper research setting. Thus, it is an ancient legend that just keeps getting propagated over and over.

I would note that people think *differently* than each other. Just because thinking X way is natural for person A does *not* necessarily mean X is natural for person B.

Don't paint with too wide a brush.

If OO and Smalltalk model *your* head well, that is fine. Just don't extrapolate that all over the planet without real research first.

Personally, I think it is more important to focus on making software change-friendly rather than making it easy to learn to program. Although, both are important factors.

Re:Java != OOP, C++ != OOP (4, Insightful)

scrytch (9198) | more than 12 years ago | (#4127406)

Go see that page, oop.ismad.com and you'll mod the parent up to +5 funny. Just ignore the gross misunderstanding of OO, the selective process of argument where he flips between implementation and concept, the plug for some vague "table driven programming" thing (that basically is OOP without inheritance), and the entire fallacy of division (google for it) that is promulgated throughout... probably a good fifth of the material is dedicated to red baiting, to the point of displaying a hammer and sickle flag. My congratulations on a masterful troll. It had me going for a bit. Love the "beat up spock" visual analogy for "abuse of logic" too.

Re:Java != OOP, C++ != OOP (2)

Tablizer (95088) | more than 12 years ago | (#4128484)

(* Go see that page, oop.ismad.com and you'll mod the parent up to +5 funny. Just ignore the gross misunderstanding of OO *)

Let's cut to chase.

Where is this grand evidence that OOP is objectively better?

The evidence on my webpage is as strong as ANYTHING used to justify OOP.

Where is your evidience, Mr. GlassHouse?

Ignore the fact that you don't like me and think I am a troll. Just produce the evidence for the world to see. Good evidence is orthogonal to any alleged troll.

(I was often told that good evidence existed in Meyer's famous work. So, I purchased a copy. However, I found tons of reasoning holes in it. A review of it can be found on my website.)

Re:Java != OOP, C++ != OOP (0)

Anonymous Coward | more than 12 years ago | (#4129644)

This guy's website reminds of Creation Science. It is meticulous and relatively carefully written, but he seems to miss the big picture of OOP. Just like Darwinian evolution, OOP is hard to properly grasp just by reading a few examples, and some people never seem to grasp it. Even some well-educated and high-scoring scientists never seem to grasp evolution.

Granted, OOP is tough to correctly teach. I don't know of any easy solution. Perhaps his hint that "OOP is too hard to do right, and therefore we should look for simpler alternatives" (rough paraphrase) does have a certain appeal to it.

OOP is at risk of becoming an "elitist" technology if educators don't do a better job of properly teaching and justifying OOP.

It needs a better fence or else more such "trolls" are eventually going to kill its acceptance with superficial, but catchy attacks.

Re:Java != OOP, C++ != OOP (2)

scrytch (9198) | more than 12 years ago | (#4129745)

OOP is at risk of becoming an "elitist" technology if educators don't do a better job of properly teaching and justifying OOP.

I doubt this. OO is as mainstream as structured programming became when it was the rage. It is in fact so entrenched now that it's a bit of a *problem* to do even minor tweaks to enhance OOP itself, such as method(object,arg,arg) instead of object.method(arg,arg) in order to better support multiple dispatch, since it looks too much like non-OO code, regardless of the scoping of the actual implementations of method.

In fact, it's hard to convince people to write things in functional styles when OO is always the rage. Probably because functional's disdain for variables has made it hard to know where to put state, but there's a good amount of herd mentality too.

It needs a better fence or else more such "trolls" are eventually going to kill its acceptance with superficial, but catchy attacks.

Actually, I take the opposite view: it's kooks like Tablizer that make honest criticisms of OOP look bad.

Re:Java != OOP, C++ != OOP (0)

Anonymous Coward | more than 12 years ago | (#4127456)

It takes "years of meditation and study" to unlearn improper methods of "thinking naturally".

If you have spent 20 years doing things in a non-OO fashion, changing your mindset is not going to happen over night.

If you are taught OO principles from the beginning, it will indeed be natural.

God I hate idiots.

I don't care what side of which argument they're on.

Idiots should be put to death.

Re:Java != OOP, C++ != OOP (2)

Tablizer (95088) | more than 12 years ago | (#4128531)

(* If you have spent 20 years doing things in a non-OO fashion, changing your mindset is not going to happen over night.....If you are taught OO principles from the beginning, it will indeed be natural. *)

In that case *anything* can be "natural" if you simply do it first and early.

That is not the issue. The issue is what to force students into and why.

(* God I hate idiots. *)

Me too. They often skip a step or two in science: "Evidence? We don't need no stinkin' evidence because we voted ourselves 'experts'."

Re:Java != OOP, C++ != OOP (0)

Anonymous Coward | more than 12 years ago | (#4128601)

Watching this discussion, the real issue seems to be consistency in training.

If we taught people how to properly recognize and apply different methodologies in clear-cut examples then it would highlight the strengths and weaknesses of all of them.

It's not whether procedural, functional, object oriented, etc. don't all have a place or that they can't all be used for any given problem set. It's just that different developers have different ways of thinking and coding. The fact that OOP makes sense to me doesn't mean that it works for everyone. The fact that it doesn't work for everyone does not invalidate the fact that it works for me either.

Calling for Balance (2)

Tablizer (95088) | more than 12 years ago | (#4129059)

It's not whether procedural, functional, object oriented, etc. don't all have a place or that they can't all be used for any given problem set. It's just that different developers have different ways of thinking and coding. The fact that OOP makes sense to me doesn't mean that it works for everyone. The fact that it doesn't work for everyone does not invalidate the fact that it works for me either.

I agree that much of it is subjective.

However, the "trend" seems to be to rank OOP as more sophisticated or "better" than other methodologies.

And, all the research and tools flow in the direction of OOP. How many NON-OO pattern books/articles do you know about? Why so few? How many non-OO software engineering books do you know about? (Besides those written in the 70's before relational databases were readily available.)

OOP is stealling far more spotlight than it's evidence (zilch) justifies.

Until one is proven objectively better, teach *all* paradigms equally: Procedural, Relational, Functional, OOP, etc........

Balance

OOD101 or CS101? (5, Insightful)

one9nine (526521) | more than 12 years ago | (#4123964)

Are we talking about a beginning OOD class or a beginning CS/Programming class? When you first teach someone how to program, the last think you want to do is start with OOD. One must learn about variables, arrays, assignment vs. comparison, loops and conditional statements. Then one must learn about functions and how to separate code into them. Simple algorithms need to be introduced as well. Also, how to break down a problem into several steps and then code it. Finally you can start to teach about classes as well as one of my personal favorites, data structures.

Just because Java is focused on objects doesn't mean you have to teach OOD right off the bad. You have to start with the basics. True, you going to have kids ask "What does static mean?". You just tell them to ignore it for now. Why is that looked upon as a bad thing? The same thing happens when you teach C++. You tell your beginners to ignore stdio. Later, when it's time, you can teach about includes and classes.

This is why I didn't learn jack shit in college. Everything is focused on OOD. Object this and class that. I am not saying there anything wrong with OOD, but colleges don't focus enough on the fundamentals. That's why there are so many people who overengineer everything and who can't even tell you the difference between a Mergesort and a QuickSort or even know what a Red Black tree is!

Re:OOD101 or CS101? (2, Insightful)

Mr. Shiny And New (525071) | more than 12 years ago | (#4124080)

I agree that a distinction has to be made between OOD and algorithms and basic programming fundamentals. I would say that a good way to learn software development would be as follows:

  • First, learn basics like arrays, data types, operators, functions, pointers, structures. Learn one or two languages.
  • Second, learn about algorithms and data structures. Learn about sorting and merging lists, learn about heaps, stacks, trees, etc. Learn about algorithm complexity. Make sure to emphasize modularization; that is, if you are learning about trees, make sure the code you write to manipulate the tree is cohesive.
  • Learn about objects and OOA/OOD. Learn how data structures lead to classes and objects. Learn about data hiding, iheritence and polymorphism.
  • Learn design patterns. Show how solutions to certain families of problems can be re-used. Show how algorithms can be made more generic by using polymorphism.


  • Somewhere along the line you should learn more about algorithm complexity, various programing paradigms (like functional programing), low-level languages like assembly, operating system and networking concepts, and any advanced topics like databases and distributed programming and real-time programming. But these are all extras. I still think that a programmer needs to learn what a loop is before he should be concerned about what an object is.

Re:OOD101 or CS101? (2)

Tablizer (95088) | more than 12 years ago | (#4124803)

One must learn about variables, arrays, assignment vs. comparison, loops and conditional statements. Then one must learn about functions and how to separate code into them. Simple algorithms need to be introduced as well. Also, how to break down a problem into several steps and then code it. Finally you can start to teach about classes as well as one of my personal favorites, data structures.

And don't forget relational databases. I think relational concepts are some of the greatest ideas of computer science. You can reduce complex GOF-like "patterns" into skinney little formulas, for example. GOF looks like the old-fashioned hard-wired "noun-structure in the code" way of "doing patterns" IMO. Relational transcends most of GOF.

I don't know why database vendors don't spend more effort to point this out. I suppose because in OO projects you often end up noun-modeling twice anyhow: one in code and one in the database. Thus, it has not taken their sales. If dumb developers want to have roughly duplicate structures, why should they care?

(Note that the current vendor offerings of RDBMS are not the ideal, IMO, but good enough for now.)

oop.ismad.com

Reread GOF tehn. Re:OOD101 or CS101? (2)

angel'o'sphere (80593) | more than 12 years ago | (#4127154)


And don't forget relational databases. I think relational concepts are some of the greatest ideas of computer science. You can reduce complex GOF-like "patterns" into skinney little formulas, for example. GOF looks like the old-fashioned hard-wired "noun-structure in the code" way of "doing patterns" IMO. Relational transcends most of GOF.


You are far off topic.

a) a relational data base is not a programming language

b) the relational paradigm has nothing in common with the oo paradigm or the procedural paradigm

c) in a relational data base you store DATA, not code (except for stored procedures)

d) GOF is about structure and behaviour, further: you can't express anything you can express with GOF design patterns in relatinal terms, you are plain wrong.

e) in another post yu critics the need to meditate for thinking right: and? is it not necessary to meditate and think right to apply relational paradigms correctly? I asume you learned all ways of joins in a day? You also learned allways of normalizing data bases in a day?

The thread was about the question how to teach a language. Further more it was about the question how to teach an oo language and how to teach Java.

Its definitly not abpout tabelizers fight against OO paradigms ... you should defintly start to understand your enemy (oo) more in depth before ranting constantly about your superiour procedureal and relational approaches.

In the world I live, procedural is dead ... and in the future I move into oo is allready left behind us, as there are far more efficient ways: aspect oriented and subject oriented programming for instance.

Regards,
angel'o'sphere

Re:Reread GOF tehn. Re:OOD101 or CS101? (1)

Hobophile (602318) | more than 12 years ago | (#4127546)

In the world I live, procedural is dead ... and in the future I move into oo is allready left behind us, as there are far more efficient ways: aspect oriented and subject oriented programming for instance.

Personally, I'm holding out for Programmer Oriented Programming, in which I sit back drinking coffee whilst the IDE orders me a pizza, plays a random selection of my favorite music and monitors Slashdot for new articles.

POP -- not efficient, not maintainable, but very good for morale.

Re:Reread GOF tehn. Re:OOD101 or CS101? (2)

Tablizer (95088) | more than 12 years ago | (#4128329)

(* a relational data base is not a programming language *)

It does not matter. If it replaces GOF it replaces GOF, whether itsa gerbal or a language.

(* in a relational data base you store DATA, not code (except for stored procedures) *)

Yes it can and I have done it before. However, it is not necessary to compete with most of GOF.

(* GOF is about structure and behaviour, further: you can't express anything you can express with GOF design patterns in relatinal terms, you are plain wrong. *)

The relational part replaces *most* of it. It does *not* have to replace *all* to be an effective alternative.

(* in another post yu critics the need to meditate for thinking right *)

No! I pointed out a contradiction of claims. I don't dispute that relational takes training.

(* The thread was about the question how to teach a language. *)

Yes, but "why" and "when" is a prerequisite to "how".

(* you should defintly start to understand your enemy (oo) more in depth before ranting *)

Red herring insult. I personally think you don't understand how to effectively use relational technology.

(* In the world I live, procedural is dead *)

In practice it is very much alive, even in OOP languages (it is just more bloated in them).

Re:Reread GOF tehn. Re:OOD101 or CS101? (2)

Tablizer (95088) | more than 12 years ago | (#4128621)

In my reply I forgot to mention:

and in the future I move into oo is allready left behind us, as there are far more efficient ways: aspect oriented and subject oriented programming for instance.


These technologies are currently only at the "lab" stage and are yet more convoluted patches on top of already convoluted OO to "fix" the sins of OO.

They are at least a realization that OOP cannot handle relativism very well. Even IBM more or less agrees that OO has relativism problems in its introduction to such technologies.

Are you gonna call IBM a "troll" also?

Re:OOD101 or CS101? (2)

platypus (18156) | more than 12 years ago | (#4126241)

Indeed. You also don't teach tensor algebra before people have learned how to add two variables.

Tensor algebra & mathematics is actually a very nice analogy to OOP&programming.

One professor I had said when he introduced us to tensors that you don't understand them, you get used to them.

And that is exactly what my expierence is with OOP. At first it "feels" strange and new, and you have a problem wrapping your mind around it. But the more you try, the more natural it feels.

Another good example is languages. You can learn the rules and vocabulary of a foreign language as long as you want, if you don't speak and write ("get used to it") and with it learn to "think" the language, you'll never really be able to use it as a tool.

Re:OOD101 or CS101? (2)

bay43270 (267213) | more than 12 years ago | (#4127069)

Your right. That point, in fact, negates the entire article. He skips back and forth between intro classes and more advanced classes as his arguments require.

And I certainly hope this was just a thoughtless mistake:
"If you were highly charitable, you might give HelloWorld OO points because the println() method of the out class in the System package is being invoked."

System is a class
out is a field (a PrintStream instance)

MOD PARENT UP (0)

Anonymous Coward | more than 12 years ago | (#4127497)

This is exactly what I'm talking about. I'm tired of people saying "OO is more like what people think and how they're used to interacting"

NO IT ISN'T. When I want something done, I take a series of steps, a procedure mind-you and guess what paradigm most closely resembles that? Huh, the procedural. Imagine that. When someone is learning progrmming it's much easier to teach them something like C where it does what you tell it to (and nothing else). The student gets to go "I want to do this, then this, then this, then I'm done." Instead of, if I do this it'll send a message to these two other objects and they'll handle it in different ways and send off more messages.

You teach in procedural because that's how people get things done. You don't think in OO, you think in procedural. You say, I open the door to my car, get in and start it. You don't say, I'm going to send a message to my arm to open the dorr, the door is going to catch that message and respond appropriately, then I send another message to a my body to get in, and that goes through the inheritance tree to all my muscles to tell them what to do, etc. See how long and convoluted it gets? Sure, when you really break things down the world goes OO -- and that's what happens in a program, you kinda break things down. But it's much easier to teach someone to program by using how they do things, and then go OO and really get into the details. I really like OO and after using C++ and getting used to the OO design, I'm not sure I ever want to go back to C. But having learned C first really gives me an appreciation for C++ and for the wide variety of ways to get things done in each programming paradigm. It was also, quick easy and fun to learn. It simply did what I told it to do, no ifs ands or buts about it. I liked that a lot when I was a n00b. I use each according to what the best tool for the job is.

Re:MOD PARENT UP (2)

Tablizer (95088) | more than 12 years ago | (#4128864)

You teach in procedural because that's how people get things done. You don't think in OO, you think in procedural.

I have learned to stop declaring "how people think". There is too much variation from person to person. Thus, basing any assumption about IT on "how people think" is a can of worms. I can tell you how I think, but not much about others.

I'm not sure I ever want to go back to C. But having learned C first really gives me an appreciation for C++ and for the wide variety of ways to get things done in each programming paradigm.

I am bothered by comparisons between C and C++ as a microcosm for paradigm comparisons. I don't like OOP, but I also don't like C.

C and Pascal are *not* the pennacle of procedural. It would be like using a model T car to compare cars to trains.

(Some people swear by C, but it is just not for me. Nothing personal to C fans.)

Introduce JUnit as a means of grading (4, Interesting)

jefflinwood (20955) | more than 12 years ago | (#4123969)

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 (2, Interesting)

HaiLHaiL (250648) | more than 12 years ago | (#4124565)

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).

Re:Introduce JUnit as a means of grading (2)

jefflinwood (20955) | more than 12 years ago | (#4124800)

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

I agree with you. I think undergraduate degrees in software engineering should be more readily available (and accredited by ABET [abet.org] ). Sort of like the difference between chemistry and chemical engineering. Degrees in IS/MIS are available, but those are really focused on becoming a systems analyst or a corporate IT programmer, and not very heavy on actual programming or design.

Re:Introduce JUnit as a means of grading (2, Informative)

Orthanc_duo (452395) | more than 12 years ago | (#4124829)

JUnit could be used to create a test harn...

I'm currently at Uni and we've had several large projects with automated test as part of the assesment (some using JUnit).

Last time I checked no-one writes completly bug free code, we had problems with bugs in the tests. I believe this will happen to some extent with any automated tests being used to mark an assignment.
Anyway to use something like JUnit to define tests you also need to define all the class's and public methods for the students. This may work fine for comsci101 but at any higher level assignments need to have some design flexibility.

Orthanc

Hello World not OO? Hello MCFLY! (5, Insightful)

PD (9577) | more than 12 years ago | (#4124055)

There really is no good OO way to print in Java. How are you going to make a hello world program print? System.out.println ("foo") isn't any better than the old BASIC

10 PRINT "FOO"

It does little good to make a version of hello world that has some objects in it when in the end there will be a System.out.println call.

I think you're really arguing for a language that will let you write hello world like this:

"hello, world".print

Re:Hello World not OO? Hello MCFLY! (0)

Anonymous Coward | more than 12 years ago | (#4124085)

"hello, world".print
reads like FRENCH!

Re:Hello World not OO? Hello MCFLY! (2)

Arandir (19206) | more than 12 years ago | (#4124313)

I've always like the C++ iostreams way of printing. It's not pure OO, but it's intuitive. It just needs another set of operators.

I think where Java gets it wrong, and why "System.out.println()" looks so silly to you, is that Java students are taught that everything is an object. But not everything is an object, especially when you're printing.

Re:Hello World not OO? Hello MCFLY! (2, Insightful)

Xavier Shirin (445036) | more than 12 years ago | (#4124435)

Everything IS an object, but most computer people don't think about things that way, because they learned to code procedurally. To many programmers, objects are auxiliary to functions, used only when it is necessary to organize.

If you teach a student to think in an object oriented way from day one, they will think of everything as objects, just like most coders think in procedures now.

But that's just my two cents.

Re:Hello World not OO? Hello MCFLY! (2)

Tablizer (95088) | more than 12 years ago | (#4124835)

(* If you teach a student to think in an object oriented way from day one, they will think of everything as objects, just like most coders think in procedures now. *)

First, it should be demonstrated that OOP is objectively better *before* making students think in such ways without giving them much alternatives.

I will agree that OOP seems effective in physical modeling, where it was born (Simula 67), but IMO the benefits there do not extrapolate to modern business systems.

The main reason is that modern systems need "relativistic abstraction", which OOP does not provide without making tangled messes. OOP is obtimized for hierarchical IS-A abstraction, which is the antithesis of relativism, where sets and "view formulas" do better IMO.

Re:Hello World not OO? Hello MCFLY! (2)

angel'o'sphere (80593) | more than 12 years ago | (#4127281)


First, it should be demonstrated that OOP is objectively better *before* making students think in such ways without giving them much alternatives


this is allready shown ...
as well as it is shown that functional programmng languages are better than procedural ones ...
as well as relational languages are shown to be better than procedural ones ...
as well as it is shown that logic languages are better thanprocedural ones ...

But: procedural languages are (arguable) the easyst ones and thats why they survided still now.

I only know one language wich is still procedural only: Fortran. All other languages have made a hybrid oo evolution.

OOP is obtimized for hierarchical IS-A abstraction

How do you come to that opinion?

The main reason is that modern systems need "relativistic abstraction"

I dont't think so! Today systems need to interact. Ineract with DBs, business logic, and millions of concurrent users. They need to be maintaneable, evolveable and should be reuseable. They need to scale and you like to abstract away technical concerns as often as possible.

The DB you use below such a system, is just a replaceable technical concern.

In 90% of the cases a standard relational DB is not the best choice. Its only the cheapest in terms of available support and existing infrastructure. OO databases are in general far faster than relational ones in typical ussage scenarios.

angel'o'sphere

Re:Hello World not OO? Hello MCFLY! (2)

Tablizer (95088) | more than 12 years ago | (#4128036)

(* this is allready shown ... *)

Bull! Where's it?

(* I only know one language wich is still procedural only: Fortran. All other languages have made a hybrid oo evolution. *)

I thought they were adding OO extensions to Fortran. (Not that it proves anything except that OOP is in style right now.)

(* The DB you use below such a system, is just a replaceable technical concern. *)

Not any more than OOP is.

(* OO databases are in general far faster than relational ones in typical ussage scenarios. *)

Bull!

It is moot anyhow because OO DB's have been selling like Edsels.

I will agree that in *some* domains OODBMS perform better, such as CAD perhaps.

Re:Hello World not OO? Hello MCFLY! (4, Insightful)

Arandir (19206) | more than 12 years ago | (#4124924)

Sometimes you have to live in the real world, and you discover that not everything follows a single paradigm. Languages that follow a single paradigm have serious drawbacks. Java is one. There's a reason why Java isn't used for systems programming. There's a reason why Corel has yet to finish it's Java office suite.

An int is four bytes on my CPU. Why should I have the overhead of an object wrapped around it? Why do I need runtime polymorphism on ints? For OO educational purposes, it makes sense to teach that an int is an object. But often in the real world it's far better to make an int simply four bytes in memory.

Rule of thumb: if polymorphism doesn't make sense for an object, maybe it shouldn't be an object. What can you possibly derive from a bool that wouldn't still be a primitive bool?

Re:Hello World not OO? Hello MCFLY! (2, Insightful)

Mr. Shiny And New (525071) | more than 12 years ago | (#4125620)

Well, in Java, and int is 4 bytes. An Integer is an object wrapped around an int, as you put it. This object is useful for many things. Math isn't really one of them. For plain math, use plain ints.

C#, however, has automatic wrapping of primitive types with objects. This is supposedly done on an as-needed basis. I've never tried it, but I'd assume that the wrapping happens only when it's required, otherwise the VM will preserve the basic types for performance reasons.

As to reasons for why there is a Boolean object, it's really just a question of convenience. The Boolean class contains methods for manipulating booleans, like making Strings out of them, or making new booleans from strings. What's the harm in extending this helper class to also represent a boolean value? It's still an object. Maybe you never need to subclass it? That doesn't mean it shouldn't be an object.

Re:Hello World not OO? Hello MCFLY! (2)

Arandir (19206) | more than 12 years ago | (#4128940)

For plain math, use plain ints.

But then it's not an object! I thought everything was supposed to be an object.

The Boolean class contains methods for manipulating booleans

Sounds like an adaptor class to me. The bool itself is still a non-object. If you make a string of bools, that string is not a bool, it's a string of bools. Adaptor classes are handy for such cases, but don't confuse the wrapper with the contents.

Re:Hello World not OO? Hello MCFLY! (1)

davidmccabe (516209) | more than 12 years ago | (#4124399)

<quote>"hello, world".print</quote>

Ruby does a lot of things like that.

5.*(5)
> 25

Re:Hello World not OO? Hello MCFLY! (1)

PD (9577) | more than 12 years ago | (#4124415)

Very cool, I didn't know that.

Re:Hello World not OO? Hello MCFLY! (1)

davidmccabe (516209) | more than 12 years ago | (#4124449)

Yes, Ruby is cool, and by the way:

What about 'System.out' isn't OO? There is an object called 'out', which is of type 'PrintWriter', and a member of the class 'System', and we are calling its method 'println', passing it an object of type 'String'.

Re:Hello World not OO? Hello MCFLY! (2)

PD (9577) | more than 12 years ago | (#4124537)

It's OO, but it's the wrong abstraction, in my opinion. These things are sometimes a matter of taste, but instead of telling the system to print a string, the string should be told to print itself.

The string properly knows how to print itself. Am I null terminated or not? Am I a date string?

The system will know how to print a string, but it can't be expected to know how to print an inventory, a window, or a report.

Re:Hello World not OO? Hello MCFLY! (1)

Nicopa (87617) | more than 12 years ago | (#4124868)

The system will know how to print a string, but it can't be expected to know how to print an inventory, a window, or a report.
Yes, you just need to tell objects how to print themselves by overriding the toString() method.

You break the abstraction going the other way... (2)

Jayson (2343) | more than 12 years ago | (#4125165)

Telling the string to print itself may sound fine, but then the String object needs to be aware of how the mechanics of printing work. At some deeper level you will have function that takes ar argument that finanlly delivers it to an outbound stream, just as the PrintWriter object does. You can't win either way.

This is a good example of one of the many lose-lose situations you have in OO design.

Re:Hello World not OO? Hello MCFLY! (1)

TeeWee (98278) | more than 12 years ago | (#4125307)

What about 'System.out' isn't OO? There is an object called 'out', which is of type 'PrintWriter', and a member of the class 'System', and we are calling its method 'println', passing it an object of type 'String'.

Arguably, this is the wrong abstraction. It's the choice between:
OutputMedium.print(Object.toString());
and
Object.printOn(OutputMedium);
In most cases, the Object being printed is the more imortant of the two and the one which knows in which form it wants to be printed, so it might be a better abstraction to put the printing functionality in the Object ot be printed.

The "System.out.println(...)" way may induce a more procedural way to code things than putting the printing methods in the Object itself.

Re:Hello World not OO? Hello MCFLY! (0)

Anonymous Coward | more than 12 years ago | (#4126995)

I agree. Why is system.out.println(Object) more oo than puts(const char *). To me, it procedural, but 4x the typing.


Object.println(stream out = cout) seems more oo than me. If I'm not mistaken, NextStep/OpenStep/GnuStep is more like that. OF course, They use Objective C, a real oop language :)

Re:Hello World not OO? Hello MCFLY! (1)

davidmccabe (516209) | more than 12 years ago | (#4127009)

You also have to think about implementation.

Using the o.printOn(OM) method, every object must know how to print itself to an output medium. With the method that Java uses, only the print writer needs to know how to print any object.

Furthermore, what if we want to implement some new and different printing mechanism. You see that with your method, every object needs to know something about how output streams work. With the Java method, they don't. Streams, or any other kind of output, is actually more encapsulated.

Re:Hello World not OO? Hello MCFLY! (1)

Narchie Troll (581273) | more than 12 years ago | (#4124430)

No, the argument is that "Hello, World" (gasp) isn't an appropriate first program for learning Java. I don't think it's an appropriate first program for anything, personally.

Re:Hello World not OO? Hello MCFLY! (2)

scrytch (9198) | more than 12 years ago | (#4127553)

> "hello, world".print

You want to get finicky, that's still not great OO design. Unless you're designing a class hierarchy where every object has a print method, chances are you want to tell some output stream to print something, at which the output stream requests some format it prefers from the object being printed. With a .print method on objects, you have to have some print object in scope somewhere, on the object, the class, or globally. Should each possible scope really be deciding on its own what the default output stream is?

Thus

stdout.print(hellomsg)

Or in more familiar syntax ...

cout hellomsg;

(Note that I have issues with C++ iostreams, but they did get this part right).

In in a language that supports multiple dispatch, the issue is a bit moot, but what you put on the left side of the dot (or arrow or whatever) in most OO languages can make a big difference in design down the road.

teaching OOP first may not be the way to go (2, Interesting)

Anonymous Coward | more than 12 years ago | (#4124103)

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.

Re:teaching OOP first may not be the way to go (2)

PythonOrRuby (546749) | more than 12 years ago | (#4124320)

I like Eiffel for this purpose. Clean syntax, and straightforward, relatively simple rules.

Most importantly though, nothing takes place outside of a class. Consistency is good, as people tend to get confused when explaining exceptions to the rules.

If you're going to teach OOP, in my humble opinion, you need to stress thinking about problems in terms of classes and objects from the very first day.

The other approach I've given serious thought to is using a language like Perl to start out by showing how things can be done in a quick and dirty way, but then expand the "hello, world"(output) script to saying "hello" to a person(input), and so on and so on, and show how modules and classes can make expanding a small program much easier. At the same time, as you construct a class, you can demonstrate arrays, associative arrays, looping, conditionals, etc.

I'm still debating which is the better approach.

Re:teaching OOP first may not be the way to go (1)

Jersiais (597082) | more than 12 years ago | (#4125534)

I'm mostly replying to the one above because I can't find a 'reply' for it. "Hello World".print sounds the hell of a lot like SmallTalk. If you like a language where CASE and ELSE-IF are impossible because a program statement is an object and an object must have finite limitations, where every dimension of array needs a separate definition, then ST for you! Personlly, I suspect *all* these Ultimate Solutions of faddism. There are occasions where 'goto' is useful - even if disguised as 'break' or 'continue' or even 'throw', which is the worst example of unstructured programming I can think of. OK, I have a bias here: my favourite for personal hacking has been Algol-68 for about 15 years. None of that having to remember that C(++) can't tell that one part of a CASE ends when the next begins, no worries about one form for IF that doesn't assign, another if it does, no incomprehensible near-assembler loops or syntactic distinctions between test before/test after. And, if you really want it, yes a Procedure has as much right to be part of a Structure as anything else. Are the complexities of 'black boxing' objects (a sure way to make using them 100 times more difficult as there's no knowing what's going on) really necessary once precompiled libraries can be called or read-only modules inserted? I suspect here a certain amount of gimmickry because C is such a lousy Fortran-inspired mess.

Teach libraries first (2, Interesting)

Anonymous Coward | more than 12 years ago | (#4124115)

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.

How do you learn C, how do you learn Java? (2)

angel'o'sphere (80593) | more than 12 years ago | (#4124218)

A quote from the articel:


As we learned more and more about programming in Java, we found that C was not the right way to approach Java.


To learn C you need to know assembler(it was invented to be a portable assembler).

To learn C++ you need to know C (otherwise you better skip directly to Java/OO Pascal or well SmalTalk ... if not Eiffel).

Unfortunatly you can not teach a starter in CS assembler, hm ... why not, sure you could! I learned assembler when I was 16 ....

Unfortunatly CS emphasizes learnig of a beginners language. Instead of teaching higher level concepts. OTOH, thats what the students want and expect ...

And if a course is directly put into touch with higher level concepts, you can bet its not only functional like Miranda or Ml, no you have Lisp .... arguable the ugliest language existinge besides fortrana nd JCL.

I for my part only teach UML .... and wait for CASE systems wich skip from diagramming to code directly.

angel'o'sphere

huh? not higher level concepts? (2)

Jayson (2343) | more than 12 years ago | (#4125180)

Unfortunatly CS emphasizes learnig of a beginners language. Instead of teaching higher level concepts.
At Cal the first class you have is SICP. It is nothing but high-level languages and concepts.

Re:How do you learn C, how do you learn Java? (2)

scrytch (9198) | more than 12 years ago | (#4127693)

> To learn C++ you need to know C

A certain Mr. Stroustrup disagrees with you. In fact, C will teach you all kinds of things you need to unlearn in C++, such as pointer usage, arrays, and imperative design, that can be superseded with references, containers, and predicates, all to be found in the C++ standard library. To say nothing of generic programming with templates (you can actually write entire programs in nothing but templates, they're turing complete).

OO is for wankers (1, Interesting)

Anonymous Coward | more than 12 years ago | (#4124285)

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:OO is for wankers (2)

PythonOrRuby (546749) | more than 12 years ago | (#4124340)

Computers don't think at all. Does that mean programmers shouldn't?

Because even Assembly is an abstraction, and once you start down that road, you might as well go all the way.

The third line pretends that their are strict lines drawn between procedural, functional, and OO programming paradigms.

And how are methods anything other than functions or procedures which operate on an encapsulated set of variables?

Re:OO is for wankers (1)

Orthanc_duo (452395) | more than 12 years ago | (#4124846)

Agreed. Though like all programming tools/consepts/languages OO is a good choice is some situations (most in my opinion). A lot of the crap OO is generated by people using OO where it's not appropriate or by using it badly (eg bad abstrations).

"A place for everything and everthing in it's place"

Orthanc

Re:OO is for wankers (2)

Tablizer (95088) | more than 12 years ago | (#4124888)

Agreed. Though like all programming tools/consepts/languages OO is a good choice is some situations (most in my opinion). A lot of the crap OO is generated by people using OO where it's not appropriate or by using it badly (eg bad abstrations).

I have tried to get useful descriptions of when and when not to use OOP by asking OO fans.

But, I get a different answer from every OO fan I ask.

OOP has shot consistency between the eyes.

I find procedural/relational design more consistent: tasks go into code structures, and noun modeling goes into the database and relational algebra (as opposed to also going into code structures such as classes).

Sure, there are differences from one p/r programmer to another, but not NEAR as much between as from one OO practitioner and another. They will bash each other's OO design, but cannot articulate exactly why one is bad. It is a doctrine fight usually. "But you are violating the Wesly-Demeter Principle blah blah".

I usually justify my designs in terms of how they will handle the most likely changes and change patterns. Using this metric, I can match or beat most OO designs. (Although the doctrine sometimes blinds OO fans to actual change patterns by hiliting only certain change patterns. It is hard to get beyond such points because it is one's world view in a given domain that you are up against. "Brainwashing" is what comes to mind. Indoctrinate not only the solution, but the problem as well by focusing only on a narrow subset of reality.)

oop.ismad.com

Re:OO is for wankers (1)

Orthanc_duo (452395) | more than 12 years ago | (#4125424)

I don't think there is a simple rule to say when you should use OO, or procedural (or functional programming for that matter). Often it is simply a matter of preferance. However for many situations OOP just seems to fit. There are of course situations where using OO is a really bad idea (acursed JSP's for example).

OO has been around for a while but it only caught on relativly recently. This goes a long way to explaining the lack of consistancy.

But you are violating the Wesly-Demeter Principle blah blah
Sounds more like a professor than a programmer.

Orthanc

re: OOP and consistency (2)

Tablizer (95088) | more than 12 years ago | (#4128675)

(* OO has been around for a while but it only caught on relativly recently. This goes a long way to explaining the lack of consistancy.*)

Shouldn't they solve the consistency problems *before* taking it mainstream?

It may turn out that consistency is a fault of the paradigm and not just the learning curve.

Besides, well-known OO practicioners who have been doing OOP for 15+ years show few signs of converging with each other.

Re:OO is for wankers (1)

javahacker (469605) | more than 12 years ago | (#4126968)

Structured programming is a methodology. OOP is a methodology.

A methodology is generated by looking at what good developers are doing, and producing a description (or set of rules) that tells you how they did it.

OOP is what the best structured programming people were using, at least in some set of problems. Structured programming was what the best programmers were doing before anyone ever created the structured programming methodology.

Some programs do not benefit much from OOP. Many OOP based programs were generated without accounting for all of the requirements, either known or unknown, of the problem. They would have been bad regardless of the language or methodology used. OOP doesn't mean the code is good, it is merely a method that some very good coders use. Bad code can be generated no matter what methodology the programmer says they are using.

Re:OO is for wankers (2)

Tablizer (95088) | more than 12 years ago | (#4127969)

(* A methodology is generated by looking at what good developers are doing, and producing a description (or set of rules) that tells you how they did it. *)

How does one judge "good developers"? If you judge it by articulation skills, then most OO fans I know really suck. "It is good because I have experience and I just say so" is commonplace. Is science and western-style reductionism really dead in software eng.?

(* Many OOP based programs were generated without accounting for all of the requirements, either known or unknown, of the problem. *)

This is a weakness of OOP IMO. The "noun modeling" is in code instead of via relational formulas (as described elsewhere). Formulas are less disruptive to change than code structure (named units, etc.). GOF is the old-fashioned way.

(* Structured programming is a methodology. OOP is a methodology. *)

Structured programming + Databases is also a methodology, although it is not documented very well. Databases are what gives procedural programming its real power, not mere functional decomposition by itself. It makes structures/patterns virtual and formula-based instead of something you build by hand.

Would you rather order a bunch of bricks into place, or lay them yourself brick by brick?

Re:OO is for wankers (1)

javahacker (469605) | more than 12 years ago | (#4129277)

How does one judge "good developers"?

They are judged by their peers, the people who have to deal with the code they produced. They are judged by the results they produce, not by how well they advertise themselves. Either you, or the people you are talking about, are talking trash. I don't know enough to tell which for sure, but you talk like you didn't keep up with the last 10-15 years of software engineering, and don't care to learn it. I know your experiences with OOP are very different than mine, either because you aren't open to seeing the benefit of OOP, or because you worked with some really bad developers who said they knew (and used) OOP.

Databases are what gives procedural programming its real power, not mere functional decomposition by itself.

Believe it or not, OOP programmers use Databases! All you are saying is flexible software (whatever design methodology you use) is better than inflexible software. What an amazing observation! Tell us something we don't know. So you saw some bad OOP designs, probably created by people who didn't understand either OOP, or the problem domain they were trying to solve. Confusion processed by crap is crap, there is no other possible result. That says nothing about OOP, and everything about the people and processes involved.

Would you rather order a bunch of bricks into place, or lay them yourself brick by brick?

If I want a house, I'd rather have the house than the parts of a house (bricks), and I'd rather have bricks than the components of a brick. If you have to solve a problem, the solution takes about the same amount of work to develop, no matter what system you use.

The "noun modeling" is in code instead of via relational formulas

What on earth are you talking about? If the code has to perform certain operations, they need to be coded somewhere, don't they? Someone has to write them, in whatever form they may be in. Somewhere, either in your "formula", or in code, they need to be implemented. A bad implementation is just that, a bad implementation.

Re:OO is for wankers (2)

Tablizer (95088) | more than 12 years ago | (#4129531)

(* They are judged by their peers *)

OOP opinions are currently clouded by an Emporer's New Clothes syndrom. Anybody who speaks out is called a Luddite or the likes.

(* Believe it or not, OOP programmers use Databases! *)

But OO and databases tend to fight over the same territory. If you want to properly factor responsibilities and roles of the various technologies to reduce duplication and/or overlap, then one or the other must go.

Even Bertrand Meyer questions the wisdom of databases with OOP.

(* So you saw some bad OOP designs, probably created by people who didn't understand either OOP *)

Perhaps. I have asked for some good designs that show clear benefits and never receive any that stand up to scrutiny.

Besides, if only 2 percent know how to do OOP "properly", then there may be a huge problem with OOP. Ed Yourdon's surveys find no higher manager-level satisfaction with OOP projects, I would note. So either OO sucks or its too hard to "do right".

(* If you have to solve a problem, the solution takes about the same amount of work to develop, no matter what system you use. *)

I disagree. I found formula-based structuring/patterning to be quicker, more change-friendly, and less verbose.

(* What on earth are you talking about? If the code has to perform certain operations, they need to be coded somewhere, don't they? *)

I see a lot of OOP code or API's that *reinvents* database-like operations (find, join, get, set, insert, delete, save, filter, etc.)

I would rather *use* a database than make one.

(* Somewhere, either in your "formula", or in code, they need to be implemented. *)

I find the formula approach more compact, less intrusive to the global code structure, and more change-friendly.

Re:OO is for wankers (1)

javahacker (469605) | more than 12 years ago | (#4130059)

But OO and databases tend to fight over the same territory. If you want to properly factor responsibilities and roles of the various technologies to reduce duplication and/or overlap, then one or the other must go.

OO is good for working with database items on an item at a time basis. If you need a database join, then you should do one. I know no good developers who want to waste time coding something that they can do with a SQL statement.

I'm obviously not going to convince you that OOP is a good thing, and that is not my purpose. You are saying many things about OOP that I feel are incorrect or undeserved, and my purpose here was to say that what you have seen is not necessariy the whole story.

You aren't going to convince me that it is bad, because I have seen otherwise. Like every system for accomplishing something, it can be misapplied, misunderstood, and just generally not applicable to some problems. I think that point has been made.

big fOOt (2)

Tablizer (95088) | more than 12 years ago | (#4130282)

(* I know no good developers who want to waste time coding something that they can do with a SQL statement. *)

Then how do you explain most of the GOF patterns, which can be tablized? Perhaps they are targeting systems software instead of business applications, but shouldn't that be stated somewhere? (I think someday relational technology will be used in S.S. also.)

(* You are saying many things about OOP that I feel are incorrect or undeserved, *)

The lack of consistency in the OO community makes it such that *no matter* what I say/show about OO, at least one OO fan will object to my characterization of OO. IOW, it is probably impossible to please them all.

(* You aren't going to convince me that it is bad, because I have seen otherwise. *)

Well, either the benefits are subjective (OO better fits your mind), or are like Bigfoot: every OO fan has seen them, but never captures them on film.

When I see a side-by-side comparision of good OOP shining compared to good procedural/relational, then I will believe you.

Until then, I only have bigfoot stories from OO fans.

Equal or unknown until proven otherwise.

Re:OO is for wankers (2)

angel'o'sphere (80593) | more than 12 years ago | (#4130264)


GOF is the old-fashioned way.


Please stop ranting against GOF, Ganng of Four, Design Patterns, Elements of Reusable Object Oriented Software.

In every sentence where you write: GOF == "bad term" you only show your bloudy ignorance.

Justifying that OO is 'bad' by claming all your friends who are OO fans are bad programmers ... thats so silly.

BTW: can someone please explain me how to put one on the ignore list?

tabelzier, stick to your tables .... whats arelational formular anyhow? That term does not exist in CS!

angel'o'sphere

Re:OO is for wankers (2)

Tablizer (95088) | more than 12 years ago | (#4130338)

Your complaints against me here are as vague as most OOP evidence.

Whatever. (1)

Lukey Boy (16717) | more than 12 years ago | (#4124396)

Is it just me or is that the biggest troll ever on the O'Reilly site?

OOP is "cool" != It's the foundation of CS (1)

SyniK (11922) | more than 12 years ago | (#4124411)

Basic -> C -> ASM -> C++ -> Java

Where's the problem? OOP without the background does not make very good programmers. It makes Visual Basic programmers with VM's.

"Let's abstract everything! Let's not worry about memory size, program speed, and code reuse!"

Java is just the tip of the iceburg (5, Insightful)

Dr. Bent (533421) | more than 12 years ago | (#4124553)

The real problem here is software development has moved beyond what a scientific discipline can handle. Much like modern electrical engineering evolved from the findings of early 20th century experiments with electricity, the need for real software engineering is starting to become apparent.

But, as always, acedemia is behind the curve. Not that they should be on the bleeding edge, but now it's time to catch up. Computer Science programs across the country have started to straddle the fence when it comes to coursework. Do we teach theoretical science, or applied science? This is a mistake; Nothing done half-assed is ever worthwhile. Do not make Computer Science more like an engineering discipline. Instead, make Software Engineering an undergrad degree unto itself.

You should be able to teach CS101 in any language. If you can't, then you're trying to teach engineering in a science class. A stack is a stack regardless of what langauge it's written in. Don't pollute computer science by trying to make it something it isn't. Instead, make a new Class (pun!)...Software Engineering 101. There you can teach design methodologies (Like OOP), proper use of the latest tools, automated testing methods, and other applied theory that has no business in a computer science class.

This is not to say they there wouldn't be a great deal of overlap between a C.S. and S.E. degree. After all, you have to learn physics before you can be a Civil Engineer. But it's just not possible to teach you everything there is to know in 4 years. I've learned so many formalisms and techniques since I recieved my B.S. in C.S. that I wondered why I hadn't heard anything about them while I was in school. The answer, I realized, is the days of the computer Renaisannce man are ending. Developing an algorithm and developing a software system are two completely different tasks. Just as a physicst can't build a bridge and a Civil Engineer didn't invent Superstring thoery, you can't ask a computer scientist to build a software system or ask a software engineer to develop a new compression algorithm...it's just the wrong skillset for the job.

Re:Java is just the tip of the iceburg (1)

budalite (454527) | more than 12 years ago | (#4125916)

I find it interesting that ther term "Computer Science" is really an oxymoron. Computer Science is not a Natural Science. Our chosen field does not discover the laws of Computer Science; we make them up. These "laws" are often contradictory. (Poor HAL.) Compliance with the laws is not always compulsory. Indeed, if one has the power, one may even change the law(s), thereby changing the basic structure of the universe that Computer Science purports to study. Even Psychology, the least coherent of Sciences, has a natural model to study. It is also interesting to study the behavior of those that are given the opportunity to act like a god.

Re:Java is just the tip of the iceburg (2)

Tablizer (95088) | more than 12 years ago | (#4129172)

I find it interesting that ther term "Computer Science" is really an oxymoron.

About half of it belongs in the same category as "engineering" and the other half in psychology. The psychology part is key to software engineering (SE). SE is mostly about humans communicating with *other* humans (programmers). The computer is secondary.

Many early SE experts tried to apply math, but it did not work very well. It comes down to the human brain, which still ranks among the biggest mysteries of science.

Thus, anything in SE that deals with "is X better than Y" is going to have to get neck-deep in psychology.

The only known semi-objective metrics outside of psychology that have any merit are code size (quantity of lines of code or tokens) and scenario-based change-impact-analysis.

Re:Java is just the tip of the iceburg (1)

g1zmo (315166) | more than 12 years ago | (#4126550)

I am a Software Engineering major.

My school [uta.edu] offers 3 degrees in the Computer Science Engineering department: CSE, CS, and SE. There's a comparison of each degree here [uta.edu] . I think these programs are well-balanced, and a good separation of the fields that you are talking about. I chose the SE path because I enjoy the design process of thinking, planning, and adjusting based on project requirements much more than I enjoy cranking out code (although I've lost much sleep and a couple of girlfriends due to late night coding frenzies). I'm still young, and in school, but I would love to be able to work on a large software project in a team environment with capable peers. In fact, I'd love to be able to work on a project with gods, so I can soak up as much as possible. I love this stuff!

C++ inventors on how to teach C++ (2)

devphil (51341) | more than 12 years ago | (#4126828)

Do we teach theoretical science, or applied science?

You teach by example, and do both. Andrew Koenig and Barbara Moo, two of the prime movers behind C++, wrote a book called Accelerated C++: Pratical Programming by Example [att.com] , as a new approach to teaching C++.

It absolutely kicks ass. Somebody else on this page commented that you need to learn C before learning C++. Most C++ people disagree; this book proves them correct. It starts with

#include <iostream>

// something went here

int main()
{
std::cout << "Hello, World!" << std::endl;
}
and the first lesson was, "the most important line in this program is the second one," i.e., the comment. How refreshing is that? It does not then follow up by diving into the guts of the IOstream library; they simply say, "when you want to send stuff to the screen, use this; when you want to get stuff from the keyboard, use this," and leave the details for later. Even though the IOstream library involves OOP, they don't shove the user's nose in it.

The people I know who have started using this book, and the approach that they advocate, to teach beginning programmers, have all found their students not only picking up the language faster, but being less frustrated with programming in general (admit it, we've all been there), and having a better understanding of what's happening in their code.

(Pointers aren't even introduced until chapter 9 or 10, which means anything that visibly uses pointers isn't needed until then, either. Very nice.)

like the old joke... (1)

dhclab49 (567553) | more than 12 years ago | (#4130030)

iceburg, goldburg, whatever...

Fundamental CS FIRST (0)

Anonymous Coward | more than 12 years ago | (#4124576)

Goals for first time CS students (not those with any programming exp.) should be:
  • Learn what a text file is and what code is
  • Learn what machine language is (not learn machine language, just what it is... like: French is the language spoken in France)
  • Learn that text is compiled into machine language
  • Learn how to create a text file, put some code in it... and then compile it into French... er machine language ie: HelloWorld
  • Now we learn variables, control statements, loops, functions, and simple data structures including objects if you like

You can't introduce Objects first. To do that would be like introducing a child to touch typing before they know the alphabet. You can do it but damn it makes so much more sense to build up from the basics.

*lol* Now some hair-brain is going to teach his kid to touch type before the A-B-Cs and we'll read about it next year on Slashdot!

-- Zarf

Use this program in classes (2, Interesting)

doc modulo (568776) | more than 12 years ago | (#4124894)

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

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

OO overrated - Lisp beats Java any day, too. (1, Insightful)

Anonymous Coward | more than 12 years ago | (#4125039)

Bleurgh. OO isn't everything, and Java OO is deeply crippled and sucky anyway. Common Lisp, perhaps closely followed by Smalltalk, has the best OO programming (and is the _only_ language that can fully satisfy every feature on the OMG description of OOP!) - but, paradoxically, Lisp is a language where one seldom resorts to huge baroque OO stuff anyway.

N.B. One should be teaching general principles, not language-of-the-day, anyway - I am not suggesting Lisp is the one-true-language, anymore than Java is - Lisp would suck for teaching manual memory management techniques, for example.

Re:OO overrated - Lisp beats Java any day, too. (0)

Anonymous Coward | more than 12 years ago | (#4125762)

Mod this up. Why the hell is Java being used for introductory courses?

Re:OO overrated - Lisp beats Java any day, too. (2)

Tablizer (95088) | more than 12 years ago | (#4128720)

Mod this up. Why the hell is Java being used for introductory courses?

Because the outside world often does not share the same ideologies as universities, and graduates need jobs so that they can pay off their student loans.

I am just the messenger.

Python (2, Insightful)

tdelaney (458893) | more than 12 years ago | (#4125279)

print 'Hello, world!'

It does exactly what it needs to, without anything extra. Each piece can be discussed separated, and picked apart or expanded as desired.

Re:Python (1)

zero_offset (200586) | more than 12 years ago | (#4125674)

The use of apostrophes is an obvious improvement over the quotes used by BASIC: PRINT "Hello, Python." Now THAT's what I call unacceptable syntax. (Of course I know the difference, it just struck me as amusing.)

Re:Python (3, Funny)

ameoba (173803) | more than 12 years ago | (#4127021)

actually, python is a -very- dynamic language. You can do hello world as:

print 'hello world'

or:

print "hello world"

or even:

exec(__import__('zlib').decompress(__import__(
'binascii').a2b_base64("eNqNkuFqgzAUhV/lUhi5m"
"T HoxvZDqtC1b+FE7BQWMCqaMfb2S6LVxcra/MnlcL5zr"
"95g XchzWcCBQRenQcbgzVyPz4E5DI4Qw2Q5aUvHQEoGZ"
"wER4A mKpgTEkwYgjoHsiVWaVmknz/OhUkJVMs8xYNh12"
"uaH9OHp 5ZVC28OMJTcxbwvzFkxKB7MMkzK1haEd0L8X9"
"FcgW8A8F7 Jre6UhMvwMhPJBle2X4t+9zsJdAjv6f5e2L"
"3EzRTS8r4qy Fk2FVDupOwS/e4iPzx7nb6F0nOcs9L7CK"
"Pu7TLdBSqa9jq NP/AzzoauFQpIRFtI0dINsEl5DpqMLB"
"qsJZudqtDEynK4I jngYLfql6uc5gjd+BHlvCKV6Kd7lp"
"PtLlfjZnieObCSPTx I3BU/9LPGuTHwJnCNd3YpWMim+P"
"dOli+1U223J5Tv6C+uY BZc=")))

Python also has the added bennefit of being an all-around much simpler language to learn than Java, as the last example demonstrates.

Re:Python (0)

Anonymous Coward | more than 12 years ago | (#4129706)

More cute would be to show that strings are actually objects in python2. The following prints "HELLO WORLD", but without using the built-in syntax "print" just to be different. The module "sys" has an object "stdout" which knows how to do "write":

import sys
sys.stdout.write("hello world\n".swapcase())

It's different for some. (0)

Anonymous Coward | more than 12 years ago | (#4125305)

In a nutshell, OOP even nowadays is treated as somewhat innovative concept in the classroom, mainly because of educators, who were taught C.

I post this as a first year Computer Systems Engineering/Computer Science University student.

At my Uni (Perth, Western Australia), a students first introduction to programming is in Java. The fundamental concept that is pushed through that first introductory course is the Object Orientated approach to program developement.

For me, it is not taught as a 'somewhat innovative concept'. It is taught from the beginning as valuable concept that we should openly embrace. In fact, it's required of us.

Why use Java for CS101? (1)

TeeWee (98278) | more than 12 years ago | (#4125347)

So many languages to choose from, why use Java. You're unlikely to be able to explain the uses and benefits of OO in the first classes, better stick to the easier to explain benefits of good structured programming and progress from there.

Use good strict languages to enforce good behaviour (I was taught using Modula-2) before letting students tackle something as loose as C. It doesn't matter that the language for teaching programming skill is not your fanciest and hottest language, if creating a good programmer is the goal, learning a new language within the same paradigm should be easy!

Progress from one paradigm to another. Put things like OO, functional, logic, procedural in relation to each other. What are the benefits, what are the drawbacks, etc. Also a historical overview is important. Much more important than simply using the fashionable language and paradigm in a 101 course.

Re:Why use Java for CS101? (0)

Anonymous Coward | more than 12 years ago | (#4128938)

Put things like OO, functional, logic, procedural in relation to each other. What are the benefits, what are the drawbacks, etc.

That, my friend, is the Billion Dollar Question around here.

Perhaps a course in comparing and metrics may be helpful. Good critical thinking is probably harder than programming.

A First Language that wasn't BASIC (0)

Anonymous Coward | more than 12 years ago | (#4125707)

I miss Pascal. Siiiiiigh.........

To be or not To Be... (1)

zaqattack911 (532040) | more than 12 years ago | (#4126179)

I agree with the initial question: "Why not just start off with OOP instead of going through the linear hello world approach first".

But oddly all the best programmers I know started off learning something like C , and then later became seasoned and excellent OOP programmers in C++/python/java.

I remember feeling lightyears ahead of my "Intro to programming (using java)" class because I had already tackled some basic C coding in High School."

Is it so hard to beleive that perhaps it's important to learn howto walk before learning how to run ?

--Me

What is an object? What is function? (4, Insightful)

angel'o'sphere (80593) | more than 12 years ago | (#4126423)

I think one problem is the structure of a language.

I mean: what is a first class citizen? In C everything can be degenerated down to a pointer, except a preprocessor macro.

So the only true first class citizen is a pointer, or in other words a memory address. Structs and functions seem to be something utterly different. Even besides the fact that you can take the adress of both.

In C++ suddenly we have similarities: structs are similar to classes and similar to unions. With operator overloading you can manage to get a class behaving like a function, a functor.

But: wouldn't it make more sence to say we only have *one* thing? And wouldn't it make sence to make far more stuff optional? Like return types, access modifiers, linkage modifiers ... void as return type, how silly. I have to write: "HELLO HERE IS NOTHING" instead of writing nothing.

{
int i =1;
}

Whats that? Data? A thing with a 1 inside stored in a thing with name i? Or is it a function with no name and a local variable i with value 1?

lets give it a name:

thing {
int i = 1;
}

Why can't a language creator understand that OO and functional paradigms are just the two sides of the same medal? The thing above serves pretty well as function and as class.

thing a = new thing;

Create an instance of thing ... if (a.i == 1) is true!

if (ting().i == 1) is true also, call thing like a function.

There is no need to have functions and structs to be different kinds of language constructs and thus it makes no sence that a modern our day language forces one to distinguish it.

In short: System Architects get a language wich allows to express the world they like to modell in terms of Objects/things and assign behaviour/functions to objects. Unfortunatly the language designers are mostly BAD OO designers and are not able to apply the first principles of OO correctly to the languages they invent: everything is an object.

Even a for(;;) statement is not a statement. Its an object. Its an instance of the class for, the constructor accepts 3 arguments of type expression, you could say Expression(.boolean.) for the second one. Well, for the compiler it DEFINITLY is only an object: java.AST.statement.ForStatement ... or something. Why the heck can't it be a class available to the ordinary programmer? At least for the teacher and the student it should be viewable as a for object and not a for statement.

Sample:

for (Expression init; Expression(.boolean.) test; Expression reinit) { Block block }

Hm? a function or a class with name for.
Two parameter sections, one in () parenthesis and one in {} braces.

What you pass in () is stored in init, test and reinit. What you pass in {} is stored in block.

The compiler crafter puts a for class into the lirary:

class for (Expression init; Expression(.boolean.) test; Expression reinit) { Block block } {
init();
loop {
test() ? block() : return;
reinit();
}
}

Wow, suddenly everything is a class. Hm, a meta class in the case above probably. A language would be easy to use if I told my student:

Ok, lets store an addressbook! What do you like to be in an adressbook? Name, first name, birthdate, phone number? Ok, then you do something like this:

{ Name, FirstName, Birthdate, PhoneNumber }

We group it. That thing has an anonymous type.

How to create objects?

new { Name="Cool", FirstName="John", Birthdate="12/27/66", PhoneNumber="080012345" }

Wow ... and now we need two of them, so lets give them a name:

cool = new { ... }
bad = new { ... }

And we need to compare them and search them and suddenly we need to put "methods" aka "behavioural" objects into them. Oh, yes and the anonymous thing above needs a name, so it becomes a class.

What I describe above is Lisp, but with a more C/Java/C++ like syntax.

And a radicaly reduced language design. The best would be to put the language design into the runtime libraries.

Yes: every typed language should be able to work typeless as long as you are in a "skteching" phase.

Regards,
angel'o'sphere

Note, for template arguments I used (. and .) instead of what you expect ... /. eats the less and greater signs.

Re:What is an object? What is function? (2)

scrytch (9198) | more than 12 years ago | (#4127777)

> What I describe above is Lisp, but with a more C/Java/C++ like syntax.

Actually it reminded me of nothing so much as the ML line of languages, which includes SML/NJ, Ocaml, and Haskell. All of those give you "anonymous types" like that, with named fields. They even infer types for you, so you can pass an anonymously constructed struct into a field that expected an AddressBookEntry for example, and so long as it had all the same fields, it would accept it. In fact, you don't typically tell functions what type to expect, you just write the code, and the compiler will infer it all for you (sometimes it needs help, so they support type constraints, but those are still inferred, you don't need to declare your anonymous struct as such a type).

I strongly suggest you check out ocaml

Java, OOP, & CS (0)

Anonymous Coward | more than 12 years ago | (#4127441)

I have tutored a lot of people who were taking CS101 type classes at a local community college. The only problem I can see about using Java, or any object oriented language is this.

First of all CS101 is usually counts as an elective in other programs and it is and should be simply an introductory course to programming in general focusing on OOP is being too specialized. Most of the Profs I have talked to average a 50% drop rate during the course of the semester as it is. (Don't worry I'll come back to this point)

Second CS101 is mainly to get people used to programming. It is used to get one to think about all of the details. Forgetting a ';' will come back to bite you in the ass. In a non-language specific class you have to do one of two things then; teache a little of every language any one might use, not likely in the course of 1 semester, or teach the entire intro class using pseudocode. Now ask yourselves honestly, has anyone written an application in pseudocode and gotten it to compile?

Third many people who I tutored for the CS101 class did not learn how to approach programming a problem. The used the plug & chug method, and copied example verbatum out of the text book and had been doing this instead of thinking. So when the instructor gave them an assignment which was a combination of things(eg. read from file, sort alpha betically, sort in new entries, save to file) they could not do it. They saw a sort program in Chapter 4 and a file load program in another and could not figure out how to combine them into a program using functions.

There seems to be a trend of using the cookie cutter approach when teaching CS 'do this because it works don't as why!' if more basic theory was taught in the intro classes I think people would not have a hard time adapting to OOP when it is presented in CS201 or the Data structures course.

And thanks to DR. Krauss who did teach theory.

Computation-as-interaction is a bad idea (3, Interesting)

p3d0 (42270) | more than 12 years ago | (#4128882)

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.

Teaching Java as an OO language (1)

merigold77 (156634) | more than 12 years ago | (#4129854)

Eight years ago I started teaching introductory OO programming classes, first in Smalltalk, then in Java. The classes I taught (which I didn't completely design myself, but mostly taught classes designed by my employers, though I had a bit of free reign to actual instructional technique) did not start with Hello World because that is not the best place to start when teaching object oriented programming.

I saw people ask "well how else can you print" and the answer is: don't start by teaching people how to print. Start by teaching them what objects are, then how to create objects, then how to interact with objects (send messages), then have them create an object and interact with it. If you need to, write a simple "print" object and preload it for them in a JAR so they don't have to think about how to print, they can send a string to the print object and it prints it for them. This is how you get new programmers' heads aimed in the right direction for OO.

Smalltalk is better for this because it always comes with a print object: the Transcript. But it is not so hard to do in Java really.

Take A Step Back First (0)

Mackoid (112674) | more than 12 years ago | (#4130045)

HelloWorld.java is a good enough example of OO programming from the Java perspective but only if it is presented properly. The biggest problem isn't the example, it's the approach used to explain the example.

To present this example an non-OO:

public class HelloWorld {
public static void main( String [] args) {
System.out.println("Hello, world.");
}
}

where clearly from a Java standpoint we have several objects and methods staring back at us is totally incorrect. Perhaps the approach should be to explain from day one why this is considered non-OO and then present an improved example of "good" OO as a contrast. Then, I think the instructors/writers are getting somewhere.

HelloWorld.java isn't about OOP (1)

skSlashDot (518871) | more than 12 years ago | (#4130128)

The real purpose of a "Hello, World" program, in any language, is to ensure that you can compile and execute a program (or run a script). It doesn't have anything to do with OOP at all, and shouldn't.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?