On Tue, 18 Dec 2018 at 17:40, Thomas Burrows
<thomas.burrows.1957@xxxxxxxxx> wrote:
Is there anyway that IBM could be convinced to update SEU to provide
support for the H, F, & D specs in SEU?
-snip-
Would in my opinion allow the people who are wanting to hang around on the
"whatever the heck the system is called today" to be here.
Hi Thomas,
The hangers-on... are hanging on!
We don't need an updated SEU, and the reason is deeply ingrained in
what we do for a living.
When I started, back in the 70s, computerised work flows were simple:
print reports. Aged trial balances, payroll ledgers, invoices - simple
things that anyone could understand. In that time, in that place, SEU
was quite a good fit. A simple editor for simple work flows that
delivered simple solutions. If my business still had simple
requirements like this (and some do!) then SEU is /still/ a good fit
for those programmers, for that business. There's nothing - nothing! -
wrong with using an editor that is well suited to your work flow. It
was no disgrace to use SEU for that 1980 work, and it's no disgrace to
use SEU in 2018 if you're still doing that kind of work.
But as time goes on, the batch-oriented work flows are being replaced
by transactional work flows, and these in turn are being replaced by
work flows that no longer involve people at all, but are machine to
machine transactions. These more sophisticated work flows can be
handled by SEU, but doing so places an ever increasing burden on the
programmers, who now have to keep more and more things in their heads
- SEU isn't doing hardly any housekeeping for them, whereas editors
that have evolved in tandem with the work flows all have 'programmer
helpers' built into them. At some point, the work flow gets
sophisticated enough that using SEU is a competitive disadvantage
compared to say, RDi. Because the competition's programmers aren't
having to keep all the mundane scut work details in their heads -
their editors are helping them out with that stuff. This means that
the competition's programmers aren't bogged down counting parentheses
a hundred times a day - they're thinking about the business problem,
the logic. They're working at a more sophisticated level of
abstraction than our SEU sisters and brothers. No, not all - nothing
is 100% - but as a statistical cohort, those of us using a simple
editor will be thinking in simpler terms than those of us using a more
sophisticated IDE.
The problem, based on my own experience, is that there's no bright
line where SEU is a great fit /here/ and a poor fit /there/. The work
flow doesn't evolve overnight from 'load, sort, print, update' to
'JSON + machine learning = executive dashboard'. There's a continuum.
But that continuum doesn't ever move from more sophisticated to
simpler - it's always from simple toward complex. And that's what
makes it important to move to a more sophisticated programmer IDE. You
may not use the power of the IDE straight off - I know I didn't - but
when your work flow evolves to the point where you welcome the IDE's
help, you'll have been using RDi long enough that you're well past
that initial learning curve that everyone seems to talk about, and
you'll be well placed to learn that one new thing that will help you
out with your new business task.
RDi. Not because it's a shiny object. Because it's much more suited to
the work flows I have to deal with.
--buck
midrange.com
