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