Information Systems:Exploring programming language alternatives on IBM i

From uniWIKI
Revision as of 13:23, 19 April 2017 by Norwinu (talk | contribs)
Jump to navigation Jump to search
Settled on Python as the modernization platform to move forward with. Specific discussion of Python on i is located  here

Overview

There is a shared interest in finding a modern and alternative programming language to RPG that can help facilitate future development endeavors. This page will discuss ideas related to this exploration.

I started this page on modernization a long time ago which touches on this topic briefly. But the discussion should be moved here as it addresses programming modernization specifically. -norwizzle (talk)

Possible programming language options

Python

Currently, Python appears to be a viable platform/language. The package (5733-OPS) is officially supported, and Python has proven itself to be a very powerful and widely used general-purpose programming language.

The following are questions specific to Python on IBM i:

  1. What does it look like to run Python code on the i. Is it as simple as doing a CALL PGM() or do you have to go through QSH and run it from there. Do the programs run under a certain subsystem or just the normal ones like QBATCH etc.?
  2. What are some of the conventions or best practices of having two runtimes (RPG and Python). Can we just assume IBM will be as good managing job queues, resource contention etc. for Python programs?
  3. Which version of Python is better invested in, 2.x or 3.x.
  4. Where is the source code contained? Is it like RPG where each program source is a member within the source file QRPGLESRC? Or is each source member its own object?
  5. Can Python interact/make calls to RPG or CL?
  6. What editor tools are available? RDi is out of the question, it can only do RPG/COBOL, EGL or Java. Python is an interpreted language, so does that mean we can just compile at any time?
  7. If we're using open source code, should we use git?
  8. Important: Python can output HTML as well (in which case you'd need FastCGI or some other mechanism to serve Python-generated web code), but we already have WebSmart. Should we decide to separate Python to back-end and Infonet to front-end? This is an important decision because it will establish boundaries for internal and external development. To elaborate:
  • You can have Python parse files, crunch data and output to tables, and then separately, have Infonet reading and modifying the data in these tables. Thus you would you be programming in Python and PML (WebSmart).
  • Alternatively, you can have a separate Apache CGI instance serving out Python generated code. The number-crunching as well as the front-end interface (web pages) development would be done ENTIRELY in Python.

PHP

  • PHP on i is a much older platform (i.e. had official IBM support a long time ago), but its use is still widely web-oriented. Unless we restrict our modernization scope to just the user interface and interacting with tables (and not batch-processing, or core business logic programming), PHP may not be appropriate.

Node.js

  • Node.js is a javascript runtime. Javascript is mostly used for front-end web programming (e.g. AJAX), but Node.js leverages javascript to do front-end and back-end programming. Of the biggest criticisms for javascript is its syntax.
I think if you were branching out from being a web programmer, Node.js would be a more natural path to do server-side programming, instead of learning another language. I don't know enough about it and have never programmed in it, but it's also an option in 5733-OPS, so we could try it out as well.