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
midrange.com
