Re: Please vote for Syntax check in /FREE! -- RPG400-L

Hmmmm, where to start?....

jt wrote:

...
I and a some other posters have some no small experience in this regard,
which I believe the RPG development team lacks.  I would be surprised to
learn (pleasantly surprised, 'course) if there is much RPG app development
experience on the team.  But I believe there are a fair number of very vocal
posters who don't have a real good idea of what RPG even CAN do currently,
but who like to believe they have a real GOOD idea of where RPG just HAS-ta
be headed.

You do have a point here. The developers on the RPG team understand compiler writing and language design a lot better than application development.

But then again, compiler writing and language design is what we get paid for. And an important part of our job is to understand the needs and wants of the RPG programmer, and to satisfy those needs and wants. Another important part of the job is to try to understand trends in the industry, and to try to anticipate the future needs and wants of the RPG programmer. The latter is, of course, not easy.

Which is why we are here, discussing the issues with RPG programmers who care about these things too.

...
I've listened to what "they" say for 2 1/2 decades now.  Few offer metrics.
Most offer, what Don Park (I think, couldn't find link) of MS calls,
Software Engineering by anecdote.  I like Tom DeMarco's methodology of
videotaping and measuring results and running "code wars" and such.  I've
seen the this-technology and the that-technology promise these gains TOO
many times.

However, what I've read and what I've seen and what Tom DeMarco measured
(back in late 70s, iirc, and I don't know if he's still doin this kind-a
stuff, or who is) was that the most effective programmers offer productivity
of 5-10 times the "average" programmer.  So I can't help but wonder how
much-a the "this-technology offers a 5-10 times productive advantage" isn't
explained by the phenomena.

The late 70's? That was many generations ago in computer terms. I'm not sure if anything written *that* long ago has any validity now anymore. Things are very different now. Very different indeed. (More on this later.)


| (BTW, note that most of these scripting languages fall into the
| category of OO languages *without* method name overloading.)

Again, then I wonder why this doesn't call into question the efficacy of
procedure name overloading.  (Which, I noticed, a lotta posters have loudly
claimed is REQUIRED for them to do their job properly.)

Touche!

But I think it's also important to understand why those particular languages don't have (or need) method name overloading. Take Python for instance. (My current fave!) In Python, there's simply no syntax at all to say that a function expects a paramater of a particular type. Take the following code as an example:

.........................................
class A:
    def f(self):
        print "Hi There!"
class B:
    def f(self):
        print "Get Lost!"
def t(x):
    x.f()
a=A()
b=B()
t(a)
t(b)
.........................................

Look at the function "t" in the middle of the code. It takes one parameter, x. Python doesn't care about the type of the object passed (at least, not at compile time). All that matters is that (at run-time) the object has a function f defined in it. You don't have to code one function t that takes an A object and another function t that takes a B object.

(Basically, this is what OO is about. It's actually about defining the interfaces, not the types.)

But compiled languages are fundamentally different. In order to generate efficient code, compilers like to know the types of things at compile-time. Which leads to much syntax intended specifically to deal with types. And in the compiled OO languages, leads to a lot of cruft like interfaces, virtual functions, and templates (to name a few). To write the above example in Java (for example), you'd have to define an interface, define the two classes as implementing that interface, and define the type of the parameter to function t as that interface.

Why is that important? As I mentioned before, supporters of Python claim a 5-10 times productivity advantage. One of the reasons for that is that Python programmers don't have to waste time getting all the nitty gritty details of class and interface definitions right. You just write code, and most Python programmers find that they get their code working faster. Similar arguments can also be made for other interpreted languages as well.

But back to RPG, overloaded procedure names would add a syntactical convenience for programmers in that they could call a set of related procedures by one name (for example, "getinfo") instead of many names (for example, "getinfo_by_name", "getinfo_by_partno", etc.). Programmers would still have to implement each of those procedures, however, the user interface to that set of procedures is simplified, possibly resulting in easier to read code.

So, sure, overloaded procedure names is not a requirement. But like many of the improvements we add to the language, it can make the job of programming a little bit easier.


| Anyways, perhaps you could remind me which specific article by
| Greenspun you were referring to? In what I've read by him so far, I
| don't see any relevance to RPG.

(See above.)  I believe it calls into question some-a the maxims that a
lotta people that post here live by.

Yes, I do agree with that 100%. But I still believe you don't fully understand what he's saying. And that you haven't addressed my question of how what he says relates to RPG.

As I mentioned earlier, this is not the 1970's. Or even the 1980's either. For all this time (and longer), we've had two types of programming languages, compiled and interpreted, each with their own advantages and disadvantages. Compiled languages have the advantage of fast run-time performance. Interpreted languages have the advantage of powerful functionality.

Greenspun is simply echoing what others have said that interpreted languages, by virtue of their strong functionality, have a significant edge in programmer productivity. Sure, compiled languages still have the advantage of better run-time performance. But remember, Moore's Law still is in full force. CPU's are still getting faster and faster, and along with that, the speed of interpreted programs is also getting faster and faster. We've long ago now reached the point where, for a large class of applications, the run-time performance difference between compiled and interpreted programs simply no longer matters. And so now, programmer productivity becomes a more important deciding factor for many shops.

(Actually, some Perl (yucch!) fans claim a well written Perl program can easily match the performance of a comparable C++ program. Why? Much of the time running a well-designed Perl program is spent in the built-in library code, which is compiled C code.)

Sure, there is still a large class of business applications that benefits from coding in a compiled language like RPG, and running on a robust machine like the iSeries. So I'm not advocating the whole-scale rewriting of business apps. (On the other hand, Moore's Law is still going on strong, continually changing the software development landscape.)

And contrary to what you posted, Hans, an awful lotta the points I raised were NOT addressed, yesterday.. and one in particular: I would guestimate that there are some half-a-million, mebbe a million RPG coders. Just a swag, but somewhere in the vicinity of the right order-of-magnitude... Now there are how many on this list?? On this poll, the highest vote-getter (which you claim was by ballot-stuffing) was.. what?... 39 or so??? I posited that you don't have a statistically random sample, and the data you are collecting is misleading, Hans, and I don't actually recall ANYbody saying that you're sampling DOES reflect the needs of the RPG community. I sure DO recall many saying that I don't have a clue, but don't recall anybody posting any facts that said this method of determining the course of the language was unbiased, a-tall. It was just taken as a given that anybody who SHOULD have ANY say in the course of the RPG languange would already be on this list, (or one similar). ...

First, I suspect that that number of RPG coders is over-estimated by at least an order of magnitude.

Secondly, jt, I assure you, I do understand statistics. A couple of courses in statistics were required for my degree. (Actually, at my school, the mathematics requirements for a CompSci degree were just one credit shy of a minor in Math!) One of my stats courses was in experimental design, so I do understand it when someone says, for example, that a survey is valid within 3%, 19 times out of 20.

Of course our polling is non-scientific. Do you think we can justify the cost of commissioning a truly scientific poll?

What we base our design decisions on is input from a group of RPG programmers who care about what gets in the language. Many RPG programmers simply don't care one way or the other. Some simply don't bother (or can't) keep up with the latest developments in the language. In some cases, programmers ask for things that have been in the language for several releases!

Of all the available on-line sources of input, this particular mailing list is probably the most useful to us. This group can also be counted on (generally) to understand the complex issues involved, which I'm sure you would agree is also an important consideration.

In other words, we prefer informed input, not necessarily a representative sample of the whole population. For example, we may see 100 requests for a particular change. But if 1 person offers a very good reason why that change should NOT happen, that may well override the majority. And that's another reason why "ballot stuffing campaigns" (for lack of a better term) don't have as much influence as some might like.

Cheers! Hans