aspose file tools*
The moose likes Java in General and the fly likes What makes Java difficult Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "What makes Java difficult" Watch "What makes Java difficult" New topic
Author

What makes Java difficult

Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
Hi all,
With procedural type languages all you have to learn is the syntax of a language its basic types and hey you call yourself a programmer.
The advanced "stuff" involves learning/knowing how to improve you code ie. making it more effcient. Thats about it. Hey dont attack me on this "very simplistic" view on advanced programming ala procedural languages, I dont have a week to type a full essay.

With Java however. To write good "advanced" code you REALLY have to know the "environment" you are programming in.
You need to know :-
OO - and REALLY understand it.
Java JDK - its API classes, when to use what.
Java Doc
The Java Language Syntax
And if you want to program using/for the "web"
- HTML
- EJB
- JSP
- XML
Am I forgetting something ???
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I don't really think the issue is so much about the difference between procedural and OO languages as much as the complexity of the standard APIs. Java can be very daunting to learn because it appears as if you have to learn and memorize everything about a huge amount of standard APIs (and probably lots of extensions) before you start.
In practice the Java language itself is not much more complex than a typical procedural language. It does have objects but it doesn't have a separate linker; it has packages but you don't need to manage your own memory; and so on and so on.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
But dont you think that using OO correctly also adds a massive burden on the learning proccess ?.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
No more than using a procedural language correctly. In many ways, makeing robust, maintainable, reusable code is harder in a procedural language. In Java and Smalltalk, for example, you don't really have to learn not to use global variables; you don't need to worry about accidentally naming two functions the same in different files; and so on.
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
Maybe its my lack of experience with OO that makes it seem harder, or I've always been a bad procedural programmer anyway.
But when would you say can one define youself as an "advanced" Java programmer. Would completing the assignments at the Cattle Drive give one a "hint" of hey I'm getting there?, or getting your SCJP.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I'd say that completing the cattle drive is a much better indicator than getting SCJP. The cattle drive is more like SCJD as it has a significant practical, hands-on, component. SCJP is a good start, but is all theory and memory of APIs and language features.
To get a fast-track to good OO skills, take the cattle drive, read up on patterns, study "Refactoring" by Martin Fowler and "The Pragmatic Programmer" by Hunt and Thomas, all the while reading and writing lots of code and being harsh with yourself whenever you fell tempted to write anything which is less than perfect.
For more information about books, don't forget to visit The Bunkhouse with its steadily growing selection of incisive reviews.
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
I assume by patterns, you mean understanding the actual code (solutions) that implements the patterns instead of simply "cutting & pasting" them into your own code.
As for your comment regarding "perfect". Perfection is so damm different depending on the person and/or situation. My perfection might be a far cry from yours, because of my lack of experience with Java for instance (the list is much longer of course). But as a rule its a good "thing" to aim for.
Regarding the Cattle Drive, would you agree with the following statement :
To the question "do you know Java" , I can categoricaly say "yes" if I have completed all assignments to the satisfaction of the "nitpicker".

[This message has been edited by Johannes de Jong (edited March 21, 2001).]
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
One good thing about patterns is that they are actually very hard to "cut and paste". By the time you have implemented one in your code, you have to have understood it at least a little, even if you have used it inappropriately. And the next time, you will learn more, even if it is only about how to reuse your code.
I agree that perfection is a moving target, but aiming for it is the best way to keep it moving. Each time you knowingly do something which you yourself value as less than perfect, then you are not learning as much as you can from that situation. This is why I recommended the two books above. Both are books about improving both your code and the way you produce it, and should help you to think and learn in any programming situation.
As for your assertion about the Cattle Drive. Yes I would agree. But, like perfection, completing the Cattle Drive is also a moving target, as new sections and exercises are added from time to time.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4991
    
    8

