× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Mon, Jul 24, 2017 at 7:43 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:
Of course I will eventually learn the APIs John - but in comparing this with other RPG oriented APIs I think it is going to be a lot harder than it need have been. Take Scott's wrappers for YAJL for example:

yajl_object_find, yajl_get_string, yajl_beginObj, yajl_beginArray, etc. etc.

Aaron's RPGMail - similar notions.

I agree that YAJL function names are more self-documenting. But I also
feel it's more appropriate for them to be. Let me explain.

YAJL is what I think of as a task-oriented library. The task it helps
with is serializing to and deserializing from JSON. Libraries to send
mail or read data from an Excel workbook or get user input from a
browser are all task-oriented.

The vision for RpgMap isn't to do some predefined task. It's to extend
the language itself. Think of it more as providing new operators
rather than a collection of procedures.

Also look at the coding patterns. If you examine the samples for
RpgMap, you see that you have to repeat some of those functions a lot.
I mean, it's almost painful how much you have to repeat them. And the
functions are designed to be nestable/chainable. You wouldn't use YAJL
or RPGMail in that way.

These factors taken together put a premium on brevity.

Someone encountering code using [YAJL or RPGMail would] have a reasonable idea of what was going on - when I looked the function list for RpgMap I _knew_ what I was looking at and still couldn't make head or tail out o some of the names.

There is going to necessarily be some stuff that is unfamiliar to RPG
programmers, because this is stuff that RPG wasn't designed to do.

Let me tell you, when I first learned RPG. I had no clue what "SETLL"
meant. Even once I learned that it was a mnemonic for "set lower
limit", I *still* had no idea. Or CHAIN. What the heck that? What am I
joining together when I chain?

Ah, you mean seek. Or find. Either of those would be a much more
sensible and clear name. (And still shorter!)

Clarity is in the eye of the beholder. And our previous experience has
a HUGE impact on what seems clear. Before you learn something, there's
a good chance it's going to be weird.

RPG used to have to be terse - that's what we lived with for years. But we don't have to now and it just seems too retro to go back to the bad old days when there was no need. Most of us doing modern RPG are using editors like RDi that can provide assistance for the typing so having a 16 character name rather than 8 is not exactly a punishment when it makes it more obvious from the outset what the function is about.

There are trade-offs to be made. Brevity has value.

Why is it NOT too terse to have an expression like

foo = 400 * (bar + 5) - baz;

Would it not be clearer to write

Let foo equal 400 times (bar plus 5) minus baz.

No, actually, it would not! The one that uses the funny symbols rather
than the clear and obvious words is actually quicker and easier for
typical programmers to parse. So much so that even Cobol allows
arithmetic symbols. Cobol!

And lest we forget, we did NOT learn asterisk and slash (for multiply
and divide) in grammar school. Those came later. For most of us, much,
much later.

There will definitely be some differences of opinion regarding where
the sweet spot is in terms of brevity. But fundamentally, operators
have more of a reason to be short than other names.

You know, even with unlimited allowable opcode length, do you really
think RPG would have been better off with SetLowerLimit, rather than
SETLL? Really? And though an IDE can ease the tedium of entering a lot
of the keystrokes, you are still left having to read much longer or
more vacuous lines.

John Y.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.