Slashdot Mirror
What's wrong with HelloWorld.Java
prostoalex writes: "Daniel H. Steinberg posted an article on O'Reailly's OnJava.com discussing the difficulties and current problems with introductory Java in the classroom. The textbooks used in colleges are mostly the rewrites of C/C++ textbooks and thus start with HelloWorld program without really dwelling on object-oriented nature of Java and why it is important. In a nutshell, OOP even nowadays is treated as somewhat innovative concept in the classroom, mainly because of educators, who were taught C. Hence links and description of Rethinking CS101 Project."
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!
'A lie if repeated often enough, becomes the truth.' - Goebbels
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!
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.
Tips and Tricks for Mozilla
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
If tits were wings it'd be flying around.
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.
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.
A quote from the articel:
... if not Eiffel).
... why not, sure you could! I learned assembler when I was 16 ....
...
.... arguable the ugliest language existinge besides fortrana nd JCL.
.... and wait for CASE systems wich skip from diagramming to code directly.
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
Unfortunatly you can not teach a starter in CS assembler, hm
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
I for my part only teach UML
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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?
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.
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
Table-ized A.I.
BlueJ
Teachers can start teaching objects and classes from the beginning. They don't have to tell students:
"Just write down: public static void main (String args[]) { } And don't ask me about it until later".
it wouldn't run some of my home-made classes, but then I didn't read the manual :P
- -- Truth addict for life.
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.
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.
I think one problem is the structure of a language.
... void as return type, how silly. I have to write: "HELLO HERE IS NOTHING" instead of writing nothing.
... if (a.i == 1) is true!
... 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.
... and now we need two of them, so lets give them a name:
... } ... }
.) instead of what you expect ... /. eats the less and greater signs.
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
{
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 (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
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
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
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
Software sucks. Open Source sucks less.
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 , 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
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.)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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
In the world I live, procedural is dead
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
(* 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?
Table-ized A.I.
(* 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.
Table-ized A.I.
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.
Table-ized A.I.
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.)
Table-ized A.I.
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.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
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
Table-ized A.I.
(* 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.
Table-ized A.I.
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
BTW: can someone please explain me how to put one on the ignore list?
tabelzier, stick to your tables
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
(* 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.
Table-ized A.I.
Your complaints against me here are as vague as most OOP evidence.
Table-ized A.I.
The fallcy here is that you don't seem to have problems that are large enough to be modeled. When you have problems that are medium to large you need to model them. If you don't you'll have a hell of a job to get people working at the same time.
Modelling a problem is often easier in OO than procedural. The actual flow of information crosscuts the object design, which has spawned ideas such as aspect oriented programming.
So yes, things happen procedurally. ("You open the door to the car.") But the design "You" and "car" are object oriented.
Some of the major alternative paradigms are well out of the lab stage. Popular functional programming languages have been used for real world projects for years, and some of those languages have well researched and documented advantages over current mainstream approaches (much faster development, formal proofs of correctness, much more concise code to solve the same problems, etc). Why doesn't the programming world move to them en masse? The same reason so many ex-procedural types don't "get" OO: momentum. It's really as simple as that.
BTW, what do you mean by "OOP cannot handle relativism very well"?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
It's harder for a poorly trained lecturer who doesn't really know his own subject to make a fool of himself within five minutes in Java than it is with C or C++.
I'm sorry, but in my experience, a lot of the time it really is that simple. Java has no inherent CS-based merit over many other languages that have gone before or since, but a lot of people teaching CS don't really know their subject, and it's easier to cover that up without the risk of some smart alec noting that you dereferenced a null pointer in your lecture on linked lists.
I hasten to add that I don't think all CS lecturers are like this -- just the vast majority, based on my own experiences and what I've read of others'.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
(* This is one of the problem domains that OOP is trying to solve - reuse. A programmer doesn't need implementation details, and doesn't need to implement functionality him/herself. With a well designed object, the programmer just needs to know how to use it *)
Even many "high-level" OO fans believe that "OOP is not about reuse". Here are some excerpts:
http://www.geocities.com/tablizer/reustalk.htm
If you disagree with these OO fans, go argue with them, not me. "Reuse" has been falling out of favor as an important "attribute" of OOP over time.
Show me an actual biz app example of OOP being better reuse, not just talk talk talk.
Table-ized A.I.
I wrote the following about GoF patterns in some Slashdot thread a few months ago, but it is more relevant to this thread so I'm going to be a lameass and cut/paste it. (In fact, your handle rings a bell. Maybe you were even in that thread and have read this before. I can't remember.)
Of course those GoF patterns can make life hell for the maintenance developer or app framework user, when people turn it into a contest to see how many design patterns they can fit into a single project. The overall "Design Patterns" philosophy is really "how can I defer as many decisions as possible from compile time to run time?" This makes the code very flexible, but the flexibility is wasted when a consultant writes code using lots of patterns to puff up his ego and then leaves without leaving adequate comments or documentation. Without insight into how the system works, the configurability and flexibility that these patterns offer is lost. The system hardens into an opaque black box.
Deferring decisions to runtime makes code hard to read. Inheritance trees can get fairly deep, work is delegated off in clever but unintuitive ways to weird generic objects, and finding the code you're looking for is impossible, because when you're looking for the place where stuff actually happens, you eventually come across a polymorphic wonder like
object.work();
and the trail ends there. Simply reading the code doesn't tell you what it does; the subtype of object isn't determined until runtime. You basically need a debugger.
You can take a really simple program and screw it up with aggressive elegance like this. Here is Hello World in Java:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, world!");
}
}
But this isn't elegant enough. What if we want to print some other string? Or what if we want to do something else with the string, like draw "Hello World" on a canvas in Times Roman? We'd have to recompile. By fanatically applying patterns, we can defer to runtime all the decisions that we don't want to make at compile time, and impress later consultants with all the patterns we managed to cram into our code:
public interface MessageStrategy {
public void sendMessage();
}
public abstract class AbstractStrategyFactory {
public abstract MessageStrategy createStrategy(MessageBody mb);
}
public class MessageBody {
Object payload;
public Object getPayload() {
return payload;
}
public void configure(Object obj) {
payload = obj;
}
public void send(MessageStrategy ms) {
ms.sendMessage();
}
}
public class DefaultFactory extends AbstractStrategyFactory {
private DefaultFactory() {;}
static DefaultFactory instance;
public static AbstractStrategyFactory getInstance() {
if (instance==null) instance = new DefaultFactory();
return instance;
}
public MessageStrategy createStrategy(final MessageBody mb) {
return new MessageStrategy() {
MessageBody body = mb;
public void sendMessage() {
Object obj = body.getPayload();
System.out.println((String)obj);
}
};
}
}
public class HelloWorld {
public static void main(String[] args) {
MessageBody mb = new MessageBody();
mb.configure("Hello World!");
AbstractStrategyFactory asf = DefaultFactory.getInstance();
MessageStrategy strategy = asf.createStrategy(mb);
mb.send(strategy);
}
}
Look at the clean separation of data and logic. By overapplying patterns, I can build my reputation as a fiendishly clever coder, and force clients to hire me back since nobody else knows what all this elegant crap does. Of course, if the specifications were to change, the HelloWorld class itself would require recompilation. But not if we are even more clever and use XML to get our data and to encode the actual implementation of what is to be done with it. XML may not always be a good idea for every project, but everyone agrees that it's definitely cool and and should be used wherever possible to create elegant configuration nightmares.
This is my rant on the subject. You don't have to agree, but it comes from a guy writing software since he was 10 years old, who is now very old and crusty by comparison. This is what experience has taught me, perhaps your mileage will vary.
:-)
:-)
:-)
OOD, without risking and sounding like those "experts" is no silver bullet for software design. But it is a sound evolutionary advance in Software Engineering techniques. Yes, I do agree, that the OLDER generation, is more inclined towards Structured Design before implementing OOD/OOP techniques. However, I disagree that it is because that is the only thing we have been taught or have been teaching. Thats complete bonk.
Everyone in this field advances with the times. I would suggest, if it seems that way, the older generation, simply realizes what OOD/OOP is and what it ISN'T, and use OOD/OOP where appropriate in building software.
First of all, OOD/OOP builds heavily on Structured Design techniques. (i.e. Building software using ADT definitions and the 4 foundation sequences of computer science: statement, do-while, while-do, if then else, case or selector statement.) That is, a properly built OOD will embody in every one of its object interfaces, methods which are built using sound Structured Design methods. So it is a Myth that OOD/OOP gets rid of Structured Design techniques. In FACT, those who write POOR OOD/OOP's are those that have not mastered the 4 constructs of computer science and the ADT that goes along with Structured Design.
OOD does not a attempt to do away with Structured Design, it complements it by organizing Data AND Code in such a way that further increases the resulting code abstract properties. (i.e. it allows the resulting algorithms to be expressed in a way that makes said code even more reusable through inheritance for example. OOD is therefore impossible to implement without Structured Design.)
The resulting code is far more abstract, and therefore generalized to be more reusable, and therefore, theoretically, more reliable. (i.e. Code that is used over and over again becomes more reliable over time, and is an extensible property of the life cycle of software. Although structured design allows you to reuse code through simple function calls, OOD/OOP takes it one step further and allows function calls and data representation to be generalized as a functional unit.)
It has been pointed out, with good reason, that Java is a language which can help enforce good OO programming. However, it is not required and for example through the use of static methods, one can build Java code without using OOD/OOP techniques of any kind if one decides to do so.
This is important: OOD because of its abstract properties, (primarily the use of inheritance) can be used to create software patterns that lend themselves to creating certain types of software.
Certain types of software that benefit greatly from OOD/OOP implementations are for example, User Interfaces. Why? It is obvious. User interfaces are built using repeatable patterns themsleves application after application. (File, Edit, View, Window, etc.), at thier most basic level.
When an implementation in and of itself such as the building of a GUI, for example, has a clear pattern itself, OOD/OOP methods can get a great deal more mileage out of simplyfying and building code. This creates a better implementation of a GUI than just a Structured Design approach alone can provide.
With that said. You are probably thinking, what sorts of things is OOD/OOP NOT good at, and in fact SHOULD NOT be used. This is the part that gets controversial and you will decide, without knowing it, which camp you fall into by reading the next paragraph.
Well, abstraction, which through inheritance in OOD, while it provides excellent reusability in the context of building software, does not always result in the most effective implementation. By an effective implementation, I mean most efficient.
So what am I saying? Well, I am saying that you sacrifice some efficiency to gain the increased code reliiability that inheritance provides in OOD by compartmentalizing code AND data within an object vs Structured Design, which cannot do this through the use of simply an ADT and function/procedure calls.
(i.e. You can never directly modify data in context of a classic OOD/OOP, you have to overlap or build a middle man, as it where, to modify any data you declare private through the use of accessor methods.)
Althouh this enforces and corrects some deficiencies in Structured Design, it makes the program arguably slower to execute.
In the context of building, say an Operating System, for example, OOD/OOP is not the way to go if you want a highly speedy and effective OS implementation.
If you want such speed you invariable have to give up inheritance, and the benefits it provides, and resort to Structure Design principles only, to build your OS. (i.e. ALL function calls and procedures DIRECTLY access the data structures of the OS through passing parameters to functions or procedures, there by eliminating the middle man as above.)
Which, is not so bad, really. OS's and components of OS's such as kernels, etc...are designed to be speedy, as they should be.
So, my view on the topic is that OOD/OOP is best suited on top of the OS, vs IN the OS design.
Not everyone agrees with that, and that is fine.
Why? Well, because many argue that the sacrifice in speed is justified in the complexity of building a OS kernel, and that the reliability gained through the extensive use of OOD/OOP techniques in building the OS kernel for example, yields a better OS.
Which is not something to be taken likely if your OS is charged with the responsibility to keep systems software on the space shuttle for example working with the fewest number of defects, and human lives riding on what the OS may or may not do next.
On the other side, like I said, you have me and others who believe that OS should be very small and very fast, and that OOD/OOP shouldn't be used and that the realibility sacrificed is acceptable.
So, that is just one aspect of when and where and why OOD/OOP should and should not be used. But as you can see, it is far from cut and dried, and primarily is once based on IMPLEMENTATION and engineering REQUIREMENTS, not on methodology.
Which is how the real world works.
For the most part, which drives 90% of the disagreements is the fact that many people see OOD/OOP being a generalized approach to solving ALL problems, and not a specialized addition to Structured Design techniques, suitable for SOME problems, not ALL problems.
I personally, obviously, feel that OOD/OOP is NOT a generalized programming methodology for ALL cases.
However, some of my friends feel very differently, and we have a good discussion on the topic wherever we go when we start discussing OOD/OOP.
Things can get pretty heated, and most patrons at the local 3am diner wonder what all the screaming is about, particularly the buzz words.
Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
When a problem gets bigger, OO will be more helpful. If we're talking about how people tend to think, I can right now admit that I hate recursion becuase I simply do not think like that. I *can't* think like that. I avoid recursive solutions whenever I can. Yes I know, it's offtopic :)
Will work for bandwidth
Last time I checked no-one writes completly bug free code, we had problems with bugs in the tests.
Same thing at Rose-Hulman, for Dr. Anderson's classes (UNIX system programming, and programming language concepts). The students discussed the assigned problems in the course's newsgroup, and often, students would find bugs in the public test suites. That's how it is in any decent-size software engineering endeavour: a cat and mouse game between coders and testers.
Will I retire or break 10K?
As I've pointed out before, it's in the collective experience of legions of software developers..... It's hard to believe that they're all wrong on everything after all this time.
1. Collective experience use to be that the world is flat.
2. It could be subjective (the "mindfit" argument). That is fine, but 99% of the stuff on the shelfs implies that OOP is objectively better. I don't see disclaimers that the benefit list may be subjective.
3. The "popularity metric" is that Windows is "better". Do you really want to back that?
4. I have never seen a good survey that said most developers prefer OOP.
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.
Narrow, but large, I might point out. Not a single OO book ever limited it's braggings to specific domains, instead strongly implying a "step up in evolution" over procedural.
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.
Unless you can define/measure "natural", that appears to be a rather subjective thing.
Plus, some OO fans here have said that OOP is *not* "natural" nor should that necessarily be the goal of it.
I believe in the scientific process where you have to openly justify things based on open evidence, and not personal opinion and "feelings". Your "evidence" fails miserably here.
BTW, who gave that ahole a "4"? It contains almost nothing but personal digs. Damned moderators!
Table-ized A.I.
(* When a problem gets bigger, OO will be more helpful. *)
OO fans seem to have divergent opinions on this. It seems split about 50/50 when I ask comp.object. IOW, half say it only really shines on large projects, and the other half say it shines on medium stuff also.
But, I find that procedural/relational scales better because each task is relatively independent from each other. You don't really have to care about the other 2000 tasks. You simply try to use the relational tables to communicate among tasks instead of huge parameter lists (a common design mistake in bad p/r).
True, the schema (ER) becomes more complicated as the project scales up, but a relational schema is 100 times simpler to grok and manage to me than a tangled, interweaved mess of 2000 OOP classes. There is too much "protocol coupling" in many OOP designs such that to grok A you have to grok B, and to grok class/protocol B you have to grok C, etc. Making communication "data centric", you can stop these "grok chains".
Table-ized A.I.
(* Ultimate Solutions of faddism. There are occasions where 'goto' is useful - even if disguised as 'break' *)
The C "break" statement is unnecessary if you have languages that use "sets" for their case lists instead. Look at VB's case statement, for example. (I am not promoting VB here, but it's case statement is far better than C's.)
(* or even 'throw', which is the worst example of unstructured programming I can think of. *)
I don't like try/catches either. They make the exception to the rule take a bigger influence over the code than the regular logic, bloating up the code and the nesting.
But, this is another one of those "language fights" that never ends once it breaks out.
Table-ized A.I.
(* It's generally good for making reusable designs though. *)
I don't think I have ever heard that claim before. It is a little vague though. What constitutes the "design" exactly? I have reused procedural and relational "designs" also (with modifications).
(* Now you're really starting to sound like an old gheezer refusing to learn new ideas. *)
Perhaps I have seen too many "magic bullets" that turned out to be made out of melting ice.
I think it is a better use of resources if *volunteers* test "new ideas" FIRST. When and if it turns out to be better, then I will be more open to it.
In short, there are too many things for one person to test all by themselves. Let willing volunteers test it. When good evidence shows that it is better, then I'll switch.
If that is not Volcun-wise reasonable use of resources, then shoot me.
The medical institutions don't test every new cancer drug on EVERY cancer patient. They ask for volunteers, or at least a smaller group first. If it shows success, they then test it on increasingly larger populations. If it fails, then it fades in oblivion without dragging all patients with it.
Why should software fads be treated any differently?
Because dead software is less risky than dead humans? Well, maybe. But dead software is still dead software.
Table-ized A.I.
Sure, there's a lot of crap C++ and Java code that's written by people who don't know what they're doing. That's true for any language. And a powerful language is easier to screw up in, just as it's easier to kill yourself in a Massarati than in a Model T. But that's a problem with the programmer/driver, not the language/car.
(* I agree. scrytch needs to provide more info. Bad graphics alone does not a troll make. *)
Lack of specifics is a huuuuuge problem for OOP proponents. They keep quoting OO scripture/cliches, but rarely say *exactly* how such produces benefits using code or tracing the thought process throught the assumed mental steps.
After years of prodding, the only inkling is that perhaps OOP fans perceive the patterns of change differently than me. IOW, they assume change patterns that favor OOP, yet those change patterns seem unnatural based on my experience and observation. Their perception of change appears affected by their very OOP training (such as "adding new subtypes"). IOW, their perception of the solution is affecting their perception of the problem it appears.
I am trying to push the industry to document and analyze change patterns. We need to understand *how* things change *before* we start offering sound solutions to being change-friendly.
The problem is that it is hard to describe the change patterns without using a specific paradigm or language I have found. If somebody can find a more neutral way to describe it, then it would be less biased and reduce flame-wars when discussing patterns of change in general.
There too many researchers studying (alleged) solutions and too few studying the problems themselves (without the bias of specific solutions).
Gee, I rambled on again, didn't I? It is a fascinating, but frustrating topic though. At least to me.
Table-ized A.I.
If your goal is to have useful acronyms on your resume, don't drop out after your introductory courses. Take some advanced courses that involve the specific languages you want.
(* The worst thing you can become is a zealot. OOP at least is a broad and friendly enough paradigm to allow for flexibility in design. *)
Friendly my ess. Goto's allowed "flexibility" BTW.
(* Just consider how many design patterns are out there. The only real procedural pattern that paid a worthwile salary was Cobol's "spaghetti" pattern. *)
So if cutting off your wanker is the paradigm that earns the most money, that is where one should go?
I would rather program in something that is clean, simple, flexible, and change-friendly and earn less money than go OOP or some other lemming paradigm.
Table-ized A.I.