Home » forums » LtU Forum

Jura, a OOMP language and potential DBMS

I am surprised to not find any results on LtU for Jura, which looks like a promising alternative to Java:

Jura is a data language and there is no difference between source code and data. However, Jura goes one step further - there is no difference between the jura text file that represents an object instance and the code required to create that object programmatically...Jura can be used to represent any structured data, not just classes. A Jura file can be created which corresponds to an instance of any Jura class...Jura allows such data files to be saved or loaded and validated at the language level. A Jura objectloader (corresponding to a Java classloader) is able to load and validate any structured data, not just classes.

Even though it's not persistence-inference, it is language-integrated persistence, which is a large leap ahead of manually coding persistence in LISP and Lua.

Jura also supports generic programming, abilities (somewhat like Smalltalk traits), restricted types, and transforms (similar to XSLT). In short, Jura seeks to abstract away OOP design patterns--it is object-oriented metaprogramming (OOMP).

By Winheim Raulsh at 2008-02-05 19:13 | LtU Forum | previous forum topic | next forum topic | other blogs | 5967 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Integrated persistence is desperately wanted

I am currently writing a new c++ application for our client that involves a GUI and structured persistent data. 90% of the 5000 lines of code I have written so far is about persistence and connecting models with views.

The guys next to my office are building a similar application in Java for another client, and they are using a database. Their code is 90% about structured persistence and connecting models and views.

I have spent around a month coding a persistence framework which I can reuse in the future and involves automatic identification of modifications, automatic persistence of modified state, a declarative style of defining run-time constraints and data validators, and many other things necessary for a data model.

The guys next to my office have spent 4 months doing the same thing, but with JDBC, which is much more complicated that what I did. The result is a framework that allows the programmer to declare the data model, the constraints and the queries with simple Java constructs, and everything else is adjusted automatically, including automatic persistence of changes, adjustment of the database schema and transactions.

With these frameworks, a complex data entry form can be built in 2 hours, with most time spent in adjusting the GUI. Without these frameworks, each form could take a week, with code patterns largely the same from form to form.

I am saying all this to prove how much effort, time and money automatic persistence saves. In my experience, most code in an application is not useful code that implements customer requirements, it is code that provides the backbone for writing the code which implements the customer requirements.

By Achilleas Margaritis at Thu, 2008-02-07 09:24 | login or register to post comments

I couldn't have said it better myself!

The next thing to do is distribution and concurrency inference.

By Winheim Raulsh at Thu, 2008-02-07 17:25 | login or register to post comments

Amen

I wonder how many things there are in the software world which: Cost a lot of time and therefore money. Aren't the main point from an end-user perspective. Are reinvented all the time. Maybe have libraries to do them but the libraries are complicated, or not sufficiently standard.

Things like replacing manual memory management with GC seems like an example where we're willing to abstract things away for the greater productive good. Or, as another example, Erlang leading you to do concurrency in a very particular way. Sure, the particular GC might not be as optimal as carefully and laboriously hand-rolled manual memory use, but in most cases why bother? Sure, you might not have done the Actor approach in Java, but in Erlang why would you not?

Seems like other aspects of our day jobs could likewise use help. Maybe DB4O or SQLAlchemy are decent examples in the field of persistence? Then I wonder how much it helps to have something good actually baked into a language - seems like having everybody agree on some basic core standard (people don't go changing their GC as often as they might switch trying persistence libraries across all the Java projects in the world) can really help.

By raould at Thu, 2008-02-07 18:06 | login or register to post comments

Re: Amen

db4o LINQ support shows a nice language integration (at least for queries):

http://evain.net/blog/articles/2008/02/06/an-elegant-linq-to-db4o-provider-and-a-few-linq-tricks

By german at Fri, 2008-02-08 05:08 | login or register to post comments

I agree that dealing with

I agree that dealing with persistence causes a lot of bloat. Unfortunately, making persistence transparent involves dealing with schema upgrade, which is a much, much harder problem.

By naasking at Thu, 2008-02-07 19:29 | login or register to post comments

reduplication of Datalog

I hate to sound like a fool, but why isn't an (independent) declarative data language, like Datalog, good enough? Of course, we do not want to suffer through SQL -- but SQL is not a well-founded language, and disappoints many people inside the relational community as well as out.

There is an endless list of services that people want for their language of choice -- creating them in a language specific form raises the barrier for new languages, as well as frustrating cooperation between projects in different languages.

By Jason Dusek at Fri, 2008-02-08 02:07 | login or register to post comments

Good point about the trade-offs

Agreed that if a language has "do it this way or else" then "this way" had better be damned good. Since everything can be pithily solved with just another layer or two of abstraction, maybe the API could be consistent but the plugged-in-back-ends could be open to development? Just trying to brain storm a way to have and eat cake.

By raould at Fri, 2008-02-08 18:44 | login or register to post comments