OE Vs other Db's

rzr

Member
A new / potential client of ours would like to know....

1. How the Progress DB compares with any other new DB out in the market.
2. What is the structure of this programming language? How does it compare with Other RDBMS
3. are there any migration tool or approach from Progress to Dotnet/Java"

Any thoughts / comments will be much appreciated :) ....
 
What is the structure of this programming language?

The answers to these questions would be easier to provide if we knew the context. What exactly you do for them? If you are a Progress application partner, providing them with an OpenEdge-based solution, then I think they should be less worried about dogmatic concerns like "is ABL truly OO", etc., and more concerned with practical matters like your pricing, service, support, features, and the applicability of your solution to their need. In other words, if they aren't writing the code then the nature of the language shouldn't matter to them. Which of course is quite a separate matter from the nature of the database. If, on the other hand, you are consulting for them and they are looking for an integrated development and database platform in which to do their own development, then that's another matter. I'll let someone more knowledgeable like Thomas, Tom, or RHD weigh in on that, but they might want a little more info to go on.

How the Progress DB compares with any other new DB out in the market.

Sorry, I can't help but be a little pedantic here. The "other" implies that the Progress DB is also new, which as you know it isn't. Also, I'm not sure why one would compare it against new databases separately from older ones. Any database of any vintage has strengths and weaknesses, and should be assessed as such based on the business needs. Different clients will have different priorities. A client looking for a data repository may want different things from an RDBMS than one looking for an OLTP back-end. A client with 1 TB DBs may have different needs than one with 1 GB DBs. A client with existing DBAs may have different needs than one that doesn't even have a single DBA and never will. If ease of use is at all important, I think OE is a strong candidate.

How does it compare with Other RDBMS

Same question?

are there any migration tool or approach from Progress to Dotnet/Java

Again, development is not my personal strong point, but ABL versus .NET/Silverlight/XAML doesn't have to be an either-or proposition. You can run OE end-to-end. Or OE in the business and data layers, with a .NET front-end. Or even OE code with a non-OE database. I am curious about their interest in migrating from Progress, which they're not using yet. But then I know very little about the situation so far...
 
How the Progress DB compares with any other new DB out in the market.
How would you compare yourself with anybody new out in the world? There are lots of databases out there and not all of them are relational like the OpenEdge database. You should be more specific as to which databases you mean.

What is the structure of this programming language?
Mostly I would say it doesn't because RDBMS usually are not programming languages. On the other hand many RDBMS support SQL to access their data - but I wouldn't SQL call exactly a programming language. You could compare the ABL with some other languages like C# or Java but they all miss the the data access and use "third party" technology to access RDBMS. The SQL and how it is used in languages like Java or C# is result set oriented whereas the Progress ABL is record oriented. That means in the SQL world you always deal with a set of records and you need to roll your own logic to handle them whereas the Progress ABL provides a extremely convenient way to work on a single record - be it iterative or having retrieved just one record (SQL does not know something like FIND or CAN-FIND).

As I do development in Java an Progress ABL to me the most important difference is:
  • The richness of Java comes from the zillions of libraries that you can use. The language itself does not have many keywords and most Java developers use only a handful of them on a regular base. In combination with the libraries (many of them are open source but some of them are commercial) you can develop anything in Java. But does it make sense: No it doesn't. I would never trade the Progress ABL when it comes to business logic for Java. Plus, the relational database world and they way you can work with it in the Progress ABL does not really fit into the OO concepts of Java. In Progress ABL you talk about tables and relations, in Java you have collections of objects (and an object in Java can really be anything).
  • The richness of the ABL comes from the language itself. The language has keywords for each and everything. If it doesn't you need to embed third-party technology - which you can. At the end there are some limitations but you can develop almost anything in Progress ABL. But does it make sense: Again, no, it doesn't. I would never trade Java and Java frameworks to build RIA (rich internet applications) for Progress ABL.
At this point I do need to state that I've never wrote a line of code in some .Net language.

When it comes to development environments then the support for Java in Eclipse is way better than the one the OE Architect (Eclipse plug-in) provides. Plus for the OE Architect you need to purchase a license. But, the fact that you don't need to purchase a license for Eclipse does not mean that it comes for free. Plus, some use something like RAD from IBM (which is based on Eclipse - I would say Eclipse several times raped) for developing EJBs, which is much more expensive.

How does it compare with Other RDBMS.
See above. You just don't compare with anything.

are there any migration tool or approach from Progress to Dotnet/Java
There are for Java but and the vendors claim things that I don't believe hold water in reality. Plus it depends whether you want to migrate an OOABL or a procedural piece of code to Java. The procedural structure of "classic" ABL procedure definately does not fit with the OO approach of either Java or .Net (C#, respectively). And that is where a migration tool must compromise both approaches to bring something from the procedural world into the OO world or vice versa. That way you will always get something like a least common denominator.

Heavy Regards, RealHeavyDude.
 
There are at least four companies I am aware of that do some version of converting ABL to .NET or Java. Only one has a system actually in production afaik, and one more is close. The .NET and Java code which results from such a process is predictably awful and requires a massive refactoring to become something one might actually want to live with. In fact, at the one site that is in production, they are still writing in ABL and translating to Java rather than writing in Java! Contact me off line if you want more specifics.
 
Back
Top