Results of MacLabs at MacWorld

ick sums it up.

Took the AppleScript MacLab (2 hours) and while the instructor may be “all that” in Automator and PeachPit circles, the class was rambling, undirected, and not very useful. Tried to cover waaaaay too much with nowhere near the depth even a beginner would need to get started. I could learn far more spending two hours poking around here and reading the tutorials here.

Also took the UNIX Scripting MacLab (2 hours) and it didn’t fit the description. I was looking for a very basic intro to UNIX command-line scripting…introduction to grep, awk, sed piping, etc. Turns out it was 4 hours of material tried to be crammed down to 2 and was aimed more at systems administrators coming from a UNIX-centric background and “having to work with” Macs. Meant I was 25-50% lost most of the two hours.

He did give a nice quick overview of the various shells and scripting languages, but his overview of AppleScript was aweful. Even someone like me realized his informaton on AppleScript was a few years out of date, he used bad terminology (they are handlers not subroutines or functions for crying out loud, for a start), and he never once mentioned the “do script” command (which given that he covered bash, perl, etc. would seem a natural thing to mention). I found that you could execute AppleScript from shell (via osascript) kinda ironic.

One thing it did do is help me appreciate the syntax of AppleScript or JavaScript. Bash seemed straightforward, but Ruby has the most bizarre syntax I’ve ever seen. Perl’s syntax is decent too. What do command-line geeks have against human-readable programming languages and scripting, anyway? ;-p Honestly, I’d rather use AppleScript with the necessary “do script” to do stuff faster or that AppleScript just can’t do than stick 100% with Perl or any other scripting for the “rapid development” I have to do 99% of the time. I like the idea that some other programmer can just read my code and make some basic sense out of it (this was brought home in the class where most students could tell what the AppleScript did just by staring at it).

Both classes I got something out of in my own peculiar way, but overall they were quite aweful.

And the Expo itself? I think they named it wrong, it was really iPodWorld or iPhoneWorld. Also disappointing unless you live a trendy, “mobile lifestyle.”

Ah well, cross my fingers for next year. ;p

The big advantage of AppleScript syntax is that it makes it easy to get a broad idea of what an existing AppleScript does, even if you don’t know the AppleScript language in particular or programming in general.

The big disadvantage of AppleScript syntax is that it makes it very difficult to form an accurate understanding of how it actually does it. For example, is ‘foo bar’ a property name, a constant name, a command name, a command name followed by a property/constant/variable name, or something else again?

With more conventional language syntaxes, you have the opposite situation: in order to make any sense at all of an existing script, you first have to learn to read the syntax and know some basic programming. OTOH, once you’re past that initial hurdle, it’s easier to understand exactly what makes it tick, e.g. x.foo_bar is a property name, :foo_bar is a constant, foo_bar() is a command, foo(bar) is a command name followed by a variable name, and so on.

The upshot of this is that AppleScript has a lower barrier to entry but higher cost of use compared to other languages. It’s a trade-off, but one that probably fits quite well with the needs of many AppleScripters, who write relatively small programs on an irregular basis. A high cost of entry will be harder to justify if you don’t actually use the language very often. OTOH, if you write large programs on a daily basis then what matters most is long-term productivity, and you’ll recoup the time taken to learn a language fairly quickly by comparison.

Amen!

I agree hhas, I agree. Well, to a point anyway. :wink:

Funny, your description is why I chose FaceSpan over Apple’s application development environment…though nobody here ever seems to get that. :slight_smile:

Ruby then must be ultimate by that standard (or the extreme example?)…looks super-shorthand. I can make some sense out of it, but it’s less human readable at a glance than any language I’ve seen in a while…and I’ve used some oldies (anyone ever played in line-BASIC?). Then there are things like JavaScript which go a bit overboard on syntax. Call me a fuddy-duddy, but some of the older precedural languages like C and PASCAL were reasonably human-readable, they just lacked features. Even line-BASIC was more or less human-readable.

I think language designers have fun inventing syntax and rules only the elite will understand, which keeps their club exclusive. Which is probably why I have some attachment to AppleScript…it speaks to the less-excluding side of me, the ease-of-use-that-is-Macintosh. I’ve used my share of cryptic and geeky languages, even before procedural languages, and I’m glad to be done with them. Same way I’ve used my share of operating systems and machines that needed too much tweaking all the time, and glad I found the Macintosh all those years ago.

Maybe what we need is some programming-language designer who is not so prideful of some existing language to meld the best aspects of AppleScript with something like Perl. Or just wait for AppleScript so slowly evolve (and it has, albeit VERY slowly).

For the record though, length of script has less to do with it that frequency. I write scripts relatively infrequently, but my “proudest creation” is Clorox File Repair…1400 lines of AppleScript application. You can write 'em long n-useful if you need to. :wink:

Okay, so I rant. :slight_smile:

Would you mind posting some of the Ruby code you are describing?

He posted some more wild examples (well, wild to untrained eyes, to hhas’ point), but you can poke-around here:

http://www.ruby-lang.org/en/

