PHP – What Really Sucks About It?

PHP sucks. That’s something I think a lot of programmers will agree on, even PHP programmers. For example, Jeff Atwood offers an interesting viewpoint in his blog entry The PHP Singularity. But heck, a lot of programming languages suck. And even though they suck, there are many millions of KLOC written in languages like COBOL, PL/I, and RPG.

Programming languages, like human languages, evolve. PHP started life as a web templating system, and evolved into a general-purpose programming language. During subsequent releases, new features have been added and some cruft deprecated. Other languages, like Perl and RPG have over the decades undergone similar transformations away from their original purposes.

Why is PHP so maligned? Perhaps because many of us have had to deal with PHP code written 10-15 years ago when the language lacked many of the nice features added in recent releases. Or PHP code written by programmers who knew better than the previous programmers on the project.  Or PHP code written by programmers without extensive programming experience. 10-15 years ago, programmers who knew the risks associated with web programming typically chose other languages if they could.

When I started doing PHP programming, I started with PHP 5 and CakePHP. With Cake, you can’t help but structure your application using a more or less proper MVC design. It’s probably too much trouble not to. And so I know from personal experience that it is indeed possible to write relatively clean code using PHP. Unfortunately, we don’t all have the luxury of working with clean PHP code.

What kind of programming shop typically uses PHP? I would guess the typical PHP shop evolved as follows: The shop started out small, perhaps as a one-person company. As the business grew, the demands on the custom PHP application grew as well. Other programmers were brought in, each with their own programming styles. Perhaps one of them was assigned the task of managing the others. But without any significant management experience, eventually the programming staff gets to the point of running from crisis to crisis as the code base gets harder and harder to maintain. Does that sound like your PHP experience? It’s a sure-fire recipe for job stress and significant staff turnover.

Based on my own experience, the next time I’m interviewed for a programming position, PHP or otherwise, I would come armed with a bunch of questions, including:

  1. Can I see your documents describing your development process?
  2. Can I see proof that the documented development process is followed?
  3. Would I be reporting to a manager with specific management experience?

To be fair, it’s possible to write bad code in any language. But if a programming shop wants to grow beyond a small business, it needs to adopt a different mindset. It needs professional management experience. It needs proper coding standards and processes. It needs programmers who know what it means to work as a team. It needs a staff that understands the importance of egoless programming. Can those things be found in the typical PHP shop?

Cheers! Hans

Is RPG Dead? The Wake

In a previous post called Is RPG Dead? The Autopsy, I suggested I’d probably have more to say on the subject. This offering is in response to Scott Klement’s editorial, RPG is Dead? Are You Serious?! I’d like to respond to a couple of points he makes.

First, he brings up the fact that people have been debating RPG’s death for the past 20 years, and yet RPG is still around. But why bring up the question at all if there was any doubt as to RPG’s future? Does anyone ask if Python is dead? Or PHP? Of course not! No one has to.

Next, he raises the point that most application development on IBM i is done in RPG. No one is denying that. However, no one can deny that IBM i is a platform in decline. The numbers just don’t lie. The fortunes of RPG are intimately tied to the fortunes of the platform. As IBM i slowly dies, so does RPG. (I said more on this theme in my blog posting Is RPG Dead? Do We Still Have To Ask?.)

Skipping past some history, Scott talks about what’s important to programming business logic. Let’s look at each in turn:

Business logic uses numbers heavily. Well, this is not unique to business applications. However, most arithmetic in any business application, like in any other domain, is integer arithmetic. Business logic does make use of decimal numbers, but even there, most operations involving decimal numbers are simply the movement of data. Actual decimal arithmetic is a small part of the logic, and in most business apps, could be implemented fully in SQL code. That said, other languages do have support for decimal arithmetic. Scott mentions Java for one. Python is another. Even PHP has support for decimals.

Business logic uses databases heavily. Business applications don’t have a monopoly on using databases. Many different domains, from gaming to on-line social networking to statistical analysis make at least moderate use of databases. And so you can find support for databases in practically every programming language out there. RPG gives you two choices: built-in I/O operations and pre-processed SQL. Other languages often provide higher-level access to databases. For example, in CakePHP, you define your high-level relationships (1-1, n-1, 1-n, n-n) between your tables, and one find() operation can bring in all related data for a transaction. That is, the framework figures out the SQL for you, including joins. Among the available RPG frameworks, which one can provide that level of power?

