Letters

There's Always Room for Forth

Dear DDJ,

I enjoyed seeing the coverage of Forth in John Sadler's "FICL: An Embeddable Extension Language Interpreter" (DDJ, January 1999). Forth is a solution to many development problems. For instance, here's a real-world precedent for Forth-like embedded interpreters.

At Jet Propulsion Laboratory (JPL), we embedded a Forth interpreter in a large military simulation back in the mid 1980s. The simulation and the interpreter are still in use; the Corps Battle Simulation (CBS) supports military training exercises at sites throughout the world, and is still maintained by a small team at JPL.

We use Forth not only as an embedded interactive scripting language, but also as a symbolic debugger. Of course, debuggers have come a long way in the past 15 years, but we still find ourselves using Forth commands on an alphanumeric terminal to examine and change variables while several hundred users are interacting with the simulation.

One more technical note: Our simulation and the interpreter are written in Simscript II.5, a simulation programming language marketed by CACI. Simscript turned out to be a great tool for writing interpreters in addition to simulations. Nowadays, the product has its own symbolic debugger, but it looks nothing like Forth.

Jay Braun
[email protected]/

Online Op/Eds

Dear DDJ,

I enjoyed S. Balamurugans' online Op/Ed "Why Is There a CPAN but No CCAN?" on the DDJ web site (http://www.ddj.com/), which asked (and answered) the question of why we have a Comprehensive Perl Archives Network (CPAN) but not a Comprehensive C/C++ Archives Network (CCAN). By coincidence this is a concern of mine as well. I have, in fact, been placing C++ source code onto my web site. By the first of the year I expect the amount of source code to grow considerably. The site right now is rather dull looking but is at http://www.frontiernet.net/~guffy/source. If at all possible I would like to pass this web site on to other readers. The source code there is free for download and I look for contributions from others.

David Cox
[email protected]

Parsing Expressions in Java

Dear DDJ,

