Quick facts:

1. Writing Slang code is easier than writing C code.
2. Slang programs are small, fast and reliable. Slang programs have been running in control applications for many years (continuously).
3. Slang is based on a LISP interpreter. This gives Slang some very unique abilities that you won't find in any other QNX development environment.
4. Slang is easily embedded into today's smart appliances and web devices.

What you gain by using Slang

1. Reduce time to market.

2. Upgrade running applications.

The time savings alone can be significant when you are able to send out upgrades and bug fixes in small chunks of code that are automatically handled and integrated by the appliance at the other end of the Internet connection. Small download time and uninterrupted performance at the customer site are just some of the reasons why Slang is perfect for developers of Internet Appliances.

3. Diagnose live systems.

Using Slang, it is also possible to develop applications that are able to deal with errors themselves and react in a suitable manner. You can trap any system error and have the appliance call back and report faults, before the user sees any sign of a problem. Trapping errors and dealing with them effectively actually means you can produce 'crash-proof' appliances, at least from the end user's perspective.

4. Quickly prove a concept.

5. Extend the functionality of Slang.

6. Customize Slang to meet your needs.

Now let's say that you have defined the scope of your project and you are able to identify which parts of the Photon development environment are needed in your application and how many of the other features within Slang you need to use. Cogent can fully tailor a run-time Slang engine to include only the features and Photon support you require. This means that you can reduce the hardware requirements of your Appliance and deliver the finished product on a software platform customized for optimum performance.

Slang vs Java vs C comparison

Property	C	Java	Slang
Running size (RAM requirement)	Small.	Large. Even small Java programs load a large amount of library code.	Medium. Run size converges on C run size as application becomes larger.
Disk size	Small.	Large. Large library hierarchy must exists on disk.	Medium. Disk size converges on C disk size as application becomes larger.
Computation Speed	Fast.	Slow. Large portions of system implemented in Java. CPU intensive functions can be written in C if necessary.	Slow. CPU intensive functions can be written in C if necessary.
GUI Speed	Fast.	Slow. GUI activity is always diverted through the interpreter.	Fast. GUI event path bypasses the interpreter whenever possible.
Development Time	Slow.	Medium. Programming is like C++, with some productivity improvements. Programs must be byte-compiled before run.	Fast. Simplifies Photon programming while adding flexibility and power. Programs are just-in-time byte compiled. Running program can be modified without shutting down.
Uses PhAB	Yes.	No.	Yes. Slang can read any PhAB dialog or window.
Available on QNX4	Yes.	No.	Yes.
Available on Neutrino	Yes.	Future.	Future.
Implements all Photon widgets	Yes.	No. Implements a virtual window system which excludes most interesting Photon functionality.	Yes.
Extends Photon	No.	No.	Yes. Adds substantial functionality and simplicity to the C Photon API.
Interpreted	No.	Partial. Code is static once loaded. Embodies the worst attributes of both compiled and interpreted languages.	Yes.
Byte coded	No.	Yes.	Yes.
Dynamically Loaded Libraries in QNX4	No.	No.	Yes.
Dynamically Loaded Libraries in Neutrino	Yes.	No.	Yes.
Platform Independent	Partial. Programs using only ANSI functions are portable.	Yes. Programs may exhibit some differences in GUI and OS interaction.	No.
Run-time Modifiable	No. System must be recompiled, shut down, and restarted.	No. System must be recompiled, shut down, and restarted	Yes. Running systems can be patched, queried and debugged in situ, with no visible impact to user. Uses bumpless update technology.
Executes from a Single File	Yes.	No. Requires supporting files on disk.	Either. Can run as one file, or using separate code files as appropriate.
Binding Time	Early. All binding is done by the linker.	Late. All binding is done by the loader.	Dynamic. All binding is done at run-time. Code can reloaded at any time, or even self-modifying.
Event Model	Fixed. Events have fixed interfaces, and must be pre-defined.	Fixed. Events have fixed interfaces, and must be pre- defined.	Open. Event interfaces are free-form, and may be defined at any time.
QNX Timers	Difficult.	Difficult.	Simple. Nanosecond timers implemented as one-shot, periodic, or time-of-day with a single line of code.
Active Values	No.	No.	Yes.
Object Oriented	No.	Yes.	Yes.
Maps Photon Widgets as Classes	No.	No.	Yes.
Dynamic OOP	No.	No. Class definitions are static at compile-time.	Yes. Class definitions may be changed at any time. Instance variables and methods can be added at runtime.
Memory Management	No.	Slow. Stack-searching garbage collector with stop-and-copy.	Fast. Mark-and-sweep incremental, re-entrant garbage collector performs no copy.
Operating System Hooks	Yes.	No. Supports no QNX-specific functionality.	Yes.
Re-usable PhAB Screens with Code	No. PhAB screens can be re-used, but underlying code is lost.	No.	Yes. Both PhAB screens and underlying code are re-usable.
Allows Template Creation in PhAB	No. Dialogs may be multiply instantiated, but widget naming is lost.	No.	Yes. A PhAB screen can be used to create a template class which can be multiply instantiated.
Support for Common Control Methodologies	No.	No.	Yes. State Machines, Forward Chaining, Confidence Factors, Data Driven Execution
Flexible Development Direction	Yes. QNX controls future direction of OS development.	No. Future direction determined by Java standards committee.	Yes. Future direction determined by customer feedback.
Differentiates QNX and Photon	No.	No.	Yes.
Helps to sell PhAB	Yes.	No.	Yes.
Availability	Now.	Future.	Now.