EGL is often described as a 4GL. When EGL was only accessible in the context of IBM products and was a closed black box this view was reasonable. However, the current Eclipse implementation is not just the rehash of that closed system in an open source arena; it is a completely generalized and extensible framework for expressing domain specific concepts in a programming language together with an extensible compiler/code generation framework. EGL the progamming language itself actually only provides a syntax and compiler for creating and validating instances of the EGL meta model; the real meat is in the code generators which read these models to produce code. Furthermore any code generator can be extended to add new progamming model elements, or change existing code generation patterns without affecting the original generator. New generators can be written to target runtimes that may not exist today. A good example a new generator would be one targeting an Objective C runtime instead of Java or Javascript. An example of an extended generator would be one that was built upon the base Java generator but was extended to also understand how to map user interface application concepts to an Android runtime framework.
This approach of a defining models and mapping them to runtime using a Model Compiler may seem familiar to some as classic Model Driven Development (MDD). In many ways this is true. However the point of EGL is to do everything in the programming language, including the modeling itself, so that one never has to edit the generated code. In other words, the model IS the code. Futhermore, the tools within the EDT project also provide debugging in terms of EGL, not the generated code though that is always possible as well.
What the EDT project is really about is providing a programming language infrastructure in which the low level 'assembler' languages generated are the well established runtime languages of the given target platform instead of the bytes codes of a VM or hardware. The current functionality of EDT 0.7.0 just released is really just one implementation aimed at the domain of Web 2.0 based client/server business applications where the target runtime platforms are browsers for the client and JEE based services. Other choices can be made and extensions to the current choices can and will be added.
EGL is not meant to replace existing languages and frameworks. It is instead meant to leverage what already exists and to be molded onto whatever comes in the future. This can be done because EGL itself is a 'meta' language in relation to something like JavaScript in a way similar to the relationship between traditional 3GL languages and the assembler they generate. What is different here compared to other 4GLs that generate 3GL code is that the programming models surfaced to EGL programmers are extensible and the code generation that maps those programming models to real runtime is also completely extensible.
So what does all of this buy us? Some examples:
- Common programming language across all application tiers
- Common definitions of shared components across tiers enabling a DRY (Don't Repeat Yourself) disipline. Typical example is data definitions and validation logic that must exist in both the client and the server and often in batch applications as well.
- Changes in choices of middleware and frameworks and even runtime platform can be managed by updating the compiler and regenerating instead of being stuck with whatever choice was made at the time. This presupposes that the programming model abstracted the semantics of what the given framework or middleware was doing. Typical examples are things like persistence, remote invocation, transaction management , business rule definition and management, etc.
Is EGL for everyone and every problem? No. However, there are several kinds of situations in which EGL is an ideal solution:
- Multi-tiered applications which target multiple platform technologies and must integrate with existing investments. Integrating across these technologies using the technologies of the systems themselves is tremendously hard. Even if you get a particular solution to work it is likely the underlying technology choices made to support it will need to change over time. If the solution is done with EGL, it is both easier to program and maintain along with being flexible enough to change the underlying target technologies when the need arises.
- Common application components which need to deploy to multiple environments
- Flexibility in using staff in producing code across technology boundaries. This one comes from the fact that the ability to create application components that target a given platform has been limited to those who are proficient in that platform's typical programming language. While it is absolutely necessary to have those people it should not be the case that building a business application requires the platform skills of all the places the application components may be deployed. I have seen kids coming out of college able to build applications deploying to the mainframe right out the gate. I have also seen COBOL programmers able to produce Web 2.0 client server applications. The point is that too often the actual important skill of knowing the business is not accounted for. A technology like EGL allows organizations to leverage that important skill for their new applications.
I hope this blog has clarified somewhat the point of EGL and why it is not just another programming language doing what has already been done. People take their programming language of choice seriously and EGL is not trying to replace those choices. It is simply saying that in today's ultra complicated world there is a need for a way of writing, managing, and maintaining applications at a higher and more productive level of abstraction and that compiler technology has always done this well. Let the best of those skilled in those particular technologies express the best of their knowledge into a model compiler so the rest of the world can take advantage of that knowledge.
In the near future we will be having a place out in EDT for 'Extensions'. These will be examples of how EDT is extended to solve particlar problems of interest to the community. Those that get enough people interested will end up producing sub projects under EDT to bring the given extension to production quality. It is these kinds of projects which will bring out the true nature of what EDT is aiming at.
