When old-time green-screen programmers and New Age GUI advocates meet, there’s always a certain tension in the air. With apologies to Theodor Geisel, a.k.a. Dr. Seuss, Joe Pluta draws from one of his favorite authors to depict this age-old conflict in a slightly different light.

This is the story of the Hack in the Back, a curmudgeonly old RPG programmer who lives back in the computer room and greatly resembles me (except perhaps bearing a slightly greater resemblance to Paul Newman), and his alter ego Zappie, also known as Zap-Am-I (it’s an identity thing; we’re hoping that therapy will help). Anyway, the Hack in the Back has no use for screens not green (“24-by-80 or Fight” is his motto).

Zap-Am-I, on the other hand, is attempting to drag the Hack into the 21st century— or even into the 1990s, for that matter— but the Hack isn’t having any part of it. This month’s issue of MC, with its focus on IDEs, particularly rankles the Hack, who doesn’t even like menus for Pete’s sake, much less some silly graphical front-end. “If I want pretty pictures and sounds, I’ll hook up a Nintendo,” he says, grimacing. “If I can’t do it from the command line, I don’t need to do it at all!”

Listen as the two of them square off.

“I am Zap, Zap am I. I have a pretty G-U-I.” “I do not like that Zap-Am-I. I do not like his GUI.” “Do you like my GUI?” “I do not like it, Zap-Am-I. I use green-screens, don’t you see, not something that is called Gooey.”

And so the culture clash begins. These two come from different worlds. The Hack in the Back prefers RPG, while Zap-Am-I writes Java. The Hack can barely spell GUI, while Zap has no clue what an indexed access method is but is sure he’d like one if he met it. The Hack bench-tests his code (Zap calls this “napping with your eyes open”), while Zap uses Rapid Application Development (the Hack calls this “the thousand-monkeys programming technique: Hit enough keys and eventually something will get written”). The Hack drinks coffee and eats donuts. Zap drinks Jolt and eats Ramen.

This won’t be pretty, folks.

“Green connects without a hitch. Gooey always has some glitch.” “But not with TCP/IP! CA/Express works GREAT for me!”

Ah, the first shot! The Hack immediately uses the old standby of connectivity. And once upon a time, he would have been right. Back in the days of the first cave computers, it was much easier to connect a simple green-screen to a midrange. The complexity of connecting a PC via Advanced Program-to-Program Communications (APPC) was daunting even to the network gurus: 5250 emulation was bulky and balky and just plain unreliable.

However, in these days of clean TCP/IP communications, most of those complaints have lost their relevance. The new IBM AS/400 Client Access Express for Windows (the Express client) offers an extremely thin, extremely reliable client that sets up and runs just about as easily as a green-screen. For lots of information on the Express client, please take a look at some of the recent issues of AS/400 Network Expert.

“And GUIs will run Excel! And Word! And Domino as well!” “But OfficeVision’s fine for me. I do not need your dumb PC.” “But OfficeVision’s going to die. And then you’ll need my GUI!”

In this interchange, Zap-Am-I counters with the simple point that a workstation allows someone to do a lot more than just access the AS/400. It seems like a simple enough point on the surface, but, of course, the Hack isn’t listening. He’s content to stick his head in the OfficeVision/400 (OV/400) sand, at least until Zap reminds him that this particular sandbox is not long for this world. With the formal announcement of OV/400’s demise, green-screen technology just took a serious kick in the head.

And, be honest, the truth is that a green-screen simply can’t compete with the features of graphical applications for any sort of document processing, be it spreadsheets or text. Anything from email to mass mailing can be done better, quicker, and more easily with a PC. And as sound and images proliferate, it’s becoming more and more difficult to agree with the Hack.

In fact, about the only reason to print from an AS/400 at all is that you can’t create PDF documents on the AS/400. (Well, you won’t until the June/July issue of AS/400 NetJava Expert, which will include a utility to convert AS/400 spooled files to PDF.)

“There’s very little text I do, so I am fine with SEU.

My job is writing RPG, so GUIs are not for me.” “Well, come and try an IDE and boost your productivity!” “But PDM is fine for me. I do not need your IDE.”

So! In this round, Zap-Am-I goes for the jugular. He brings out the dreaded P- word, productivity. The Hack insists that PDM is just fine, and for good old monolithic RPG or COBOL programs, he’s probably right. SDA is an excellent tool for developing green-screens, and SEU provides all the functions a programmer needs to build big, complex enterprise programs. Face it, when you spend most of your day in a single program, there’s really no reason to be able to open more than one source member (well, maybe one other member, for cutting and pasting, but hey, that’s what F15 is for).