Business logic uses dates frequently. And so do many other types of programs. And so you can find date support in practically all modern programming languages. RPG is certainly not unique. Python has the datetime class. PHP has an extensive list of date/time functions and classes.

Business logic uses a lot of string manipulation. I disagree with that assertion since strings are most commonly needed in the presentation layer of an application. But let’s assume it’s true for business logic. Again, what modern programming language lacks support for strings? Languages like Python, Perl, and PHP (to name a few) all have very powerful string support. Much more powerful than RPG’s support. In those other languages, strings are all objects, with a rich set of methods. RPG, in comparison, has a rather limited choice of string operations. Consider the ease of doing regular expression matching in Perl, Python, and PHP. And compare that to what you need to do in RPG.

If these four categories define what’s important in programming business logic, there are clearly languages other than RPG that have a definite advantage. Whenever I see someone claim that RPG is the best language for business logic, I always interpret that to mean that the author simply knows RPG best. And Scott certainly is an expert on RPG.

Finally, Scott makes the point that RPG is still being enhanced and supported. True. However, other languages have long ago surpassed RPG in terms of features and capabilities. In my previous missive, I listed half a dozen features common to other programming languages that are still lacking in RPG. And I could have listed more. And other languages continue to grow and gain in popularity.

RPG will not disappear overnight. To say that RPG is dead is an exaggeration. However, it is becoming increasingly irrelevant in the I.T. world. I’m reminded of a job interview I had back in 2008 where the interviewer looked at my resume and asked: “What’s an iSeries?”. (RPG wasn’t discussed at all in that interview.)

Cheers! Hans

Is RPG Dead? The Autopsy

In a previous post, I promised to say more on the subject of RPG’s death. But I’m finding it tougher than I expected. Don’t misunderstand me, it’s not for lack of content. It’s just that I worked with RPG for a long time. I don’t want to see RPG go away. Writing this blog posting feels like I’m kicking an old friend while he’s down on the ground. On the other hand, it’s just a programming language. And the facts need to be understood.

When I first learned RPG III, 31 years ago, I was impressed by a couple of things. First, I was impressed with the externally-described file. As far as I knew, no other language had such a powerful feature. Second, I was impressed with the syntax-checking source editor. At my university, some professors were just beginning to think about something like that.

But other aspects of RPG III were definitely goofy, such as the fixed-form syntax and the indicators. Fortunately, the language has grown since then. Indicators can be largely avoided, and calculations can be coded in a free-form syntax. However, although RPG has progressed, other languages have progressed faster, and new languages have cropped up with even more powerful features. More and more, RPG looks like an anachronism, rather than a modern programming language.

I’ll list some features that are commonplace in other, modern programming languages that RPG still lacks:

1) Namespaces. That is, what happens when you want to import two libraries with the same name? In languages like Java and Python, imports can be put into a directory hierarchy. And if there are conflicts, things can be renamed.

2) User-defined data types. Sorry, data structures and LIKEREC just don’t cut it.

3) Object-oriented programming. What language doesn’t have OO support these days? It’s something we now take for granted elsewhere.

4) Extensive list of built-in functions or classes. Just compare what RPG has to the Python Standard Library or PHP’s Function Reference. No comparison.

5) Frameworks. Most modern programming languages have a goodly selection of frameworks that simplify programming web applications. These frameworks have various levels of functionality, however, typically they take care of a lot of nitty-gritty details. Using a framework, you should never see a query string, or XML, or JSON, or SQL.

6) Operating system independence. Programs written in languages like Java, Python, and PHP can easily be ported across different operating systems.

Some would argue that RPG could be further enhanced to address these short-comings. But why bother when there are already other languages that have these features? The planners at IBM certainly know what’s lacking in RPG, and they still seem to have the resources to make the occasional enhancement. But over the past decade, there seems to have been little effort to address these specific short-comings. Looking at the situation from that perspective, one could argue that IBM itself also sees no future for RPG.

So far, I’ve written about 500 words, and yet there’s still more to be said. Stay tuned.

(Update: Next installment: Is RPG Dead? The Wake)

Cheers! Hans

Is RPG Dead? Do We Still Have To Ask?

