This reminds me of a discussion some time ago around XML.
No problem that data represented in XML format is at minimum 10 times larger 
than the original data. BandWith has become cheap and widely available. So 
crank the amount of data up to make sure that the result becomes 'just as slow'.
 
Eduard.

Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
> From: Of Hans Boldt
> 
> But that was then, this is now. Memory today is cheap, and you don't
> have to worry as much about allocating lots of storage. CPU's are now
> lightning fast, so performance isn't so much a concern.

"Cheaper" and "faster" are relative. I worked in 8KB with a sub-MHz
processor. Yes, we wrote differently when processors leaped to 8MHz and
we could have 64KB. But there were two kinds of programmers:
programmers who threw out good programming practices and wrote as if
they owned the machine, and programmers who kept good programming
practices and instead added more features and functionality rather than
bloated code.

And what happened? We got to multiuser machines, where more than one
user needed the memory. And the bloated, crappy programs crashed and
burned, while the well written programs thrived. We're getting there
again. Just because you have gigabytes of memory doesn't mean you have
to use them.

This idea that megabytes and megahertz are cheap is what got you a
Portal product that requires 4GB of main storage just to run adequately.
Or desktop programs that require 2GB to install.


> But the goalposts have moved since
> the S/3x days. Programming is different now, and older programming
> styles are becoming more and more passe.

This is so much hokum. Every generation of programmers likes to think
that they're doing some groundbreaking new breakthroughs in programming,
but truthfully most algorithms were discovered in the 60's, and we're
just reimplementing them with new tools. That sounds trite, but look at
the examples.

For instance, scripting languages (macro processors) are the rage in the
"new programming paradigm". Basically, they're just extension of the
macro assemblers of the 70's. Or how about OO? Now we find that
there's another way to do things - it's called Procedural Java. Cracks
me up. Or how about this? JDBC added a great new feature: an
updatable, scrollable cursor. It allows you to create a view over a
table and then read forwards and backwards, updating each record one at
a time. Of course, we've called THAT a logical file for about 20 years,
but hey, "it's new to them!".


> As Chris P has pointed out, no one - NO ONE - in any other language
> community would (or could) even imagine Java or C or C++ or Perl or
> Python or whatever as a fixed-form language. And no one in any of
those
> community could possibly imagine assignment operations that worked
like
> RPG's MOVE and MOVEA.

That's because nobody in that community ever programmed an ERP suite.
It's clear to me that the people who created Java never had to run a
month-end process. It's the same with the SQL folks who don't
understand why CHAIN is such an important instruction in business
programming. It's because they've never done any business programming.
Just like the people who pulled the MOVE operation out of RPG free.

Joe

--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.