heres mine…

I think the main drawback of Java for web apps is that they are compiled. I just want to log in from my Iphone and make a quick edit. Hmmm… Not really quick…

Here is an example: How complex is a Java CMS vs. a PHP CMS? How portable is it? Usually the PHP app is more portable. Weird huh?

Yes, a change of employment setting would be nice. Unfortunately, there are no paid jobs anywhere in the world, especially in the USA.
My life’s goal, ever since I was a kid: to be a bionanotechnologist. To all my math and science and engineering to use in genetic bio-nano-engineering. Regarding the right tool for the job, for the ideas I hope to see realized and things I want to achieve, math is still 99.9999% of the work ahead of me. Computer programming it afterwards accounts for only 0.0001% of the work.

Firstly, thanks for reading and taking time to respond.

I work for one of the largest insurance and breakdown providers here in the UK, and we use Java exclusively for our Web tier, and the majority of the business layer systems. I spend a decent amount of time at the beginning of any large project designing my classes using UML and ERD (for DB related matters), and this is a constant thing.

It sounds like you’re doing a lot of mathematical related development, where things are probably more procedurally structured in terms of logic. Whilst I’m sure there’s a lot of use for OO in the maths software development field, I am inclined to think that the tools/languages you use such as FORTRAN do not provide the features that you’re looking for. Without seeming blunt or rude – perhaps a change of employment setting might provide you with a means of gaining experience on a day-to-day basis with not only Java, but OO design and implementation.

Failing that, there are plenty of open source projects that will use OO as their development approach, so perhaps looking for a project on sourceforge.net or Google Code might yield something along those lines.

There’s no right or wrong with all this. Like you’ve said, OO is one approach and we all use the tools we need to get the job done.

Cheers,

Placid

However, I feel I simply cannot get into object-oriented programming (OOP), even though I marvel at its structure.
For ALL of my computational needs spanning my entire life – beginning in high school when I touched a computer for the first time for word-processing project, through my first FORTRAN course in 1981 at the same community college where I would take C++ 24 years later, through chemical engineering courses where I wrote and ran FORTRAN programs, and a physical chemistry course where I programmed a TI-59 calculator to its maximal capabilities – to my work as a chemical engineer at Rohm & Haas chemical research plant where I did a few computations using SAS (statistical analysis system) through my 12 years as a mathematics graduate student, earning a PhD in Math in 2000 – using MS Word and Mathtype and a little Mathematica computation to put together a 275page dissertation – as both a fulltime and parttime professor of mathematics -
to one week of work in 2006 at a casino slot machine testing facility where I computed odds and payouts on an Excel spreadsheet -
to a homework assignment on molecular modelling in 2008 in which I used Maple computer algebra system to compute electron orbitals -

when I actually have to do the REAL practical useful computer work – the work which gets evaluated and graded or paid for – NOT ONCE have I used C++ or Java or any other form of OOP (except, of course, for the 2 C++ courses I took).

Oddly, OOP has inspired me to create innovative mathematical models of game theory – competition, war, etc – because of its way of organizing the universe. But the inspiration for me is still on good old paper (or, rather, in an MS Word document stored on the computer). OOP has not inspired me to do more computer programming.

I know that every individual’s needs are different. Each individual needs to use the right tool for the job. So, I shouldn’t feel guilty about not having made any use of OOP and of Java in particular.

But, what I want to know – does ANYONE in this world have a job where they get paid money AND where they HAVE to use some form of OOP or Java for their job?

I published my 6th math paper this year, and I am energized to write more – although I am terribly stuck on how to get the thoughts from my brain to the page.

what seems to be overlooked in all of the discussion is the development and use of tools which generate most of the code. programmers debating the “efficiency” or “work” to write 4 lines of code versus 6 lines of code have missed the more important issues altogether: maintainability, interoperability, and portability.

20% of the cost of an application is the development. 80% of the cost is lifecycle costs after deployment.

java addresses all three of these key issues. WORA clearly addresses the portability issue – for a price. applications do run considerably slower because the byte code is interpreted by the jvm rather than having binary code fed directly to the cpu. for web based applications, the performance considerations are minimal. where performance does matter, there are java compilers availble – at the price of portability.

strong typing helps enforce good design. good design improves maintainability.