If you are coming from a procedural programming background, I would say that that your biggest obstacle would be the proverbial "paradigm shift." I made the jump to OO a couple of years ago and I still find myself falling back on my old "procedural" habits. Reading books like the ones that Frank suggested help a lot. Other books I have found helpful/useful are "The Object Primer" by Scott Ambler and "Designing Object-Oriented Software" by Wirfs-Brock, Wilkerson, and Wiener. Scott Ambler also has a regular column "Thinking Objectively" in Software Development magazine. Try reading up on the use of CRC Cards, too. The book "AntiPatterns" catalogues several anti-patterns that are caused by unfamiliarity or inexperience with OO development.
J.Lacar

Junilu - [How to Ask Questions] [How to Answer Questions]
Max Rahder
Ranch Hand

Joined: Nov 06, 2000
Posts: 177
Johannes de Jong: Your list of hurdles looks good. To it I would add:
o Learning the development environment,
in other words, the developer has to
learn how to use JBuilder, or Visual Age
or whatever tool is being used by the
developer's team
o If you're doing EJB development you have
to learn the rules of how to code EJB
and the deployment procedures for your
EJB server
o If you're using a UML tool you'd also have
to be trained in its use
In summary, there are a heck of a lot of hurdles to doing project work in Java. (Although at least they have the common characteristic of using Java. For example, if it were a pure Windows solution you'd have just as much breadth of training without the benefit of a common underlying language.)
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
For a topic that I wasnt so sure about putting here, I'm getting some pretty good advice.
Thanks a lot I appreciate your input.
Bill Prentice
Greenhorn

Joined: Mar 06, 2001
Posts: 26
Mind if I put in my two pence worth.
I been using OO for a long time now, I still have copies of the first books from gentlemen such as Rumbaugh and Booch, published long before they teamed up to invent UML. The students favourite in the early days was OMT because the diagrams were easy to draw and understand (there were very few software tools available) and the rules were relatively simple.
Like most things in software development the essential simple idea has grown, evolved and become far more complex. There has been many esoteric debates as to the effectiveness of which object method to use and which language is more OO than another.
My advice is simple, keep it simple, utilise existing skills as handles to new learning, if the prospect of learning UML is daunting have a go with OMT or Fusion first, use your new skills as a transition into UML or whatever.
Mapraputa Is
Leverager of our synergies
Sheriff

Joined: Aug 26, 2000
Posts: 10065
In practice the Java language itself is not much more complex than a typical procedural language.

Frank, maybe after you passed first stages of learning it doesn�t look much more complex anymore, but at the beginning... I also have procedural background, and Java does look much more complex to me.
OO paradigm was invented to fight complexity; if you have a fairly simple task you probably do not need object-oriented approach so desperately. IMHO complexity cannot disappear; it can, however, migrate into
1) language itself
2) function libraries (API)
Both things happened to Java. Look at Java modifier table (only modifiers!): it is 12 x 18 table! A few concepts were added to OO languages. Well, you add n new features (class, objects, overriding...) and you get about n <sup>2</sup> extra complexity.
Next thing: many Java�s design features were not only non-intuitive for me, they were contr-intuitive. I remember this question from some mock during my SCJP preparation:
What is the output of

I did not know the answer, so I thought: well, folk who designed equals method most likely wanted to make it useful. Comparison variables of int and long types is a valid operation, so for equals method to be useful it should return true. Of course, I was wrong.
Another discovery: with procedural languages if you have a function � you have a function. You call it � you have result (at worst you have wrong result ). No such luck with methods: they can be left without implementation or they can be partly implemented. It took me a while to figure out that Object�s clone() method does only easiest part of job
All this is not to say that Java is a horribly designed language (of course, it was exactly my first impression ). Object oriented languages are better tool for designing and coding complex programs, but it comes with price � languages become more complex themselves.
Am I wrong?
[This message has been edited by Mapraputa Is (edited March 22, 2001).]


Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I think some of the confusion here comes because many people here have learned procedureal languages first.
I'm not denying that learning an OO language after learning a procedural language can be hard - there's so much to "unlearn". What I am suggesting is that learning an OO language (Smalltalk, Java etc.) if you have no prior programming experience is not significantly different to learning a procedural language (C, basic etc.), or a functional language (ML, XSLT etc.), or a list-processing language (lisp, scheme etc.), or a word-redefinition language (Forth, Postscript etc.) and so on.
In many ways an OO language suits a non-programmer world view better than a procedural language. The real world is full of objects which have state and behaviour, but you don't exactly bump into global functions every day.
Johannes de Jong
tumbleweed
Bartender