Guess what, folks? It’s that time of year again when people debate the future of RPG. Is RPG dead? Think about it: Does anyone ever ask that question about any other programming language? Why do some people still insist that RPG does have a future?

To start with, let me make one assertion: Of all participants in this debate, I’m one of the very few who is both knowledgeable about RPG and who does not have a financial stake either way. Some commentators make their living by moving people off of IBM i. Others make a living doing RPG programming or training others. If anything, I don’t relish the idea of RPG disappearing because of my long involvement with RPG development.

RPG is very much unlike practically all other programming languages in use for application development. It is one of the few programming languages that is available on only one operating system. That’s right! If you want to do RPG programming, you need a system with the IBM i operating system. And IBM i is one of the last of the traditional proprietary operating systems.

What do I mean by that? Look back at the history of computers: In the 1950’s and 1960’s, there were a lot of computer companies, colloquially called “IBM and the Seven Dwarfs”. After a couple of mergers, they became “IBM and the BUNCH” (Burroughs, Univac, NCR, Control Data Corporation, and Honeywell). Each one had their own mainframe computer products. And each computer ran its own proprietary operating system, each incompatible with all the others. Over time, almost all of these proprietary operating systems have disappeared. Today, there are just two left: z/OS and IBM i.

Today, most computers run either Windows, or some variant of Unix or Linux. Even the machines that run the O/S relics z/OS and IBM i now also run Linux, with significant cost savings over the dinosaurs.

So here’s the current situation: The fact is that the main reason for running IBM i is to run RPG applications. And to be fair, a lot of them are still running. Without RPG, there’s no reason to choose IBM i. And without IBM i, there’s no way to run RPG apps.

Is there a future for IBM i? When I was looking for work back in 2007, one headhunter specifically told me that the bottom had fallen out of the i job market. Indeed, over the course of about 8 months, I saw only three listings for iSeries jobs in the greater Toronto area. If there are so few IBM i job openings in the 8th largest metropolitan area in North America, what hope is there for IBM i programmers elsewhere?

Frankly, in this day and age, if you want to develop a new application, it just doesn’t make any sense at all to limit yourself to one particular operating system. Especially one that is clearly in decline. Other languages like C, C++, PHP, and Python can run on practically any operating system. If you want to protect the value of your software development investment, clearly, any of these other languages is the way to go.

I have more to say about RPG, but I’ll save that for another blog post. Stay tuned!

Cheers! Hans

OS/2 – 25 Years Later

I almost missed an anniversary. Last month was the 25th anniversary of OS/2. I suppose that’s understandable. After all, who cares about OS/2 anymore?

Well, I still remember OS/2. I used it on my home computer up until June 1998. By then, the writing had been on the wall for years. But rather than turn to Windows, I put Linux on my home computer. My first reaction after booting up Red Hat 5.2 for the first time was: What the heck am I getting myself into? However, KDE version 1 was released just three weeks later, and that made Linux much easier to use. Not as easy as OS/2, but still acceptable. And unlike OS/2, interest in Linux was increasing.

At IBM, I worked with someone who was at the meeting where Microsoft effectively told IBM that their OS/2 partnership was over. And I still remember his description of the meeting. Both sides presented their status. After Microsoft presented their status, the IBM’ers present slowly began to understand the implications of Microsoft’s position. Meanwhile, on the other side of the room, the Microsoft employees were smiling giddily, knowing full well that they were shafting their loyal partner.

After the “divorce”, Microsoft did everything in their power to stop OS/2 from gaining any traction. But OS/2’s failure in the market wasn’t entirely Microsoft’s fault. IBM’s sales division didn’t know how to sell it. And later on, Windows was adopted as the standard workstation for all IBM employees. Clearly, the OS/2 supporters within IBM were a small, albeit dedicated, minority.

There were broader implications. At the time, I was working on the AS/400. Penetration of OS/2 within AS/400 shops was practically zero. Microsoft had pretty much 100% of the desktops within that market. And yet, few people listened to the warnings that the desktop was a beachhead for Microsoft’s incursion into the SMB market. And over time, as many of us predicted, Windows became more and more prevalent in that market, displacing AS/400 installations (and later, iSeries). And now, interest in IBM i is way down. Perhaps the only thing keeping IBM i alive now is the fanatical devotion of it’s remaining users.

