Objective

One day in June 2020 I was encouraged to start a new POC. In simple terms, the idea was to read an XML file containing the processing specification for a z/OS tool, GenevaERS, and attempt to translate that into another language and file format. The target language was undefined; it might range from COBOL to Java to Scala to something else.

It was an interesting day for me, how a number of threads of things came together.

Where to Start?

I set an objective to get something on this done that day; and it wasn’t pressure filled. Even if I did not get something to work, and it was a complete failure, I would know what would not work. Edison is a great example of finding value in failure.

I have been using Intellij for a few years now and have some proficiency with Scala, but I knew it wasn’t quite the right language for what I was doing. It could do it, but there are probably better languages out there.

One that I had used years ago which was well suited to this sort of work was REXX; very good at parsing and text manipulations. Since I had some experience with that, I then started to try to move towards using that in some way.

What IDE to Use?

An IDE can help make these things go quicker, because at times they bring together a lot of the needed elements. A quick search of Intellij showed me there was nothing there for REXX.

I also have used Eclipse IDE with its Scala package. I knew Eclipse came with a wider set of languages and plug-ins, some of which are older languages and more connected to z development like REXX is.

So diving into Eclipse for a while, I got lost. The idea of perspectives took me a while to understanding (they are different products in Intellij), and that led to IBM Developer for z/OS or IDz which is even more z/OS centric for development and had more references to REXX.

When I installed it, I chose too many components to install.  There are a lot of components that seem like they will be useful at some time, but then those things automatically install other things that I didn’t want.  For example, I installed some CICS components (not all but some) when I was quite sure I’m not going to do anything with CICS.

All of these things started to make me feel like my the Eclipse environment had become a bit unstable.  I started getting error message when it loaded like, “Exception occurred while creating new instance of component Component[name = org.eclipse.epp.mpc.core.transport.http….” I had no idea how to start to fix that, or even desire to try.

Even after doing all of that, I couldn’t find something that easily allowed local development of REXX.  I was working from the java developer mindset of local development and then deploy to the execution environment if that needed to be on z.  I found in the end one can do the local execution of REXX (even on a Mac which sometimes is a challenge), but IDz as a development tool is not really meant for that paradigm.  

I decided I would have been faster to go to ISPF on z and type the program into it in edit mode than doing all of the above. It might have been the easiest. Sure, I could write and execute REXX on z, but that wasn’t the type of development environment I thought would solve this problem.

Rethinking the Language

I realized through all this work that REXX is getting fairly old, and all (that I could find) the Eclipse plug-ins supporting it were 10 years old and not working any longer. Although REXX is all over the IDz documentation, none of it is about writing REXX; rather it’s about using it perhaps to automate development in some way. I never did find something that gave syntax checking of it.

And then I discovered that a better answer than REXX is Python.  In a sense it seems Python has perhaps been influenced by REXX (or other similar languages) and can do the parsing of XML with built in functions without having to code it all myself.

And the Python add in on Intellij is robust.  

So in the end, I landed back at Intellij for prototyping this little thing, and decided on Python, a successor to REXX.

The Day’s Results

The next morning,  Sandy Peresie connected with me, saying she wanted to learn Python. #ThePowerofOpenSource was very clear in that moment. Her desire along with my fail fast investigation resulted in starting to make progress on the work. The results of her work can be found on the GenevaERS.org site.

However, the larger connection for me was when I realized this whole process might look very different in the future.

RosettaCode.org

The day of my prototyping I discovered RosettaCode.org. 

In short, a guy found a listing of “hello world” programs in various languages, and decided that program didn’t teach one too much about the various languages.  So he started the site which puts out a problem, and then people write a solution in whatever programming language they know.  The list of languages used on the one sample XML problem I looked at was very impressive. 

I stumbled into this when looking for REXX and XML parsing; one of the sample programs was written in REXX.

I had strong feelings in the evening that there is something interesting about the concept of this website; It teaches that in fact the language used for some computing problem is really not all that important; or perhaps that ‘soverstating it – is perhaps not critical to a very large set of computing problems to be solved.  The things the language influences is:

  • The resources that can work on the problem; people only know a limited set of languages, and specialize in even fewer.
  • The length and complexity of the resulting code, as languages have different strengths and weaknesses, even if they can ultimately produce a particular output
  • The platform used.  Not all languages work on all computer systems.

The site shows that someday our use of computer languages might be very different. Like the premise of the Rosetta Stone which allowed translation between a number of ancient languages, is it possible that at some point one could write a program in one language, but the function of that program to produce that output from that input might be presented to someone else in a language they know, not the one the function was originally written in.

During my years of international travel, I saw Google Translate transform from something that was not very useful to being in the middle of many conversations.

At some point, it is possible that choosing a language won’t be that important, as through a similar type of mechanism, whatever we specify will be translated into whatever processing language is needed to deliver it.

Insights

So what did I learn from this day? Here are a few points for me:

  • Failure, particularly when fast, is very useful in getting us on the right path
  • Speed in failure comes from not being afraid of failure; if failure is punished, then it will be avoided, and learning will be delayed–perhaps until it is too late
  • I gained a broad overview of tooling in the mainframe development space, but touching on more modern languages and data structures (like XML)
  • But the implications of the Rosetta Code site are the most powerful. In that I gained a principle, and understanding principles helps guide us to greater efficiencies in future learning and abilities, particularly when we can use them to predict the future.

Fail fast was very helpful for me to learn a lot in one single day.