Re: Describing the Janus

"David Cressey" <david.cressey_at_earthlink.net> wrote in message news:JdlUe.9463$_84.7352_at_newsread1.news.atl.earthlink.net...
>
> "mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message
> news:%R6Ue.27154$FA3.821_at_news-server.bigpond.net.au...
>
>> We have created an object, some years back, similar in nature
>> to what you describe above. I have posted about it previously.
>>
>
> I'm impressed by your description of LittleSteps. I expect you've had
> some
> success with it.

Thanks, we've had some very happy clients but we are only a small company and our marketing has been practically non-existent to date.

We've had success with word-of-mouth sales, but need to gear up the product for use by other developers.

> As I understand it, the Janus has a very different purpose than
> LittleSteps.
>
> The purpose of the Janus is not to obviate the need for application
> programming, but to enable application programs and SQL databases to
> collaborate more easily and cheaply than is presently the case.

Application programming is not obviated, rather, because it is created using SQL and stored within the database environment as stored procedures, it has been "re-located". It is also very much optimised, because it there is min I/O external to the DBMS.

The cost benefits are actually enormous. Although the application needs to be maintained, this is done in SQL within the database. There is no client environment coordination, there is no middleware coordination. No compiler, no code to distribute external to the DB.

The key to understanding the cost benefits is the comparison between the change management of the LittleSteps arrangment, and change management of your traditional arrangment. The following articles covers this aspect:

http://www.mountainman.com.au/software/history/it6.html Change Management & the (Traditional) Development Cycle

http://www.mountainman.com.au/software/history/it7.html Change Management & the LittleSteps Development Cycle.

>Whether or
> not an information system has any need for some real programming, or
> whether the entire functionality can be built by simply plugging a
> database,
> a froms package, a report generator, and a user interface together, is a
> question that desreves separate study.

I guess when you say "real programming" you are referring to the traditional forms where lines of code are written in VB, C, or some other "programming language", and are then installed out in the client environment.

I have found that this functionality can be adequately handled by SQL alone, when used with this (LittleSteps) tool.

> I'm taking it for granted that the future of programming is going to
> continue to trend in the direction of OOP, and that the direction of
> large,
> shared databases is going to continue to trend if the direction of SQL.

The second proposition looks universal, while the first proposition may already have some counter example:

Trends over the last decade have seen increasing use of stored procedure objects interactively operating with the OOP objects.

This may be interpretted as a form of migration of lines of code from outside the DBMS environment (within the OOP objects in the client env, or the application server environment, into the DBMS environment.

If this migration were allowed to continue, the endpoint is towards your Janus scenario, very similar to LittleSteps, where there is only one single OOP object - being the single user interface for all the (application code) developed as SQL coded stored procedures.

> Those are arguable propositions, but I need to make some assumptions in
> order to make some headway.

The theoretical implications of this radical departure from traditional OOP standards stem from this massive reduction in the number of moving parts.

I have attempted to describe the theoretical benefits in a short article (also previously referenced in this NG) entitled " A Theory of Organisational Intelligence".

Readers should translate the term "Organisational Intelligence" as meaning the sum of all code used by the organisation PLUS the database itself. ie: traditionally, all OOP code objects and the corresponding database.

The article is written as a discussion rather than anything formal, and targets the theoretical benefits of the Janus/LittleSteps approach. http://www.mountainman.com.au/software/Theory_of_Organizational_Intelligence.htm

The theoretical reasons behind the (massive) cost benefits achievable with this approach are outlined and discussed in this article.

This article may serve to provide elements of differentiation between the Janus and LittleSteps.

-- 
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/software