archives

Latest usability for polymorphism?

Thinking about Scala recently (trying to grok now self types are used), I found it interesting to note that there are many features of a language's semantics which must play together well. E.g. there several types of polymorphism. I wonder how best a language design can make all the semantics usable (as in usability) in the three contexts of: writing code, compiling code, and running code? I think for me Scala might have gone too far, as others have said. Sounds like Fortress is considering self types as well. I guess I wonder if there will some day be a way to abstract the semantics somehow to keep the usefulness but lower the mental load on the developer.

I expect some people think this sounds like a weak developer looking for an easy way out; that isn't totally true in my case. :-) At the very least I think a devil's advocate could suggest that something complicated won't get far in industry.

[edit: hm, apologies if this sounds too much like already discussed thoughts. I guess I am (re) asking the question how far along the strict typing path to go before things collapse under their own weight, and people won't use it.]

Signals in an OOPL

In UML the boxes used to describe classes have three compartments: attributes, operations, and signals. This brings up an interesting question: should an OOPL deal with signals (and signal handlers) as primitive constructs that are independent from operations (i.e. methods). Of course we can implement signals as objects, and signal handlers as operations in a library, but perhaps it is so fundamentally useful that a language should support it natively. Especially given the trend towards concurrency in software. I only have vague ideas of how this could improve things, but I think that it could simplify writing concurrent programs by the programmer, since the compiler can identify the concurrency patterns, and verify the code.

I'd love to hear people's thoughts on the subject.

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).

Jumbala : An Action Language for UML State Machines

Jumbala : An Action Language for UML State Machines, Juro Dubrovin, Master's Thesis.

UML 2.0 is a language for modeling complex software systems. A UML model may describe the dynamic aspects of software as well as the static structure. We concentrate on models of reactive systems, such as embedded controllers or telecommunications switches. The behavior of such systems is modeled using UML state machines. Although UML defines the structure of state machines, it leaves open the choice of an action language,which is the language used to specify how the transitions of a state machine affect the configuration of the underlying model.

A UML action language named Jumbala is introduced. The language has been designed as part of a project where the goal is to formally analyze behavioral UML models. Jumbala is based on the Java programming language. It has nearly the same syntax and semantics for statements and expressions as Java. Some new programming constructs have been added to facilitate state machine modeling. Jumbala also supports object-oriented programming with classes and inheritance.

An interpreter that parses and executes Jumbala programs has been developed. The interpreter will be part of a prototype tool set for analyzing the behavior of reactive computer systems modeled in UML.

This is interesting because it is another example of efforts from the modeling community towards combining models and programming languages to provide a single compilable specification of software. Some of these efforts are being coordinated using the term model-driven architecture (MDA).

[edit: fixed formatting issues]