BEFORE WE GET STARTED with programming an experimental project, it is important to consider which language is best suited to the project's needs. Below we will look at some of the criteria on which languages are evaluated.

Selecting a Development Environment for Experimental Interactive
In order to choose a development environment, a number of factors are involved. It helps to look at the layers of programming involved in interactive environments. Analyzing the input, output, data, methods and handling layers of the development process will give a clear picture as to whether an environment will offer enough features, with a learning curve smooth enough to allow interactive prototyping.

Input/Output
Interactive environments react to a number of inputs to produce an output. In the context of what we are discussing, the output is visual and possibly auditory as well. Input comes from two forms:

1) immediate, real-time user input from input devices like the mouse and keyboard

2) static data, which is saved in an external data file, or hard-coded into your programming.


It is the input and output that defines the user's understanding of the interface. The seek out a suitable environment for 3D development, we must look at the input/output capabilities of a product first.

Methods/Handling
Where things get tricky is when a programming language has all of the necessary input/output features a designer is looking for, but the coding is too intense, or the output doesn't have the performance to deliver a convincing experience to the user.


Low-Level Languages: Designers, Don't Try This At Home
Languages like Java and C++ are the best for creating software from the ground-up to be solid, robust applications. However, they are crap for prototyping. They are so low-level that it requires extensive knowledge of the language, as well as the underside of your operating system to even get to the point where your programs will do anything. In this case, the methods layer, which is the programming offloaded to the system to make your data more easily accessible to you is minimal. It is up to the developer to handle the raw data, and create their own functions to display information to the user.


High-Level Languages: From Flash to Flashy
Flash is an efficient method for developing and implementing 2D web-based interactive. While a number of input/output options are available, performance is often hampered by Flash's computational overhead. This is the tradeoff for an environment that offers quick prototyping by hardwiring things like animation of all elements into the system.


Mid-Level Languages: Introducing Processing
Processing is a project initiated by Ben Fry and Casey Reas at the MIT Media Lab. It is essentially a series of extensions written on top of Java to allow designers easier access to the power of lower-level languages. Processing offers the opportunity to publish interactive work into a browser plugin for the web or run as an installation, just like Flash does but with far less clutter in the compiled program. The tradeoff is the lack of a cushy user-interface to import your art files and compose your animation and layouts. Processing is intimidating in that there is no immediate feedback when designing. Fonts must be loaded-in using code, and there are no keyframes to time your animation. Its a more scientific way of treating input and output. That said, the Processing language is not inaccessible for users of high-level languages such as Actionscript or javascript, which conform to the same ECMA-262 standard as Processing. Processing also has built-in methods for communicating with external devices via the serial port, something perhaps not impossible, but highly impractical in Flash, and native support for 3d transformations.