RE: DIM question (Was MOVE/MOVEL and %Scan)

> From: boldt@ca.ibm.com
>
> Does a language need to be "integrated" with a database for it
> to be a good language for business apps?

Yes.


> One problem with RPG is that it is "too" integrated with OS/400's
> database.

Statements like this convince me that you don't really understand your
client base.  You're too involved with what you want RPG to become to
understand what it really does - what in essence pays your paycheck.  This
does not bode well for the product.


> Many RPG programmers would like to be able to port their apps to
> other operating systems.  But matching the semantics of RPG's
> database operations to databases on other systems is not easy.
> The inability to easily port business applications written in
> RPG is a major impediment to more widespread adoption of the
> language.

Your client base doesn't care about porting their applications, Hans.  This
is the red herring mantra I hear over and over.  "It doesn't port well."
Most people don't want to port thweir applications, Hans.  If your goal is
to turn RPG into some hybrid changeling that can run on a Windows box, then
I truly fear for the future of the language, and the future of the platform.


> For example,
> with my program, if you wanted to display a different number of
> columns in the report, you only have to change one line of
> code - the SQL query.

The sort of flexibility that you're talking about only applies to the very
easiest part of a business application, the inquiries.  You're not the first
to espouse this particular argument.  Every so often somebody throws
together a couple of inquiry screens and because they can move columns
around a report they think that this somehow indicates that the language is
well suited for business applications.  It's just not true.  An order entry
system is far more complex than any inquiry you could possibly write.  By
the time you figure out the massive SQL statements required for a price
lookup, an RPG programmer will be on to the next application.  This problem
has plagued every Unix conversion I have ever seen, not to mention the VB
front-end applications.  Once again, I suggest that you write an MRP
generation.  Until you understand the difficulties involved in that sort of
programming, you really have no reference point.  Make no mistake about
this: inquiry programs are to business applications as algebra is to
calculus.  A nice introduction, but the tools don't translate.


> OK, database access is not an "integrated" part of the Python
> language.  So what?  Database programming in Python is done by
> using modules written to support specific databases or database
> access methods.  Furthermore, these db modules have a standard
> interface, and so you can easily switch database products
> without the need to substantially rewrite code.  I don't nean to
> bad-mouth RPG, but this degree of flexibility just doesn't exist
> with RPG.  (Unless you're using the SQL CLI, perhaps, but that's
> still not as easy as the DB-API in Python.)

Again, I have to point out: nobody cares about other database products.
None of my clients care whether or not their applications run on an Oracle
database.  What you fail to realize is that the concept of "porting" is very
low on the scale of requirements for your existing client base.  Any loss of
current function or ease of maintenance in order to make a system "more
portable" is going to be seen as a negative, not a positive.  You evidently
come from a background where you take it for granted that you have to change
databases.  Midrange shops rely on the fact that they DON'T have to change
databases.  How many programmers does it take to change databases on the
AS/400?  ZERO, BECAUSE THEY DON'T CHANGE!


> I don't have to.  Another group is already doing just that.
> Check out the GNUe project.  Granted, it's still in the
> development stage, but it does show promise.  They
> specifically chose Python for it's ease of programming.

I'll believe it when I see it.  If ever a billion-dollar business is running
their day-to-day production on a Python-based system, then we'll talk.
Until then, comparisons between "promise" and "reality" are pretty moot.


> I agree fully that some tools are better than others.  But
> there are a lot of factors involved in choosing a set of
> tools for a paricular purpose.  In the iSeries world, two of
> the most important factors happen to be 1) that most iSeries
> programmers know RPG better than any other language; and 2)
> that most iSeries software is already written in RPG.  To be
> fair, these are important factors, and IBM will continue to
> recognize the importance of these factors.  But you can't
> ignore the legions of other programmers who do churn out
> business apps in other languages, and do so happily.

I don't ignore them, Hans.  I simply insist that time and history has shown
RPG to be far more productive for real, industrial-strength business
applications than any other language.  You have offered nothing to
contradict that statement, except that RPG "doesn't port well".  We've heard
this refrain over and over and as I've explained, it doesn't matter in the
real world of iSeries business application development.  From anyone else,
I'd ignore it as the lack of understanding typical to someone unfamiliar
with the platform, but coming from a member of the RPG compiler team, this
attitude chills me.

If yours is the pervailing attitude among the compiler developers, then I
believe we're actually seeing the end of the iSeries as a business
application development platform, and the beginning of its relegation to an
SQL-server also-ran.

Joe