One Reason To Use EGL: Implied Decimal Point

An implied decimal point type is but one small, insignificant reason to use EGL. (That's my way of saying HUGE and COMPELLING.)

Let's compare EGL to Java. Java technology does not have built-in support for an implied decimal point, like COBOL does. In other words, you cannot possibly declare a type like decimal(16, 2). And yet, as you know, SQL supports a column type with an implied decimal point. When reading and writing to an SQL database, Java requires jumping through hoops. You may be required to use a double-precision floating-point type, which is not exactly suited for the task.

EGL has built-in support for an implied decimal point, just like COBOL and SQL. It comes from the fact that an implied decimal point type is one of the cornerstones of business programming. You can generate from EGL to COBOL. The EGL runtime for Java comes with a Java class called something like EDecimal. It provides everything that we need in an implied decimal point type; it behaves exactly like COBOL and SQL. It is built-in so that we don't have to think about it. In EGL, when reading and writing to SQL, it's so easy.

Have you use double-precision floating-point type in your EGL code when you should use an implied decimal point type? That's another issue.

Thanks for listening!

One Reason to Use EGL

What is one reason to use EGL? It reduces risk.

Big ol' enterprises, such as state and federal government and major corporations, have been pushing COBOL and CICS as the best way of doing things for the entire duration of my career. It comes from a real need to reduce and eliminate risk.

Risk is a big factor in developing big software. It is bigger than the lifetime cost of software development. It is bigger than productivity of individual developers. It is bigger than the benefit of improved development technique and paradigms.

Big ol' enterprises are ultra-conservative corporate customers. They need a safe bet. The safer the better. They need a very predictable computer environment. The more predictable the better. They have an aversion to risk and the leading edge of technology.

So, what do they choose? They consistently choose big iron, such as mainframes and virtual machines, COBOL and CICS, along with its baggage of big ol' enterprise culture. The decades-old establishment means very little measurable risk. It does not allow software revolution. And actually, that's a Good Thing.

Meanwhile, there has been something of a revolution going on in gadgets, such as smartphones and tablets. The ultra-conservative corporate customer understands that gadgets exist. Instead of adopting the gadget way of doing things, they are finding ways to connect gadgets to big iron. They are creating a new model for gadgets to connect to low risk COBOL and CICS infrastructure.

As a big iron developer, expert in COBOL, CICS and MVS, you might be experiencing the effect of a major clash of cultures as people try web technologies, such as Java and JavaScript, to connect to the big iron. Using a dozen different programming languages to build one application—what does any ultra-conservative corporate customer that? It make no sense.

But, there is a big problem. While there is nothing inherently wrong with the Java Virtual Machine technologies, there is something wrong with the Java programming language. The language is a system programming language like C. Who wants to write a business application in a system programming language? Many people don’t know any better. They are stuck and feel like they have no choice. If you're writing for the Java Virtual Machine, you have to write in the Java programming language, right? Actually, no, you don't.

A long list of other programming languages have been ported to the Java Virtual Machine, including Clojure, Python, Scala and—believe it or not--COBOL. But, ultra-conservative corporate customers don't like the risk of using a so-called foreign programming language on the Java Virtual Machine. They use the Java programming language, the official programming language of the Java Virtual Machine.

And this is part of the reason why I like EGL. I like EGL because it generates to Java to make my ultra-conservative corporate customers happy. While they get a JEE-compatible web application (with HTML/CSS/JavaScript/Java), I get to write in EGL, a business language that gets my work done. When I get my work done, I’m happy. Everybody’s happy.