Upon reading Cliff Berg's article "Parsing Expression in Java" (DDJ, January 1999), I was surprised that he didn't mention more powerful tools than the bare tokenizer functionalities offered by the Java API. In particular, I refer to tools that implement context-free parser like yacc, which are now available in Java; for example, JavaCup, Antlr (http://www.antlr .org/), and JavaCC (http://www.suntest .com/JavaCC/index.html).

Christophe Ponsard
[email protected]

DDJ replies: Thanks for your note, Christophe. You're right, there are some very powerful Java parsing tools out there that deserve coverage. That's why we hope you enjoy Gary Schap's article "Compiler Construction with Antlr and Java" on page 84 of this issue.

Age Discrimination

Dear DDJ,

I read Jonathan Erickson's December 1998 "Editorial" on the H-1B visa issue. He was spot on. I volunteer with a group called "ProMatch" here in Silicon Valley. It is a no-fee professional career resource center. Most of its members, and there are an average of 100-200 at any given time, are senior people with many years of experience in a variety of positions. The thing I note most often is that their former employers make no attempt to retrain the staff they are laying off. Besides leading to the bizarre situation of companies laying off people in one area and hiring in another, it is very bad business management. Letting experienced people go means that part of the corporate memory and culture disappears, experience and more efficient ways of doing things are lost, morale plummets, recruitment takes lots of time and money, recruitment also extends the crucial time-to-market window, and integration of new staff into the company's culture also is time consuming. This is balanced against lower initial salaries a more malleable work force, and a more narrowly defined skill set. As a last point, well respected companies like HP, which have large numbers of temporary staff, tend to keep these people for many years. The cost of staff turmoil is not worth it in the long run and one way to reduce this turmoil is with retraining. Thus, the need for tens of thousands of foreign workers is far less than some businesses claim.

Reg Charney
[email protected]

A Better Date?

Dear DDJ,

Suppose I have to construct a system for storing dates. I decide to store the dates in a standard, straightforward MM/DD/YY format using digits. Never mind about binary numbers and the like, let them come later. Dates are allowed to range from 01/01/00 to 12/31/99. These ranges mean I am able to store all the dates of one century. About 37,000 dates.

This is where I thought: Wait a minute, something is wrong here -- six digits. Shouldn't that be 1,000,000 dates. Where does the other 963,000 dates hide?

The answer comes fast. MM/DD. This way of storing dates is very inefficient. Gladly, the solution comes just as fast. Here is mine: To be able to represent 23 more centuries, I allow dates to range from 01/01/00 to 96/93/99 in the following manner:

• century(1,1) range from 01/01/00 to 12/31/99.
• century(2,1) range from 13/01/00 to 24/31/99.
• ...
• century(8,1) range from 85/01/00 to 96/31/99.
• century(1,2) range from 01/32/00 to 12/63/99.
• century(1,3) range from 01/64/00 to 12/95/99.

For example:

• century(5,2) range from 49/32/00 to 60/63/99

This system makes it possible to represent in whole 24 (8×3) centuries, approximately 888,000 dates. It is not all of the possible combinations, but it is much better.

Now, as I see it, this system is far better than any of the systems I saw in the last journal. It is simple to understand. It should be possible to use it in all databases that stores dates in an MM/DD/YY form. It does not require any changes in such existing databases, and it is fully backward compatible. A date in the normal MM/DD/YY form will be the exact same date in the aforementioned system.

Torkel Danielsson
[email protected]/

Dear DDJ,

I was wondering the other day why nobody hasn't come up with a more extensive way to represent hexadecimal. There are more letters in the alphabet than "F." So, if the hexadecimal we all know about is based on representing 16 different values, than why don't we have one that represents 32 values? Simple enough? Hexadecimal is, of course, based on the range of 0 to F so a 32 value representation, double hex, for lack of a better word, could be from 0 to V.

This could also be used as a Y2K fix. I'll explain: If you have the last date of the millennium in the legacy format of YYMMDD, it looks like this : 991231. Use "double hex" and the same date in the format of YYYYMD could be represented as 1999CV. The month would be a "double hex," or even hexadecimal would do, and the day would be a "double hex" also. Amazingly enough, the maximum single digit value of "double hex" is 31, the maximum amount of days in a month.

The basic thinking is: Instead of compressing the year like many other Y2K schemes, why not compress the month and day? After all, there's a finite amount of months in a year (12) and a finite amount of days in a month (28,29,30, and 31) But the years are infinite ( 0 to ?). The best part is that a date could still remain "human readable" with no complicated math involved and a simple knowledge of "double hex" is all that would be necessary. You know how to read hex? Then just extend the hex table to twice its current size and there you have it. Shouldn't be that hard to learn.

Of course, "double hex" could have other applications, but Y2K seemed a good example of how to use it. Just a thought.

Christian Lanctot
[email protected]

More Y2K

Dear DDJ,

In the May 1998 issue of your journal there were two articles about the Y2K problem. "Date Compression and Year 2000 Challenges" by R.L. Moore and D.G. Foley and "Strategies for Solving the Y2K Problem" by W.Gothard and L. Rodner. Both articles were very interesting and got me thinking.

The problem of Cobol records with MMDDYY dates to be expanded to MMDDYYYY is a tremendous task since to convert millions if not billions of old records by 2 bytes would take enormous amounts of storage space.

My thought is to convert from MMDDYY to DDDYYY with DDD as the day of the year and YYY as the year from 1800. This does not require additional storage space since both strings are the same length. I am sure that assembler routines can be written to convert both to the month, day, and year format.

Yes, there is the problem of finding the usage and changing the code to handle the new format but "Date_Born" and "Date_Now", "Date_Died", and so on would just be a subtraction till the year 2800 unless you need to manipulate data prior to 1800.

Because my Cobol is a little rusty, I realize this is probably simplistic, but it does solve the record expansion problem that is such a big headache with older Cobol data.

John D. Kent
[email protected]

It's a Cult Kind of Thing

Dear DDJ,

After reading Jonathan Erickson's November 1998 "Editorial," I'd like to point out that I've called myself "Chief Programmer, Church of Cybernetics Certainty" for years. My church's goal is not so much enlightenment as tax-free programming income. I suggest that Baba-Rom Jon can have those followers looking for spiritual leadership; I'll take those looking to get rich.

Steve Furlong, CP, CoCC
[email protected]

DDJ