Joe, et al,I have started about three posts and abandoned them as this debate has progressed. My reluctance to weigh in has as much to do with my background and experience as it does with the fact that my thoughts are evolving and slowly gelling. I am not a "classically trained" programmer. I wrote my first program using Fortran when I was a Freshman in HS (we had just upgraded from using an Abacus and some stone tools), and although I continued to intersect with technology over the years, my Masters degree is in Economics, not Computer Science. I am a "Seat of the Pants" programmer. I absolutely love what I do. Would NOT trade it for any job, no matter how much it pays, primarily because of folks like those on this list. Passionate people who love technology because of the mental gymnastics workout it give us and the good feeling that solving problems can bring (well, OK, not *everyone* on the list is in that camp.....)
So here is what I can glean from the discussion (and I wish more of this was going on when I joined the list 4 years ago when we were making Web tool/language decisions):
1. You have to use the right tool for the right job 2. There is no one tool you can use for every jobI can see Joe Pluta with these two tablets, standing on the mountain top leading the programmer masses across the application desert (hey, the imagery works for me!). These are two good principles and I can see how they can apply in the following areas:
1. 85% of the applications my customers want are either A. Simple HTML CRUD applications used on an intranet for data maintenance or B. Simple web "self service" applications where data can be retrieved and updated. That is about it. No "enterprise ready" level stuff here. RPG CGI would be overkill in some cases here. I want to simply display data and, perhaps update it. RoR would fit nicely here (standard 5250 apps do as well) The frameworks we have worked with at my company are either RPG-CGI based or Java based. In both cases, for simple CRUD, they are both tools that are misplaced and I see our developers working to simplify the frameworks further and further until, guess what, it looks like RoR!
2. Another 10% are what I would call robust CRUD applications. Lots of validity checking. Perhaps some service information retrieval routines. Some "processing" type calculations. Things that a simple CRUD app simply cannot handle without breaking many of the conventions used by the framework. Java/JSP's are a good fit here as are RPG-CGI apps. These things take time to write and debug. They tend to have higher support costs as well (that could be just our experience so far).
3. The remaining 5% are what I would call "enterprise applications". In our case it will be payroll processing, student scheduling, month end closing, that kind of stuff. These applications require lots of processing power and fast I/O. Even though we want to have a cross platform application suite, we may end up having to use platform specific languages and tools to make that happen. Java works here and fortunately processing power has kept up with it's demands. But RPG is equally a player on this front. It may be advantageous to use RPG when we deploy to a System i.
Of course there would be plenty of debate on the whether Java/JSP and RPG-CGI would be a good fit for #1 above but something like RoR is a pretty good fit for that kind of stuff so why re-invent the wheel? My guess is that the Java/JSP - RPG-CGI folks who DO use it for very simple CRUD have scaled it down quite a bit to do the simple stuff simply.
I guess what I am saying is that the question "Is (insert your language/tool/framework here) ready for Prime Time?" can only be answered in the frame of reference of your business application demands. Sure, we can set the standard of "enterprise ready" as the holy grail for frameworks, but that isn't really necessary for all frameworks/languages. The question to ask is "What application are you using it for?" and then the discussion can proceed.
Finally, is RoR any better or worse a framework if it loses in the "enterprise ready showdown"? Heck no! Use it for what it is well designed for and don't try to make the square peg fit in a round hole.
This has been good discussion. A bit OT from Aaron's original post. BTW I AM working on a port of RoR to the PASE environment. My lack of UNIX/Linux/AIX background is hindering me a bit. Why do you have to compile EVERYTHING in those OS's? ;-)
Pete Joe Pluta wrote:
From: Nathan Andelin Joe, Any language or tool not having an interface to RPG and native iSeries resources wouldn't meet your standards for enterprise-level business applications, if I understand correctly. Even Java alone, wouldn't meet your standards, which sounds reasonable to me.As long as you realize there are (at least) two levels of "enterprise ready". First is my personal definition which pretty much requires the ability to take advantage of and interface with existing databases and business logic. I don't care how powerful the tool is, having to rewrite a few million lines of RPG is going to hurt my ROI <smile>. So in my narrowest definition (which is pretty valid considering the fact that all these lists say "400" in them) the language better have a darned good interface to ILE. Second, though, is the general concept of enterprise-ready, in which you can build large, secure, scalable systems that perform enterprise-level business functions (e.g., ERP systems). I contrast this with things like content management or store fronts. These are both important applications, butneither exactly taxes your business programming skills.My position on Java (and OOs in general) for creating enterprise applications has been stated pretty clearly: rigid type hierarchies make adapting to changing business conditions very tricky, and SQL as a primary database language, well that just stinks. And of course you have the thorny issue of security. Any environment that claims to be enterprise ready had better be able to address those issues. J2EE addresses it with integrated security and scalability, and the only issue is whether you can write enterprise-level code that performs acceptably using SQL. Oracle would seem to indicate that you can, although I don't know of a lot of Java-based solutions. I hope to be able to answer some of my own questions soon enough. Since nobody has ever taken me up on the challenge of writing any ERP-level algorithms using SQL, I'm going to try to do some. Once I do, I can incorporate them into RoR just as easily as I can into Java and VB, and maybe we can do some benchmarks. At the same time, I'm going to write the same code in RPG and see what happens when we call RPG. I'll probably do one version with stored procedures and another with direct calls.There are a lot of RPG programmers who assign field names and attributes in display file records the same as physical file records, so that mapping is done automatically between the two. That's an example of "convention over configuration".Yeah, but there are just as many people who will tell you they don't like doing things this way, and that they in fact choose specifically to NOT use database field names in the display file DDS. It's a coding style technique. This whole "convention over configuration" issue honestly has me a little puzzled. I think I'd prefer a framework in which *I* could set the preferences and then generate the code, rather than have a set of pretty rigid standards that I need to follow. Maybe times have changed. Back in the day, I had a hard time getting people to follow program naming conventions, much less the names of their files and fields. Today there does seem to be a lot more black box coding, so maybe the idea of following someone else's standards is more of that same philosophy. Don't get me started on the infamous WEB-INF folder of the standard J2EE layout <grin>.This discussion motivated me to look into the Rails philosophy, community, and architecture. It has been interesting. I've been reading accounts of Java and PHP developers creating Rails versions of their applications, and reducing the lines of code, cutting the code in half in one account, and comparing the versions for performance and scalability. The reports are favoring Ruby and Rails.Again, I think RoR is pretty cool, and it seems to be a good tool for some of the jobs that PHP has traditionally been used for. Rails seems to provide a quick way to generate CRUD applications on top of that. If it also lets me quickly and easily build calls to RPG for business logic, it may be a viable option. I'm still leaning towards EGL's metadata approach, though. Once you define the metadata in EGL, defining records and messages and dragging and dropping them onto JSFs is pretty amazing. Joe