SWD GmbH QNX-Logo Windows-Logo Linux-Logo
Home
Über SW Datentechnik
Aktuelles
Produkte
  Katalog
  Aktionen
  Datenblätter <
  Produktassistant
  Technologien
Services
Dokumente
Kontakt
Suche

en


Slang

Die Programmiersprache für Rapid Application Development

Tatsachen in Kürze:

  1. Slang Code zu schreiben, ist einfacher als C Programmierung.
  2. Slang Programme sind klein, schnell und zuverlässig. Slang Programme laufen seit vielen Jahren ununterbrochen.
  3. Slang basiert auf einem LISP-Interpreter. Dies gibt Slang einige spezielle Fähigkeiten, die Sie bei anderen QNX Entwicklungsumgebungen nicht finden.
  4. Slang ist leicht in aktuelle Anwendungen einzubetten.

Was ist Slang?

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

 

Seitenanfang

SWD
GmbH