× 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.



Bryce Martin wrote:
Joe,
I don't think you need to know everything listed in this description, but there is no reason that a decently good programmer can't be very familiar with most of it.
Bryce, I don't want to get into a spitting match here, really I don't. I appreciate how candidly and yet civilly you've made your arguments so I'll take a moment or two to go through them. Take it as a different viewpoint. :)

I've only been out of school for three years, and while I don't use everything listed every day, I'm familiar with most. And I don't even consider myself one of the best programmers out there.
What are you working on? How much RPG programming do you do? Are you the primary point person for a major part of your application suite? Your company manufactures products, so I assume there is ERP involved; are you in charge of things like order entry or MRP or <shudder> accounting?

I ask only because the vast majority of RPG programmers I know in the midrange community are maintaining large legacy systems and spend most of their day enhancing, maintaining or troubleshooting their legacy systems. They don't have time to learn new skills on the job and companies are less and less often sending them out to learn new technologies unless they relate directly to their jobs.

Modern RPGIV - check
subprocedures - check
use of C or Java functions from RPG - familiar with the approach even if I don't use them, could if I had/needed to.
embedded SQL - check
XML processing - I prefer JSON, but I'm familiar with XML and could pick this up if needed.
RDi - Use WDSC7 until we upgrade
PHP - check
Java - check
.Net - rather not
HTML, Javascript,CSS - check.
Great. You know the stuff you learned in school and modern RPG. Frankly, moving to modern RPG from Java is a piece of cake. How about RPG III? Or RPG II? How long do you think it would take you to be make a major modification (or even a minor one!) to an order entry program that uses an internally described display file?

I don't say this to denigrate your skill set, but to explain to you that while you were picking up Java and PHP and HTML, a lot of us green screen dinosaurs were honing our ability to code matching records and fetch overflow and record address sorts. I'm an anomaly in that I actually made my living with Java/RPG amalgams so I had a good reason to learn them, but not a lot of people out there have the time to learn them all.

When you break it down and look at a span of projects over 3 to 5 years, I really fail to see how having these skills would be that difficult to come by. Unless you are stuck in a shop that does RPGII programming only I would suspect that most programmers on this platform have at least half this stuff in their tool box.
Not so, grasshopper :)

Seriously, unless they're in a relatively small shop, or a relatively progressive one, it's not terribly likely that an RPG programmer has worked on HTML code in a production environment. The reason may be that management has avoided going to the web for ever because "green screen work fine" or it may be that the web development is done by the Windows guys, or it may be another reason entirely. But it's really not rare for RPG programmer to know what HTML is but to have never had reason to code it.

The RPG stuff I agree, no excuse, but I think I mentioned that. Every RPG programmer needs to learn RPG IV and ILE concepts and free-format coding. And they need to learn how to use the GUI right away, whatever name it has this week. But I really think you're asking a lot of a veteran RPG programmer to think they know PHP or .Net or HTML or Java.

Using PHP to generate javascript to generate HTML? Who does that? And why on earth would you? Write HTML where you need it, Javascript where you need it, and keep the PHP on the server doing stuff that can't be done on the client side. AJAX is way more than a passing fad and is quickly becoming the standard for web application data driven development. To develop in a mix'em up/mash'em up way makes for highly unmaintainable and sluggish solutions. Taking a more MVC approach and using each technology as it is intended usually works best in the long run.
If you program from the ground up using a Web 2.0 JavaScript framework, then you don't need to code PHP that generates JavaScript. But then again, you don't even need PHP in that case - you simply encapsulate your business logical in RESTful services (in whatever language) and design your pages directly using a decent JS enabled tool.

That, however, is not what the "PHP for the i" crowd is saying. They're saying to use PHP as your primary scripting language, which means your HTML is generated by your PHP, which in turn means that your JavaScript is generated by your PHP. It's a bizarre Rube Goldberg technique, but that's what you get if your architecture is just an extension of PHP 4 coding techniques, which sadly is the bulk of PHP programming out there.

Joe, I respect everything you have done. You are a great asset to the IBM i community, but I don't think it is very demanding to have the toolbox that Jon and Susan suggest.
I respect your opinion and again, I appreciate your candor and civility in expressing it. I hope I've been able to express some of the reality of the world I live in, which is inhabited by those of us with 15, 20, 30 or more years in the field. It's not that we can't learn this stuff, it's that most of us don't have time. At the same time, people do have to upgrade their skill sets so I suggest they eat the elephant one bite at a time, and maybe even ignore some of the less tasty bits ... as you yourself have done with your choice to leave .NET on the table.

Thanks for an excellent discussion.

Joe

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.