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
midrange.com
