COBOL and Elixir

Someone has created a project to transpile (their word) COBOL to Elixir. I have some thoughts on this idea. But first, let's look at the example they provide.

A sample COBOL program:

      >>SOURCE FORMAT FREE
IDENTIFICATION DIVISION.
PROGRAM-ID. Test1.
AUTHOR. Mike Binns.
DATE-WRITTEN. July 25th 2021
DATA DIVISION.
WORKING-STORAGE SECTION.
01 Name     PIC X(4) VALUE "Mike".
PROCEDURE DIVISION.

DISPLAY "Hello " Name

STOP RUN.

This is "hello, world" in COBOL. Note that it is quite longer than equivalent programs in most languages. Also note that while long, it is still readable. Even a person who does not know COBOL can make some sense of it.

Now let's look at the same program, transpiled to Elixr:

defmodule ElixirFromCobol.Test1 do
  @moduledoc """
  author: Mike Binns
  date written: July 25th 2021
  """

  def main do
    try do
      do_main()
    catch
      :stop_run -> :stop_run
    end
  end 

  def do_main do
    # pic: XXXX
    var_Name = "Mike"
    pics = %{"Name" => {:str, "XXXX", 4}}
    IO.puts "Hello " <> var_Name
    throw :stop_run
  end
end

That is ... a lot of code. More than the code for the COBOL version! Some of that is due to the exception of "stop run" which in this small example seems to be excessive. Why wrap the core function inside a main() that simply exists to trap the exception? (There is a reason. More on that later.)

I'm unsure of the reason for this project. If it is a side project made on a whim, and used for the entertainment (or education) of the author, then it makes sense.

But I cannot see this as a serious project, for a couple of reasons.

First, the produced Elixir code is longer, and in my opinion less readable, than the original COBOL code. I may be biased here, as I am somewhat familiar with COBOL and not at all familiar with Elixir, so I can look at COBOL code and say "of course it does that" but when I look at Elixir code I can only guess and think "well, maybe it does that". Elixir seems to follow the syntax for modern scripting languages such as Python and Ruby, with some unusual operators.

Second, the generated Elixir code provides some constructs which are not used. This is, perhaps, an artifact of generated code. Code generators are good, up to a point. They tend to be non-thinking; they read input, apply some rules, and produce output. They don't see the bigger picture. In the example, the transpiler has produced code that contains the variable "pics" which contains information about the COBOL programs PICTURE clauses, but this "pics" variable is not used.

The "pics" variable hints at a larger problem, which is that the transpiled code is not running the equivalent program but is instead interpreting data to achieve the same output. The Elixir program is, in fact, a tuned interpreter for a specific COBOL program. As an interpreter, its performance will be less than that of a compiled program. Where COBOL can compile code to handle the PICTURE clauses, the Elixir code must look up the PICTURE clause at runtime, decode it, and then take action.

My final concern is the most significant. The Elixir programming language is not a good match for the COBOL language. Theoretically, any program written in a Turing-complete language can be re-written in a different Turing-complete language. That's a nice theory, but in practice converting from one language to another can be easy or can be difficult. Modern languages like Elixir have object-oriented and structured programming constructs. COBOL predates those constructs and has procedural code and global variables.

We can see the impedance mismatch in the Elixir code to catch the "stop run" exception. A COBOL program may contain "STOP RUN" anywhere in the code. The Elixir transpiler project has to build extra code to duplicate this capability. I'm not sure how the transpiler will handle global variables, but it will probably be a method that is equally tortured. Converting code from a non-structured language to a structured programming language is difficult at best and results in odd-looking code.

My point here is not to insult or to shout down the transpiler project. It will probably be an educational experience, teaching the author about Elixir and probably more about COBOL.

My first point is that programs are designed to match the programming language. Programs written in object-oriented languages have object-oriented designs. Programs written in functional languages have functional designs. Programs written in non-structured languages have... non-structured designs. The designs from one type of programming language do not translate readily to a programming language of a different type.

My second point is that we assume that modern languages are better than older languages. We assume that object-oriented languages like C++, C#, and Java are better than (non-OO) structured languages like Pascal and Fortran-77. Some of us assume that functional languages are better than object-oriented languages.

I'm not so sure about those assumptions. I think that object oriented languages are better at some tasks that mere structured languages, and older structured-only languages are better at other tasks. Object-oriented languages are useful for large systems; they let us organize code into classes and functions, and even larger constructs through inheritance and templates. Dynamic languages like Python and Ruby are good for some tasks but not others.

And I must conclude that even older, non-functional, non-dynamic, non-object-oriented, non-structured programming languages are good for some tasks.

One analogy of programming languages is that of a carpenter's toolbox: full of various tools for different purposes. COBOL, one of the oldest languages, might be considered the hammer, one of the oldest tools. Hammers do not have the ability of saws, drills, tape measures, or levels, but carpenters still use them, when the task is appropriate for a hammer.

Perhaps we can learn a thing or two from carpenters.

Amazon drops Chromecast and Apple TV

Amazon.com announced that it would stop selling Chromecast and Apple TV products, a move that has raised a few eyebrows. Some have talked about anti-trust actions.

I'm not surprised by Amazon.com's move, and I am surprised.

Perhaps an explanation is in order.

The old order saw Microsoft as the technology leader, setting the direction for the use of computers at home and in the office. That changed with Apple's introduction of the iPhone and later iPads and enhanced MacBooks. It also changed with Amazon.com's introduction of cloud computing services. Google's rise in search technologies and its introduction of Android phones and tablets also made part of the change.

