Originally published at: https://latenightsw.com/about-script-debugger-lite/
With the release of Script Debugger 7, we’ve introduced a free version called Script Debugger Lite. You may be wondering what’s the catch - how can Script Debugger really be free? Here’s the deal.
Too bad there is no feature comparison vs Script Editor.
Isn’t this exactly what you said doesn’t exist:
Yes. I’m seeing SD 7.0, SD 7.0 Lite, SD 6.0 but no Script Editor.
@alldritt Do you want help to create a SE column or is it something you don’t plan to have on this table (I’d think if Lite is to “compete” with SE, it would be nice to have it though…)
Yes. That’s the sort of thing people need to have their noses rubbed in – gently, but not too gently.
-Chris
I think it would be disingenuous of me to compare Script Editor’s features with Script Debugger Lite using the existing table. Such a comparison would be skewed in Script Debugger’s favour because the table is made to highlight Script Debugger 7’s features over other versions of Script Debugger.
I do intend to document some important Script Debugger Lite features that the Script Editor clearly lacks. This will probably be done in video form where I can demonstrate how these features are used.
I agree. There’s a few things in that chart that are supported natively in any macOS document-based app (e.g., Tabbed windows, Versions), but pretty much every AppleScript feature is something that SE doesn’t have. I think the only major thing that SE has that neither version of SD has is support for JXA.
FWIW, I’m writing a long-form review of SD7 that will largely focus on the differences between scripting in Lite and scripting in SE (though due to other matters I simply haven’t got very far with it yet).
And, to a certain extent, its simplicity. It has everything that’s needed for most AppleScript writing and very little that isn’t. For learners and dabblers, it’s ideal precisely because it allows them to concentrate on learning the language and getting code to work without being distracted by the bells and whistles of an overendowed “scripting environment”. People who’ve been scripting for years may like it for similar reasons.
Script Debugger, on the other hand, is aimed squarely at already competent, possibly professional scripters who either work on extensive and complex projects, have deadlines to meet, need to use ASObjC, or would simply find a few time-saving features nice to have. Since different people will find different things useful, most will find SD packed with features they’re never going to use — and which may even be annoying if they can’t be switched off. I suspect that, except for the more gullible, potential SD users are going to be more impressed by the presence of one or two features for which they understand and feel the need than by the sheer number of features SD has which SE doesn’t.
Hmm, I think that’s subjective. Speaking purely from my own experience, I found SE intimidating precisely because it was so austere. I’d have welcomed an editor that offered something to explore (and ideally a tutorial mode like Vi).
Script Debugger has a lot of features, and it is a great tool for experts and experienced scriptures, but the ability to step through a script line by line, and see variables is ideal for someone just learning AppleScript and scripting.
I disagree.
Any comparison of a feature list is going to be skewed in favor of SD, just because it has so many more features.
If you had a table comparing SD7, SD7 Lite, and SE, how would it be different from the existing table?
How would it be less skewed in favor of SD?
I suppose having two tables makes sense from the perspective of different target audiences: existing SD6 users vs non-SD users (SE users). Those that see clutter everywhere would argue that having SD6 in the table adds unnecessary clutter. Perhaps. But for those who like data to make informed decisions, having the SD6 in the table shows the SD is alive and growing, a key feature IMO.
One option to consider is to have two tables, but organized differently:
You could also consider showing a small popup on the page on mouseover that defines the feature and provides a link (open on new tab) for details/demo. Personally, I really like this style because it allows me to quickly understand a feature, and get details if I want.
Just my 2¢.
Well subjectivity’s important, of course. My own experience when I started learning AppleScript twenty years ago was that I didn’t like Smile, Scripter’s icons-for-everything mentality made it unusable, and Script Debugger was too expensive for the advantages it claimed to offer and the payment method at the time too insecure. So I stuck with Script Editor, got used to it, and found it perfectly adequate until I started learning ASObjC a couple of years ago.
Trying to imagine how a beginner today might see things: they decide to have a go at learning AppleScript, join a help forum or two, and read several posts proclaiming with missionary zeal “Script Debugger’s much better than Script Editor! It makes scripting so much easier. I couldn’t manage without it!” So they go to the Web site and see the feature list alluded to above. Now that’s intimidating if you don’t know what most of it means!
But it seems to be one of the features explicitly excluded from SD Lite.
…and we can imagine different scenarios that would illustrate the opposite. I think the key is how much help does a tool offer a learner?
SD 's dictionary wins hands down on that one.
Neither offer much help with compilation errors, but SD does at least offer some help with completing quotes, one of the most frequent compile-time errors beginners are likely to make.
And as for run-time errors, all you’ve got to hand in SE is the possibility of using log. With SD Lite, the variables view is an absolute gift for beginners.
That said, I agree that SD is itself quite an intimidating interface when you first look at it. It’s why I always recommend people to watch the tutorial videos.
But it is in the trial.
That one feature (two features, actually, stepping and viewing variables) is so valuable, that if it were included free, some may not feel they need anything else. That could be self defeating.
That gives beginners just twenty days either to wean themselves off it or to fork out for a version with features they’re either never going to need or won’t be in a position to use until a few more paid versions down the line! 
Just to be clear, it’s only the stepping that requires the paid version. SDLite still gives you the variables view, and that is the main feature, IMO, that is a bonus for beginners.
Truth be told, in the 2 years or so that I’ve been using SD I’ve hardly ever needed to actually invoke the debugger itself because the variables view is usually enough to see where I’ve gone wrong.
Keep in mind that while I decided to display the value of global variables in SDLite, this display does not have all the capabilities of the full version of SD. It lacks the ability to look “into” container objects (lists, dictionaries and object specifiers). This means that there is no app object model exploration.