Slashdot Mirror
Only 32% of Java developers really know Java
prostoalex writes "Research firm Gartner draws attention to the fact that less than a third of people who put Java on their resume actually know their stuff. The knowledge gap between someone who can successfully write a System.out.println() and someone capable of designing and implementing a complex Java system brings to companies being back-logged with pending projects."
It really is sad.. I've been dealing with Java for years, and I know that I couldn't bring myself to bother messing with a 'complex' project... Of course, I'm not going to be putting 'Java' on my resume anytime soon, either...
Knowing Java is very different from knowing programming. If you can't do a complex project in Java you can't do a complex project in any language. If you can do it in any language, you can do it in Java. The first step might be learning Java, but any good programmer can handle that in a short time. Now granted I'd want someone who knows all the tricks on the team so I don't re-implement the wheel, but a complex project by definition requires many people so that isn't an issue.
HR is far too hung up on what you have already done, not realizing that the data structures and algorithms are what counts, and they are the same in any language.
Just for clarification... your second paragraph is slightly confusing. I know you're talking about programming *styles*, not the languages themselves; but, anyway, my clarification: ...
C is not a functional programming langage. It is a sequential programming language. Scheme, LISP, Haskell, etc. can be functional programming languages, although their implementors love to sneak in sequential stuff too.
Functional programming languages only have functions. No loop structures. Your programs are just deep calls to functions (very often recursive). Examples I know are Scheme and Haskell. I assume LISP is too.
Sequential programming languages can have functions, but they also have loops and are told to execute functions one by one in sequence. Examples of sequential languages are C, C++, BASIC, Java, VB, Perl, PHP,
You can store a primitive in a collections object in Java 1.5; haven't you read JSR 201? (Well, okay, it actually automatically boxes them for you, and you have to declare it as "Collection" instead of "Collection", but the compiler error message is reasonably informative, and it's trivially caught at compile time.
I'm personally more worried about people who claim to know Java, but think that it is a good idea to keep pools of objects and reuse them. Aside from all of the programming hassles this creates for anyone trying to use the stuff, it messes up the garbage collector, which can't optimize dealing with objects that live forever and reference a ton of unrelated short-lived stuff over time. The problem is not the people who can't actually write any Java; the problem is the people who can write Java, but just make things slower and harder to maintain.
You're correct, of course. The principles should be simple. They should be fairly compact, and like all principles, they should come from the well of experience. The principles for good OO design are fairly simple:
Don't Repeat Yourself: knowledge should be represented only once in the system.
Tell, don't ask.
Classify objects in your systems by the messages they respond to, and the responsibilities they hold.
An object should only call features of: a: an object passed into it as an argument, b: an object it creates, or c: itself (I think this is the correct form of the "Law of Demeter")
Prefer short methods.
Apply design patterns according to the problems they are intended to solve.
When using design patterns, find the pattern that sets the context, this will help you identify other companion patterns that typically apply to the problem (or related problems).
Design your code to be tested, or better, write test code to help flush out the design.
Keep a nostril open for code smells, use refactorings and tests to fix the problem.
...
Always remember these are principles and not rules.
Now explaining those principles with code and narrative will fill up 700 pages if you give the whole history of how they came to be. Or you can just visit the pragmatic programmers' web site and read a bit less than 700 pages.
I also agree that the typical notion of encapsulation doesn't necessarily protect the data. When most people think of encapsulating they think of putting a barrier of functions between a data consumer and the provider (I was revolted when I first saw this in Java, I think C# and Delphi do this better with the first class notion of property). But the other meaning for encapsulation is "to embody" the data. I think that ends up being a more powerful concept when properly applied than publishing getters and setters for attirbutes that might as well be public. The idea that some other object must consume (get) the data is the first warning sign that the design is deviating from the OO way of thinking (OK, OK, paradigm, there I typed it again). When an object embodies the data, encapsulation can, in fact, protect it. But I was actually thinking that polymorphism provides a better way to ensure consistent handling of data in an OO system.
Ironically, MDA is closer to your concept of TOP than OOP is, as MDA is metadata-intensive and oriented to the creation of purpose-built syntaxes (modeling languages), although it is not specific to relational database access.
You might find this flabergasting, but I'm tempted to believe that relational databases aren't all that necessary any more. Most modern relational database hold nearly all of their data in memory. That's the only way they can achieve the performance they do. Take Oracle databases for example. In my shop the Oracle instances we run typically hold 98% of their data in memory (we have big Solaris boxen). So why not use some sort of memory snapshot system like Prevayler? The answer, of course, is that too many developers find this scary. The other argument against this is 'reporting tools.'
No, I'm not suggesting we all throw out our relational databases. But I do think there is life beyond relational data.
Also, I didn't build an example of a bad procedural system for this post. I apologize. As you know, that takes a lot of effort. Instead, as a consolation, have a look here: http://www.nakedobjects.org/section6.html Their discussion is actually about the pitfalls of task-oriented UI design, but their arguments apply to this discussion. Task-oriented UI design typically goes hand-in-hand with transaction script architecture and falls prey to the same issues (I'll even add an 'IMHO' to that). I think you'll like their spaghetti diagram a bit of the way down the page.
Thanks for the response, and the discussion.
Michael Murphree
This article is an advertorial, I am in the development industry in south africa and itweb.co.za is often used to dispense stuff like this. In fact some software products I have written myself were paid for and featured on itweb.