In September, net.digest traveled to the heart of BSEPA, Philadelphia, for HPWorld 2000. As usually happens, it was a week of manic depression for me full of both highs and lows.

In her taped remarks prior to Ann Livermore's keynote, Carly Fiorino, Grand High Exalted Ruler of Hewlett-Packard, had some very nice remarks about MPE and the HP e3000. Of course she has had numerous occasions to mention the HP e3000 and MPE/iX since, but appears to have reverted to form. There she was, two days into HPWorld, espousing the same old "HP-UX, NT and Linux" mantra at the Super Dome introduction in, not Philadelphia, but New York. I stood on the show floor at the HP booth watching this presentation on one of the many large screens set up for the purpose. There was an audible groan when she dealt out this line. A week later during her talk on HP's " Always-On Internet Infrastructure" vision at NETWORLD + INTEROP in Atlanta, it was the same thing, "therefore NT, HP-UX and Linux all receive mission-critical levels of support". I will say it again. It costs nothing but two seconds time to add MPE/iX to any recitation of strategic operating systems. Would it be so bad if an analyst or member of the press asked, "What's this MPE/iX"? Think free marketing opportunity. This is constructive criticism, by the way, not whining (more on that later).

Ann Livermore followed Carly Fiorino at HPWorld 2000 with her keynote address and did just fine in her mentions of MPE until she ad libbed a little and, in my opinion, stubbed her toe. In fairness, I need to admit that of the people I talked to afterwards, there was an even division about whether her comments were positive or negative. I guess I'm just a sensitive kind of guy. At least that's what I keep trying to tell my long-suffering spouse. OK, this is probably whining.

Speaking of which, I’m going to give Donna Garverick, of Long’s Drugs, credit for bringing up the topic of whining, how it is counterproductive and a waste of energy. Others may have said similar things on HP3000-L, but Donna, as Chair of SIGSYSMAN made this a part of the SIG’s agenda. She led the group on a discussion of positive steps we can take to channel our energy productively to help ensure the continued success and viability of the HP e3000. Duane Percox of QSS has also written to HP3000-L about ways to partner with CSY.

This month's topics come from threads either directly or indirectly started by something that occurred at HPWorld.

Ted Ashton, in the last of several excellent commentaries on HPWorld 2000 that he posted to HP3000-L, said this about the 3000 Roundtable:

"They got asked about WSJ [Wall Street Journal] advertising. A good laugh was had when Christine from Marketing asked, 'do you know how much a WSJ ad costs?' The upshot was that CSY does not feel the return from an 'awareness' campaign is very much compared to the return from campaigns aimed at actually getting boxes into businesses. Christine said that new businesses are bringing up 3000s every month. If only we could know about it! The big push is vertical markets and evidently that's being pretty successful. I think that 3K survival may well depend on its ceasing to be sold as other OSes are, by name, but rather as the core of solutions. Neil Harvey, could you give us a quick summary how you succeeded in no longer having to defend the platform?"

[Neil Harvey, of Neil Harvey Associates, South Africa had commented earlier that his company had gotten away from trying to defend the 3000 platform and instead was concentrating on selling solutions, not the OS.]