What would have happened if Microsoft didn’t go their own way? Would we all be using some form of OS/2 today?

Cheers! Hans

Adventures in desktop Linux

I’ve been using Linux now for about 14 years. Previously, I was using OS/2. So when I tell people “I don’t do Windows”, it’s a legitimate statement. Linux has matured a lot during the past 14 years, however, it is still often an adventure best suited to the tech-savvy.

Take last week: I booted up my Linux box only to see a frowning face and the message: “Oh no! Something has gone wrong. A problem has occurred and the system can’t recover. Please contact a system administrator.” System administrator? In this house, that’s me! I could boot into a failsafe session, but with a degraded video mode. Well, I’m no X11 configuration geek. Heck, I skipped openSUSE 11.4 since I did’t want to dive into video driver configuration. So I reinstalled openSUSE 12.1.

The reinstall went fine. The openSUSE 12.1 installer is perhaps the best one yet! And things were working well even after loading all the patches. But after loading the nVidia driver, I saw that frowny face again. After yet another reinstall, I noticed that the default video driver, nouveau, looked pretty good, albeit with one or two rough edges. I reported the problem to nVidia, but I’m not sure if it’s worth the trouble trying the nVidia driver once a fixed version is available.

Another issue I have is with desktop manager. The two primary desktops are Gnome and KDE. For years, I used KDE. I still remember installing version 1 of KDE back in July 1998, and appreciating how easy it made Linux. But, like many others, I didn’t like KDE 4, and moved to Gnome. KDE 4 has matured since then, and Gnome is now on version 3, and I sometimes wonder if I should move back to KDE. I liked Gnome 2. I was able to configure it easily, and it worked well. But Gnome 3 is harder to configure. It just doesn’t have all the configuration options that KDE has. For example, after installing Komodo Edit, I could have set things up by manually editing a bunch of files. But instead, I started a KDE session and used its GUI tools to set up the necessary file associations.

But it isn’t always a troublesome experience. I started using Shotwell to manage my photos. Today, I discovered that Shotwell has the ability to post photos directly to my Google+ photo album. The only trick is that you have to choose “Picasa Web Albums” as the target.

Several years ago, it was common for people to ask: Is Linux ready for the desktop? I haven’t seen that question lately. Perhaps people have given up on the question. After all, Linux isn’t much easier now than it was five years ago. Or perhaps in the age of web-connected phones and tablet devices, the question is just no longer relevant.

Cheers! Hans

I’m Shopping For A New Ukulele!

A while ago, we decided to move from Toronto to Kingston. We sold our house in Toronto, bought a house in Kingston, and planned and implemented the move. The last step in the process was for me to find a job in Kingston. We knew that wasn’t going to be easy. Kingston is a much smaller place, with less demand for programmers. As motivation, I decided that one of the things I would buy with my first paycheck would be a new ukulele. Well, I can now shop for that ukulele! I start my new job on Monday!

How did I get to this point? My “sabbatical” started getting a bit too long. So back in the Fall, I went to the KEYS Job Centre for advice. To start with, my councilor gave me some great advice on resume writing. She also recommended the MCF Kingston Practice Firm. What’s a practice firm? It operates very much like a real company, allowing participants to gain real work experience, albeit without a salary. But in addition, participants are expected to spend time searching for jobs and learning the skills needed to look for work. I decided to give it a try.

I decided to concentrate on developing skills in PHP, since that’s used by some local firms. I was assigned the task of developing a new software system for the local Operation Red-Nose organization to replace an old DOS-based application. I visited their operation on New Years Eve, and for what they were doing with that ancient program, they could just as easily be doing everything on paper.

To cut a longish story short, what I had implemented in five weeks using PHP and CakePHP, I had originally expected to spend most of my 12 week stint at MCF working on. Within weeks, I was able to confidently add PHP to my resume. I had expected to be at MCF longer. But an opportunity arose, I sent off my resume and cover letter, and I went for an interview and testing. I accepted an offer, and finished my stay at MCF after just those five weeks. Granted, there’s still more work left to do on the ORN project. But I expect to finish that in my spare time.

What have I learned from this? First, that CakePHP is a great way to implement a web-based application. Some point out that it has a harder learning curve than other PHP frameworks. And sure, you need to understand why the framework insists on doing things a certain way. But having strong conventions is not a bad thing. In all, I think CakePHP was a good choice for that project.

