Wednesday, February 20, 2013
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!