Re: Impressions of EGL - Part Duex

Actually, my response was to Aaron and only because the ephemeral "solid business application" is thrown around so often that it is taking on the characteristics of Bigfoot or Elvis sightings, everybody says there is one and all I am seeing is "fuzzy photographs". Knowing what would comprise a "solid business application" was what I was after from Aaron. Perhaps that is what the scheduling application you and Chris developed is in response to. I went back and scanned the posts but didn't see anything approaching a "spec". But I was just scanning and there are a LOT of posts on this subject.

We have ended up in a "Mexican standoff" situation where everybody thinks the tools and languages they use are superior to EGL but no one is 1. Willing to try EGL and 2. Unwilling to replicate an EGL application because it will take too much time. Me, I am not really interested in replicating yours and Chris's application because I already know the tools I use can do it (with great difficulty) and, yeah, I don't have the time. I think it would be interesting to compare approaches but I already like what I see in EGL. Replicating the app at this point brings nothing to the table for me since I am already evaluating EGL. The 15 or so hours I invested in getting started with EGL last week were OK to invest because not only did I learn some EGL but I also learned about some of the tools EGL leverages that might make me more productive even if I didn't embrace the language. Also, some of the discussions surrounding the implementation have been helpful. Putting the acrimony and chest thumping aside, I am learning a thing or two. For me that is good.

Yeah, building an app AND a tutorial is a lot to ask, but I am asking because such a thing doesn't exist. As I said before in other posts, I have walked through framework tutorials that are carefully crafted to to make the framework look brilliant and then as I try it out on real world applications, I find myself dealing with a less than productive environment. It would be awesome if there was a site that had a set of "standard" business applications (like an order entry system) that could be used for coding benchmarks. You know, a "relatively" simple application that creates and updates orders (for example). Maybe a web services interface for order inquiry. Whatever. Comparing apples and oranges is difficult and I know that programmers are called to implement application designs so they would vary from programmer to programmer but it would be a heckofalot better than saying "build me a solid business application". One programmers idea of solid is another's POC program. For me (sounds like Nathan and Aaron are ambivalent) but for me, I'd like the tutorial because I would like to actually compare approaches myself. Your idea of building the app and then having others build the same application and then getting together and showing how each part was coded might get to the same place but that would assume that we could understand each others code (sometimes I don't understand my *own* code.... :-) ).

Nathan was part of a company I and some others started a while back (and I have since left) where we had a great, lengthy discussions about the relative productivity of several approaches, both RPG and Java. We all attempted to build the same application using different approaches so that we all could appreciate the relative merits of each approach. 5 years ago, our conclusion was that the backend stuff was easier than the frontend stuff and that when it came to coding the HTML and JavaScript, we all slowed down (being traditional RPG programmers). We never settled on any one approach. That same company went on to embrace Java, Nathan's framework, PHP and, more recently, Adobe AIR. They are still working on delivering solutions we thought would be done years ago. Their problem is their constant search for a better approach without evaluating what they have learned from the past. The point here is that coding the same application can be a good way to demonstrate that one approach can be more productive than another but I can't see how that can be evaluated unless we can each see how difficult (or easy) it is to deliver the final solution. Even that will be biased because someone like Nathan, or you who has a complete mastery of a specific approach will naturally find any other approach less productive. Thus the standoff.

Me, I was immediately more productive with EGL. My plan is to get my hands dirty in EGL over the next week in order to prepare of the continuation of the training on June 2nd. I still would like to see at least a "storyboard" if nothing else, of what Aaron would characterize as a "solid business application" showing screens, flow and database layout. But I am probably just spitting into the wind.

Pete


Joe Pluta wrote:

Pete Helgren wrote:

I think Thorbjørn and I would both like to see a functional outline of what a "solid business application" would look like. Order entry would be good, and there is an EGL tutorial already available that does this in a rudimentary way. Beyond producing such an app, I'd like to see a tutorial, as close as possible, as how to create it.

Well, sure we would. But do you see something like that for any other language? I think you're asking a lot for someone to say "here's how you build a solid business application". That's really the programmer's job. The language's job is to make sure you can get data from the database to the user and back, and EGL does that really, really well.

The reason is, unlike Joe's throwing down of the gauntlet that says "replicate this", a step by step of how you arrived at the solution would help explain the simplicity or complexity of the approach. The "black box" approach that says "make me one of these" and then one them appears, isn't that helpful to me.

Understand the purpose of my gauntlet. If the primary focus of this mailing list were to share working examples of code, I'd be far more likely to engage that way. Instead, it's a whole lot of "my method has brighter teeth than your method" combined with "here's another flashy demo that doesn't address the issue".

When I threw down the gauntlet, it was to set a baseline of functionality. The baseline was to basically recreate any of the components Chris and I have done. What did we see? A JPEG with buttons, and a lot of excuses as to why nobody has the time to do it.

And now all you want is a complete tutorial on building business applications in EGL. That's a lot to ask for, isn't it? <grin>

Anyway, not dissing your point, Pete. I'm just saying that I don't want to waste my time writing free business application examples unless someone want to step up to the plate for the other technologies and show theirs. I just did it with that little image thingie of Nathan's - it does everything Nathan's does without a single line of JavaScript or HTML, and it attaches to a back end using Ajax.

Until someone acknowledges the advantages of the approach, and/or matches it with some other technology, I see no reason to continue writing examples. I don't plan to do any more until that its matched. So if you want to see EGL examples, why don't you get the RPG-CGI or PHP advocates to do the same, eh?

Joe