Fun Script, also known as F-Script, is a command-line based interactive Cocoa shell. The open source F-Script offers a new way to create and interact with Cocoa objects using a simple scripting language and a Smalltalk-like development environment. Recently, the F-Script shell went beta, providing a new way to interactively build Cocoa.

Moving from Objective-C to F-Script

F-Script, for all its Cocoa support, uses syntax that's similar to but not the same as Objective-C. The assignment operator is := and not =. Instead of delineating strings with @"", F-Script uses single quotes. Object/message pairs do not appear in square brackets; they're just listed one after another. Statements are separated by a period, not a semicolon.

This "almost-but-not-quite" approach is pervasive. On the one hand, everything seems really familiar but coding according to your normal Objective-C habits is bound to trip you up unless you internalize the F-Script way of doing things, an internalization that I was personally unable to achieve to any degree of reliable recall.

A language overview entitled Learn F-Script in 20 Minutes lays out the Objective-C/F-Script differences, showing you how to transform familiar Cocoa-style calls into F-Script ones. That's not to say that everything transforms without error. I ended up crashing F-Script over and over again when trying to perform selectors, a feature that's not entirely stable.

For the curious, the @selector() syntax of Objective-C transforms into a selector name prefixed with the pound (#) sign in F-Script. Here's a block object, which uses square brackets to delineate its statements. To run such blocks, use the value method to evaluate the code. This block causes the system object to beep:

beepScript := [sys beep]. beepScript value.

For target-action pairs, you'd pass the block as the target and the #value selector as the action.

Using F-Script to do stuff

The biggest problem with F-Script is that you need to go in having a really good idea of how you'd do something in Cocoa. Before you even start building your code, you sort of have to already have figured it out. That's because the calls remain as literal in F-Script as in Cocoa: all the little numeric fussy adjustments you'd normally make in Xcode remain in F-Script without a simplifying set of classes to do all the basic tasks you'd imagine that a system like this could provide.

Consider typical Cocoa code that creates an NSWindow, orders it out, gives it a title and starts populating it with sub-views. This couldn't get any more standard in its approach and yet I was really hoping for lightweight window and dialog features that would simplify the job for me.

> foo := 'hello world' > foo 'hello world' > foo length 11 > foo uppercaseString 'HELLO WORLD' > foo uppercaseString hasPrefix:'HELL' true

Yes, you retain all the control and style of the original Cocoa classes but you also inherit the Cocoa bookkeeping that comes along with creating these classes. You have to build exact extents and frames for each object and consider how each one is placed on-screen. So you win in terms of the interactive nature of F-Script but you don't move past the fussy little details that come along with Cocoa.