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."
How shocking this news is to me, because it confirmed a survey report I just read yesterday: that 68,015% people lie in their resumes!
Actually, the report is wrong. They just don't read the resumes carefully. The other 68% actually know *Javanese* Java, not Sun Java.
"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."
We also would have accepted: Only 26% of submitters to Slashdot can create proper sentences.
Also "99% of researchers and statisticians have no idea what they are talking about and don't know what research means"
Joe Llywelyn Griffith Blakesley
[This post is in the public domain (copyright-free) unless otherwise stated]
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...
Java was the popular thing of it's time. If you didn't know it at the apogee of the internet bubble, you didn't get a job in the computer idustry; it's a lot easier to say that you know it, and hope that you never have to use it. I for one hope that I don't have to write Java code again...
.NET - buzzwords rule the market from the big business' point of view.
Now things are pointing similarly towards C# and
However, those who really know their stuff normally stick to the older languages... hype is good in some ways, but in the grand scheme of things, it's the older, better stuff that will prevail.
I see that I'm not the only one!
"Send an Instant Karma to me" - Yes
For the record I do NOT ask those boring certification style questions that you'd only know the answer to by memorizing the spec. All the questions we ask start with "here's a problem, now solve it with real Java code, please." If I've learned one thing, it's if somebody groans and complains that writing code is so trivial you shouldn't even ask it, then sit there and force them to write code because chances are they can't.
www.HearMySoulSpeak.com
My real world experience tells me it is much less than 32%. 15% at best (though another 15% THINK they know java - this is where the real danger lies).
If you require knowledge of complex topics like sensible J2EE architecture or multi-threading it falls into the single digits.
The second half of the article recommends Model Driven Architecture for the masses as the solution. This amounts to putting complex tools into the hands of idiots. Tools that go out of their way to keep people ignorant, while simultaneously giving them the power to commit their sins on a grand scale. Brilliant.
dhk
"Only 32% of Java developers really know Java."
An old Digital Equipment Company manual for technical writers said that only a small percentage of people really know English. And here is an example of not knowing English, in the Slashdot story:
"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."
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.
On the other hand, most of us mortals don't store all the details of API's in our heads. Back in the Stone Age we used manuals and in the Information Age we use the SUN Web site. If your interview objective is to see how someone would get the information to solve the problem, that is fine, but if your objective is to see if that person already has some narrow set of information, you are going to exclude some capable people.
I am mainly a Delphi developer (I should say a Delphi component developer), and my Java experience is only 4 months old, and gee, my Java experience is limited to using JNI to allow a Delphi ActiveX component to invoke an extension module written in Java and using a class loader so that extension module can be reloaded while the ActiveX component is still running.
I don't know the answer to your question about Java collection objects without looking it up, although I have enough sense to know that you have to use Object wrappers for value types in collections and then have to cast those objects back to their original types when you pull Object references out of collections -- I know that from "wasting" time reading Slashdot.
I guess I would fail your interview.
I've dealt with java on dozens of project. I've never claimed once to know it, nor will I ever.
I've never seen a situation where java was a good solution. I've seen plenty of places where java could be used.. but with the very very few people who are good with it (even fewer than those that "know" it) it's just inviting bugs and an ongoing project.
And just because they may know the syntax, that does not mean they can write code worth a crap. I took over a project where a guy wrote his own xml parser while there were tons of free ones on the market. That was a disgusting mess the ended up being easier to convert to real parser rather than fix some parsing problems. He also used count to 1 billion loops when spawning external processes because he didn't know about waitFor(). At first we could not figure out why his code was so slow. Add on top this was all done in static void main, which no other methods or calls.
He has moved on to writing web application in RPG for another department, where every new group of pages gets deployed on a new port...they seem lost on the whole url concept
Knowing Java is like knowing English (or any language.) Just because you know the language does not mean you are any good at writing poetry.
Soccer Goal Plans
where "MDA" is Compuware's acronym for "buy our software and generate all your code". And since "highly skilled developers recognise the value", anyone who doesn't "recognise the value" and buy their product is an unskilled dolt.
The Army reading list
This brings up the point:
What do you have to know to put a computer language on your resume? Let's say that I put "Java" on my list. Am I expected to, say, know all of the built-in functions for a vector, or string, during my interview? If I put Python down on my resume, am I expected to know the names of built-in function overloaders for classes or the functions and parameters for the re module?
Basically what I'm asking is, if I put a computer language down on my resume, should I be expected to code something at an interview immediately without looking at any references? This doesn't seem unreasonable, if the program were simple, but I could imagine employers asking for more complex things. How complex is too complex and how much specific information should a computer programmer retain about a certain language, say, after not using it for 3 years (he was doing VBScript just until he could pay off his debt, I swear)?
I think it's more important to know "how to program" rather than "how to program in X" because the skills you learn in one language are usually easily transferrable to another, as long as you have lots of experience in different kinds of languages: functional, procedural, OO, assembly language, etc.
As a side-note, it looks in the article like by saying that 68% of employees don't understand Java, he really means that 68% of employees have never heard of MDA and have no idea what the hell it is, or don't quickly "recognise the value of MDA," since, of course, all highly-skilled Java programmers do.
--Stephen
Did you ever notice that *nix doesn't even cover Linux?
Ok so most of this article looks like marketing for Compuware's OptimaJ product.
I recently had an interview at Compuware in Canada. I have only done one Java application so that's about 3 months of Java on my resume but I have 3 years of OO development experience in C++... and I was not hired.
Compuware are looking to hire only senior level programmers and when they say there's a lack of Java programmers, they actually mean "5 years of J2EE, knowledge of WebSphere, BEA and a load of other stuff".
Big development houses like them no longer invest in hireing people who know the technology but are not seniors. It's a catch 22 IMO. If no one wants to hire a J2EE developer that doesn't have at least 5 years of experience, then they shouldn't lament that "Java developers" become hader and harder to find as time advances.
This is exactly my experience. I've been developing in Java for about 8 years and I think I met just 10 other people who really know their Java. And of those 10 people just about 2 or 3 are able to design an enterprise class application.
:-(
It's not just Java developers, in the booming years a lot of people were hired by IT consulting firms here (NL) that shouldn't be near any computer at all. I've seen system engineers who studied politicology and got an MCSE who don't know the most basic thing about Windows and are not able to solve any problem at all. I've met tens of 'project managers' who don't know anything about IT and even less about software development and are too stubborn to listen to people who do know their shit.
The worst of all are VB 'programmers' who are just able to point and click a basic application, but don't have any feeling for what a programmer should be able to do.
The worst is title inflation. Every donkey is a 'software engineer' these days, and if you are able to actually design a piece of software you should call yourself 'architect', otherwise people won't take you seriously.
Because 'programmers' are seen as monkeys that type and are doing a trick that every other monkey can do.
I mean, let's be honest. If you write JSPs, you think of yourself as a java programmer; if you go to university and take a Java 101 course, you think of yourself as a java programmer.
The first time you end up in a real project, you're doomed. The idea that 68% of the people who identify themselves as java programmers either wrote a bunch of JSPs, or took a few java courses and did the coursework for it, isn't exactly shocking.
And given that it's Gartner we're talking about, a group of people who, throughout the dot com boom, exaggerated in the *extreme* the potential markets of a broad range of subjects, I wouldn't be surprised to find that the numbers are actually not as pessimistic as those made out; but that's just the nature of reports like this and those of other research groups - they're research. They represent reality in the same way as every other abstraction: they're a generalisation.
The truth is probably more complicated and interesting.
-- A mind is a terrible thing.
The studies I'm familiar with showed that it took 5 years to become competent in C++, and that was before they added STL. So I suspect the statistics for the number of alleged C++ programmers who actually know the language would be even worse.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I don't really know what it means to "know" java. The language's entire approach is to be an object zoo rather than using a few elegant commands to do most anything. Therefore, most of Java programming is looking things up in the docs. That my friend, is the most important skill.
There's a few main types of programming styles: Object Oriented (Java), Functionally Oriented (C), Procedurally Oriented (LISP), and hybrids (C++, Perl). Once you learn how to think in the way required by each of these styles, all that's left is memorizing syntax and commands. And that's what man pages are for.
-- Political fascism requires a Fuhrer.
It doesn't work well for an applet in a browser, and it doesn't work well for stand alone apps.
Yes, and those are not the areas where Java has been very successful. However there are others, like server programming where Java is clearly the best choce.
I think most Java programmers are like me, they played with it enough to find out it's not worth the trouble.
I hope so. That will make it easier for those of us who actually understand Java and where it is appropriate to charge high hourly consulting rates.
From my experiences with the resume and hiring process I would put the number at more like 2%.
And that applies not to just Java, but ANY programming language or computer skill. After all, how many people who put HTML on their resume can actually code clean standards compliant HTML 4.01? How many know when CSS layout is appropriate, and when it is not, and can successfully blend table and CSS layout in an optimal fashion?
Basically I set up a situation where I want to create a hashmap of numeric counters such that I am going to increment a million times, but only store 100k keys into the table, and ask people to write me the structure to do it.
I have [or have had] a fairly extensive knowledge of the J2EE Collections Framework, and I don't have a clue what that "sentence" is supposed to say. In fact, screw the "sentence"; let's concentrate on the clause create a hashmap of numeric counters such that I am going to increment a million times, but only store 100k keys into the table. What does this mean? "Numeric counters" of what? "Increment" what? "Keys" into whose "table" of what?
If I were the interviewee, and my prospective boss couldn't explain himself any better than that, then I'd give some serious thought to alternatives such as bagging groceries, hanging drywall, or pushing a mop.
PS: You can make upwards of $20/hr hanging drywall; of course, if you don't wear a mask, the dust might take its toll on your lungs, but hey, we're young and we're gonna live forever, right?
It is possible to program functionally in C, just avoid side-effects like you would in Lisp.
I logged on this morning and discovered that my brief reign as a moderator had come to a screeching halt, but if I still had the points I had yesterday, I'd be in a real dilemma as to whether I'd call you Informative, Insightful, Funny, or what.
They need to invent some uber-Adjective that means "All of the above."
But it is mind-boggling what people can get away with on their resumes. Knew a guy who claimed to have graduate degrees from schools whose names he couldn't spell. You'd think employers would spot that, but no -- he actually held a couple of director-level jobs at the height of the bubble.
I really should get a little more creative with my resume. People who see it always ask why I don't mention where I got my 4-year degree. Answer: I don't have one. Which is a pain -- some companies won't even talk to me because of it. I could fudge up a degree from Whatsamatter U (double major, computer engineering and journalism). I'm sure nobody'd check. But I'm too much of a coward to pull off that kind of fib!
Oops. Just had a thought. I know Java. My credentials are impeccable: I wrote the JDK release notes for almost a year, and I once played a video game with James Gosling! But I've never worked as a Java programmer, being absolutely the worst coder on the planet. But if the shortage of Java programmers is that bad, maybe that's not such a problem!
I list Java among my skills, even though I cannot write Java code worth a damn. And I'm not lying to the resume reader.
I know what Java is, I know how to use the Java commandline to turn on Debugging, manage memory usage, turn off GC, etc. I know more about idiosyncracies in Java VM versions on 6 different platforms then most programmers.
I never said I knew how to program Java.
buzzwords rule the market from the big business' point of view.
.NET implementations they don't control), it is an open standard, it has excellent facilities for interfacing efficiently with native code, and it addresses some serious limitations of the Java language. This is progress. However, even C# is still years behind the state of the art in programming language technologies.
Java did represent an important step for industry beyond C++: it was the first widely accepted language with runtime safety, garbage collection, and reflection. Those aren't just buzzwords, they make a real difference.
On the other hand, Java has failed to keep up: Sun's irrational insistence on insulating programmers from the underlying platform, their intellectual property claims and licensing strategy over Java, and their failure to evolve the language mean that Java has remained a poor choice for many applications.
C# improves over Java in several of these areas: it is "just" a language (Microsoft actually doesn't seem to want you to use third party
However, those who really know their stuff normally stick to the older languages... hype is good in some ways, but in the grand scheme of things, it's the older, better stuff that will prevail.
You mean, older languages like Lisp, Modula-3, CLU, Smalltalk-80, Algol-68, Prolog, and Scheme?
Or do you mean older languages like Visual Basic, C, and Fortran?
There are good, well-designed older languages, and there are poorly designed older languages. Many people seem to stick with poorly designed older languages out of habit and because they don't know any better.
If you are referring to C and C++, they are, in fact, relative newcomers as far as languages go, and they represent a significant step back over the languages that preceded them. And both C and C++ were enormously overhyped at their time.
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
This "languages don't matter" argument comes up again and again, and it is bogus. Yes, you do need to know programming in order to do well at programming, but that is not sufficient. You also need to know a language and its libraries inside and out in order to be able to design and implement large projects in it effectively.
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.
In most real-world applications, algorithms and data structures are irrelevant: all the algorithms and data structures needed are implemented either in the standard library or the underlying database. The time isn't far off in which knowledge of algorithms and data structures will be about as relevant to 99% of the programmers as knowledge of VLSI design. That may be sad, but it is the way things are going.
Java is a very strict OO language. You cannot get anything done in Java without a myrid of class extensions and "implementations." This has the great benefit of allowing lots of developers to work on very specific parts of a project and not run into eachother very often. This has the very negative effect of discouraging creativity in the individual programmers work since so much is set in stone.
...Yes, that was two rants in one. It's twofor day here on /.
Most Java programmers end up as class monkeys, taking very specific directions from a select few who determined the entire arcitecture of the system. This is not programming as an art. This is monkey work. Put them in a position where they need to use Java (or any language) to solve a real problem and they will fail.
Java has had the misfortune of a gigantic hype machine pushing it. Because it could not live up to the hype in some areas a lot of people have dismissed it. This is probably less Java's fault and more the fault of those who consider it "dead." For they should look at the language and realize where it's strengths are.
Java in the browser - DOA. It sucked. Still sucks. And nobody uses it anymore (or nobody SHOULD...)
Java as an App - So it turns out that the whole "corss-platform" thing was a joke. Multiple JVMs across multiple OSes made for far too many variables. Write-once, run-anywhere it most certainly is not. And these days you have multiple GUI implementations and their VM/OS-specific quirks.
Java on the Server - Ok, this has a future. Cross platform doesn't matter. Speed isn't an issue nearly as much. And there are a slew of components already available (J2EE) that do the hard part for you.
A better middle ground perhaps is like what the Mozilla folks have done - adopt C++ but make it understood that only a subset would be used.
As for the anything-goes C++ approach...I advocate this strongly, for my competitors.
... or an advertisement for OptimalJ?
This has resulted in a tremendous backlog of projects," says Aad Van Schetsen, Compuware sales director for application development and integration solutions in the Europe, Middle East, Africa region.
Ben van Niekerk, Compuware SA product manager, says locally the backlog is mainly in projects to integrate new applications into Java legacy code.
Van Schetsen says the key to the success of tools such as Compuware's OptimalJ is their use of a model-driven architecture
Tools like OptimalJ ensure best practices and standards as well as enable companies to leverage the core capabilities of their developers by allowing them to focus on applications and not the underlying technologies.
"Although we are still in the education phase, particularly with less experienced Java developers and development companies, momentum is gradually growing with OptimalJ sales increasing threefold in the past financial year."
But what about all the task where you can't use a database at all? Things such as Photoshop, 3d studio, webbrowsers, compilers and so on.
But the real problem with OO is that most people owerdo it, but I think it all come back to the fact that 2/3 don't really know how to code and design software, and no amount of language/tool support can solve that problem.
And just to be a bit offtopic:
Say I have a relational databaes, and an application used to access data in the database. The application is a "desktop" type application running at several people at the same time.
Now say A fetch data from the database and view it in a table. Now B update the database that A views. Thus A has stale(old) data. How does B tell A that A need to fetch the new data from the database. B can't signal A directly because A and B don't know each other.
The best solution would be if an application could register itself as a "listener" in the database to be notified when specified data changed, but I have newer seen a database that allow that. An other solution is not to allow the applications direct access to the database, but insted have all requests go to an task running at the databaseserver, but this seems as a bad solution too because you can't send sql to this application so you end up writing far more code then what should be needed)
Martin
In college when they were trying to teach me Java, I wiggled my way out by proving I knew both C++ and pascal really well. I'm also allergic to C++, and will use it happily only if the API is QT (not MFC).
I played with QBASIC for many years, made many little pascal apps, did quite a bit of Visual Basic, but was always a little allergic to C++. There were too many things I couldnt even conceptualize. C is so clean and easy, you can make tiny C programs, then read the assembly language and you understand everything. C++ seperates you from the hardware.
Now Java takes that to another limit. Everything is in nicely packed boxes, you program and end up with something thats relatively slow. I know portability is a bid deal, which is why I'm a big fan of making sure my code is ANSI C 89 or 99 with no warnings, and I test it with gcc, borland c, visualc, forte, and intel compilers. Heck gcc compatibility alone will guarantee portability to Java's extent.
Java does allow larger projects, but with too many developers who dont have a clear larger picture in their heads, the project will have the quality of Windows95 and changing the whole model becomes increasing difficult (think of how easily a new linux kernel version is released with everything rewritten, now think of the same in windows). I'm not bashing OO programming, I just think it has its place and that place is not EVERYWHERE.
Java has really become a way to put the half-a-techies colleges are spewing like theres no tommorw to work. You put 20 of them in cubicles and give them parts of the project and they'll deliver. But is it the same as a good C/C++ developer who will understand everything in the project?
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
78% of all statistics are made up. //smirk
JSP lacks the rich text processing it needs to actually be a safe/useful cgi langauge, it's still relativly immature and incomplete, I could go on all day.
I beg to differ. What text processing capabilities do you find missing? A lot of people uses JSP for all kind of web apps without any troubles.
And for inmaturity: Servlet/JSP have a third or four generation spec (2.4/2.0). One could guess the spec is very complete by now.
There are many open source and commercial implementations of Servlets/JSP servers, most notably Apache Tomcat at version 5.0.19 (after the last few years 4.x and 3.x).
If the standard isn't enough there are lots of tools, frameworks and libraries like Struts, Taglibs, Velocity (templating), etc. Most are de facto standards like Struts that implements a model-view-controller framework for JSP.
Don't forget the usefulnes of standards to stop reinventing the wheel every time, something that some C/C++ programmers seem to prefer. Standards help lower the cost of development.
If I would do my app in perl or python, how many options of compatible servers can I find? Just one each? IDEs? what about portable binary database drivers that don't force me to recompile my server or my app?
If I would code in C for speed, how would I get database independent, portable code? And the text processing capabilities of C are nearer assembler than any modern language. But who does web projects in C these days?
Java has a very nice fit in a big domain of problems, and does it fast enough.
"I think this line is mostly filler"
I've been wondering what you might think of n-tier EJB / EDOC style systems. Those styles of systems are actually procedural designs (sad but true). They are task and table oriented, they just happen to be implemented in an OO language.
Well-designed OO code does not degenerate into spaghetti, any more than well-designed procedural code does. So much depends on the quality of the people creating the code that we often forget that the tools they use are less relevant than the skills they leverage.
You've written a whole site on "Procedural-Relational Patterns" as a response to the GoF Design Patterns, so you must know that your statement here just sounds like you're ranting. I'll concede that I haven't always seen design, analysis, or architectural patterns applied consistently, but that again comes down to people.
My take on OO? Well it depends on what view of the system you take. You can take an OO conceptual design and implement it in a procedural architecture with an OO language (the typical approach for EJB). You can go completely OO from the UI (NakedObjects)to the underlying language (Java) to the database (I prefer O/R mapping to OO databases myself). This often works quite well in keeping the code small and understandable. I have a background in Pascal but Java is currently my language of choice as I find I'm more productive with it. And no, I don't particularly like EJB.
You mentioned Extreme Programming, a practice which orients the developer to producing small, loosely-coupled, tightly-cohesive modules. And if the code isn't that way the first time you create it, it adds a set of practices that aid the developer it putting it into that condition.
This has little to do with "incremental hacking" but rather factors human cognitive progression (we gradually understand a problem and its solution) into the software creation process. You can apply agile processes to procedural or functional programming just as easily, although you'd be hard-pressed to find an "agile" book with C, Pascal, or COBOL examples in them.
So how many times must you encode the rules for "contributing" to the river consistently? Relational data constraints often cannot handle complex decisions based on individual values in a record or a set of related records. Business consistency must then be enforced with code in every task accessing the data. You must repeat code, or at best, explicitly call it without fail, to ensure 'the river' does not become polluted. In cases like this, OO languages provide more powerful tools to represent this knowledge and ensure its consistent application.
Of course, there's no guarantee that a given developer will design with these tools (have a look under the covers of your average large EJB application and you'll see what I mean).
Happy coding (or, seeing as how I work on Compuware's OptimalJ, happy generating (grin)). BTW: MDA != OO, although you can produce one with the other.
Michael Murphree
Consider me a noob, but I consider OO design to be a gift from heaven. It is easy to separate different aspects of a given job. You call functions from classes with a meaning. I still prefer the good old direct approach when the need is there (just now have a project to handle a weird ADC, which acts more analog then digital...), but that too can be wrapped in C++, in a function that disregards all OO-paradigms.
And when all comes together, I dislike Java because it denies me the direct control over the hardware and memory, and I dislike C because it becomes a mess...So C++ is the answer.
Still like to see a usefull combination (ie like combining the primitive 'native' cals in Java with C++, in a useable manner. Java is just too nice to leave alone).
And no, I don't need any guru's to tell me what to do. The guru's can give pointers...(no phun intended). To give a peronal favorite: Bruce Eckel, with his Java and C++ books.
So "used" cases that used "unused" could break, though older compilers in essence used "unused" to mean both "used" and
I suspect you'd like C# then. It has C/Java-like syntax, a strong OO paradigm with escape hatches for direct memory manipluation (among other things). If you don't like Microsoft, that's OK too, as the Mono project has made some serious progress in producing an open source C# / .Net platform.
>If I would do my app in perl or python, how many options of compatible servers can I find?
Any server that supports cgi.
>But who does web projects in C these days?
No one, but I didn't suggest doing web projects in c either. I was speaking of non web projects.
>And the text processing capabilities of C are nearer assembler than any modern language
C's PCRE implementation of regular expressions and java's are almost exactly the same. So to say c's text processing is nearer to assembly is to say so is java's.
>Don't forget the usefulnes of standards to stop reinventing the wheel every time, something that some C/C++ programmers seem to prefer. Standards help lower the cost of development.
More libraries are written in c than in any other language. If a c programmer chooses to reinvent the wheel, that's their own problem. More than likely the needed library has already been written. And ANSI has been standardizing C since the 80's.
...more specifically, I blame my school and schools like it.
Right now I'm attending a large university (formerly an "institute of technology") for a degree in Computer Information Systems, the main programming language they teach is Java (we also have to take classes on VB, PHP and COBOL, no C or C++ though)
I like to think that I have a pretty solid understanding of programming (I had 5 years experience with C++ before I started school), but I had never used Java before, I am probably about average in it now (average for the people who actually know the language anyway). The quality of the classes at my school (and I suspect other similar types of school) is absolutely horrid, I mean I know a guy who got an A in the first level java class and was unable to write a console application to convert between farenheit and celcius, even when he was given a class to read input from the keyboard so he didn't have to use BufferedReaders or anything like that. I know people who are graduating this term, have 3.5s and 4.0s and were absolutely amazed at a simple app I hacked together in a couple hours to allow me to remotely manage the MySQL database that runs behind my website (yeah I know I could have done that in PHP, but I'd never had java connect to a database before and I thought it would be fun to write a java app to do so).
What it comes down to is that there are a lot of degree factories that let people leave honestly thinking they know something about $subject when in reality they only know enough to be able to use a few of the right keywords in their resume.
I don't know how many of these people I've just looked at square in the eye and informed them that they need to do some heavy personal-time learning or they might as well just quit, because with their knowledge the only thing they will be doing is getting outsourced to india 6months after they find a job. And yes, I realize that ALL of our jobs are in danger of being outsourced, but I would like to think that it is the clueless code-monkies (people who's entire skill set involves turning a comprehensive UML diagram into really shitty code) who are really in danger of losing their jobs, and not the serious programmers (people who understand how to actually solve problems, how to write good code, understand the subtle nuances of the various languages, etc).
Famous Last Words: "hmm...wikipedia says it's edible"
>Any server that supports cgi.
Isn't cgi kinda left behind the first generation of web apps? I wouldn't want to do a medium/complex web app with cgi for what I remember of it. CGI was simple though.
>C's PCRE implementation of regular expressions and java's are almost exactly the same.
It is not, because Java has a real String class in the language without the convoluted ways of C that only knows pointers and char arrays.
I still would like to know what text processing you think Java is missing.
>More libraries are written in c than in any other language.
Absolutely true, but Java libraries are easier to reuse and put togheter even in binary format on any platform. C/C++ libraries usually requiere recompiling and/or some messing with data types at least. In C you have the added problem of poluted namespace, while in C++ each compiler makes a different name decorating.
"I think this line is mostly filler"
Someone is going to have some months of free vacationship in Guantanamo it seems. You'll beg to be let write in Visual Basic.
"I think this line is mostly filler"
Well-designed OO code does not degenerate into spaghetti, any more than well-designed procedural code does. So much depends on the quality of the people creating the code that we often forget that the tools they use are less relevant than the skills they leverage.
Well, if they are so good, they fail to turn it into words. I guess I believe that good design principles can be documented and put into rules of thumb without turning into a 700 page volume. If you cannot fit your design principles into about 3 pages or so, then something is wrong with your principle. (Of course, examples may take longer.)
So how many times must you encode the rules for "contributing" to the river consistently? Relational data constraints often cannot handle complex decisions based on individual values in a record or a set of related records. Business consistency must then be enforced with code in every task accessing the data. You must repeat code, or at best, explicitly call it without fail, to ensure 'the river' does not become polluted. In cases like this, OO languages provide more powerful tools to represent this knowledge and ensure its consistent application.
I would like to see a specific example, past claims that procedural "repeats" or fails have failed to be true when scrutinized. Encapsulation does NOT better protect data. That is an urban legend.
Table-ized A.I.
But what about all the task where you can't use a database at all? Things such as Photoshop, 3d studio, webbrowsers, compilers and so on.
Those are generally not the domain of Java anyhow (at least not yet). I would note that I have considered the idea of a table-oriented interpreter as an experiment. Speed aside, I think it would be great idea.
Say I have a relational databaes, and an application used to access data in the database. The application is a "desktop" type application running at several people at the same time.....Now say A fetch data from the database and view it in a table. Now B update the database that A views. Thus A has stale(old) data. How does B tell A that A need to fetch the new data from the database. B can't signal A directly because A and B don't know each other.
Generally the user knows their view is stale, and to press the Refresh button to get fresh data. However, one can implement polling on an update flag/file/record, or simply refresh every X seconds if auto-updates are needed.
I would need more info about the nature and context of such an app to choose the best approach. There are multiple approaches to solving such an issue. It can be confusing and problematic to change data in the middle of viewing or editing anyhow in my experience. A "snapshot in time" is generally cleaner anyhow, as long as the user has the OPTION of refreshing. But there are exceptions, and I have dealt with them.
Table-ized A.I.
and I dislike C because it becomes a mess...So C++ is the answer.
I don't like C either (nor C++). It is too primative for my tastes. It might be fast and portable, but not very programmer friendly IMO. But C is not the pinnacle of procedural, I would note.
Table-ized A.I.
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
Don't Repeat Yourself: knowledge should be represented only once in the system.
Not specific to OO.
Classify objects in your systems by the messages they respond to, and the responsibilities they hold.
I find these often artificial. In the real world the relationship between operations and nouns is often many-to-many and dynamic in the longer run, and OO is generally crappy at many-to-many relationships.
Prefer short methods.
Results in too much "packaging" IMO. One spends all their time managing interfaces instead of code that actually does something. Too wordy and bloaty for me.
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.
RDMBS and disks are generally orthogonal. A database is more than something to keep information if somebody trips over the plug. Disk versus RAM has almost nothing to do with the reasons for using a RDBMS.
Prevayler's tend to be too language and/or paradigm specific. In the real world one often needs to share information with many systems, languages, and tools. Prevaylers are too insular.
And they tend to reinvent the navigational DB's of the 1960's. Almost nobody complained about their demise until OO proponents tried to resurrect them for OO.
Their discussion is actually about the pitfalls of task-oriented UI design, but their arguments apply to this discussion.
I did not see any specific "failure scenarios" raised. Perhaps I missed it.
Thanks for your feedback. Perhaps we can take this offline if it gets longer.
Table-ized A.I.
DRY is indeed not specific to OO. Design by responsibility and collaboration, on the other hand, tends to be.
Many-to-many relationships between classes (verb-to-noun) are often handled the same way you handle many-to-may relationships in a relational database; with an intermediate entity (class) that serves as a go between.
Good point about Prevayler and navigational / network DBs, but as for sharing data, or preferably services, with other applications, messaging protocols can accomplish this.
It might not have been on that page but I thought they discuss problems in changing or repurposing code bases built with a transaction script style (or perhaps I read it somewhere else). I've actually seen such problems in practice (with both procedural and OO implementations), and it's usually the result of bad initial design. So we're back to people again.
Regards,
Michael
I got my first Java job without any knowledge of Java at all!! chock!. Only after several days working with Java did I understand the basic packages java.lang, awt, applet, net and text!!
Turns out a lot of the "very experienced/but selftaught java programmers" in that company didnt really understand object orientation and still wrote code that was completely unmaintanable even after several years!! but on their resume they can truthfully state that they know most of the language and api.
As long as there are people putting "I know CHMOD and Upload/Download" on their resumes, I guess anything is possible....
At what point does a person *know* java? I graduated a few years ago, and I listed Java on my resume. I had taken two semesters (Introduction and Client/Server) and felt like I should list it. I would venture a guess that no project done for a class rivals the complexity of a real world project, but are college students supposed to leave their resumes blank? Naturally I didn't list Java under the experienced listings,but under languages known. Maybe there should be industry standardized tests for each language, not unlike A+ certifications or Redhat Linux Certifications.
#) Isn't this true for every langauage....
#) Building complex systems requires experience(on large projects and exp in a particular domain),no matter which language you are using....
#) One good way to identify someone's love for a langauge or platform is to check for his participation and contribution to FLOSS. that loves ensures his personal interest and can be a pointer to the fact S/he is inquizitive and likes exploring more (not just learning the basic sytax required to do the job).
Linux: Self-mutilation is a snap.Be a geek!!!
Programming *shouldn't* be an art! Not if you're being paid to do it. The last thing I want on my projects is individual programmers getting creative. All that unmanaged creativity does is screw up the design we've spent hundreds of man-hours writing the spec for, testing the requirements of, and documenting in painful detail.
"Monkey work" is the bread and butter that makes real applications happen. "Monkey work" is what we need to keep large projects managable. "Monkey work" is what can turn software development from a craft into engineering. If the design is good then it works damn well.
/rant over
Forget thrust, drag, lift and weight. Airplanes fly because of money.
Remember the Matrix, when Keanu says "I know Kung Fu"? It's like that, only with Java. It doesn't mean you can puddle your way through a toy app, it means you make the language your bitch. It does what you want, when you want it, how you want it. Maybe you don't remember all the classes and their methods, but you know the common ones, and you can find the rest from the API in a flash.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
I think you need to examine your logic a bit here. Just using an OO language to accomplish a task does not make you an OO programmer, even if the language or compiler imposes some OO onto your fundamentally non-OO code. OO isn't about a language, or what a compiler does with the language. It's a way of deconstructing problems into objects and the way they interact. If you aren't doing that, you're not doing OO programming.
The indonesians renamed their islands (or various portions of them) from what we normally call them. So Java = Jawa, Sumatra = Sumatera New Guinea = Irian Jaya etc. But the main tragedy is we can no longer make puns about procreation in the Celebes Sea, as that island is now Sulawesi. Sincerely, the wild man of Kulimantan.
"Waste not one watt!" - CZ
I remember reading postings on Monster, Dice, and Careerbuilder that asked for something like three years of C# experiance when it had just come out.
I agree that Java could be considered DOA on the browser because no one wants to deal with AWT classes.
However checkout Thinlets , if this ever got widespread adoption I think we would start seeing more and more applets popping up. Being able to define interfaces with using xml allows people to just rip through and create interfaces likity-split, and the speed amazing.
I guess the need for applets isn't as important anymore for rich-client applications due to the ease and success of Java Web Start.
"It takes many nails to build a crib, but one screw to fill it."
The language is straightforward enough. But I tried to do a few things in the early days, and between the AWT/Swing transition, discontinued development products, and Sun's annoying tendency to releaase huge half-implemented class libraries (remember Java 3D?), and the general realization that you don't write applications in Java, I got fed up and left.
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.
I think Java GUI's will make a huge resurgence now that SWT is gaining popularity.
provide a development platform by which developers could do applications applications that would run either on the client or the server. The big problem is that Java never really delivered on the client end. Applets run, but they are so poorly engineered, in the words of Marc Andreeson "client side java is dead'--and Javascript has take much of the role it was anticipated that Java would take on the client.
I previous poster made legitimate points that Java brought garbage collection, reflection and runtime safety into the popular eye. However, there are other widely used, well-standardized languages with those same features, namely Javascript.
C# may be better in key respects than Java, but I have trouble conceiving of C# as a really open standard. The ECMA standard for Javascript is already supported by a variety of companies(i.e. IBM, Lotus, Microsoft, AOL/Time/Warner/Netscape) in a variety of products.
The folks at have shown that they can extend Javascript quite a bit-even in browser implementations.For all of the talk of C#, one thing that is interesting about
I'm a DBA and Perl/Python programmer. I've used Java for class projects at CMU. Java and C# both strike me as overly complicate for most of the work I do on a day by day basis. Javscript isn't there yet-but I can see that it might get there. There is a real niche for a well standardized, universally available scripting language that just hasn't been filled yet. If a small fraction of the engineering effort applied to Java were applied in this direction, I'd expect big benefits.
You're right..I did..thanks for the catch, I was perhaps just finished playing SoCom, and it must've still been on my mind...oh well..
Your version of "knowing" java is like saying that the ability to hook up a power supply, motherboard, processor, and hard drive and install Windows on it makes you a system administrator.
You know how to administer a Java app, but you don't know Java. If that's not what it says on your resume then you are lying. Your skills are needed and they're non-trivial - i'm Sun certified in Java programming and i don't know all the stuff you know - but if an employer says they want someone who knows Java then you're just wasting their time.
The only thing necessary for the triumph of evil is that good men do nothing.