Tatsachen in Kürze:
- Slang Code zu schreiben, ist
einfacher als C Programmierung.
- Slang Programme sind klein, schnell
und zuverlässig. Slang Programme laufen seit vielen Jahren ununterbrochen.
- Slang basiert auf einem
LISP-Interpreter. Dies gibt Slang einige spezielle Fähigkeiten, die Sie
bei anderen QNX Entwicklungsumgebungen nicht finden.
- Slang ist leicht in aktuelle
Anwendungen einzubetten.
Slang ist eine Rapid Application
Development Sprache, die speziell entworfen und optimiert wurde, um die
benötigte Zeit für die Auslieferung fortschrittlicher QNX und Photon Applikationen zu verringern.
Slang ist die leistungstärkste
Entwicklungssprache, die für QNX entwickelt wurde und minimiert
entscheident die benötigte Zeit und die Anstrengungen, die für die
Entwicklung von Applikationen für das Photon microGUI
benötigt werden.
Durch die Benutzung von Slang
können Sie schnell Algorithmen implementieren, die unter C oder anderen
Sprachen sehr viel umständlicher auszudrücken sind. Slang gibt den
Entwicklern den Vorteil von Zeit sparenden Features wie gesteigertem
Speichermanagement und verbessertem Photon Support. Diese Features, verbunden
mit der Fähigkeit, die Programme zur Runtime zu beeinflussen und zu
debuggen, bedeuten, dass Ihre Entwickler die Applikationen in einem kleinerem
Zeitrahmen entwickeln, testen und verfeinern können, als wenn sie eine
andere Entwicklungsplattform verwenden würden.
Welchen Vorteil erhalten Sie durch Slang?
1. Reduzierte Zeit bis zur Vermarktung.
Slang beinhaltet Features, die Ihnen
erlauben, schnell Applikationen für QNX und Photon microGUI zu
entwickeln. Die Programmierung in Slang ist ähnlich zu der Programmierung
in C oder C++. Der wirkliche Vorteil bei der Benutzung von Slang ist, dass es
mit Slang sehr viel einfacher ist, komplexe Algorithmen und Techniken zu
entwickeln, als mit C oder C++. Die Fähigkeit, Code leichter zu
entwickeln, reduziert die benötigte Zeit für die Entwicklung eines
Produktes. Sie benötigen ferner weniger Zeit für Debugging und
verfeinern das Programm während des Testens, denn Sie können dies
On-line, d.h. ohne die laufende Applikation zu unterbrechen.
2. Aktuallisierung laufender Applikationen.
Slang Programme können
modifiziert werden, während sie ausgeführt werden, und zwar an Ort
und Stelle des Endbenutzers. Bei Slang brauchen Sie nie mehr ein
vollständiges, ausführbaren Programm downloaden, um Fixes oder
Erweiterungen zu erhalten. Sie laden nur den Teil des Slang Programmes
herunter, der sich geändert hat. Dann, während die Applikation
läuft, wird der neue Code unbemerkt übertragen und ausgeführt,
ohne einen Neustart oder eine Unterbrechung dessen, was der Kunde gerade macht.
Die Zeitersparnis alleine kann
entscheident werden, wenn Sie in der Lage sind, Upgrades und Bugfixes in
kleinen Blöcken von Code zu senden, welche auf dem Gerät an der
anderen Seite der Internetverbindung automatisch verarbeitet und integriert
werden. Kurz Download-Zeit und unterbrechungsfreie Performenz auf der
Kundenseite sind gerade einige der Gründe, warum Slang so ideal für
die Entwicklung von Internetanwendungen ist.
3. Diagnose arbeitender Systeme.
Ihr technisches Supportteam erfasst
die Probleme der Anwender durch direktes Einwählen beim Kunden, so dass
sie mit der Applikation zur Laufzeit in Interaktion treten können. Die
Diagnose von Problemen On-line und die Möglichkeit, sinnvolle
Informationen über das System zu erhalten, versetzt Ihr Supportteam in
die Lage, die Probleme schnell zu beheben.
Unter Slang ist es ferner
möglich, Applikationen zu entwickeln, die fähig sind, mit eigenen
Fehler zu arbeiten und in geeigneter Weise zu reagieren. Sie können jeden
Systemfehler abfangen und haben die Möglichkeit, Fehler
zurückzusetzen und zu protokollieren, bevor der Benutzer überhaupt
ein Problem feststellen kann. Das Abfangen von Fehlern und das effektive
Arbeiten mit ihnen bedeutet, das Sie aus der Sicht des Anwenders,
'ausfallsichere' Anwendungen erzeugen.
4. Schnelle Überprüfung von Konzepten.
Bei der Entwicklung von neuen
Produkten besteht immer die Notwendigkeit, so schnell als möglich das
Konzept zu überprüfen. Slang erlaubt Ihnen, rapide einen Prototyp
der Applikation zu entwickeln, der schnell modifiziert werden kann, um den
unabhängigen Veränderungen der Entwicklungszyklen zu folgen. Wenn
Sie später dazu übergehen, Ihr Produktionssystem in C zu
implementieren, dann sind Ihre Oberflächen, die mit dem Photon
Application Builder (PhAB) für Ihren Slang Prototyp entworfen wurden,
100% compatibel. Sie können gleichzeitig unter Slang und C Applikationen
mit dem gleichen Satz von Oberflächen entwickeln, was dazu führt,
das sich Prototyp- und Produktionsentwicklungszyklen überschneiden dürfen.
5. Erweiterbarkeit
Sie können die Fähigkeiten
von Slang durch hinzufügen Ihrer eigenen C Funktionen erweitern. Dies
erlaubt Ihnen, Ressource intensive oder hoch spezialisierte Teile Ihrer
Applikation in C zu schreiben, ohne das Sie die ganzen Vorteile der Slang
Umgebung verlieren. Die Features, welche in Slang eingebaut sind,
beschränken Sie nie - Sie fügen die Funktionalität hinzu, die
genau das macht, was Sie wollen.
6. Minimalkonfigurationen
Hier sehen Sie etwas, was Ihnen sonst
kein Software Anbieter bietet. Cogent hat über 400 Funktionen in die
Slang Entwicklungsprache eingebettet. Diese beinhalten die Unterstützung
aller Photon Widget, der Interprozess Kommunikation und einiges mehr.
Lassen Sie uns annehmen, Sie haben
einen Entwurf Ihres Projektes vorliegen und sind nun in der Lage, zu
entscheiden, welche Teile der Photon Entwicklungsumgebung und welche anderen
Features von Slang Sie für Ihre Applikation benötigen. Cogent kann
einen run-time Slang Engine, bestehend aus einzig den Features und der Photon
Unterstützung, die erforderlich ist, anfertigen. Dies bedeutet, dass Sie
die Erfordernisse an die Hardware auf Ihre Anwendung reduzieren und Ihr
fertiges Produkt mit einer plattformgeschneiderten Software für optimale
Performanz ausliefern können.
Ein Vergleich zwischen Slang, Java
und C
Wir werden oft gefragt, wo die
Unterschiede von Slang zu anderen Programmiersprachen wie z.B. C und Java
sind. Aus diesem Grunde haben wir folgende Tabelle erstellt, um Unterschiede
und Ähnlichkeiten dieser Programmiersprachen hervorzuheben. Für jede
aufgelistet Eigenschaft haben wir das hervorgehoben, was wir als Vorteil
dieser drei Sprachen ansehen. Teilen Sie uns mit, was Sie darüber denken.
|
Eigenschaft
|
C
|
Java
|
Slang
|
|
Erforderlicher RAM
|
Klein.
|
Groß.Selbst kleine Java
Programme laden viel Library Code.
|
Mittel.Die Größe
konvergiert gegen die Größe von C mit
zunehmender Größe
der Applikation.
|
|
Disk Größe
|
Klein.
|
Groß.Eine große
Library Hierarchie muss auf der Disk existieren.
|
Mittel.Disk Größe
konvergiert gegen die Größe von C mit
zunehmender Größe
der Applikation.
|
|
Verarbeitungs- geschwindigkeit
|
Schnell.
|
Langsam.Ein großer Teil
des Systems ist eingebettet in Java. CPU intensive
Funktionen können,
falls nötig, in C geschrieben werden.
|
Langsam. CPU intensive
Funktionen können, falls notwendig, in C
geschrieben werden.
|
|
GUI Geschwindigkeit
|
Schnell.
|
Langsam.GUI Aktivität ist
immer umgeleitet durch den Interpreter.
|
Schnell.Das GUI Event
umgeht den Interpreter, wann immer es möglich
ist.
|
|
Entwicklungszeit
|
Langsam.
|
Mittel. Programmierung wie C++,
mit einigen Verbesserungen der Produktivität.
Programme müssen vor
Ausführung byte-compiliert sein.
|
Schnell. Vereinfach die
Photon Programmierung, da zusätzliche
Flexibilität und Leistung.
Programme sind just-in-time byte compiliert.
Ein laufendes Programm kann
modifiziert werden, ohne es zu beenden.
|
|
Verwendet PhAB
|
Ja.
|
Nein.
|
Ja. Slang kann jeder
PhAB dialog oder Window lesen.
|
|
Verfügbar unter QNX4
|
Ja.
|
Nein.
|
Ja.
|
|
Verfügbar unter Neutrino
|
Ja.
|
In Zukunft.
|
In Zukunft.
|
|
Implementation aller Photon Widgets
|
Ja.
|
Nein. Implementiert ein
virtuelles Window System, welches die meiste Photon
Funktionalität ausschließt.
|
Ja.
|
|
Erweitert Photon
|
Nein.
|
Nein.
|
Ja.
Ergänzt entscheidende Funktionalität und
vereinfacht die C Photon API.
|
|
Interpretierend
|
Nein.
|
Teilweise. Code ist einmal
geladen statisch. Vereinig die schlimmsten Attribute
von compilierenden und
interpretierenden Sprachen.
|
Ja.
|
|
Byte Code
|
Nein.
|
Ja.
|
Ja.
|
|
Dynamisch geladene Libraries in QNX4
|
Nein.
|
Nein.
|
Ja.
|
|
Dynamisch geladene Libraries in Neutrino
|
Ja.
|
Nein.
|
Ja.
|
|
Plattform Unabhängig
|
Teilweise. Alle Programme, die
nur ANSI Funktionen verweden, sind portierbar.
|
Ja. Programme stellen
vielleicht einige GUI und OS Interaktionen
unterschiedlich dar.
|
Nein.
|
|
Run-time modifizierbar
|
Nein. Das System muss neu
compiliert, gestopt und neu gestartet werden.
|
Nein. Das System muss neu
compiliert, gestopt und neu gestartet werden.
|
Ja. Das laufende System
kann gepatcht, abgefragt und debugget werden,
ohne sichtbare Auswirkung zum
User. Es wird stoßlose Update Technologie
verwendet.
|
|
Ausfährung von einem einzelnen File
|
Ja.
|
Nein. Erfordert
unterstützende Files auf der Disk.
|
Beides. Kann von einem
File laufen, oder benutzt separate Codefiles.
|
|
Bindungs- zeitpunkt
|
Früh. Der Linker erledigt
das Binden.
|
Spät. Der Loader erledigt
das Binden.
|
Dynamisch. Zur Laufzeit
wird das Programm gebunden. Der Code kann zu jeder
Zeit neu geladen werden
oder auch self-modifiziert.
|
|
Ereignismodelle
|
Festgelegt. Ereignisse haben
festgelegte Schnittstellen und müssen
vordefiniert werden.
|
Festgelegt. Ereignisse haben
festgelegte Schnittstellen und müssen
vordefiniert werden.
|
Offen.
Ereignisschnittstellen sind nicht festgelegt
und können zu jeder Zeit
definiert werden.
|
|
QNX Timer
|
Unterschiedlich.
|
Unterschiedlich.
|
Einfach. Nanosekunden
Timer implementierbar als 'one-shot', periodisch oder
time-of-day durch eine
einzige Zeile Code.
|
|
Aktive Werte
|
Nein.
|
Nein.
|
Ja.
|
|
Objekt orientiert
|
Nein.
|
Ja.
|
Ja.
|
|
Mapt Photon Widgets als Klassen
|
Nein.
|
Nein.
|
Ja.
|
|
Dynamische OOP
|
Nein.
|
Nein. Klassendefinitionens sind
statisch zur Zeit der Kompilierung.
|
Ja. Klassendefinitionen
können zu jeder Zeit geändert werden. Z.B.
können Variablen und
Methoden zur Laufzeit zugefügt werden.
|
|
Speicher Management
|
Nein.
|
Langsam. Stapelverarbeitung mit
stop-und-copy. Stack-searching garbage collector with
stop-and-copy.
|
Schnell.
Markieren-und-streichen Zuwachs, einspringender
Kollector erzeugt keine Kopie.
Mark-and-sweep incremental, re-entrant garbage
collector performs no copy.
|
|
Ankert im Operating System
|
Ja.
|
Nein. Unterstütz keine QNX
specifische Funktionalität.
|
Ja.
|
|
Re-usable PhAB Screens with Code
|
Nein. PhAB Graphiken
können wiederverwendet werden, aber der
zugrundeliegende Code ist verloren.
|
Nein.
|
Ja. PhAB Graphiken und
zugrundeliegender Code sind wiederverwendbar.
|
|
Erlaubt Vorlagenkreation in PhAB
|
Nein. Dialoge können
mehrfach instantiated, aber die Bezeichnung der
Widgets geht verloren. may be
multiply instantiated
|
Nein.
|
Ja. PhAB Graphiken
können zum Erstellen von Vorlagenklasse benutzt
werden, welche mehrfach
verwendet werden.
|
|
Unterstützung von Common Control Methodologies
|
Nein.
|
Nein.
|
Ja. State Machines,
Forward Chaining, Confidence Factors, Data Driven
Execution
|
|
Flexibele Entwicklungs- richtung
|
Ja. QNX kontrolliert
zukünftige Richtung der OS Entwicklung.
|
Nein. Die zukünftige
Richtung ist abhängig von dem Java Standard
Kommittee.
|
Ja. Die zukünftige
Richtung ist abhängig vom Feedback der Kunden.
|
|
Unterschiede in QNX und Photon
|
Nein.
|
Nein.
|
Ja.
|
|
Unterstützt den Verkauf von PhAB
|
Ja.
|
Nein.
|
Ja.
|
|
Verfügbarkeit
|
Jetzt.
|
Zukünftig.
|
Jetzt.
|
Katalogeintrag
Evaluationsversion
|