Joined: Jan 27, 2001
Posts: 5089
That always been the difficult part about learning something new, "unlearning the old".
My original posting was simply stating the fact that I get the feleing that to learn Java one has to learn much more than for instance Cobol.
As a matter of interest Mapraputa, how long did it take you felt "comfortable" with Java?
Geoff Tate
Ranch Hand

Joined: Feb 06, 2001
Posts: 55
I did RPG for years - you can't get more procedural than that!
Anyway I found the patterns books by Mark Grand very helpful in not only learning the patterns but also illustrating how OO concepts actually produce a superior product than procedural code. A big help in solidifying concepts was the Complete Java Cerfitication study guide from Sybex.


<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR> fantastic, a towel? <HR></BLOCKQUOTE>
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
I have to disagree with Frank. I think OO is significantly more difficult to learn than procedural because even though we live in a world of objects we don't think in those terms. I don't interact with my alarm clock by sending it a message to turn off. We think in terms of what we do. I wake up.. turn off the alarm clock.. get out of bed.. etc. OO adds abstractions. I don't actually send a message to my alarm clock after all... I send a message to an abstract clock that implements the alarm interface. Procedural languages are much easier but they tend to be much less reusable (although reuse is highly over-rated in OO) and less easily maintained (which is too often under-rated in OO).
OO is much more difficult but that is not a bad thing. We are professional programmers so we are supposed to be able to handle the difficult things.
And I disagree about the complexity of the API. Most programs use just a few small pieces of the API. I have never tried to memorize the API... that is what reference books are for.
You are right that Java is not much more complex than other languages. In fact it is fairly simple. But learning OO can be a daunting task. Give me two people: The first is an expert at OO design, UML, patterns, etc but has no knowledge of Java. The second knows Java inside and out and can quote from the JVM manual but knows nothing about good OO design. I'll train them for 6 months in the area where they lack. At the end of 6 months, who do you want working on your business critical application? I'll take the OO guy.


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Mapraputa Is
Leverager of our synergies
Sheriff

Joined: Aug 26, 2000
Posts: 10065
I'm not denying that learning an OO language after learning a procedural language can be hard - there's so much to "unlearn".


�New arrivals to this field take short-cuts only to get lost later�
A discussion on approaches to learning XSLT http://www.dpawson.co.uk/xsl/approaches.html

Never mind, just trying to make myself feel better...
As a matter of interest Mapraputa, how long did it take you felt "comfortable" with Java?

Immediately after I got my SCJP title I started to feel comfortable with it... Kidding!
It was about 5-6 months, I think. Enormous time for learning a programming language.
I also started to understand what OO programming is about after reading about paterns. Before it was on �a car is a vechicle� level, as somebody in �OO, Patterns, UML..� forum put it.

[This message has been edited by Mapraputa Is (edited March 23, 2001).]
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
The funny thing is that inheritance is one of the easier aspects to understand and yet the one that you should probably code with the least. "Design Patterns" second principle of OOD is "favor object composition over class inheritance". As it says, "Inheritance breaks encapsulation." Inheritance causes a tight coupling between the parent and child classes which violates OO. The goal should be to inherit interfaces and not implementations. There is of course a tradefoff since an application built around object composition will have more objects.
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
OOOOOO I LIKE that. (Cindy stealing post. . .) Can I quote you over in JigB??? Well I'm doing it anyway .
http://www.javaranch.com/ubb/Forum33/HTML/002016.html
Thanks
[This message has been edited by Cindy Glass (edited March 23, 2001).]


"JavaRanch, where the deer and the Certified play" - David O'Meara
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
You know what the problem with JavaRanch is? It is so big that it is not possible to locate all the interesting conversations! Glad you enjoyed my comments. That's why I keep a copy of "Design Patterns" on my desk at all times!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What makes Java difficult