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" 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.
Is it just me or is that the biggest troll ever on the O'Reilly site?
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!"
-Tom
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.
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
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.
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.
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.
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.
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.
I miss Pascal. Siiiiiigh.........
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
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.
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.
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.
(* 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.
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.
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.
Writing is the only socially acceptable form of schizophrenia. (E. L. Doctorow)
iceburg, goldburg, whatever...
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.
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.
(* 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.
I am transferring to UCSD as a CE major this fall. UCSD intro programming course is java, however at my community college java was the last in a long line of pre-reqs(not really pre-reqs because they were more usefull) first we started with a CS survey class, things like turring machines, pusedo code, a fictional machine language that we had to write on paper ugh, then a C class that focused mainly on syntax and the such and just learning how to solve problems and use the tools provided (MS visual studio) from there we got an intro to data structures class learning about sorting methods, stacks, list, dynamicly linked list, binary trees, has algorithims. then assembly(could have taken that before data structures, probably should have but hey) didnt do anything to spetacular hear but got use to machine code. A C++ class was next. here we got introduced to object oriented design the course seemed to focus on how things are done in C++ we reviwed basic syntax then got introduced to classes, and all the fun that comes with them like inheritance, polymorphism, we did function overloading and stuff. the thing i think we missed the most in this class(it was an online summer session) was the standard libaries in C++ didnt touch them too much but now if i got a reference book i could pick it up pretty quick i am sure (nevver bought the book for the class, but we had some really good online notes that i failed to save after the class damn it). Finally we got to java where we were expected to know OOP already and we learned about the tools of java how to build windows and place buttons and text boxes and stuff, threads, streams and all that fun stuff. For our final project we had to write a client app and a server app that was basicly a really limited Instant messging program. The thing i liked the most about java was how easy it was to build applications in a windowing enviroment. never learned how to do that with C/C++ but from the templates MS visual studio spits out it looks a bit more complicated than java. Of course there is always gtk and good stuff like that. when i transfer i think i got an advanced data structures class to look foward to as well as OS design and compiler design classes. those will be fun. along with all the ee courses I am pretty happy with my progession overall but i got a hell of a lot more to learn
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.
>To learn C you need to know assembler
ummm... I've used C for years and although I've worked with PDP-11 and 80x86 assembly languages I'm 100% sure that I could have learned to function in the C language without a background in assembly language
Also
>To learn C you need to know assembler(it was invented to be a portable assembler).
Wrong again. C was designed to be used to develop the unix operating system. C is most definantly not a "portable assembler" pointers and bit-level operators were added to the language to make it useful for developing system level software
>Unfortunatly you can not teach a starter in CS assembler
I cannot begin to point out everything that is wrong with that statement, but I'll try anyway.
1) The study of computer science involves alot more than "learning to program in _____ ".
2) An assembler converts a program written in an assembly language to a computers machine language. (an assembler is a program NOT a language) remember that a computers "assembly language" is simply an abstraction from a computers machine language. There are many different machine languages and thus many different assembly langauges
3) A student should study many things before they are taught a language, including boolean algebra, logic circuits, circuit reduction, algorithm design & analysis & theory, binary arithmatic, base conversion, etc.
4) What exactly do you know about CS and teaching CS?
I'm too angry to continue this post...
recompile.org
>> You should be able to teach CS101 in any language.
A computer science 1 course shouldn't involve a programming language at all. That should be reserved for course in programming. CS101 should include algorithm development and testing, boolean logic, logic circut design and reduction, base conversion, binary arithmatic, etc.
I can not say this enough: COMPUTER SCIENCE IS MORE THAN JUST PROGRAMMING!
recompile.org
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.
Wow. That was the kind of statement you expect from somebody who knows only one computer language well. If the writer had even picked up Java for Dummies he would have learned that Java is not 100% objects and does have native data-types like int, long, char boolean which are totally separate from the similar objects Integer, Character, Boolean.
Java biggots are equally bad when bashing C++, and everybody here likes to dump on VB.
Introductory programming books usually start by explaining the benefits of the language, and all too often these books use comparative terms like " Java is better than C++ because Java doesn't use those complicated, ugly, pointer thinggys that are too complicated for anybody to user correctly anyway". So the new Java student goes off into the world telling all his friends that Java is better because it doesn't have pointers. Of course he would be wrong on many counts with that statement. If he really understood pointers he would know they are essential to efficient programming and even Java uses them in an indirect way.
I would like to suggest that people on Slashdot should only be allowed to criticize a language if they understand it themselves.
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.
Love the "beat up spock" visual analogy for "abuse of logic" too.
You must not be a Trek fan. Tablizer's page is in reference to "mind melds" (as in melding data and behavior) and not so much about Volcan logic.
(* 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.
My congratulations on a masterful troll.
At least he documented his opinion and reasoning in pretty good detail. Now where is yours?
(* 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.
Are you sure you are not the architect of the RTTI/attribute system of the .NET class framework in Visual Studio?
Why do we subject ourselves to OO? I think what we are really after is indirection (pointers) in function calls. Objects are an attempt at a structured way of doing function pointers, which are potentially a scarier thing than the GOTO.
The classic deal is a numerical algorithm to optimize a function. How do we make it generic to allow optimizing different functions with the same algorithm? We could use a C++ template type of generic, and compile time generics is one path to take. Or we could have a polymorphic object with a virtual method EvalFunction(), and we could pass an object reference to the numerical algorithm to pass it different functions.
The GUI world needs to do gobs of function indirections in order to tie together mouse and widget. But even traditional inheritance OO proved cumbersome and hence the Java anonymous inner class, the even more atomistic C# delegate, or the Qt signal and slot.
Also the GUI world is hierarchical -- a form contains a widget group which contains a button widget -- which lends itself to the Composite pattern and a tree-graph of objects.
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. Just consider how many design patterns are out there. The only real procedural pattern that paid a worthwile salary was Cobol's "spaghetti" pattern.
"It's not just what you say, no it's mostly how you feel it." - Tim Buckley.
(* 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.