Tom Liotta wrote:
Jon Paris wrote:
I guess so Brad. As soon as I found the toolkits my immediate reaction was "why did I waste my time" with the APIs.
I'm on both sides of these opinions.

I followed this discussion and didn't reply because I too found myself on both sides, and both sides were well presented. I think I began writing an ILE-based Web interface about the same time that CGIDEV2 came out, but I didn't know about it. I sometimes wonder if I ever would have begun writing my own interface if I had known about Mel Rothman's work. Now that I have my own I'm glad I did lay the groundwork myself, but there's also a good case for simply using the tools that are available.

I didn't think there was much risk in using CGIDEV2 because it was supported by IBM and licensed originally as "open source", although IBM evidently deterred from the open-source status.

It's interesting that proponents of learning low-level API's are also the same people who are building tools. Tool vendors, of course need to know low-level APIs. But what about application developers? Wouldn't it make more sense to focus on applications? Not tools? I'm on both sides of that discussion too. I build both tools and applications, but it's not always a great position to be in. At some point I hope to focus most of my time on applications - not tools.

Nathan.


CGIDEV (and CGIDEV2) is an interesting example for this discussion. The storm that came out of IBM's handling of it -- IBM lawyers, open/closed/proprietary-source status, Mel Rothman's and then Giovanni Perotti's retirement and the rest -- has pretty much settled; but there was a lot of nervousness going around. At least, among those using CGIDEV/2 without understanding their internals, there was some stress.

For those who coded directly to the APIs and who weren't using CGIDEV...? There was little reason even to pay attention to the storm.

Toolkits are great resources. Yet, there is much to be said for spending time with the APIs themselves.

A toolkit or tool (WRKDBF? QUSRTOOLS and Y2K?) might disappear or break at any time. A licensed product with a maintenance /contract/, e.g., DBU or TAATOOLS, provides buffering; but the APIs always go straight back to IBM for support, fixes and documentation.

Whenever possible, I use the toolkits as learning resources and try to minimize any production use. Burying a tool in production code can leave a nasty surprise for some later developer. Learning and using the appropriate APIs in appropriate ways can make a significant difference for years after development is finished.

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone 253-872-7788 x313
253-479-1416
Fax 253-872-7904
http://www.powertech.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.