Comments on: Why don’t you replace COBOL with something useful (not Java)

By: More on replacing COBOL with something useful — JT on EDM

More on replacing COBOL with something useful — JT on EDM — Thu, 11 Feb 2010 03:52:22 +0000

[...] posted an interesting comment on an old post of mine (Why don’t you replace COBOL with something useful (not Java)) in which she make some interesting comments: I understand your last point that using a declarative [...]

By: Lisa Keeler

Lisa Keeler — Fri, 05 Feb 2010 21:34:03 +0000

(sorry for such a late comment)

I understand your last point that using a declarative “model” such business rules would be preferable to replace legacy COBOL applications instead of using a procedural language.

However, is there an example (or examples) of a real-world product that you could suggest? I assume that “under the hood”, these products would be code-generators.

If there are such wonderful tools available, then wouldn’t they be widely used already for new business applications instead of C or Java?

I thought that, since the 80′s at least, these types of tools have been explored / attempted, but they have been unsuccessful so far.

Thanks,
Lisa Keeler

By: Dynamic BPM and agility — JT on EDM

Dynamic BPM and agility — JT on EDM — Wed, 07 Oct 2009 15:24:08 +0000

[...] used a slide very like one I use around exploding the application(see this post on the decomposition of the application). User interface, decision points, paths of execution and data definitions used to all be part of [...]

By: Are programmers the problem? » Smart (Enough Systems, the blog)

Are programmers the problem? » Smart (Enough Systems, the blog) — Tue, 24 Jun 2008 00:46:32 +0000

[...] COBOL is not evil, but COBOL programmers are. Now I already posted a response to James’ post (Why don’t you replace COBOL with something useful – not Java) but this new post made me think. I should say that not only are some of my best friends [...]

By: James Taylor

James Taylor — Mon, 16 Jun 2008 21:02:43 +0000

James
Not sure you followed my argument! My point is that replacing one from of techie-only procedural logic with another (no matter which one) does not get it done. Ease of maintenance and business agility mean replacing process, decision and other components with declarative “models” like business rules and using the hard-core languages that can only be edited by a programmer only when absolutely necessary.

By: James Owen

James Owen — Mon, 16 Jun 2008 20:55:57 +0000

OK, let’s say, just for giggles and grins, that we have a system that actually is written in COBOL and the upper management wants to replace it. What “language” would you suggest? You’ve already take the stand that Java is not a good idea, and you might be right; don’t know. BUT, what are the alternatives? C? C++? Ada? Scripting? (OK, I got a bit silly there, but you get the idea.)
So, let’s consider that a rulebased system, the engine itself, is nothing more than a compiler. The underlying language is irrelevant, whether C or C++ or Java or whatever – even COBOL. So far as the business is concerned, it’s just a compiler that they can use if the engine has a BRMS interface. The IT guys, on the other hand, have to maintain this puppy. And you can bet your bottom dollar that for an extensible, flexible, expandable system they will vote for Java every time.
Unless, of course, performance is a problem. Then they might go for C or C++. Yes, I’m one of the die-hards who believe that C++ is still faster than Java, as proven by CLIPS, CLIPS/84, CLIPS/R2, etc. The latest version of CLIPS runs the Waltz-50 benchmark in just over a second, faster than ANY of the Java-based engines including the OPSJ Rete 2 engine.
Dr. Forgy (the original Rete guy) has always said that C/C++ would run the Rete 2 algorithm much faster than the Java version but he never could find the economic justification to do such a thing. Well, maybe now he has one. We’ll just have to wait and see.
BTW, if you want to talk to Gary Riley (CLIPS guy), Mark Proctor (Drools guy) or Dr. Forgy, make it to the October Rules Fest. See http://www.rulesfest.org for more details.
SDG
jco

By: James Taylor

James Taylor — Mon, 16 Jun 2008 15:04:42 +0000

Charlie
You are, of course, right. I blogged about this in a post about the making of meals from leftovers (http://jtonedm.com/2008/05/28/making-meals-from-your-mainframe-leftovers/). My point here was more that when you decide to replace COBOL, don’t just blindly re-code in Java.

By: Charlie Bess

Charlie Bess — Mon, 16 Jun 2008 13:22:32 +0000

Although it is hard to disagree with the desire for something more modern than COBOL, the statement “there’s no reason why aging COBOL apps can’t be replaced” is emotionally based. If the software (COBOL or Java) is continuing to add business value at minimal maintenance costs, there are likely other investment avenues to pursue with greater ROI. It’s a business not a hobby. Hand-crafted code that has a limited resource pool for enhancements… calcifies the organizations ability to change, but there are so many opportunities and so few resources, we need to focus on what differentiates the organization, not on what feels good.