Re: Java and OO Concepts

Thorbjoern Ravn Andersen wrote:

Joe Pluta skrev:
I'm glad your code is fast, I am just of the opinion that microoptimizations may make your code less readable so it may be harder to maintain. If you are the only maintainer, great :) Saves time since you know the pattersn you write in.

Then you write bad code <shrug>. I think good code is eminently readable, and in fact I've always found that you know you're writing good code when you remove lines rather than add them. I don't use "clever" code, just well-written, well though-out code. I avoid trickiness, and concentrate on writing good code the first time. What I don't think is good is just writing code and then "refactoring" later; an occasional rewrite is necessary, rewriting everything over and over is a sign of bad design.

I'd like to hear them. Get it all out! Feel better!!

Nope. I've done it in the past. The BigDecimal alnoe is enough to kill the entire language in my estimation. Add in a lack of an integrated ISAM database and I get ill thinking about writing real business applications.

Well, Java 6 SDK ships with a database so perhaps it helps a little?

Not much. I don't consider Derby a business database, but rather a useful utility for storing small amounts of data. The last I looked, Derby doesn't support even basics like row expressions. And in general, SQL-only databases are far slower than ISAM for business applications.

What is so wrong with BigDecimal? That everything must be done as a method call, instead of +, -, etc just works?

Uh... yeah. Trying to read a complex expression written with BigDecimal is very painful.

THis is actually a core issue which we need to solve.

The inflexibility of modern day software. A modern application is so complex that you need to divide it up to be able to mentally cope with it. That has worked well in abstracting away the machine hardware by the operating systems but is failing to work well for developers. You can only get rigid Lego blocks, which allow you to build large things, which can then be put together again to build even larger things etc until you have a real cathedral which in principle can last for a thousand years. We cannot today in software build robust things that can easily be adapted to something else, you can only snap the legos together as intended, not mold them to be another shape.

I think the idea of snap-together business software is a myth in the first place. The very purpose of business software is to provide a unique competitive advantage to a business based on their business practices. By definition, no two business have exactly the same practices so business software must either have lots of switches to determine its functioning (which absolutely kills SQL access), or it requires at the very least semi-custom software.

Anyway, enough on this. I really do try to avoid opinion, and this is very much opinion. But I still guarantee that I can sit down with a client and design a customized MRP generation (or just about any other complex business process) in RPG faster than any Java programmer on the planet.

Joe