One of the reasons I hate to watch TV (there are several) is that I’m constantly bombarded by the message that I need something I don’t have. I’m told I need a new car, a certain exercise machine, and new clothes. I need to eat certain foods, take a cruise, and switch long-distance providers. (What I really need is to get rid of my TV!) I’m tired of listening to those who think they know my needs better than I do, so I turn off people who tell me I need something. That includes people who tell me I need a certain piece of hardware or software.

That’s how I used to feel about people who pushed Integrated Development Environments (IDEs). A large part of my consulting time is spent modifying and writing RPG programs using, for the most part, IBM’s tools: PDM, SDA, SEU, and RLU. They get the job done, so why would I need an IDE?

On e re ason is that IDE s ar e th e ne xt l ogic al s tep in t he d evel opme nt o f th e sc ienc e of pro gram ming . Th e ea rlie st p rogr amme rs h ad t o pr ogra m th e ea rlie st co mput ers in m achi ne l angu age. Bec ause thi s wa s a tedi ous, err or-p rone pro cess , as semb lers wer e in vent ed. Asse mble rs a llow ed p rogr amme rs t o wo rk i n sy mbol ic la ngua ges. Thi s al l to ok p lace bef ore my t ime, but I’v e he ard that mac hine lan guag e pr ogra mmer s di d no t co nsid er u sing an asse mble r to be real pro gram ming .

Assembler language did make programmers more productive, but it was not without its faults. Because assemblers required programmers to code too many operations to perform simple tasks, compilers were then invented. Programmers have inferred that “compile” means “translate,” but any dictionary says that compilation is the process of gathering together. Compilers gather previously designed and coded routines into working programs. I’m told that assembler language programmers, like machine language programmers before them, didn’t consider using a compiler to be programming, either.

With compilers, programmers are even more productive because they can code just one compiler instruction instead of many assembler language instructions. However, compilers also present challenges, one of the biggest being the nightmare of monolithic programs.

Computer scientists have preached against monolithic programming for years. IBM’s solutions of ILE and object-oriented programming (OOP) are consistent with what’s going on in other computing platforms, especially in the worlds of UNIX and Windows.

Constructing programs from reusable object code is smart, and programmers who reuse code are being more productive than those who continually reinvent the wheel.

Ho weve r, r euse has its dow nsid e. I nste ad o f ma ny l arge pro gram s, I hav e a my riad of modu les. As I co ntin ue t o de velo p mo re s oftw are comp onen ts, I ne ed so meth ing to h elp me k eep trac k of the m an d or ches trat e th eir use. Tha t’s what an IDE do es, and as a res ult, I’m mor e pr oduc tive .

The first computer I learned to program, the IBM System/3 Model 12, had no interactive programming; operators had to key data onto 8-inch diskettes at 3742 dual data stations. Even back then, those days were drawing to a close. People wanted terminals at their desks.

Now the terminal era is drawing to a close; people want GUIs. Never mind that GUIs are rotten for heads-down data entry. Never mind that constantly switching between mouse and keyboard can be tiring. People want their mice and icons, and whether we programmers like it or not, we have to provide them.

T hi s is a no th er r ea so n I ne ed a n ID E. T he t oo ls I h av e ar e OK f or g re ens cr ee n pr og ra mm in g, but I’ve recently been writing CGI applications, and when I find the time to convert RPG II programs to native RPG III or RPG IV, I’ll develop Java applications. The right IDE can help me make that jump.

It’s clear to me that, to take advantage of the emerging trends, I need to learn about IDEs, which is what this issue of MC is all about.