Re: Smile 252
Re: Smile 252
- Subject: Re: Smile 252
- From: Emmanuel <email@hidden>
- Date: Tue, 1 Jul 2003 18:57:14 +0200
At 12:14 AM +0200 30/06/03, Mikael Bystrvm wrote:
>
Excellent info on this thread so far, but something I'm sure more newbies
>
like myself would like to know is how Smile compares to Script Debugger
>
and Applescript Studio as a learning environment as well as a coding
>
environment. AFAIK Applescript Studio is also free. So what more options
>
are there in Smile for me than in As Studio for example and what do I
>
miss if I start out using AS Studio instead of Smile?
There are two issues in your question (the learning environment and the coding environment). Both are difficult to answer. Furthermore my opinion has to be biased since I belong to the company that makes Smile.
Though here I give my thoughts on these points.
I. Comparing Smile vs Script Editor as a learning environment.
Smile was designed as a productivity environment for scripters. Thus, most things that you can do in Script Editor, you can do faster or much faster in Smile. Such as, for instance, fixing an erroneous line and re-testing it: Smile's environment is much more favorable and fast for debugging scripts. This is mainly because of three of the features that you have been told already:
- on-the-fly execution
- persistence of the variables
- "Balance" and "Find definition" commands.
Let alone a powerful "Find" etc.
Though you have to know that if you use Smile "` la" Script Editor you will find it cumbersome and you won't smile. You have first to read the very concise on-line documentation (Help > Smile Help), a 5 or 10-minutes reading.
I don't know Script Debugger, but it seems an agreement that for debugging complex systems of scripts their sophisticated interface is very effective - not a beginner's issue, I think.
II. Comparing Smile vs AppleScript Studio as an application-making environment.
AppleScript Studio is better at making beautiful applications. For instance, don't expect to include a movie viewer in a window in Smile, not to handle the resize events as gracefully as in AppleScript Studio. The "databrowser" (the multi-column presentation like in Finder) is not implemented in Smile while it works in AppleScript Studio. Smile does not make aluminium.
AppleScript Studio allows for a layer in C (objective C). If your application has to perform some specific task that no one yet has programmed in a scriptable fashion, or some task that involves so big data that speed becomes an issue, you have to program in C and Smile does not allow that layer.
So, what is Smile good at?
Smile is multi-level. Let me illustrate with an example - an imaginary example - where I try to evidence Smile's ability to perform automation in successive layers.
Suppose my company produces numerical tables (such as, e.g., soccer scores or weather reports).
Suppose I think, oh, it would be better if I could make those tables into html's, and upload them to my web site. Surely this is an important issue for me - yet not a priority. Do I have some time today to make the ultimate table-to-html converter? Surely not. So, today, I'll just test some ideas. I'll make a draft script that I run manually. Testing new ideas is simple with Smile, since you may run lines individually. So far, I work in a text window. Gradually, as my scripts get more tested and more robust, I make them into handlers. I am already working, testing, and having results. My automation level is low.
When I have made enough tests, I can suppose my algorithms are reliable, I want to test them. Not on one file, but on any file. So, I shall make a dialog with two buttons "Open new table", "Convert to html". Within few minutes I realize that I should also have "Display in Safari" and "Display in Exploder". That's very fast with Smile, since Smile is its own Interface Builder (exactly like with Hypercard, for those who know Hypercard) and its own script editor of course. Here my automation level is higher: one click triggers the conversion.
Here I would say that I am in the AppleScript Studio level: that dialog box would be what you would have developed with AppleScript Studio - probably in much more time than with Smile [1], mainly for the reason that with Smile you never have to switch applications, the same application is the IB, the script editor, the debugger and the runner.
But the point with Smile is that, thanks to a very special and careful design [2] [3], "what you've done with Smile you can automatize in Smile". What would be my next step? Probably to convert plenty of tables. No problem with Smile: I have several ways to make what I have done more automatic. For instance, I can simply call the dialog by script, in a loop which will convert a large set of tables. Actually I could (not that it is a good idea, it's just to illustrate) make a "master" dialog which would use the other one as its "slave", and that would control from a higher level the conversion process: that "master" dialog would be aware of what files have and have not been converted etc.
Now, I still have to launch the process manually. Actually, the ultimate solution would be to process the files as soon as they are made. You would add this feature very easily with Smile - whereas with AppleScript Studio it would not be so simple.
Let me summarize: Smile is designed by a team of lazy engineers, who type very slowly and don't want to type the same thing twice. So, Smile is designed so as to promote as much as possible re-usability of your scripts. In French we say that it is "un outil de capitalisation du travail", a tool that capitalizes your work. Once you've made some script in Smile, that script will forever be included in your toolbox, it is part of your know-how. The Smile environment ensures it be so.
Thanks for your attention,
Emmanuel
[1] As a contest would prove.
[2] The founding concepts of which were first suggested by Cal Simone.
[3] This design is the reason for various features that may look odd to users at first. For instance, when you make up a dialog window, you use a "Palette" which is not like the other GUI editors, Hypercard, Revolution, Supercard, Interface Builder. Why ? Because, in order to keep Smile scriptable to full extent yet keeping it simple, the "Palette" itself a dialog. This kind of design options is what allows Smile today to be as consistent, as powerful and as versatile as it was when it was much simpler.
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.