Konzept des Auftraggebers, Spezifikation, Aufgabenverteilung, Code im erweiterten Sinne, technische Dokumentation, Benutzerhandbuch: eine normale Software-Anwendung wird im Laufe ihrer Entwicklung 6mal beschrieben Beispiel.
.sql
CREATE TABLE addresses (id INTEGER auto_increment, strasse VARCHAR(50), ..., PRIMARY KEY id)
CREATE TABLE customers (..., ADDRESS_ID, ...)
.java
@Table("addresses")
class Address {
...
@Column("strasse")
private String strasse;
public String getStrasse() {
...
}
}
@Table("customers")
class Customer {
@OneToOne("addresses")
private Address address;
...
}
.xhtml
<c:outputLabel id="lbl_strasse" for="it_strasse">#{intl.strasse}</c:outputLabel>
<c:inputField id="it_strasse" minlength="5" maxlength="30" value="#{currentUser.address.strasse}" />
.properties
strasse=Straße
...
...
...
Die Programmiersprache Lisilogic adressiert diese Schwierigkeit, indem sie lesbar ist, und zwar auch für nicht-Informatiker Beispiel.
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
Damit sind Code, Spezifikation, Dokumentation und Benutzerhandbuch eins.
Entscheidende Merkmale und Unterschiede zu den historischen "menschlich dekorierten" Basic-Dialekten sind:
In üblichen Programmiersprachen steht in der Spezifikation "Straße", in der Datenbank "STREET" und eine maximale Länge (VARCHAR(50)), im Server-Code "street" oder "$street" und ein Mechanismus, der eine maximale und eine minimale Länge erzwingt.
Damit wird das selbe Ding mehrmals unterschiedlich genannt und an verschiedenen Stellen mit (eventuell fehlerhafterweise unterschiedlichen) Verhalten versehen.
Nicht alle Beispiele sind so einfach: wer erinnert sich nach 3 Monaten noch daran, dass ein "Änderungsantrag" der Spezifikation (und hoffentlich des Benutzerhandbuchs...) im Code "ModificationProposal" und nicht etwa "ChangeSubmission" heißt?
Dazu kommen im Code zahllose Varianten wie getStreet(), input_id_street, usw., von den der Programmierer wissen muss, wie er sie zu erfinden hat, und wie die diversen Compiler und Server sie miteinander verknüpfen.
In Lisilogic wird für "Straße" durch und durch "street" geschrieben, das System ist clever genug, um die Varianten dieses Wortes (streets, Street) miteinander zu verknüpfen und korrekt anzuwenden - genauso wie ein nicht-Informatiker es tun würde. Die dazugehörige Logik (im Beispiel minimale und maximale Länge) wird nur an einer Stelle beschrieben, das System ist clever genug, um diese Angaben für die unterschiedlichen Komponenten (Datenbank, Code, Oberfläche, ...) automatisch korrekt umzusetzen. Die nötigen maschinen-orientierten Varianten der Benamsung werden dabei automatisch und zuverlässig vom Compiler verwaltet und weder dem Programmierer noch einem unschuldigen nicht-Informatiker zu lesen gegeben.
Diese Automatismen sind der Grund, warum in Lisilogic nur in Englisch programmiert werden kann: die anderen Sprachen haben viel zu komplizierte Wortflexionen.
Dafür kann das sehr systematische Englisch von Lisilogic sehr gut automatisch übersetzt werden. Dadurch, dass die Übersetzung automatisch ist, wird auch garantiert, dass keine Information verloren geht, und dass die gesamte Anwendung einheitlich übersetzt ist.
Wieviele Male haben Programmierer dieser Welt ein <input type="text" name="email" /> mit einer EMAIL VARCHAR(255) Datenbankspalte, einer String email Membervariable, einer checkEmailAddress(...) Funktion und einer sendMail(...) Funktion per Hand verknüpft, sich jedesmal erneut Fehlermeldungen ("keine valide Emailadresse", "konnte Email nicht senden", ...) ausdenken (und dokumentieren!) müssen und sie mit einem jedesmal unterschiedlichen Mechanismus bis zum Benutzer durchgereicht, und dabei irgendetwas vergessen oder irgendeinen Tipp- oder Programmierfehler eingebaut?
Lisilogic bietet zusätzlich zu den banalen boolean, int, float, string, text, usw. Datentypen wie die folgenden out of the box, mit einem sinnvollen Standardverhalten (UI, Checks, Funktionalitäten, ...) und sinnvollen Parametern (Größe, Länge, ...):
In Forschung ist eine lesbare Darstellung von Format-Strings mit Platzhaltern. --> Verwirklicht am 28.04.2015!
XZusätzliche Vorteile einer lesbaren Programmiersprache sind:
Die Erfahrung zeigt, dass es sehr schwierig ist, während der Entwicklung Vorkehrungen für eine Internationalisierung der Anwendung zu treffen. Viele Tools versprechen es, die $NON-NLS$-Tags und ResourceBundles von Java sind guter Absicht, aber Fakt bleibt: Strings finden in den üblichen Programmiersprachen eine so große Vielfalt an Verwendungen (als IDs, als Keys in Maps, als Platzhalter in Queries, als Emailadressen, URLs und Dateinamen, für SQL-Stücke in PHP oder Java, zur Kommunikation per POST und GET, ...), dass die Programmierer es meistens nicht schaffen, gleichzeitig die technisch erforderlichen Strings zu beherrschen und die zu übersetzenden Textstücke durch noch mehr Keys und Fernreferenzen zu ersetzen. Code, wo alle bedeutenden Wörter durch Referenzen zu einer Resource-Datei ersetzt worden sind, wird auch so unlesbar, dass selbst der Entwickler, der dabei ist, ihn zu schreiben, nicht mehr klar kommt. Diese Bemühungen sind auch häufig vergeblich, weil die Übersetzung einer Anwendung viel komplizierter als ein Mapping von einzelnen Textstücken ist (Wörter, die in einer Sprache flektiert werden, werden es in einer anderen nicht; die Reihenfolge der Satzteile ist anders, usw.), und weil mit den üblichen Programmiersprachen die Dokumentation und das Benutzerhandbuch extra übersetzt werden müssen - meistens von anderen Übersetzern, die dabei andere Wörter auswählen, weil sie nicht unbedingt Fachwissen und technischen Background besitzen...
In Lisilogic kann man nur in Englisch programmieren. Damit ist gesichert, dass keine unvollständigen Übersetzungen entstehen, und dass die Programmierer keine Zeit in misslungenen Übersetzungsversuche verschwenden.
Dafür ist das Englisch von Lisilogic sehr systematisch: es bleibt eine Programmiersprache, die die Vielfalt und Kreativität einer natürlichen Sprache nicht zulässt.
Dieses systematische Englisch kann automatisch übersetzt werden: automatische Übersetzer werden mit Lisilogic angeboten, die mit dem Fachvokabular gefüttert werden können;
Lisilogic extrahiert automatisch die zu übersetzenden Begriffe und ein entsprechendes Tool vereinfacht die Arbeit der Übersetzer.
Durch automatische Übersetzung wird auch garantiert, dass die Ergebnisse vollständig sind, sowie durch die ganze Oberfläche und Dokumentation einheitlich.
Die Übersetzungen müssen nicht gespeichert werden, sondern können bei Bedarf aus dem Code erstellt werden: damit ist auch ihre Aktualität verbessert.
Jede Anwendung, die nominelle Daten speichert, muss die Datenschutzgesetze einhalten. Dies wird von vereidigten Consultants geprüft und zertifiziert.
Zur Zeit führen diese Consultants ihre Prüfungen durch, indem sie gegen Ende der Entwicklungsungsphase sich vor Ort begeben und die Spezifikationen und technische Dokumentation der Anwendung untersuchen.
Dadurch werden die Entwicklungsfirmen gezwungen, im stressigen Moment kurz vor der Abgabe noch die ganze fehlende Dokumentation zu erstellen - oder alternativ, diese Situation
vorzubeugen, indem sie die Dokumentation ganz früh erstellen, noch während der Entwicklung. Beide Ansätze führen dazu, dass die Dokumentation wenig mit dem tatsächlichen Code
zu tun hat: schnell in letzter Minute erstellt ist keine gute Voraussetzung für Qualität, früh während der Entwicklung dokumentiert heißt fast immer unaktualisiert. Damit prüfen
teure vereidigte Consultants, die den Bürger schützen sollen, ins Leere.
Mit Lisilogic können die Consultants den Code lesen, und prüfen damit genau das, was die Anwendung tatsächlich tut.
XDie Arbeit der Programmierer wird mit Lisilogic nicht vereinfacht, aber auch nicht komplizierter gemacht: die Grammatik von Lisilogic ist genauso streng
und die von Lisilogic angeforderten Angaben sind genauso pingelig wie bei den üblichen Programmiersprachen, der Code ist "blumiger" aber weniger zerstreut und weniger redundant.
Kommentare, die nichts bewirken aber trotzdem Pflicht sind, gibt es nicht mehr; Klarheit und Sauberkeit des Codes werden nicht mehr als ständige Vorwurf- und Anstrengungsquelle gesehen, sondern als Teil der Arbeit.
Die Interaktionen der Entwickler mit den anderen Teilnehmern des Entwicklungsprozesses werden entspannt, weil man versteht, was sie getan haben.
Zwecks Einfachheit der Programmierarbeit und Schulung sind weitere fortgeschrittene Programmierwerkzeuge (Fully Structured Editor) in Entwicklung.