Development Speed

[ConvertFromOldNGs]

by Larrikin >> Fri, 3 Dec 1999 17:56:50 GMT

JADE's OO Database must make it a lot quicker to develop. Especially when compared to something like Java where you have the problem with mapping to (say) ORACLE or DB2. Does anyone have any experience with this, like is using JADE measurably faster?

[ConvertFromOldNGs]

by Carl Ranson >> Sun, 5 Dec 1999 22:07:15 GMT

IMHO - this is the major advantage that Jade gives you over other toolsets. Its also one that I've found quite hard to explain to people.

But consider the simplicity of
begin
Transaction;
create customer;
customer.name := "Mr Smith";

create purchase;
purchase.value := '100';
purchase.myCustomer := customer;
commitTransaction;

There is a distinct lack of computer related concepts here. No files, no tables, no records. The only thing thats for the languages benefit is the transaction.

Its like the argument in user interface circles that file|save is a unnecessary concept to burden users with because it forces the user to deal with the computer concept of memory vs disk storage.

I would say that the difference between Jade and other languages in terms of the persistent storage support has a significant effect on development speed.

Regards,
CR

[ConvertFromOldNGs]

by Tim Duggan >> Thu, 9 Dec 1999 22:06:18 GMT

Here's some raw data you might find interesting.

I just had a look at a couple of systems I implemented in the past. The following metrics were gathered using wc. I divided the sum from the db module in each case from the sum of all modules (.c files) in the app. The 'db' module in each case provides a database independent abstraction layer to perform insert, update, delete, and select/find of each 'persistent thang' used in the app.

1. C (OS/2) app to read data from a file and insert into SQL Server database. Based on lines of C code, 32% of the code was for database access.

2. C (Unix) app to read from Oracle database and pass data to client connected via a socket. Also based on lines of C code, 27% of code was for database access.

Although these apps aren't of an interactive nature, they give you an indication of the proportion of code that is necessary to access (map to) a relational database. Jade wouldn't require these db mapping modules.

I used to think half my code was db access, but it looks more like a third. Still a significant saving.

My 2c worth,
Tim Duggan

[ConvertFromOldNGs]

by The Swami >> Fri, 11 Feb 2000 4:38:28 GMT

For Database Developement JADE is definitely faster. You don't have to conect to databases, log in work an interface between it and your application or any of that stuff.

Interfacing to the database via forms is also a snap and very easy to do as your forms are in the same repository as your data.

However all this power comes at a price and you pay it when you want to turn your database app into a windows app that does the same stuff as your other windows apps. Try to issue Word Basic comands (like mailMergePrint etc) to MSWord, use Active X xontrols with certain data types and other such fancy bells and whistles and you will find that JADE will be out of its depth very quickly.

You will most likely wind up writing DLLs to bridge the gap and at that point you will start burning up extra resources that you diddn't before. However if you dont need any of that stuff then you should getprobably a 10% improvement in developement speed.

This may sound low but all my experience (and every decent book I've ever read on the subject) has told me to dismiss any claim of a more than 15% improvement in development speed from a new tool as rubbish.

[ConvertFromOldNGs]

by Geoff McIlraith >> Mon, 14 Feb 2000 22:00:17 GMT

However all this power comes at a price and you pay it when you want to turn your database app into a windows app that does the same stuff as your other windows apps. Try to issue Word Basic comands (like mailMergePrint etc) to MSWord, use Active X xontrols with certain data types and other such fancy bells and whistles and you will find that JADE will be out of its depth very quickly.

You will most likely wind up writing DLLs to bridge the gap and at that point you will start burning up extra resources that you diddn't before. However if you dont need any of that stuff then you should getprobably a 10% improvement in developement speed.

Just a specific comment... In Jade 5.1, you will find that ActiveX server and control support is MUCH improved.
Including support for all ActiveX datatypes, and support for Automation Servers (such as Word).

Cheers, Geoff

[ConvertFromOldNGs]

by Wilfred Verkley >> Tue, 15 Feb 2000 2:38:09 GMT

Se we will we be able to create and interface to any COM object (specifically and most importantly Microsoft's ADO)?

This would be a big bonus. Having to write DLL's or ActiveX controls as "bridges" to other systems is a very big hassle.

Wilfred.

[ConvertFromOldNGs]

by Geoff McIlraith >> Tue, 15 Feb 2000 21:58:35 GMT

Se we will we be able to create and interface to any COM object (specifically and most importantly Microsoft's ADO)?

I'm sure that we'll find a very small number of COM objects that don't work correctly, but the intent is to fully support those that conform to the COM spec. One thing that has become very apparent in this work is that a fair few of the COM objects out there (including ones written by Microsoft) don't fully conform to the COM spec, and don't always behave as expected. The person implementing it (not me) has spent a good amount of time and effort working out which parts of the COM spec to make "flexible" in order to get the large majority of COM objects to behave as expected with JADE. From my read of the ADO spec, I didn't notice anything that would cause me to think it wouldn't work.

This would be a big bonus. Having to write DLL's or ActiveX controls as "bridges" to other systems is a very big hassle.

Good stuff eh?

Cheers, Geoff