Table of contents

General

Acquired by WRQ, Inc.

User Interface

Compiler features

Middleware / interfaces

Database interface

Tools

Compatibility

Productivity features

if exists (select * from sometab where  company_code=lv_code) then
error "Company already exists!"
end if

DEFINE x LINKED TO tabname PRIMARY KEY (pkcol)
..
LET x.pk=123
SELECT USING x
LET x.someval=2
UPDATE USING x
 

IBM EGL

Strength

Weakness

• Java Server Faces allow Visual Basic-style form design and "coding without coding", which allows for quick prototyping that is somewhat usable as a base for actual development too.
• Allows non-Java programmers some access to  some J2EE technologies without learning Java. They will still have to learn all about J2EE (as a platform) components they wish to use. Which will in turn require that they learn a fair bit of Java (as a programming language)
• It can potentially provide a gentle introduction to J2EE and Java to non-Java programmers.
• Number of potentially useful tools are bundled with WebSphere Studio IDE (A.K.A. Eclipse). Then again, most of them are freely available, since Eclipse (IDE WebSphere Studio is based on) is an OpenSource product.
• Event if its not a x4GL, it is still a 4GL, as in Fourth Generation Language. Which still makes it more productive for the purpose of creating BRDO (Business related, Database Oriented) applications, then any general purpose 3GL (like Java, C/C++/C#, etc.) will ever be.
• It is a (potentially) simple way to incorporate existing mature, tried & tested 4GL code into a corporate strategy that mandated use of Java/J2EE, without manually rewriting everything, and retraining all staff.
• Depending on the actual ease of integration between Java and EGL, it might be possible to benefit from many 3rd party, both commercial and OpenSource reusable components available in Java world. EGL code translated into Java is based on OpenSource Struts framework, which is a very popular component in world of Web interface oriented Java developers.
• It is based on Java, and not C#, so at least in theory maintains platform portability
• Being a 4GL, it maintains a level of abstraction from underlying technologies. In theory, it is possible to imagine a EGL to C# compilation option, just as we now have EGL to Java and EGL to COBOL options. Or any other programming language/platform that will appear in the years to come.
• Database objects access definitions kept separately ("Dataitem"), and therefore reusable, which is in theory a good thing. They also contain some basic business rules, which can be used for validation (server-side only - client-side validation has to be hand coded). Based on meta-data which is static, and therefore an invitation for all sorts of bugs that will be hard to trace (because of this layer of abstraction)
• EGL is potentially a great web front-end for x4GL business logic in Services Oriented Architecture scenarios. Most x4GL are limited in there ability to handle customized web sites development, but EGL, thanks to the JSF (Java Server Faces) technology brings almost drag-and-drop, Visual Basic style solution to it. Which will also make VB programmers happy.

• "Automatic" conversion from i-4GL to EGL has a manual with 150 pages. It is questionable how automatic is something that needs such a large manual. The mention of "large percentage" of x4GL code that gets converted automatically, is making me uneasy too...
• Conversion of 4GL report formatting blocks is limited to format only, and results in Jasper Reports XML file. No tools for maintaining them are provided. Any functionality embedded in formatting ("REPORT" block) is lost. While Jasper Reports framework have number of solid OpenSource implementations, it is open for debate if it is 100% ready for large scale corporate reporting tasks. Maturity of report design tools also leaves a significant gap, when compared with the likes of Cognos, BO and  Brio, and is not user friendly enough for the power users.
• .per forms are converted into embedded hard-coded strings, losing separation of presentation and logic, and removing even vague visual correlation between form layout and end result. All multilingual forms will have to become embedded in programs
• Converted forms are usable ONLY in TUI mode. When converting existing 4GL code (that uses forms) to EGL to be used as Web interface applications, all forms will need to be re-created manually, from scratch. Given the nature of  interaction between Java Server Faces (EGL UI component) and EGL code, significant parts of user interaction related 4GL code will have to be manually rewritten in EGL.
• No tools for forms design of converted forms are provided (form painter)
• Metadata extraction is static, and has several limitations. The way it is created and used will cause noticeable productivity overheads, without obvious benefits
• Cobol generation only on iSeries and (maybe?) on zSeries, and does not work on any other platform
• C code cant call EGL functions
• Language syntax is a Frankenstein composed of several iterations of old IBM 4GL from VisualGen products, Informix-4GL plus bits of Java, shell scripting, and JavaScript syntax. Significant parts of the built-in functionally, which in 4GL are expected to be part of language syntax, are instead implemented as function calls. Language syntax is everything but consistent, not to mention elegant. Which all translated to loss of productivity.
• In 95% of the cases expect to create more code for same functionality then in x4GL. In many cases, a lot more code. Even the simple things like returning variables to a calling function require several statements. SQL is not embedded, and most database interactions require referencing extracted (static) meta-data.  As a result, productivity is degraded.
• Quote from conversion manual: "The performance of I4GL applications converted to EGL will be somewhat reduced." Given the legendary resource hunger of WebSphere AS (Application Server), which is the ONLY supported and REQUIRED AS, and IBM's conflict of interest when selling expensive hardware, expect to buy brand new server hardware. The bigger the better.
• It is completely unclear if EGL is able to produce GUI apps in any client configuration (Thin, fat...) It appears only web browser and TUI (Curses) clients are supported
• Mostly because of the enormous footprint of the Eclipse and WebSphere application server, each developer will need the state-of-the-art machine to develop. Budget for dual CPU machines with 2GB memory and SCSI RAID disks. (Download size of basic package ["Web Developer"] is 4GB!) Otherwise, expect any potential gains in developer productivity to be lost by developers watching the hourglass, waiting for things to happen...
• EGL does not allow Java code to be embedded in EGL, making me wonder what they mean by "tight Java integration"
• Database support is unclear at this stage. It seems that there is no SQL run-time conversion. Again, there is a conflict of interest on IBM side, even between DB/2 and Informix families.
• 100% complete vendor lock-in: Once you convert to EGL, IBM is your only source for everything from products, training support and tools.
• EGL creates a long chain of dependencies; you will not be able to choose your IDE, Versioning control system, database, application server, automated testing framework, web server, or operating system. Since IBM purchased Rational, it is easy to guess which tools will be promoted for all jobs possible. This might be a good thing in some environments, providing standardization. IMHO, it will be a bad thing in most development environments. Developers are craftsman, and have to be able to choose there tools based on task. Also expect to pay for a lot of things you don't need, and will never use, because of the way IBM packages products together.
• On AS side, supported only on Windows, Linux, iSeries and zSeries. Which means that HP-UX, AIX Solaris, etc... are not supported. Support is apparently planned, but no date was released.
• Whole EGL platform is a brand new product. Maturity, performance, scalability, productivity... are all unknown quantities. I am not aware of any mission critical EGL applications in production, or successful x4GL to EGL conversion projects.
• If EGL is really not capable of creating any user interfaces other then Web and TUI, this will represent a significant limitation in most business environments. Web browser interface is not suitable for many transaction oriented tasks where information is rapidly updated on the screen, or speed of operator input is critical. This includes POS environments.
• No QBE (Query By Example). Which is only the number one time saver and user satisfaction tool in every x4GL.
• IBM is misleading customers big time by talking about Java and EGL. There is no Java in EGL - EGL is translated into JSP (Java Server Pages) which is a separate programming language dedicated to web applications programming. JSP is Java as much as JavaScript is.
• The only available demo code is explicitly compatible with DB/2 only. I wonder what this is saying about database portability of EGL apps. I did not find any mention of Informix in the documentation.
• Few things IBM is promising for future releases includes "Extensions to records - relationships" and "GUI / Rich client support". Which means there is no tables relationships support in current "Dataitem" implementation, which is in my book making it completely useless. And how they plan to support GUI on top of JSP is going to be interesting to see. Also note that "future" has no date.

Vendor Strengths

Vendor Weaknesses

• Its IBM - and an old saying tells us that no-one ever got fired for buying IBM
• If anyone can promote 4GL concept back into enterprise, and get people thinking about productivity again, IBM can.
• Most of the team from Informix we love and trust is still at IBM product development.
• If you get everything from IBM, there can be no blame passing between vendors. When IBM database is running on IBM AS platform on IBM hardware running IBM development tools, you will always have to call only one number if things are not working.
• IBM is not going anywhere for at least few centuries.
• Selling non-technical management on basing a business critical systems on IBM products is a sure thing.
• If having sufficient resources counts for anything in technology development, then IBM sure has it (just don't ask them about "San Francisco"...)
• According to IBM marketing material, 5000 enterprises worldwide use some form of IBM 4GL technology. If any company knows the 4GL market, it should be them. Weather they understand it, is a different question.

• IBM has many agendas built-in in every product; when they sell you software, they want to sell services, hardware, and more additional software too. This agendas are built-in in every product, often in form of intentional limitations that require additional purchases of products or services to resolve. EGL, and WebSphere platform are a very good example of this approach. Buying IBM product more often then not means forming a relationship, much more then buying a product. If you are reluctant to accept this fact, EGL is probably not for you. If you already have a relationship with IBM (and know how to manage it), this may work  for your benefit.

• With tools of any kind, it is very important to have the ability to influence features implementation priorities and product direction in general. If you use this tools for mission critical tasks that impact your ability to compete in your marketplace, it becomes essential. When dealing with suppliers of the size of IBM, unless your vendor is Fortune 100 company, you will remain far below the radar for IBM product management people to notice you. In other words, you will get upgrades and fixes when you get them, and you will get features that you get. Think Microsoft. With mature products like I-4GL, this is probably acceptable for most users. With emerging ones, like EGL, this may not be the case.

After 10 years of promoting Java as a corporate mantra, the importance of admitting that Java cant do something (that is, deliver productivity for BRDO developers), is a step in the right direction. It marks the day when Java itself gained enough maturity and understanding, that it exited the technology hype phase. So we can finally get back to responsibly discussing strengths of different technologies on there own merits, without screams of "Legacy" from sales people. (Warning: there is a new "Java" on the block, it's called .NET, and has a lot of sales folks itching to sell it to you just because it is new. And new is always better, right?).

It feels good to finally be able to say that even the biggest supporters of Java admit that there is nothing wrong with 4GL technology, and that in fact it can even be a better solution for some tasks. And it's OK to say it in public now - people will not think you are insane, incompetent or afraid of the new. And nobody got fired for thinking what IBM is thinking :-)

However positive, this step unfortunately brings us less productivity then x4GL based products, but still more then plain Java/J2EE. Reading available IBM brochures and presentations, the strongest advantage of EGL is apparently that it is "modern", and "not legacy". Even a claims of higher productivity over x4GL languages where nowhere to be found. If the only motivation for making EGL was to make "not legacy" product, as far as I'm concerned, they should had not bothered.

Mutant programming language syntax bring in question the very core advantage of 4GL concept - the language itself. Half-hearted implementation of meta-data will probably hurt more then help. Possibly more flexible development environment, with functionality that is still lacking in most x4GLs. But not ready for mission critical production environments for at least one more year. Lets hope for another step in the same direction soon.

Four J's BDL

Strengths

Weaknesses

• Tried & tested, mission critical proven
• No vendor lock in - most if not all Four J's BDL (Business Development Language, A.K.A. Dynamic 4GL or D4GL) extensions are  implemented in several x4GL compilers, including i-4GL, Aubit and Querix. A simple recompile will move your apps to a different x4GL compiler
• Several useful language extensions to i-4gl, resulting in even better productivity when compared with I-4GL base
• Low resources consumption, shared linking even for P-code
• Choice of two implementations of thin clients - TCL/TK and Java (which can work as a web browser applet)
• Usable Web Browser client implementation (WebFE)
• Very good database independence, with run-time SQL translation for many SQL dialects (ODI)
• Wide OS platforms support
• Can use a range of AS for WebFE inckuding OpenSource ones
• Integrated AS support for Web and Thin clients via same AS servlet
• Thin clients are message-based (as opposed to bit-map based) resulting in low latency and reasonable bandwidth consumption. They are actually usable over very average networks, and work well in conditions the likes of Cytrix will not even start.
• 100% i-4gl compatibility - recompile your code and it WILL work.

• With per-user run-time licensing, it can quickly become expensive, especially over longer periods of time
• Small, privately held company with unclear feature.
• GUI interface fully functional, but esthetically not up to today's desktop GUI standards
• No direct control over UI widgets from 4GL code
• No built-in XML or PDF support for reports
• No built-in XML read/write support
• After the release of second generation 4GL product ("Genero") it is not clear how much longer will this product be available, or supported. One should probably not hope for much enhancements/development effort to go into BDL. (NB. BDL product is on version 3 level for almost 5 years.)
• Due to per-user licensing, it is easy to mount a DOS attack on WebFE server, by exhausting available licenses, unless a per-server licensing is purchased. Which is not always cost effective.
• Very strict licensing policy can cause many wasted hours. For example, it is enough to change a network card in your server to have to re-license the product.

Solid contender, proven functionality, but how much longer will a small company like Four J's support two comparable products? Expect to be "forced" to upgrade to Genero in the near future. So you should probably do your evaluation of Genero instead.

Four J's Genero

• All of the strengths of BDL (minus the vendor lock-in & tried&tested points) plus:
• Cutting-edge XML based, message oriented thin client technology that works
• Based on tried-and-tested product
• Built-in support for many business critical technologies: XML, PDF, Web Services (SOAP), separate report transformation tool
• New Genero UI looks much closer to "true" GUI then any other attempt, and better then any other message-based thin client I have seen. It blends well into native OS, thanks to use of native widgets sets. But its still not what can be achieved using, for example, Visual Basic (if productivity and resources are not an issue)
• Web browser AS finally reached the level of maturity where it is almost fully possible to recompile existing x4GL TUI program and expect it to do something usable with almost no changes. I used "almost" twice, but since realistically changes will be needed because of the nature of web browser technology, that is not as a big shortcoming as it sounds. But technically, it is a great achievement, and it opens many new possibilities fro your existing code, without requiring years to achieve.

• Strong vendor lock-in: once you start using Genero extensions, your code will become incompatible with the rest of the x4GL compilers
• To benefit from new XML based UI, manual effort is required. On the positive side, most work will involve REMOVING existing hard-coded formatting, since new interface does most of it automatically
• With per-user run-time licensing, it can quickly become expensive, especially in the long run. Writing an application today, that will require per-user run-time license for next, say, 10 years, can be more expensive then the productivity gained by using x4GL based development tools.
• Small, privately held company with unclear feature. Granted, they have been around for a while, but so where 90% of the companies gone in last year. Since they are privately owned, the whole product line can literally vanish over night, for whatever reason.
• No direct control over UI widgets from 4GL code. This is a price to pay for message-based thin client.
• Due to per-user licensing, it is easy to mount a DOS attack on WebFE server, by exhausting available licenses, unless a per-server licensing is purchased. Which is not always cost effective.
• Very strict licensing policy can cause many wasted hours. For example, it is enough to change a network card in your server to have to re-license the product.
• It took Four J's almost 5 years to arrive from announcements to GA product. Still not all components are GA, with some being available only to selected customers, and others mutually incompatible because of the different lines (and speed ) of development. This opens questions about the ability of the company to deliver this level of enhanced functionality on permanent basis that is needed to keep up with emerging and ever-changing technologies.

Strong contender, rich in built-in technology options, a "looker" almost. Some aspects of large-scale production readiness are still open for debate, and most 4Js customers are still using BDL product. If you can live with the risk of your business-critical systems being in the hands of 50 people privately held company that can be gone tomorrow,  technology is certainly worth at least evaluating. But remember, there will be no easy switching to other x4GL products once you start using enhanced functionality.

Aubit project - Aubit 4GL

Disclaimer:

Author of this document is closely involved with Aubit project

• Many unique features, enhancing both productivity, integration and performance
• Full plug-in architecture enables 3rd party development of components and functionality, as well as the rapid progress in Aubit compiler itself, while at the same time protecting the stability needed in corporate environments.
• Only x4GL with option of fat GUI and therefore full GUI widgets control, even for "block" screens (.per based)
• Only x4GL will "real" GUI option, utilizing cross-platform GTK+ and Glade/libGlade
• Unique high-low approach brings best of both 4GL and 3GL worlds together, thanks to ability to embed 3GL code directly in 4GL code.
• Automated regression testing suite with complete coverage of x4GL language available. On each release it will take less then an hour to make absolutely sure all features are working correctly
• Production ready, used in large scale, business critical installations
• Many external tools come as standard; from dbaccess,isql,ace,perform,r4gl and dbschema equivalents, to migration and conversion tools. Many tools compliment well any other x4GL compiler
• High transparency of the OpenSource development process allows both constant user participation and fast turnaround of bug fixes
• Active, knowledgeable and involved user community means that you can share not only experience, but also influence the direction development is taking. Even better, you and your company are more then welcome to participate in development process directly.

• Not all features available are on the same level of the maturity. Some may be implemented only to the level sufficient to satisfy particular environment or purpose; some will be nothing more then an experiment; thankfully, given the available source code, nothing stands between you and implementation of this features to your precise specifications
• No usable HTML/Web browser option. Can run as CGI, but there is no mapping of UI (forms, menus) to HTML
• No message-based thin client. Uses VNC (Virtual Network Computing) for GUI thin client. VNC server not integrated, so requires separate installation.
• No SOAP implementation. XML-RPC is client only
• Only Informix and PostgreSQL are fully tested for emulation/translation of Informix specific SQL dialect/features. While thanks to target specific configuration files its possible to support practically any RDBMS, this is not tested
• Full PostgreSQL support requires PG engine with Informix compatibility patches applied. Limited to version 7.4
• P-code version not production ready
• Manual out of date on semi-permanent basis, because of the fast pace of the development changes

• Freedom to choose your support vendor, freedom to alter or build product features to suit your needs, freedom to choose time to upgrade (or not to upgrade), freedom to support yourself if you so choose.
• Cost (or rather absence of it) - no per-developer cost, no run-time cost, no hidden costs, no add-on cost... you got the picture...
• Ultimate flexibility and extensibility; there is nothing you will not be able to do, if you know how to do  it (or who to hire, that knows how to do it)
• No chance of product or vendor becoming unavailable or unsupported
• No forced upgrades, no license fees extortion games
• No vendor buy-outs, no product direction change, no "upgrade paths" that require conversion of all code, retraining of all staff and buying licenses for five more products.
• No database vendor agendas or preferences, no OS preferences, no hardware preferences. No hidden agendas at all. Aubit developers are not trying to sell you anything. The only goal Aubit developers have is to make tools that will make them more productive and competitive as software developers. Which is probably your goal too.
• Ultimate future-proofing; all x4GL by there nature have the ability to abstract low-level functionality (that changes and will continue to change) into high-level, task-based language. Think GUI or Web browser user interface - you can take 20 years old x4GL code, and with practically no changes, run it in web browser. And 20 years ago web browsers did not even exist! But Aubit, by the virtue of its GNU/GPL (Gnu General Public License) OpenSource license adds another side to it. Since Aubit, x4GL will exist as long as one single person on the planet is willing to maintain it, and it will continue to be enhanced to accommodate emerging technologies for just as long. Product End of Life will not happen until there is a single user that see benefit from using it.  And thanks to Aubit project, this goes for most x4GL applications out there. IBM wants you to move to EGL. Four J's wants you to move to Genero. Now, you don't have to.

• Nobody to blame, nobody to sue
• No glossy brochures, no free tea mugs, no user conferences that someone else pays for.
• No full-page adds to tell you that you where right and make you feel good about your choice.
• No "independent" studies "sponsored" by the vendor making the product to tell you how much better it is then anything else, and how excellent your choice was.
• No fancy vendor certifications to add to your CV
• Not necessarily a license weakness, but the fact is that development team resources, and numbers, are very limited, as they depend on volunteers, and even they have bills to pay. Which means that sometimes you will have to pick up the bill for things to happen in particular timeframes. Which is still in my view much better then not being able to get it done no matter how much are you prepared to pay.

Most flexible and arguably most technologically advanced option, but it will suite best the environments which are prepared to (and able to benefit from) take charge of there own technology future. Managing expectations will be critical.

It can provide significant savings, as well as open some unexpected enterprise integration options. But probably most importantly for a developer, you will never feel like you cannot achieve something because your tools are limited or someone is stopping you. The ultimate future-proofing has arrived.

Beware: freedom always has a cost, and it requires both knowledge and determination. Lack of professional documentation illustrates this point well. Environments unfamiliar with the way OpenSource software and projects work from process perspective, may have a bit of cultural shock. Calling 24/7 support number and shouting at support guy is not an option here. [Comment by Mike Aubury:] Although commercial support contracts are available at highly competitive rates :-) (& The big difference is you get to speak to the organ grinder...)

Similarly, due to the nature of OpenSource development process, occasionally you will see more nuts & bolts that you would like to; unfinished functionality that looks tempting, but is not, well, finished. Things you would not expect from commercial vendors. Not most of the time, anyway.

As with all OpenSource software, vendors that will benefit from Aubit the most are the ones that know what they are doing, how to do it, have a clear plan how to benefit from it, and are prepared to share the load. Because that's what OpenSource in essence is - coopetition.

"The man who trades freedom for security does not deserve nor will he ever receive either. " - Benjamin Franklin

IBM Informix 4GL

• Rock solid, tried & tested, tough-as-nails product for mission critical environments
• Fast, light on resources, portable  (in actual sense of the word)
• Award-winning documentation
• Global support network
• Just can make it stop working

• Lacking in functionality by today's standards - no GUI, no Web browser interface, no XML, no Web services, etc
• Since IBM declared EGL as it's successor, this is End Of Life product. But in IBM, this can mean even 10 years of supported life. Don't expect any feature developments though.
• No database portability outside if IBM universe (Informix or DB/2)

Granddaddy of them all is still with us, and going strong. As do all inventions based on real needs, clear ideas and leadership, instead on marketing, focus groups and buzzwords, it still fulfils its purpose.

The fact that you hold in front of you a document comparing products inspired by I-4GL product, is a big salute to the author (Chris Moloney was the chief architect of I-4GL)

If you have it, keep it, unless you can prove in no uncertain terms what will you gain by replacing it. Hint: "It's old" is not a valid argument.

But if you plan new development, seriously consider other, more feature rich x4GL tools.

IBM EGL vs. Four J's Genero

1. IBM is a zillion-dollars global uber-corporation
2. Completely new product, no known production installations
3. Based in merger of products; a complete rewrite
4. Resources uber-hungry
5. EGL language is not a x4GL language, and is 100% proprietary
6. One stop shop; from hardware to database to tools
7. Many agendas built-in the products
8. With the company of this size, products disappear or change directions 180 degrees whenever management feels like it or gets a new corporate mission statement. Or the guy who put it together in the first place gets fired. Or quits. Or whatever, really. The whole product is so small for IBM, it really does not mater.
9. Medium productivity

1. Four J's is a 50 people privately held French company
2. Has some users in production, but not known how many
3. Genero is based on well known & tested product (BDL)
4. Moderate to low resources consumption
5. x4GL language with proprietary extensions
6. Tools only vendor
7. No agendas beyond tools
8. With company of this size, products disappear or change directions 180 degrees whenever the owner feels he can make more money that way, or feels like changing profession. Or whatever, really. It's his company.
9. High productivity

If you have existing x4GL code, evaluate Genero first.

Look at EGL if you know how to deal with IBM, and are at least medium sized (500+) people company.

IBM EGL vs. Aubit

1. Complete lock-in
2. Most expensive of all x4GL based options (TCO)
3. If it's you who is making a call, you are safe; IBM will supply a lot of paperwork unlikely to ever be challenged, to show that it was a good idea (at least at that time).
4. Medium productivity
5. Unknown quantity
6. Inability to influence or participate in product development
7. Solid to good documentation
8. Many intertwined and not always obvious agendas, with the goal of all commercial vendors - making more money. Just be aware, that IBM is better at it then most

1. Complete freedom
2. Free
3. If it's you who is making a call, you better know what you are doing, and how will you achieve it. There will be nobody to blame
4. High productivity
5. Production ready
6. Ability to influence and participate in product development
7. Poor documentation
8. No agendas at all beyond productivity

Evaluate Aubit if you feel confident about your knowledge, determination, and management support, if you do not have endless budget and if you are looking beyond a year or two.

Look at EGL if you know how to deal with IBM, and are at least medium sized (500+) people company. Be aware that web browser is currently the only interface on offer.

Four J's Genero vs. Aubit

1. As soon as you start using Genero enhancements, you are locked-in
2. Very strict, in a long run potentially expensive per-user and per-developer licensing
3. If it's you who is making a call, make sure you understand the nature of the company and its history.
4. High Productivity
5. Production ready in most respects, still some polish needed in advanced features
6. Some developers are very friendly and willing to listen, usually more then management. YMMW
7. Solid documentation.
8. No agendas beyond selling its product

1. Complete freedom
2. Free
3. If it's you who is making a call, you better know what you are doing, and how will you achieve it. There will be nobody to blame
4. High productivity
5. Production ready basic feature set; limited usability of some features in active development
6. Ability to influence and participate in product development
7. Poor documentation
8. No agendas at all beyond productivity

Evaluate Aubit if you feel confident about your knowledge, determination, and management support, don't have endless budget, and are looking beyond a year or two. Make sure you don't immediately need functionality still lacking in Aubit, or that you can supplement it using another product.

Evaluate Genero if dealing with commercial company is a more natural fit for your organization, or you feel uncomfortable with OpenSource nature of Aubit's development process.

Four J's Genero vs. Querix

1. Mature P-code, C-code no longer supported
2. Advanced XML message-based thin clients
3. Mature support for many databases via ODI
4. Number of x4GL language enhancements as well as support for current technology
5. Sold support for Web Browser clients
6. All products require both development and run-time licenses
7. Support for Apache and IIS
8. ODBC supported only for Microsoft SQL Server
9. Clients don not support encrypted connections themselves.
10. No ESQL/C compiler

1. Mature C-code generation, P-code a recent addition
2. Windows client supports Active X based controls, but otherwise clients are on Four J's BDL level
3. Support for databases other then Informix and Oracle a recent development
4. Fairly strict adherence to the the x4GL base syntax, missing support for Web Services, XML, PDF...
5. Relatively basic support for Web Browser clients
6. Free licenses when used against Informix database
7. IIS Web server supported, therefore Windows only
8. ODBC supported to multiple databases
9. Thin clients support SSL encrypted connections
10. Supplied ESQL/C compiler supports all Querix 4GL supported databases, but with somewhat limited compatibility with Informix-ESQL/C

Querix suite is a solid product, but its development and feature set is apparently limited by the limited resources of the company. If for no other reason, free licenses may appeal to people that whish to stay with Informix database for a while, and don't have the need for some of more current Genero features, and want more then Informix-4GL can give them. Just check first if support is available in your country - Querix is a small English company, even smaller then French based Four J's.

If you care about GUI client looking pretty, or need Web Services, XML or PDF support, Genero is a way to go. It is more polished then Querix line, but still lacks maturity of the other Four J's offering (BDL) and in parts even some Querix components exhibit more maturity. Genero is GA since very recently, so things will probably only get better.

Aubit vs. Querix

1. No thin message-based clients available
2. Only PostgreSQL and Informix are fully supported by automatic run-time SQL dialect translation & DB features emulation
3. Number of language enhancements, limited support for Web Services, reasonable XML support, and extensive PDF support
4. No support for Web Browser clients
5. No licensing - Aubit is OpenSource product
6. No ESQL/C compiler
7. Number of tools supplied, including Ace & Perform compatible compilers and translators, dbaccess, dbschema, r4gl and other I-4GL compatible tools.  Apart from r4gl clone, no IDE is supplied, but integration support exists fro Jedit and GWD
8. Direct support for GUI widgets manipulation in both block and Glade (XML) GUI modes
9. Logical reports transformation to CSV, XML, PDF and plain text

1. Windows & Java message based thin clients available
2. Support for databases other then Informix and Oracle a recent development
3. Fairly strict adherence to the the x4GL base syntax, missing support for Web Services, XML, PDF...
4. Relatively basic support for Web Browser clients
5. Free licenses when used against Informix database
6. Supplied ESQL/C compiler supports all Querix 4GL supported databases, but with somewhat limited compatibility with Informix-ESQL/C
7. No additional tools supplied, apart from somewhat limited IDE
8. Some configurable access to ActiveX controls on Windows thin client, but none from 4GL code
9. Plain text reports only

Evaluate Aubit if you feel confident about your knowledge, determination, and management support, and you are looking beyond a year or two. Make sure you don't immediately need functionality still lacking in Aubit, or that you can supplement it using another product.

Evaluate Querix if dealing with commercial company is a more natural fit for your organization, and you feel uncomfortable with OpenSource nature of Aubit's development process. Make sure you fully understands and accept limitations of Querix tools.

Four J's Genero vs. Four J's BDL/D4GL

1. Second generation x4GL product from Four J's
2. XML thin clients look much closer to what is today expected of GUI application
3. Most development efforts of the company will go into Genero
4. Relatively new product, of unknown stability and performance in large scale mission critical environments
5. Significant vendor lock-in. Once Genero-specific language extensions are extensively used in your code, it will no longer be compatible with other x4GL products.
6. New technology support, like Web Services, XML, etc.

1. First generation x4GL product from Four J's
2. "Block" message based thin clients look a bit dated, but are fully functional
3. No significant development will go into this product in the future
4. Mature, tried & tested, large scale production installations
5. No vendor lock-in. Almost all Four J's language extensions are implemented in several x4GL compliers
6. No support for XML or Web services

If you need x4GL compiler now, and need it if for mission critical tasks, look at BDL/D4GL first.

If you can afford to experiment a bit, and can benefit from features available only in Genero, give it a chance. Evaluate carefully if it is acceptable for you to become dependent on Four J's by using new language extensions.

In both cases, do the math first, as the cost in both products might be a factor.

x4GL vs. x3GL

Characteristic

(Note: all viewed from the perspective of Business Related Database Oriented applications development environments)

x4GL

x3GL

(C/C++/C#/Java/VB/COBOL/ASP/PHP/JSP...)

Crucial problem with 3GL skills availability is again the complexity of the technology itself. Anyone with determination can become "certified" Java or C# programmer,  however in my experience there are no more then maybe 1000 people on the planet I would call "experts" in any given 3GL technology.

Enormous size of dominant 3gl "platforms" like J2EE is a critical issue here. Knowing Java programming language itself, does not make one any more useful as a J2EE programmer, then a driver that knows how to change gears and turn the steering wheel is if he does not understand traffic signs.

Add to this requirements the knowledge related to relational database design and manipulation, including SQL and its RDBMS specific dialects, and then add a requirements related to business process analysis and understanding, as well as communication skills needed to make any member of a development team productive. From the above, it is easy to see why is an really good 3GL business applications programmer a very special person, and a very rare occurrence.

To compensate, typical 3GL development team will be several times larger then comparable 4GL team; as a result, the whole core issue of communication will become worse, and management of the team and the process challenging even for the best PMs.

Which is possibly the most common pitfall in skills selection in 3GL development environments - because of the size of technology knowledge needed, very few of the team members are expected to cover even half of all needed skills. (Contrasting this with 4GL developers, where we expect any member of 4GL development teams to be fully capable of all tasks). Therefore, 3GL team members need to be excellent communicators, to be able to share skills between themselves. Most IT industry analysts agree, that finding combination of high level technical skills and good communication and "soft" skills is rare occurrence.

From technology perspective, any x4GL is a future proof technology, as it provides abstraction layer that can accommodate new technologies transparently. For instance, when new Microsoft UI arrives with Longhorn,  as long as one x4GL vendor implements it, expect to recompile your x4GL apps and be able to use it.

Additionally, expect to be able to support multiple technology implementations in same group (Database, UI, middleware) from same code base, since abstraction layer shields you from technical details of particular implementation.

From technology perspective, all 3GLs are expandable, but there is no abstraction layer to shield you from manually making any changes needed to adopt or migrate to or from this technologies. For instance, when new Microsoft UI arrives with Longhorn,  expect to have to spend a significant effort to migrate to it.

And I did not say "use" with a reason - if you will want to use Longhorn APIs and at the same time continue using old Windows GUI, you will need to maintain two code bases, since there is no abstraction layer present to allow you to use both from same code.

Database portability is very high; depending on specific x4GL product, there will be some limitations in functionality that simply cannot be translated or emulated. In practice, expect very few of those when migrating between reasonably advanced databases.

Product portability is significant in most cases, and almost complete if your code is using pure I-4GL syntax. Expect to be able to compile 99% of your code out-of-the-box. And run it too.

Database portability is a utopia in 3GL world. Sure, you can CONNECT to any database imaginable, but differences between SQL dialects, combined with connectivity APIs differences and different behavior of databases themselves, all mean that even if you limit yourself to ANSI SQL92 semi-standard dialect, you will still have a significant effort to actually make it all work in the real world.

Product portability is very limited in 3GL world. C/C++ code written for MS VC will rarely compile any any other C compiler without extensive changes, and the same goes for Java implementations too. And compiling it is just the beginning.

In environments where IT is a "Business Supporting" or "Business Enabling" component, even if vendor has unlimited resources, arriving in the marketplace second will often mean loss of market share. Or worse.

When all the gains of productivity are put together, x4GL is undisputed champion here. It is common to expect gains of several multiples of scale. Simply put it, x4GL technology can be your "secret" competitive advantage, no matter which business you are in, as long as your business depends on time-to-market figures.

Folks without previous 4GL experience usually are not that harsh, but I am yet to hear claims of "adequate" or even "acceptable" speed of development using 3GL technologies.

The fact that this sentiment is almost universally shared between all 3GL development environments and tools, clearly shows that this is the shortcoming of 3GL technology, and not any 3GL product of language in particular.

In addition, users will often have to budget for additional components like Application Servers and 3rd-party component libraries, as well as for platform and databases dependencies in some cases.

However, in most scenarios productivity gains will successfully offset this.

Some 3GL product that appear to have low TCO will have hidden costs due to there dependencies on platform and/or databases. For instance, if your application is expected to live 5 years, and is written in .NET, expect to calculate in your TCO cost of Windows server licenses, plus all related Windows dependencies.

Add to the inherent complexity, high-level skills required of programmers, and common dislike of documentation and business process knowledge among highly technical people, and you get long update cycles and extensive re-testing after even minor changes.

I know of few that got canceled because of changing business needs, but not because of technology limitations, significant budget or deadline overruns (significant by 3GL standards, meaning 50% or more)

Decide what type of applications you want to make first.

If you are making operating systems, text processors, web browsers, video games or similar, you really have no choice - you will need to use one of appropriate 3GLs.

However, if you spend most of your time building and maintaining Business Related, Database Oriented (BRDO) applications, you do have a choice. The alternative has been there for a while, and it runs countless successful businesses for last 20 years.

If you do need a flexibility of 3GL, remember that 3GL is for x4GL applications just an underlying technology, just as assembler is underlying technology for 3GL, and machine code is for assembler. There will always be performance sensitive parts of 3GL applications that are written in assembler. You can always make parts of your BRDO application that require flexibility of an 3GL, using appropriate 3GL language.

It's not about the left or right choice, either. Everybody is talking about Services Oriented Architecture, and using, for example an x4GL to run a business process service that is accessed from UI clients written in, say, JSP and C#, sounds like a great example of it to me.

Very rarely will an organization make a good choice by selecting only one tool, or tool vendor. Which is what all tools manufacturers are trying to get you to do. So think pragmatic, and remember the saying:

"When all you have is a hammer, everything starts looking like a nail"