Client concept, specification, programmer tasks, code in the broader sense, technical documentation, user handbook: a normal software application gets described 6 times during its development Example.
.sql
CREATE TABLE addresses (id INTEGER auto_increment, street VARCHAR(50), ..., PRIMARY KEY id)
CREATE TABLE customers (..., ADDRESS_ID, ...)
.java
@Table("addresses")
class Address {
...
@Column("street")
private String street;
public String getStreet() {
...
}
}
@Table("customers")
class Customer {
@OneToOne("addresses")
private Address address;
...
}
.xhtml
<c:outputLabel id="lbl_street" for="it_street">#{intl.street}</c:outputLabel>
<c:inputField id="it_street" minlength="5" maxlength="30" value="#{currentUser.address.street}" />
.properties
street=Street
...
...
...
The Lisilogic programming language answers this difficulty by being readable, even for non-computer specialists Example.
X
Each customer has an address.
An address has:
- a street, which is a string (min. length 5, max. length 50),
- ...
On the "Profile" page, the customer can:
- edit his address's street,
- ...
- click "Save" to save.
X
With Lisilogic the code, the specification, the documentation and the user handbook are all one.
Key features and differences to historical "human decorated" Basic dialects:
In common programming languages, you'll find "Street" in the specification, "STREET" and a maximal length (VARCHAR(50)) in the database, and in server-side code,
"street" or "$street" and a piece of business logic to ensure a maximal and a minimal length. The same thing is named several times differently and provided at
different places with (eventually faultily different) behaviors.
In addition, the code will contain endless many variants like getStreet(), input_id_street, etc., of which the programmer must know how he should invent them and
how the various compilers and servers will link them up with each other.
In Lisilogic you write "street" throughout, the system is clever enough to associate the variations of this word (streets, Street) and to use them correctly - exactly like a non-computer specialist would. The corresponding logic (in the example maximal and minimal length) gets described at only one place, the system is clever enough to use these informations correctly for every component (database, code, user interface). The necessary machine-oriented names are produced and managed automatically and reliably by the compiler and are neither given to read to the programmer nor to an innocent non-specialist.
These automatics are the reason why Lisilogic allows only programming in English: the other languages have much too complicated word flections.
But the very systematic English of Lisilogic can be translated very well automatically. Since this translation is automatic, it also ensures that no information
gets lost and that the complete application is translated consistently.
How many times in this world did programmers associate by hand an <input type="text" name="email" /> with a EMAIL VARCHAR(255) database column, a String email member variable, a checkEmailAddress(...) function und a sendMail(...) function? How many times did they have to invent the same error messages ("no valid email address", "could not send email", ...), and to document them, and to let them come to the user through a different mechanism? How many times did they forget something in this process and built in some typo or programming error?
Additionally to the usual boolean, int, float, string, text, etc., Lisilogic offers data types like the following out of the box, with a reasonable standard logic (UI, checks, functionalities, ...) and meaningful parameters (size, length, ...):
A readable representation of format strings with placeholders is in research. --> realized 04/28/2015!
XAdditional advantages of a readable programming languages are:
Experience shows that it is difficult to prepare the internationalization of an application during its development. Many tools promise it, Java's $NON-NLS$-tags and ResourceBundles are of good intention, but the reality remains: strings are used for such an overwhelming variety of purposes in common programming languages (as identifiers, as keys in maps, as placeholders in database queries, as email addresses, URLs and filenames, for SQL bits in PHP or Java, for GET and POST protocols, ...) that the programmers don't succeed in mastering the technically necessary strings and in replacing at the same time the text parts to translate with even more keys and distant references. Code where all meaningful words have been replaced with references to a resource file gets so unreadable that even the programmer who's writing it can't cope any more. These efforts are also often useless, because translating an application is much more complicated than just mapping text bits (words that get flected in a language remain invariable in another, the ordering of sentence parts is different, etc.), and because the documentation and the user handbook are written separately and must be translated separately - mostly by other translators, who choose a different wording, because they don't have the know-how and the technical background...
Lisilogic allows only programming in English. This ensures that no incomplete translations come into existence and that the programmers don't waste time in
failed translation attempts.
But the English of Lisilogic is very systematic: it remains a programming language, that doesn't allow the variability and inventions of natural language.
This systematic English can be translated automatically: automatic translators are provided along with Lisilogic, that can be nourrished with the necessary technical
vocabulary; Lisilogic extracts automatically the terms to translate and an adapted tool facilitates the translator's job.
Automatic translation also ensures that the results are complete and consistent through the whole user interface and documation.
The translations don't have to be stored, they can be generated from the code on demand: this enhances also their actuality.
Every application that stores personal data must comply with the privacy protection laws. This compliance gets verified and certified by sworn consultants.
Nowadays these consultants accomplish their inspection by going to the development company shortly before the end of the programming phase and by investigating
the specifications and technical documentation.
The programmers get forced to produce the missing documentation at the most stressing time, just before release - or alternatively, to prevent this situation
by producing the documentation earlier, during the development. The result of both approaches is that the documentation doesn't match well the real code:
quick last minute production generally doesn't leed to quality, and early documentation seldom gets updated. So the expensive sworn consultants supposed to
protect citizens against data abuse do check... wind.
With Lisilogic the consultants can read the code, so they inspect exactly what the application really does.
XLisilogic doesn't make the task of the programmers easier, but it doesn't make it more difficult either: Lisilogic's grammar is exactly as strict as any
usual programming language, and the informations it needs are identically precise. The code is a bit more "florid" but less scattered and less redundant.
There are no more mandatory effect-free comments; clarity and cleanliness of the code are no more sources of reproaches and efforts, they become part of the job instead.
The interactions of programmers with other participants of the development process are more relaxed, because everybody understands what they've done.
Further advanced programming tools (Fully Structured Editor) are planned for the purpose of learning and to simplify the programming tasks.