Second, it helped me convince myself that the things I wrote in my resume were true. I can learn new skills. I got the skills. I know what I’m doing. I demonstrated that nicely with the ORN project. Sometimes it seems we can forget what we’re capable of, and lose confidence in ourselves. Especially when between jobs.

In my previous job, I used Zope and Plone, but without ever really reaching the point of fully mastering those frameworks. I took that job because it offered me the chance to use my favorite programming language, Python. But while I still love that language, I would never recommend using Zope. We just could never get the Zope-based project to where we needed to be, partly due to the complexity of the framework, and also due to some nasty intermittent bugs. These were the kinds of bugs that you could never really be sure you fixed. And no one should have to depend on that kind of system.

(Fortunately, the Zope-based project was shelved. Unfortunately, development moved on to an ambitious .net based system, which is not really a good place to be for a Linux/Unix geek. Frankly, I was glad that moving to another city offered me a good excuse to quit that job.)

But now my new job beckons, and I’m really looking forward to it. From what I’ve seen so far, it seems like a really great place to work, and I know I can make a difference there. And soon, I expect to add a new ukulele to my modest collection. A banjo-ukulele perhaps?

Later, dudes!

Should Everything Run on IBM i?

re Shouldn’t Everything Run on IBM i?

To start with, I’m reminded of a couple of things told to me when I was job-hunting four years ago. First, a head-hunter told me that, at the time, the bottom had fallen out of the iSeries job market. Second, at a job interview, I was asked: “What’s an iSeries?”

In the referenced blog, Aaron mentions that the IBM i has just seen 4 quarters of growth. That’s good to see. I worked for 22 years on the iSeries and its predecessors, AS/400 and S/38. And I really don’t want to see my good work go to waste.

But in his blog, Aaron suggests that everything should run on IBM i. The i is indeed a fine machine to store your mission critical data. You really can’t go wrong choosing IBM i for your database. But I disagree that it should be used to run everything. (Those who like the i, tend to like it a lot, which says a lot about the system. The only people more devoted to their computers seem to be Apple fans.)

First, Aaron brings up the common strawman argument that the choice is between IBM i and Windows. Clearly, there are more choices out there, especially in the Linux, Unix, and BSD realms. For example, for the top tier in a web site, you can’t go wrong with OpenBSD running on a couple of inexpensive Intel servers. You can easily configure OpenBSD to offer 100% availability, for at least your static pages, with rock-solid security.

But let’s look at the application tier. Many shops choose an IBM i solution for one simple reason: The application they need only runs on i. If the application is implemented in RPG, then it’s basically limited to the i. What if you need to develop your own custom application? Is RPG the best choice? Frankly, no. Thirty years ago, when I started working on the RPG III compiler, it was already an oddity among programming languages. It has advanced quite a bit since then, and I’m proud of my own contributions to its evolution. But it has not kept pace.

Is there an ideal choice of programming language? Again, no. Actually, I think that’s the wrong question to ask. Today, when choosing a programming language for a particular project, you don’t look at the characteristics of the programming language. If the attributes of the language were a primary consideration, Python should be the most popular programming language on the planet (in my opinion). Today, one does not program using just a programming language. Today, you use a programming language and a framework.

Consider PHP. By itself, it’s a rather ugly programming language. But it’s popular because of the rich frameworks implemented using PHP. In the i community, Zend is commonly used. Elsewhere, frameworks like CakePHP and CodeIgniter are popular. Other programming languages have their own rich frameworks: GWT, .net, TurboGears, Ruby on Rails, to name just a few. Lately, I’ve been implementing a web-based application using CakePHP, and I can attest to its convenience and power. But, as far as I know, the RPG community has nothing like these frameworks. IBM i does support a number of modern tools and languages. But then, unlike RPG, those tools are not limited to IBM i.

That is, when using an interpreted language like PHP, you have something that a language like RPG can never have: platform independence. For my own modest CakePHP application, I can run it on Windows and I can run it on Linux. I’ll bet that it could also run on IBM i! In other words, by using many of these rich frameworks, you can run on many different operating systems, and so, you can render the choice of operating system platform irrelevant. To get back to the original question, should or shouldn’t everything run on IBM i? I say this: It doesn’t matter. And hasn’t mattered for a long time.

Hans