To which Neil replied (I'm quoting him in full because this is a great example of how an ISV can approach "selling" the HPe3000).

"We used to spend 45 minutes of the one hour sales cycle defending the platform against misguided IT bigotry.

"We moved to an ASP (application service provider) model. We sell our software, as always, and bundle in the hardware and support required to make it run.

"We have two basic flavours:

Application Software and Software support

Above plus Hardware, Operating system and Support

"Our model 2 includes the provision and maintenance of ALL the hardware and software required to run our solution successfully - i.e. from Desktops through to Servers (MPE/iX and NT), all network stuff etc.

"Our software is Health Care Administration software, and our customers measure their efficiency and size on a per insured family and dependant basis, so we charge accordingly - a per member per month fee.

"This focuses us on growing the client's capacity to increase membership, while reducing the IT required to achieve and sustain this growth.

"The HPe3000 and MPE/iX are perfectly suited to this model. And, since (under model 2) we provide ALL IT required we have full control over the network, desktop and NT platforms (HP Vectras and Netservers, usually), we have a great deal of control over the overall efficiency of the platforms, and so availability of our application software."

Ted and Neil are of course correct. Solutions will sell future HP e3000s. This is where CSY and we need to work to support existing solution providers and help nurture new solution providers.

In a similar vein, from Duane Percox:

"I think our energy and dollars can be more wisely spent developing new systems and solutions for our favorite platform. Let CSY fight the battle internal at HP for mind share.

"Oh yeah, one last thing, continue to write good systems that your customers want so they will continue to buy/upgrade to new HP e3000 boxes as they become available."

This last from Duane applies equally for those developing/maintaining in-house written systems. Remember that you have to compete with management by magazine now. You have to continually market internally to your own organization.

An unintentional modern version of the old time language wars was started when Joe Geiser, who presented a day long seminar on "Building Web Sites and Applications Using Your HP e3000" at HPWorld 2000 was quoted on HP3000-L as saying: "Cold Fusion is the way to go for webifying your applications. Although the same work can be done with Apache/iX and CGI scripts it was stated the what takes 6 to 9 months in Apache/iX and CGI, takes only 2 to 3 weeks in Cold Fusion." Whether the quote was accurate or not is unimportant. What is important is the thread it generated (here extensively edited, with apologies to all the authors, for length and readability:

Cortlandt Wilson:

I think a far more relevant comparison would be the time difference between Java Server Pages on Apache/iX and Cold Fusion. Any word on those numbers?

Michael L Gueterman:

I'm not about to say that CF is the 'be all - end all' language. It is not. I am one of its biggest proponents in the e3000 realm though, so my view is a tiny bit biased. I think trying to compare development times between JSP/CF/ASP/etc. is silly and not really useful to anyone honestly trying to decide what the appropriate technology is for a particular application. That said, developing a web-based application with CF is probably quicker than a similar application in many other languages (2-3 weeks versus 6-9 months though seems too optimistic). That still doesn't make it the 'right choice' for every web-based application though (ex. If you need to have a totally e3000 platform solution, then CF doesn't fit the bill whereas JSP can). I've chosen CF for several web projects, and have been very happy with the results.

[Editor’s note: JSP = Java Server Pages; CF = Cold Fusion; ASP = Microsoft's Active Server Pages]

Here are the pros and cons for CF.

Pros:

Simple. CF is a "tag" based language that is very similar in appearance to HTML. People that know HTML can quickly pick it up and become proficient in a short amount of time.

Powerful. The CF tags and functions that make up the language allow for a wide variety of applications to be developed.

Extensible. If the base language doesn't offer what you need, you can use COM/DCOM objects that may already be available elsewhere, or write your own in C++ or Java. These are called 'CF Custom Tags' and allow CF to take advantage of the functionality that may have been developed for other application server products (such as ASP).

Scalable. If you need more power than a single box can offer, you can use the Enterprise version, which includes the ClusterCats technology to add additional servers into a cluster for horizontal growth. This allows you to build very large/redundant environments if necessary.

Cons:

CF does not natively run on the e3000.

CF can not (easily) interface with an existing host-based application. In other words, the existing business logic that may be present in the host-based application would need to be replicated into the CF code. For "new" applications, this is not an issue, but if your going to take an existing host-based application to the web (existing rules/logic and all), then this may be a problem.

I've personally chosen CF as my "web application" language of choice, but there may be times when I would choose something else. For example, if the customer already has experience with another technology and it can perform the functions they require, there would have to be a very strong reason to move that particular application to CF instead of what they already have).

So, I can't give you a single comparison that you can use to make a decision as to which technology is best for a given purpose. CF is but one of many and happens to be what I prefer.

Shawn Gordon:

Let me take a moment to cloud the issue even further. PHP totally rocks, and Mark Bixby has ported it to the 3000. It works with apache, runs almost everywhere and has great database connectivity built into it. While there isn't a plug-in for Image, it probably wouldn't be a big deal for someone to write. http://www.php.net/

That said, I'm becoming a huge fan of Python these days, and my company is even working on some IDE's for visual Python development (multi-platform). While PHP is more tag based, like Cold Fusion, Python would be a full server side scripting language.

Peter Osborne:

Agreed, I'm hooked on PHP. I'm currently investigating the best way for more direct Image access then calling CGI's through PHP. It is very powerful and runs completely on the e3000 so stability is not an issue. The documentation from php.net is incredible. You do not need to buy anything to get into PHP. Because PHP actually runs as a module under Apache, there is no start time overhead to call it either (same idea as mod_jserv & mod_perl).

Shawn Gordon:

As a quick example, my web master used PHP to create our web site (he is a contractor), I had never seen it before. We need to add a registration system that we could access over tcp/ip and write the data into a MySQL database. one of my programmers, without ever having seen PHP was able to build PHP scripts on the server that reacted to the messages we were sending and populated the database in 3 days. We have since created pages in our system that allow us to easily add support, news, and press on a page and have them post automatically to the site with PHP and MySQL. He is in Italy and english is a second language for him, and he still learned it all from the docs on the PHP site.

Cortlandt Wilson:

Thanks for the list of CF advantages. JSP is also a "tag based" language. I think CF has a number of pre-defined functions/classes that are very useful. In Java you have to buy, borrow, or write your own.

However, I propose for your consideration and feedback that Java makes much more sense today than it did just two year ago.

Reading up on Java I am struck by the different tone in technical magazine articles and books between those published in say 1997-1998 and this year. Reading and talking to three web developers indicates to me that what was true for Java just two years ago is much less true today. Two web developers told me that they wouldn't use Java but on closer questioning revealed that their reasons had more to do with the weight of "legacy" code they had in other languages (Python, JScript, etc). Has any one else noticed this trend?

One advantage to Java, in my opinion, over these other languages is its generality. It can be used for a number of tasks including server side programming, client side programming, and general applications. So instead of having to learn several languages, a programmer need only be proficient in one -- Java. Borland's very popular JBuilder environment for instance is now written in Java.

Java is also object oriented and is considered a well designed language.

Problems for Java:

Speed.

The powerful tools like JSP, Enterprize Java, etc are fairly new and tools are only beginning to penetrate the market place.

Glenn Cole:

I'm not entirely convinced that Java has this (generality) where others do not. Personally, I've become a huge fan of Perl, though I make no claim to being an expert Perl programmer (whatever that is). Perl even allows a platform-independent GUI (through Perl/Tk), though I've not tried this.

Interestingly, part of Perl's power is what I heard described for Java a couple years ago: the readily-available modules which perform a specific task (like Base64 encoding).

Others find Python best suited for rapid prototyping. I've not spent much time with this, but I know that Bruce Eckel (author of Thinking In Java) is a strong proponent of this. I know also that he is not particularly fond of Perl (though I've forgotten why).

Bottom line, some "modern" language, be it Perl, Python, Java, or ?, seems imperative for programmer productivity today. But personally I'm not convinced there ever will be just one language that's "good enough" to know, with disregard for all others.

Mark Wilkinson:

One open-source product that deserves a mention in this discussion is PHP. I've just developed a site for a client using PHP (front-end), Perl (batch stuff) on Linux/Apache with MySQL. It was a joy to work with, is packed with features and extensions and is easy to learn for someone with a Perl background. It has classes (OO), support for most major RDBMS, is commercially robust and seems to be extremely fast (well version 4 anyway).

For those interested, see http://www.php.net

Cortlandt Wilson:

By "generality" I was thinking in part of the very wide support of Java applets by web browsers. A single language, Java, can be used to program both the web client and the server.

Also, class or function libraries for various interfaces and foundational architectures seem to be very important for all the languages. Java seems to hold it's own with the rest.

I can rephrase my initial idea as a question. If one is starting out today to learn web and e-commerce programming, where does one start? Given a blank slate, what language or languages does it make the most sense to learn first? Obviously, first some HTML. I propose that Java has become or most likely will become a very good second.

Glenn Cole:

In general, I would still go with Perl as the second language (after HTML), and Java (for Java Server Pages) as the third.

On the e3000, though, it's not as clear, since, unless I missed an announcement somewhere, Perl cannot access an IMAGE database (at least, not through the standard DBI/DBD interface). In this case, there are several choices, though Java may be best for future career growth, and it would allow the use of JSP.

Cortlandt Wilson:

OK, why Perl over Java?

Glenn Cole:

Several reasons,

Client-side programming is out. Applets are a pain. As a client, I’m not going to wait for the thing to download, despite the relative proliferation of broadband these days. And I am not too keen on leaving Java enabled in my browser. This means that Java, if used, would be on the server side.

CGIs are easy. Not the fastest, most scalable technology, but easy. Surely the CGIs would not be written in Java.

There may still be a back-end server process. Java is a candidate here, but development is much quicker in scripting languages such as Perl, the sheer volume of code is less, and Perl runs reasonably quickly.

Perl is a more stable language than Java, having been refined over a longer period of time (approaching 10 years in the field, versus 5 for Java).

For more on CGI programming, and coincidentally an intro to Perl, see http://www.cgi101.com/

For an "empirical comparison" of scripting languages (Perl, Python, Tcl, Rexx), C/C++, and Java, not of the language features, but how the resulting programs compare in development and in execution, see http://wwwipd.ira.uka.de/~prechelt/Biblio/jccpprtTR.pdf

Editor's note: The above mentioned article is very interesting. In the end, of Java, Perl, PHP, CF, ASP and Python, no one approach stands out as the choice for all situations.