posted by acaben
on Thursday June 05, @09:45AM
from the dept.
Philippe Mougin writes "F-Script is a lightweight object-oriented interactive and scripting layer specifically designed for Mac OS X object system (i.e. Cocoa). F-Script version 1.2.4 greatly enhances the integration between F-Script and Cocoa, and comes with extended documentation."
Apple have been working on this thing called the Open Scripting Architecture (a.k.a. osascript, a.k.a. Applescript) which allows you to script *any* application running under Mac OS - source code or no source code, Cocoa or no Cocoa. I've even seen it used to control a Java MP3 player from a mobile phone - it's that flexible and really easy to use too.
Another bonus about Applescript is that it's bundled with every Mac OS distribution, including some of the 'Classic' disties. --
How do I use open source software [macslash.org] with my Mac?
by
Anonymous Coward
on Thursday June 05, @03:28PM (#56)
AppleScript and F-Script are more complementary than concurrent. AppleScript is mainly for automating and coordinating applications (defining workflow between apps etc.). On the other hand, F-Script is a scripting language like Python, Perl or Ruby. With F-Script don't send messages (or events) to other applications (you can do it but it's not the main feature), you send messages to Cocoa objects. This is why it is common to see F-Script embedded into applications.
In many cases, if you use F-Script, you don't even have to develop a whole application: you just develop the Objective-C classes relevant to your domain; then you dynamically load them into F-Script and use them directly from F-Script, which provides a very user-friendly experience. One thing to check is the object browser, a graphical tool that let you instantiate objects and invoke methods using the mouse.
F-Script is also a must-have tool to interactively learn and explore Cocoa and to test your own Objective-C classes. Not something AppleScript was made for.
--ikJoe
by
Anonymous Coward
on Saturday June 07, @01:01PM (#33914)
You just lost all credibility. Perl is a hack but it's a fairly well-known hack, and you can be forgiven for bringing it up. Python and Ruby are toy languages used only by computer hobbyists. There is no place in a serious discussion for those names.
Ever heard of Brad Cox? He was the guy who designed Objective C. He uses Ruby extensively these days. I assume you haven't heard of Red Hat, a company who base their in-house Linux configurification software exclusively on Python.
1) The Open Scripting Architecture has been around a LOOOONG time, i.e. since System 7. It's the architecture that other languages plug into, like AppleScript, HyperTalk, Javascript, etc.
2) osascript is a command line utility for running OSA scripts from the command line.
3) AppleScript is an OSA language, and it's been a part of the OS since the System 7 days.
by
Anonymous Coward
on Thursday June 05, @04:59PM (#33934)
Don't forget AppleScript's early-binding OO, and its ubiquitous serialization. Also, it's far easier to write AppleScript code thanks to its unambiguous grammar, something that a language like Perl makes very difficult by the nature of its "DWIM" philosophy and vague syntax. AppleScript also has more powerful types, including lists *and* records, and most scripting languages lack the latter. Javascript, for example, has only arrays. There's also a matter of speed. Since AppleScript can be compiled, and because its closely tied to the OS, it's able to execute a great deal faster than most scripting languages. Also, the large number of commercially developed applications means AppleScript is far more flexible and usable.
All very good points. I think if I wanted a scripting language that could actually bind to Cocoa rather than just UI-level stuff, I'd be tempted to consider Ruby. The object paradigms are very similar to Objective-C (both being derived from Smalltalk), and for a scripting language it's not tardy at all.
If you're programming Cocoa, F-Script is great for testing out your code.. you can put the F-Script pallete in interface builder and then send messages to your objects directly from interface builder. I cannot emphasize how cool it is to ask views directly for thier super views without writing and compiling any special code.
And if you think you're a h4x0r, try out F-Script anywhere. You can attach it to any Cocoa app... even ones you don't have the source code for! It's great fun to play around with the innerds of the iApps... even more fun if you combine this with the class dump utility (I'm too lazy to look up a link for it, google for it).
And from a purely language point of view f-script is cool in the stuff it's adopted from array programming language (APL). If you like vectorizing stuff in matlab, read the f-script manual and give f-script's vectorization a try -- you'll see what all you'e been missing in matlab's limited world.
One final endorsement, if you're learing Cocoa -- open source projects like F-script are great. I've learned a lot by looking through the F-script source. "Terminal" is OS X's killer app.
...on why I should even consider looking at this, if I have AppleScript Studio.
I mean, I can use AppleScript to automate applications, and I can also use AppleScript Studio to bulid Cocoa applications in AppleScript. Why do I need another scripting language here?
Not trying to start a flame war. I just really don't see the point.
by
Anonymous Coward
on Friday June 06, @05:43AM (#12537)
Well, AppleScript Studio and F-Script operate at different levels.
While AppleScript Studio is mainly for building applications, I think F-Script is really useful for interactively using Objective-C objects, and for automating task using Objective-C objects. For instance, look at the F-Script object browser described in this article on Mac DevCenter to see the kind of level you get for direct object manipulation with F-Script.
AppleScript has its own data model, which is different from the Cocoa/Objective-C object model. To Access Cocoa from AppleScript Studio you need to go trough a quite heavyweight bridge (both conceptual and technical). While this is quite useful, this also introduces its deal of complexity, limitations and bugs. With F-Script, the data model is the Cocoa/Objective-C object model. You directly manipulate Objective-C objects, and so you avoid the problems created by bridging two technologies. In the end, if you're interested , for whatever reason, in directly accessing Cocoa objects, F-Script provides a quite light, straightforward and powerful solution.
F-Script is cool for exploring Cocoa. For instance, look at the following F-Script code (extracted from the F-Script manual). It uses standards Cocoa objects and methods to produce a little graphical animation. You can past it in the F-Script console window to execute it, then modify it a little bit to see what append, thus interactively learning a lot about Cocoa.
A comparison between F-Script and PyObjC or RubyCocoa wouldn't make too much sense. Anywho, I'll give it a whirl. There are likely more on either side, but just off the top of my head-
Pros of F-Script (Cons of PyObjC/RubyCocoa) * If you are already a ObjC programmer, F-Script will be a lot easier to pick-up. There are a few more language features in F-Script (blocks, other more-Smalltalk-ey constructs), all of which are pretty useful. Going from ObjC to F-Script in one's mind is very straight forward. If you don't already know a good bit of Ruby or Python, you have more learning to do when one wants to use one of them to script a Cocoa app.
* Because F-Script is Smalltalk derived (as is ObjC), using the Cocoa API is a bit more natural, syntax wise. That is, in F-Script, you'd call this made up example keyword method like so:
obj add: 4 to: 10
Which is how you'd use it in ObjC. In RubyCocoa and likely PyObjC (can't recall for sure), you would type:
obj.add_to_(4, 10)
The weird underscores kind of ruin the beauty and simplicity of Smalltalk/ObjC syntax. Different ObjC bridges have a different means of this sort of conversion, but it is very similar and something any language with a more confined messages syntax will have to hack around.
* F-Script supports integration with Cocoa and other ObjC libraries more seamlessly. You'd never know you were using objects and methods from another language.
* The F-Script runtime is smaller and much is much easier to integrate into any Cocoa app. Both Ruby and Python are quite a bit bigger, and are nowhere near as easy to add to a Cocoa app. With F-Script, you can simply add it in IB, and get a console where you can probe the innards of *any* Cocoa app, regardless of whether or not you have the source. Which is slick. PyObjC and RubyCocoa require more setup.
* F-Script has better tool support than PyObjC or RubyCocoa. Which is horrible, as both Python and Ruby have had a helluva head start. It is very easy to browse ObjC classes and instances in F-Script using introspection and reflection. The culture around Python and Ruby seems to be afraid of a decent IDE in this sense, and it especially hasn't found its way to the ObjC-bridge world with these systems.
* If you're new to ObjC/Cocoa, the stuff you learn from using F-Script is more easy to apply to ObjC/Cocoa than going from PyObjC/RubyCocoa to ObjC/Cocoa.
Pros of PyObjC/RubyCocoa (Cons of F-Script) * Can be used for more programming tasks. That is, F-Script cannot be used for creating new classes or methods, just calling existing methods on existing classes. This limits how you use F-Script a good deal. PyObjC and RubyCocoa on the otherhand aim to be full programming languages, rather than just a really nice scripting system.
* If you already know Python or Ruby, things could be a bit easier. Although, you still have to learn the Cocoa API, which is a lot more work than mere syntax.
* Python and Ruby may have libraries you cannot get in ObjC, and leveraging both Py/Rb libs and ObjC libs could be useful. Not sure if there are any important examples of this, but its a possibility considering Py/Rb's wider use.
Tired of languages that are focused on the machine rather than the human? >> Squeak Smalltalk
my first point: the advantage of using Python and Ruby is tha ability to use some of their more powerful language constructs, for example dictionaries (hashes):
in Python (I dont know Ruby):
mydict = {}
in ObjC:
NSDictionary * mydict = [[NSDictionary alloc] init];
I mean c'mon, Python certainly has a HUGE advantage over ObjC/Cocoa here in terms of terseness.
my other point: I think the Cocoa method names need to be adapted to the language features that Python/Ruby have.
Example:
in ObjC/Cocoa:
NSPasteboard has the meathod
- (id)initWithURL:(NSURL*)url byReference:(BOOL)byRef
the same in Python should be:
def __init__(movie=0, pasteboard=0, url=0, byRef=0):
Below is an extract from the F-Script 1.2.4 announcement that I posted to the Cocoa developer mailing list. It provides further information about the main characteristics of F-Script. I hope this is useful to better understand what F-Script is about:
----------------
F-Script may interest you as a Cocoa developer as it provides the object-oriented interactive and scripting layer currently missing in the Cocoa stack. It allows interactively exploring, testing and using Cocoa-based objects and frameworks.
[Some features:]
F-Script introduces an innovative programming model based on the integration of array programming and object-oriented programming. This model shines in its ability to express computations at a high level of abstraction, allowing one to manipulate and query whole sets of data at once. As a result, complex expressions manipulating entire sets of objects are easy to design and are expressed in an extremely compact manner, without requiring the explicit use of loops, tests, or navigation instructions. The same expressions would require several tens or hundreds of lines of code in conventional object-oriented programming languages. In the recent weeks, I have worked hard with my buddy Stéphane Ducasse on a new paper describing this model. It is included in the F-Script distribution, and you can also get it at http://www.fscript.org/download/OOPAL.pdf
AFAIK, F-Script is the only open-source scripting environment for Mac
OS X using Cocoa as its native object model.
The graphical F-Script object browser (a.k.a. "behavioral inspector")
allows users to interactively invoke methods on any Cocoa or custom
Objective-C object from a point-and-click, NSBrowser based, graphical
interface. Other graphical tools like the F-Script array inspector
provide powerful means for the exploration of objects.
F-Script can be embedded into other applications thanks to a set of
extremely easy to use components. In addition, F-Script can be
dynamically injected into any Cocoa application at run-time, with the
"F-Script Anywhere" technology developed by Nicholas Riley.
F-Script is already used in various fields including game development,
software debugging, astrophysics, biology, music analysis, embedded
extension language etc. It is released free of charge, as an open
source software with a BSD-like license.
The F-Script project is sponsored by the European Smalltalk User Group and SQLI.
