The conversation started with, “Is J2EE appropriate for Web Applications?” I ended up thinking about the data model. Here’s the video which spawned the ensuing observations:

Better Web Application from Didiet Noor on Vimeo.

I had some issues with the representation, though it probably has some reasonably accurate observations in spirit. First of all, the setup – the project at NOAA was a total miss. If they
were doing it as described, the technology picks were kind of a miss. I was building stuff just like that in that time period. When we built apps on top of NeXTStep, I coded UI’s with Interface Builder on the NeXT with my customer sitting right next to me. Flip a switch and see basic functional UI, changes in moments.

In that time frame, you would parse data with SED/AWK … and depending when you were starting Perl came into being. Any text mangling for impromptu analysis was done with Emacs macros. Hardcore folks in various corners used LISP and variants. Doing this stuff in C++ was the answer to a question no one ever asked. If pressed, there were some add-on libraries should you have no choice but to do it in C++. Roguewave had some libs, as well.

So to frame up the problem NOAA had in terms of the solutions they chose … and the fact that the guy framed that as a basis of comparison doesn’tgive me much confidence in the discernment department. There were better ways in 1990, though the issue of composite applications as he described back then had other problems around IPC and high coupling.

Moving into the present set of examples, he would have done well to just skip the Hello World details, instead of the time tracker app. Modern coding environments are built to deal with a lot of contextual hair, not the least of which that apps running inside of HTML … no wait, Javascript … is an architectural hell. As if there weren’t enough problems before the three tier madness began (and with the last tier being most decrepit). The “Hello World” apps tell us not so much that our codingenvironments have gotten more complex, but that our computing requirements have gotten more complex in such a way that we don’t have clean and simple solutions for them.

I am not a fan of the complexity often seen in these solutions today. I doubt most of us are. But these simple apps can easily miss the point. These environments are targeted for certain classes of problems. J2EE is not targeted to deal with Hello World apps. It wants to be everything to every one. It is the pseudo-open source version of Microsoft; but even more complex, largely because MSFT lives more religiously within a one company box!

As I look more at applications today, especially in the enterprise, I’m becoming convinced that one key issue is how many places the data model needs to be represented, and how often the data has to be transmogrified (a Calvin & Hobbes term) for its next state of use. Let’s see – we have

1. an input form or data file/stream spec (data model)
2. software to ingest form/data file/stream (data model)
3. an OLTP data store (data model)
4. data movement to longer storage ODS/DW or … (data model)
5. ETL (data model) between OLTP and ODS/DW
6. OLAP/DataMart store (data model)
7. ETL (data model) to OLAP/DataMart
8. App queries (data model)
9. App rendering (data model)
10. Inter-app communication (data model)

This representation of data throughout the processing model is painful. Couple that with extremely crankly end user computing model and we have the current set of solutions in front of us. Folks love Rails, for example. The word I hear is for classes of simpler apps, it’s great. Complex stuff, different issue.

Portals – everyone I’ve known thus far either complains about them, or codes around them or minimizes their use. I’ve not had the privilege to code with them, so can’t speak first hand.

The backend coding doesn’t seem as rough as it use to be. Talking to multiple platforms we use to have Big and Little Indian problems (then solutions got baked into stuff like RPC), we saw a plethora of solutions that were considered acceptable to code interconnections. Some of that has grown in a somewhat respectable fashion with web services technologies, as least in that realm.

Unfortunately the industry believes everything should be obliterated into a relational model, save the text search weenies. This seems long standing, but add insult to injury it seems like it has become a given that any software system must have an RDB somewhere and some SQL buried somewhere. I wrote a lot of software and I can count on one hand the number of times in my life prior to 1999 for which I had to write SQL. If I was still writing software on a daily basis, I doubt I could make the same comment a decade later.

And to the worse point … the UI’s in the main stream just haven’t done well. Shall we forget that MFC (Win32) was a spaghetti pile? And before we can even throw our usual stones at MSFT, that XWindows was an over-engineered nightmare? To write UI’s for a living, you had to gronk the COMPLETE O’Reilly X Windows book set. If one skated on MOTIF knowledge only, or some layer on top like OIT I assure you that one’s work was superficial.

IPC between apps was not much more pleasant I suspect than portal programming today. And for all the threaded apps I tore apart and rebuilt, reducing the threading – threads were a nightmare in user facing systems which I had the “privilege” to remediate.

So let’s look at the heritage 20 years ago to now:

• proliferation of the data model has increased, due to a) more layers and b) more end points for data usage.
• data models are still RDB-centric. We use XML more for transport and interface than for comprehensive model representation (store, traverse, search).
• networking has gotten easier (whew … at least some wins?!).
• languages, IMHO, are no better than 20 years ago, but often struggle to go from “language” to pseudo-operating-system-development-lifestyle (e.g. Java). But frankly I don’t see algorithm as our core problem, so languages are adequate at worst.
• UI’s have been a train wreck for the last 20 years. Sure there are examples of better worlds, but the main stream has been ugly.

Compute and network power hasn’t helped us in this regard – Moore’s law makes us have even more freedom in a world of computing that we quite frankly have lost control of shaping complexity. Don’t believe me? Then why are iPhone apps better than equivalents on machines with 10x the power/display/connection? Try to use the eBay app on your iPhone, then on your desktop/laptop and get back to me. All of us on this distro are old enough to know how parsimony comes with limited resources.

And ironically, with the massive resources available today, J2EE authors still manage to create object instance storms that grind servers to a halt.

We need some disruptive innovations in my opinion. Compute cost for corporations has gone up in the past twenty years – while more of the business activity has gotten increasingly in bed with the corporate computer, I also believe that some of this has come from the tangled gordian knot of the above diatribe. After all if that was not the case, explain why a company like Google would GWIT their way to abstraction of JavaScript in hopes of never having to deal with its consequences again ….

level integrations anyone?