Warming up ISA
Iteration 4: What language to express ISA?
Before step into the real solutions for ISA, the way these solutions should be expressed has to be established.
As we will see soon, ISA should define its own language: ll. Primarily because having a common language to be run anywhere is necessary in a performant distributed environment like ISA. But also because the language must support several specific features either technical or functional, and in particular, those giving a foundation for the application life cycle.
Therefore, ll starts from the requirement phase and ends in the production one, going thru the design, the development and the tests.
So, with that broad scope, ll could be used to specify ISA in itself at least on a large part.
ll is a major part of ISA, this means that ll should be its own meta-model.
The main problem is that LL doesn't exist!
Another big problem is the difficulty to elaborate a so wide language.
Therefore, I would like to lean me first on existing languages that can serve as basement for LL. There are no much languages to do so, especially in the light of the following required properties:
- object Oriented and dynamic.
Because it's our underlying paradigm. - Have a very large scope (from the specification to the execution)
Be able to support consistently, and with traceability, the application life cycle in its whole. - Well experienced.
This means largely inspired from existing languages strengths and weaknesses. - Runnable.
Not just a conceptual language but one that can be executed on a machine. - Performant.
Not just runnable, but efficiently runnable, with no compromise on performance even if the oo paradigm must suffer that. - Simple and usable
Beginners, developers and business people must be able to write / read it quickly.
This means be basically textual, but also with intrinsic text enrichments and graphical capabilities…
At first glance I select only 5 languages that appear the more interesting compared to that properties: UML, BPMN, Eiffel, Python and of course Smalltalk.
However none of those ones do fulfill all the conditions.
The LL must also embrace all the phases of the software life cycle : Vision, requirements, business process, functionality, design, coding, test, production, maintenance. In that perpective, this global approach avoids the language mismatch between abstraction levels. Here is a list: Requirements / BPMN / Domain object model / UML use case / UML Classes / XMI / Programming Languages / Serialization languages / Languages for testing / Scripting / DSL.
One language to express them all: LL, Last Language.
The others approaches are mixes of more specialized languages. They are just not possible or over complicated. Of course, they may be more efficient locally, for there target purpose, but globally it's a plate of spaghettis. That's precisely what we live every days. Having a single language is the lone efficient solution, even if making this kind of language seems a monumental job. But it has to be done just one time.