The new order sees multiple technology companies and no clear leader. As each player moves to improve its position, it, from time to time, blocks other players from working with its technologies. Apple MacBooks don't run Windows applications, and Apple iPhones don't run Android apps. Android tablets don't run iOS apps. Movies purchased through Apple's iTunes won't play on Amazon.com Kindles (and you cannot even move them).

The big players are building walled gardens, locking in user data (documents, music, movies, etc.).

So it's no surprise that Amazon.com would look to block devices that don't serve its purposes, and in fact serve other walled gardens.

What's surprising to me is the clumsiness of Amazon.com's announcement. The move is a bold one, obvious in its purpose. Microsoft, Google, and Apple have been more subtle in their moves.

What's also surprising is Amazon.com's attitude. My reading of the press and blog entries is one of perceived arrogance.

Amazon.com is a successful company. They are well-respected for their sales platform (web site and inventory) and for their web services offerings. But they have little in the way of loyalty, especially in their sales side. Arrogance is something they cannot afford.

Come to think of it, their sales organization has taken a few hits of late, mostly with employee relations. This latest incident will do nothing to win them new friends -- or customers.

It may not cost them customers, at least in the short term. But it is a strategy that I would recommend they reconsider.

Overfishing your ecosystem

Vendors must execute their business carefully. Is the business providing a platform for others? A turn-key system? A multi-platform application? Doing one of these things well is difficult. Doing all of them well is much harder. It is easy to grow one sector at the expense of another.

Microsoft fell into this trap.

Early in its history, Microsoft was the provider of BASIC. The BASIC-80 interpreter was the best, and everyone considered it the standard. Computer manufacturers purchased the rights to put Microsoft's BASIC on their computers. Apple, Commodore, and even IBM.

With the introduction of the PC, Microsoft became not only a supplier of languages but a supplier of operating systems. Shortly thereafter, Microsoft offered application software: the first version of Word and a spreadsheet called Multiplan.

Microsoft was successful. Too successful, one might argue. MS-DOS become the dominant operating system, overpowering CP/M-86, the UCSD p-System, and even Microsoft's Xenix. When PC hardware was capable of supporting graphic environments, Microsoft introduced Windows and out-performed Atari GEM, Desqview, and even IBM's OS/2.

Microsoft's success was not limited to operating systems. The Windows versions of Word and Excel (the replacement for Multiplan) drove out the popular packages Wordstar, Wordperfect, Lotus 1-2-3, and Quattro Pro.

By the year 2000, Microsoft held dominance in a number of markets:

Operating systems The licensing arrangements with PC manufacturers ensured the dominance of PC-DOS and Windows. (The licenses demanded royalties for every PC shipped, with or without Windows.)

Networking software Microsoft bundled network software into Windows, destroying the market for add-on products like Novell Netware.

Office applications Microsoft had Word, Excel, and Powerpoint. Microsoft products stored files in proprietary, hard-to-decode formats. Their products were good at importing documents from other vendors but not so good at exporting them.

Later, Microsoft introduced Outlook for e-mail and scheduling.

Language compilers and IDEs Visual Studio was the dominant package. Competitors Borland and Symantec exited the business. Even smaller vendors such as Nu-mega and Rogue Wave left the field.

Microsoft's efforts did not end there.

Web browser Microsoft fought off the threat from Netscape and made Internet Explorer the dominant browser.

Database Microsoft introduced MS-Access as a low-end database (and purchased Foxpro) and later introduced SQL Server for the high end. (Competition at that level remains, with IBM's DB2 and Oracle's offerings.)

Project Management Microsoft introduced Project and took the market from Harvard Project Manager.

The problem for Microsoft, as I see it, is that Microsoft overfished their ecosystem. Their platform business was successful. Their application business was successful. But those successes came at the cost of the developers of large products. With Microsoft's ability to move into any market, few wanted to develop large applications or solutions. Why spend the time and effort when success will draw the attention of the big M?

I think that it is no coincidence that the new "big apps" of Facebook and Twitter took root in the web, away from Microsoft's empire of Windows.

I also think that the "overfishing of the Microsoft ecosystem" lead to the rise of Apple. I see several factors:

People were angry with Microsoft. They were tired of losing the battle. Not just vendors, but users. We users were tired of committing to a non-Microsoft product, implementing it, learning it, and adapting it to our business, only to find that Microsoft would roll out a competing product and take over the market (forcing us to change to the Microsoft product). Enough force migrations leads to resentment.

Microsoft become complacent. They became used to the idea of the Microsoft empire, and did not see a need to compete. Microsoft let Visual SourceSafe languish for years, and developed the successor product (TFS) only after a number of vendors started introducing new technologies and capturing market share.

Microsoft chose conservative, selfish visions of the future They enhanced products with features but not benefits for users. Windows Vista looked pretty, but offered little in the way of direct business benefits. The Microsoft Office "ribbon" interface provided questionable benefit at a high cost. New versions of Visual Studio offered modest improvements. The "advances" offered by Microsoft were designed to benefit Microsoft more than the customer.

Now, Microsoft has the challenge of re-vitalizing their ecosystem. Can they woo back developers (and companies) for the new Windows Store? After years of abuse, will people want to play in the Microsoft space?

Oddly enough, I think that the answer is "yes". I think that a lot of developers are wary of Apple and unsure of Google and Android. I think Microsoft can be successful with its new platform.

But they will have to play nicely with others.