I think what strikes me odd is that it adds little periods and extra punctuation to what otherwise would be straightforward operations. Without delving deeper (no plans to learn Perl…PHP would be my next choice…), it seems counter-intuitive. Assuming these “accents” have some meaning to the learned, but still odd. I mean “5 plus 6” is easy, but why “5.plus 6” (note the period)?

On the plus side the Ruby site makes it look easier than JavaScript (and oddly, more human-readable), so maybe this is just another example of the instructor being a little out-of-touch on anything buy his favorite Perl and C++. See the false impressions he gave even me? :wink:

There are several languages that use dot notation:
JavaScript, Ruby, Python, Java and Objective-C 2.0 to list a few.

Once you understand the dot notation it is not hard to understand at all.

Take for example:


tell application "FileMaker Pro"
	tell database "MyDb"
		tell table "MyTable"
			show every record
		end
	end
end	

Using rb-appscript


app('FileMaker Pro).databases['MyDb'].tables['MyTable'].records.show

Is it really hard to understand what the Ruby code is doing?

One of the weaknesses of AppleScript is the difficulty to
transition from it to another language. Most of the other
languages have so much in common it becomes easier to move to a new
language. A few hours and you learn the syntax and after that begins
the long journey of learning the libraries the language has to offer.

Once you make the leap and learn another language, no matter which one
it is, you will start to see where AppleScript falls short.

I do want to say though that there is absolutely nothing wrong with
only knowing AppleScript. For many this is all they will ever need.

Cheers,

Craig

Which is true of any programming language…once you’re “in the know” it isn’t “hard” per se.

Not per se, but it’s still not human-readable in any quick, easy way. As someone whose job it is to convey information quickly and easily, Ruby falls short in all categories. Better than some though, I’ll admit. Glad the Ruby website set me straight on that count, unlike a certain MacLab instructor. :wink:

I agree, except I did it the other way around…I transitioned from the other languages to this one. :wink:

I find every programming language falls short in one way or another. :wink:

EDIT:

I should add, I have nothing against Ruby, JavaScript, or what have you. I just don’t understand in this day and age why more effort isn’t put into making these things easier to do for mere mortals. Programming langauges invented by programming geeks for programming geeks seems to lack forward-thinking. Always been a peeve of mine, despite some modicum of programming skill. Yeah, I can learn the crypticness, always have. But I always have seen it for what it is–unnecessarily cryptic. It’s like the obfuscations of politicians…at least that’s a useful analogy.

I just see the loss of potential…so many “non-programmers” have great ideas but lack the entry point to execute them. And so many bad, inefficient programmers who only get saway with it because their managers don’t know any better (modern OS’s and programs are rife with this idea).

shrug

Just a peeve of mine…been my observation that making it more accessible, like AppleScript tries to, is more the right direction than other languages, that’s all.

Only for certain definitions of “human-readable”. As mentioned previously, what conventional syntaxes lose in high-level readability (what it does) when compared to AppleScript, they gain in low-level readability (how it does it). e.g. Compare:


foo bar baz zim

versus:


foo(bar, baz=zim)

In order to understand the exact mechanics of any given AppleScript, you need good, detailed knowledge of every application and osax dictionary involved, and then work back from that to determine what’s a command, what’s a property, what’s a constant, etc. To understand the exact mechanics of any given Python/Ruby/etc. script, you just follow the syntax. e.g. The above Python code is a call to a function named ‘foo’, passing the value of variable ‘bar’ as a direct parameter and the value of variable ‘zim’ as a named parameter, ‘baz’. The above AppleScript is completely meaningless unless interpreted with reference to additional, external information. Don’t underestimate the value of a regular and unambiguous syntax, just because it doesn’t look attractive.

There is plenty of work being done on end-user programming (do a web search for the term). It just doesn’t get much attention in major OS distributions, which is a pity, but I can imagine it’s a tough sell. For my money, an environment more akin to MIT’s Scratch or Carnegie Mellon’s Alice would be much more appropriate for non-programmers than the current AppleScript language, albeit redesigned as a more adult-oriented, keyboard-driven tool (a lot of end-user programming tools tend to be aimed more at kids).

Agreed, though with the caveat that the biggest hurdle for novice programmers (particularly the self-taught ones) isn’t the lack of tools, it’s the absence of thinking skills that’d allow them to employ those tools effectively. Their ambitions often tend to outstrip their abilities in fairly short order, but if they aren’t even aware of all the tools and techniques that are at their disposal then how can they know where and how to use them? It’s like trying to express yourself as an artist when the only tools you have are pencil and paper and you’ve never read a book on art theory or history in your life. Sure you can make marks with that, but how much more are you missing out on?


p.s. Craig might like this: here’s a blog I ran across the other day that has a bunch of postings on using Ruby+appscript to do neat stuff like create NetNewsWire usage graphs: http://mph.puddingbowl.org/2009/01

Absolutely! Thanks. I am always looking for cool new ways to use appscript.

If you get a chance I would like your opinion on how I did with the
Sparkle Appcast Automation script.