java has a strong framework with good implementations for interoperability. few developers ever work with enough complex applications to get into JNDI and related areas, but Java’s interoperability is another strong point where it leaves most other applications in the dust.

getting one’s head above the computer screen long enough to see “the big picture”, one should be able to gain some perspective about what makes Java a strong solution in the enterprise well beyond lines of code and functional versus OO.

let the tools write the code.
don’t be a tool !

1) ““Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler.”
Very interesting indeed. Could it be that Java’s a victim of its own success – legacy interoperability causing slowdown for future features – and thus confirming my “Java’s slow” point? Admittedly, this was not my original intention, but you’ve certainly proved your point (and helped mine along the way, perhaps).

2) “Getters and setters encapsulate fields. However, they don’t encapsulate the data structure of the object”
The problem with this subject and resulting arguments for either case, is that the specifics are implementation dependent. Getters and setters could be used for pure field access (a.k.a. Java Beans), or to wrap access to maps or lists within the object (though the Iterator design pattern would be best here, along with extending Map/List). It may have been more beneficial for me to include a larger example.

3)
The issue isn’t performance here, it’s the amount of code you have to write in Java to do the simplest thing with list/map types. Python exposes these language features quickly and easy.

4)
Interestingly, we’re in a very similar situation. The client I currently work for has the same setup: Windows developers (writing Java) and the site being deployed on a Red Hat server. The point though, is that this doesn’t really exercise the multi-platform interoperability well. Most releases tend to be built on or for that platform. The multi-platform abilities of Java were mainly aimed at desktop applications to bridge the divide in the desktop market. I don’t deny server-level aims by this feature of Java, but this wasn’t my point; hence the discussion of Ajax and the web being the platform.

Thanks for your comments and for reading. It’s an interesting topic and it’s great to get feedback.

Cheers!

1. “Interesting, can you prove this please?”

From http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html :
“Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. The main advantage of this approach is that it provides total interoperability between generic code and legacy code that uses non-parameterized types (which are technically known as raw types). The main disadvantages are that parameter type information is not available at run time, and that automatically generated casts may fail when interoperating with ill-behaved legacy code. There is, however, a way to achieve guaranteed run-time type safety for generic collections even when interoperating with ill-behaved legacy code.”

From http://java.sun.com/j2se/1.5.0/docs/guide/language/autoboxing.html :
“The performance of the resulting list is likely to be poor, as it boxes or unboxes on every get or set operation. It is plenty fast enough for occasional use, but it would be folly to use it in a performance critical inner loop.”
The above is not a proof, just an indication, but other sources such as http://www.jroller.com/voidmain/entry/jdk_5_auto_boxing_best strengthen my argument.

2. “I was actually referring to the issue with the Java conventions (bad sentence structure, perhaps). Technically the use of getters/setters are encapsulation.”
The following is my opinion… Getters and setters encapsulate fields. However, they don’t encapsulate the data structure of the object. A more object-oriented API exposes functionality instead of data. Then, subclasses can use polymorphism to perform different functionality by overriding the functional methods and those methods can operate on whatever data the subclass happens to store internally, leading to greater generality of any code using the class. The primary purpose of object orientedness is to allow reusable black box components in this way. Many people are so accustomed to getters and setters that they write them automatically. That habit is the fault of the programmer and I don’t think it should reflect badly on Java.

3. “Not only is that code awful to read, but it is inherently going to be slower than using the language feature that is parameterisation – you’re converting an Array to a collection (although the asList() method is probably optimised heavily) as opposed to just creating a list directly.”
Arrays.asList creates a list backed by an array, meaning the collection wraps the array instance and delegates to it. The list should be at least as fast as ArrayList – it’s about the fastest and simplest list implementation possible other than Collections.emptyList(). I would imagine that Python converts your special syntax into an actual object and thus does something similar. I don’t see why Java would perform worse. Of course I don’t know what’s going on under the hood…

4. “Yes, it is easy to port. Trouble is, who does it nowadays?”
A lack of porting isn’t necessarily a fault of Java. Also, some of the apps I use are Java and all are cross-platform. I use Eclipse, NetBeans, IntelliJ IDEA, and core Gnutella library written in Java; all are cross-platform. Also, most popular Java programs, like Azureus and LimeWire, are cross-platform. I develop Java apps at work on Windows and they’re deployed on Red Hat. I could also work on them at home on my Mac too.