However, in these days of smaller programming units (did I hear someone say “module”?), an IDE provides features, from mass editing to component management, that make life much easier. Mark McCall gives an excellent explanation of these features in his article, “Behold the March of IDEs: A Killer Tool for the AS/400,” elsewhere in this Focus section.

IDEs have a long and storied past, but they’ve always been the province of the workstation crowd. Those of us who first programmed on punched cards (or maybe you remember the old 3741 diskette punch) tend to have a bit of difficulty adjusting to something that immediately tells us when we make a typo and does it in color no less. Little windows popping up all over the place can be confusing, and some of those toolbars...well, who designed those icons? If the same guy were given the job of creating the international road symbols, I’d expect to see cars driving off cliffs like lemmings.

But these environments are here to stay, and I’m afraid that those of us who are comfortable with SEU are going to have to change with the times. The benefits of IDEs outweigh the shortcomings, and more features are being added every day. As the AS/400 evolves into a multilanguage, modular programming environment, we need tools to help us maintain and manage all those little bits of code. And just when we need them to, the IDE developers are starting to realize that they need to bring the “24-by-80 or Fight” crowd along and are designing their tools to ease green-screeners into the GUI paradigm. For an example of a tool that does just that, read David Morris’ article, “CODE/400: The Programmer’s Sidekick,” also in this Focus section.

All that said, the Hack still doesn’t want to listen. He’s happy in his 24-by-80 world, and there’s nothing that can budge him. It’s not looking good for our friend Zap-Am-I, but take a look at how things work out:

“I see you are not fond of me. I see you hate my IDE. I see you hate my GUI. I think that I am going to cry.” “Oh please, don’t cry because of me. I will try your IDE. If you promise not to cry, I’ll really try your GUI.”

Ah! Zap-Am-I pulls out all the stops to get the Hack in the Back to at least try the IDE, to give it an honest shot— which is what each of us needs to do before we decide whether or not IDEs are the right tool for us.

So how do you know if an IDE is for you? There’s only one way. Try it. And don’t just use the examples or tutorials the vendor might supply. Go outside the box a little. Do the kind of development you normally do. Or maybe even attempt the kind of programming you want to do in the future; if you think you might be changing your programming model, make sure that the IDE fits what you want to do.

For example, here’s my rule for an AS/400 development tool: If it makes writing a simple one-panel display program easier, then it’s probably a good tool for me. More importantly, it must be able to help me when I’m designing server programs, programs with no user interface at all. Even if a tool generates lovely progress reports, tells me my errors in fluent French, and plays soothing MIDI music in the background, if it makes my job more difficult, it’s a bad tool.

How can an IDE make my job more difficult? If it takes longer to do the same thing than if I were using SEU and SDA, that makes my job more difficult. If the IDE locks up and loses my changes, that makes my job way more difficult. If the tool can’t handle certain features of the language, that makes my job more difficult. (This is a special consideration for AS/400 IDEs: If they don’t keep up with OS/400, these IDEs can cause you grief, especially if you’re one of those brave souls who lives on the bleeding edge of technology.) If the tool forces me into certain programming techniques, that makes my job more difficult, too. (Even though this is usually more of a problem for code generators than IDEs, it’s still a consideration.)

However, if I don’t run into these problems, I may find that an IDE helps my development, especially as I move into the world of distributed development. See what the Hack thinks:

“Zap-Am-I, your IDE is making coding fun for me! I like the colors, like the speed. Your IDE has all I need! I like the edit features, too. Especially, I like Undo! Zap-Am-I, I finally see! I think I like your IDE! I even like your GUI. It really makes my coding fly! You really are some kind of guy. I like your style, Zap-Am-I!”

And so we see that even the Hack in the Back can, if he’s willing to try new things, begin to enjoy the benefits of an IDE.

Author’s Note: The curious (or bored) among you might be wondering which of the above characters is really closer to me. The answer is...both. Well, I used to be the Hack in the Back, and now I’m Zap-Am-I (although not quite as midrange-illiterate, I hope).

True Story: In the early ’80s, when the IBM PC (and XT and AT!) first came out, I took one look at the CGA graphics, with its four colors and pixels the size of golf balls, and decided then and there that graphics were a fad (the Hack in the Back!). Needless to say, this opinion caused me some embarrassment as the years went on. Ironically, I ended up in charge of a major graphical client/server development project using OS/2 and OS/400 and began to see the light. Now, with the advent of Java, I’m finally coming fully into the graphical fold (Zap-Am-I!).