Re: Impossible to even think about rewriting in RPG

Joe,

Brain-dump ensues...

I guess mainly it's #1 - my company (one of the largest software companies
in the US) won't spring for a fast PC for me - I only got my *second* GB of
RAM a couple of months ago, and as you point out, 1GB of RAM certainly won't
cut it. 2GB is better, but... Plus, because it's Java, there's a chunk of
overhead going on all the time, it seems (certainly Process Explorer shows a
lot of CPU usage). The actual opening of files/members were certainly slow,
but it was really the 2+ minute startup time.

A dealbreaker for us is the use of library lists to process compilations -
in SEU, I was able to set my *LIBL, edit a source member, compile it and
know which copybooks in which libraries would be used, and which compilation
overrides would be used. I never found the equivalent level of granularity
in the IDE's. I'm not saying it's not there, just that I never found it. We
have a lot of command-line processing which allows dynamic changes to
library lists, which is, at the very least, difficult to do, using an IDE. I
know I can create commands and command-sets, but there's a lot of hassle
(maybe one-off up-front hassle, but still hassle).

Of course, there's a certain 'old-school' bloody-mindedness to it - my
personal website is written using hand-coded HTML and I only just stopped
using a Palm Treo as my phone - maybe I'm just a Luddite, like my wife
says... Part of me just gets aggravated when someone says what john said. I
let my code (and the speed/quality with which I create it) stand for me.

I work form home a lot, so the communications/latency issues between my PC,
my firewall/router/cable modem/internet/corporate firewall/i mean that SEU
really is *much* faster.

Some of the benefits to an IDE don't really apply to me - a huge amount of
the code I write/maintain is PL/I, so there's no syntax checker. Likewise
with MI.

Finally, I'll reiterate what i said before - speed is everything. Every
second of latency or "Communicating with server" is anathema to me. And
right now, there's a bunch of it.

Rory

On Tue, Jun 28, 2011 at 10:29 AM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>wrote:

On 6/28/2011 11:19 AM, Rory Hewitt wrote:

john,

I write 'modern' ILE code in RPG, CL and C, using subprocedures,

procedure

pointers, service programs and all the other goodies. On the i, I also

write

code in RPGIII, COBOL, MI, REXX and PL/I. On my 'off time', I also write

a

bit of Java and lots of JavaScript, HTML and other web 'code'. I'm still
learning other languages.

I use SEU for *all* of my i code. I've tried different versions of
WDSc/RDP/RDi etc. and I keep coming back to SEU. Maybe if I was just

writing

RPG and CL, I'd use a proper IDE, but honestly. I haven't seen the

benefit.

I really tried (for a solid 2-weeks, without reverting to SEU, and it

didn't

'stick'. In my experience, SEU is faster, and for me, speed is

everything.

So with respect, you need to back off on statements like "Anyone who is
still using SEU, really, REALLY does NOT want to learn, anything...".

Maybe

rephrase it as "Many people who are still using SEU don't want to learn
anything...".

Rory

Please take this with no disrespect, Rory, because I do respect your
contributions to these lists a great deal. But I really have a hard
time understanding why someone finds SEU faster than the Rational
tools. I only find it faster for some very specific situations:

1. On a constrained PC. Hands down this is the primary reason people
don't like the IDE. If you don't have a few GB of RAM and a decent
processor, the user experience for any graphical product, including
Rational and iSeries Navigator, is severely diminished.

2. First time startup. SEU starts faster than Rational. Yes indeed, it
does. But I only load the IDE once a day or often even less
frequently. If I don't shut down my PC, I can literally keep the IDE up
for weeks at a time.

3. Opening a new source file (file, not member). Opening a file means
building a list of the members. It's pretty much by definition slower
than the same process in PDM. But once again, that's ameliorated by the
fact that I only have to open the list once; after that I only need to
refresh it if I add or remove members. And of course the ability to
create custom lists of members that cross files and libraries often
overrides the benefit of PDM; yes, I can open a file quicker, but I
often have to skip from file to file to get at all my members.

4. Opening a new source member. This is the one that you can't get
around. To open a 32000 line source file will take a moment. How long
depends on your network speed, but downloading a source member to the
IDE is a finite, measurable delay.

5. The infamous "quick change". Yes, it's faster to open a member,
change one line of code, and update it with PDM. The number of times I
do that in a day (week, month) is very small. It's more usual that I
make some change, test it, and then make another change. With the IDE,
the ability to keep a source member open and simply compile with Ctrl-C
after each change (and then to be able to Ctrl-Z to revert one) mreo
than makes up for the quick seconds I save in SEU.

So, in general, to me only point 1 and 4 are the real showstoppers.
Both are hardware dependent and can definitely hobble any developer.
It's unfortunate when hardware concerns (or licensing issues as in
Alan's case) stop a programmer from being able to use the best tools.

But maybe you find one of the other issues to be a deal break for you?
I'd be interested in your feedback.

Joe