Who am I?
A second answer to who am I can be found in what I have been. Prior to working for IBM, I joined a small start-up System 38 Independent Software Vendor that focused on the Oil & Gas industry. For the 11 years that I spent with that company I built or managed the building of line of business applications for that industry in the RPG language for the System 38/AS400/iSeries/System i/IBM i platform. We were "business developers" before anyone had coined the term in the software industry. This meant that our understanding of the Oil & Gas business was valued as highly as our ability to write killer applications for that industry quickly. This blending of business and technical knowledge and a keen focus on solving business problems with software applications was a perfect match for the System 38 and its successors. This is because that platform was targeted at providing a well-conceived, complete, end-to-end, highly productivce, yet simple application environment that encourages a focus on solving the business problem, not technology issues. So, this tells you that I wrote business applications and liked the i platform...
What does EGL mean to me?
This description of the System 38 can also help to describe a key aspect of EGL...that is, its keen focus on helping developers to solve business problems. Specifically, It's designed be a highly productive, complete, well-conceived, yet simple way to build business applications from one end to the other, with the added advantage of being able to run in several different runtime environments.
When I was an active programmer, life seemed simpler than it does today. Maybe that's because of the System 38 which did a great job of insulating us from many technical tarpits. At any rate, developing an application today that is received as well as a good 5250 application was received in 1988 requires the exploitation of more runtimes and middleware than was required 20 years ago. In fact, the term "middleware" didn't even exist. Its the existence of this middleware and the plumbing required to use it that dramatically complicates application development today. Any self-respecting web 2.0 application that needs to leverage data stored on an enterprise server (like z or i) must leverage HTML, Javascript, maybe PHP or VB, XML, possibly SOAP or REST services, RPG, COBOL, Java, or PL/I on the enterprise server... Whew...it makes it much more difficult to be productive building these applications, if for no other reason than the broad array of skills needed to pull this off. This is one of the key motivations for EGL...to simplify the construction of the entire application...from end to end. It is my belief that if a developer or team of developers can limit the number of technologies needed to construct a given application, then they can likely be more efficient in this task. To net it out, it is our goal to provide in EGL a language that allows business developers to express an entire application with a minimum of effort and a maximum of value to the business.
My hopes and aspirations for this site
Community is essential to a language today and we've had countless suggestions from our customers and partners that they needed a central place to meet, share experiences, and get the latest on EGL. The EGL Cafe is that place. I expect to see blogs from partners and ISV's that are leveraging EGL and have parts or services to share or sell. I expect to see additional forums spawned around specific sub-communities like Web 2.0 development with EGL or ISV's or exploiting IBM i or ... These sub-communities can drill deep and talk about things that are specifically interesting to them. I expect to see Jon Sayles' extensive portfolio of EGL content exposed to more EGL developers in "Jon's Corner". I expect to see all sorts of documents related to the wonderful world of EGL application development. And finally I hope to be surprised with new and interesting content and ideas for the EGL world!
