3 ms·

I think its a lot worse than this though; it isn't realistically a language for anyone. Anyone working on almost any task in Applescript is going to be frustra

I think its a lot worse than this though; it isn't realistically a language for anyone. Anyone working on almost any task in Applescript is going to be frustrated. In particular, just the ambiguities in the language for doing simple queries on containers makes writing even simple scripts needlessly painful.

__jal 10y ago
This. I can't remember what it was like before I learned a programming language. I do vividly recall my fights with compilers, however, and imagining trying to guess what Applescript wants in a particular context without reasonable notions of what was going on under the hood, and I would have become a plumber instead. Applescript is horrid. Seriously, every time I try to write something in it, it devolves into Googling for whatever weird, stilted 'natural language' variant is needed in a given context in the best case. The worst case is me wracking my brain for odd ways to write subordinate clauses that might make it happier. Applescript should be used as the definition of a write-only language. People like to bag on Perl, but even if you hate everything about Perl, it is still a vastly more human language than Applescript.
- function_seven 10y ago
  > Applescript should be used as the definition of a write-only language. It’s the opposite. Applescript is a read-only language. Very difficult to write, but easy to read code that’s already done. Whereas Perl is easy(?) to write, difficult to read. So it’s a “write-only language”.
mwfunk 10y ago
I agree 100%. Various attempts have been made to design "human readable" programming languages, where someone who wasn't familiar with the syntax (or with programming in general) might be able to read some code and get a sense of what it was doing. I've heard that COBOL was designed with this goal in mind- make the syntax a little more verbose and English-like, and in theory nontechnical business people could understand what it was doing. AppleScript took this concept and ran with it. The problem is that while this might (or might not) enhance readability, it definitely hurts writability. You end up with a verbose language with lots of extraneous and ambiguous syntax that isn't really well-defined. I've found AppleScript to be much more confusing than other languages, and if I wasn't a developer I would expect that to be 10x worse. I have met a few people who said they got started with programming by playing with AppleScript, but I can't escape the feeling that they got into programming despite AppleScript, not because of it. Maybe they picked it up first because it's always been pitched as a language for non-programmers, but it just doesn't seem to scale beyond something good for copying and pasting tiny chunks of code to tell an app to do something that otherwise can't be automated. It's useful as a tool to create and send Apple Events (which is really all it is- a wrapper around Apple Events), but its usefulness speaks more to the occasional usefulness of Apple Events as a part of the OS, than AppleScript itself as a language.

__jal 10y ago

This. I can't remember what it was like before I learned a programming language. I do vividly recall my fights with compilers, however, and imagining trying to guess what Applescript wants in a particular context without reasonable notions of what was going on under the hood, and I would have become a plumber instead. Applescript is horrid. Seriously, every time I try to write something in it, it devolves into Googling for whatever weird, stilted 'natural language' variant is needed in a given context in the best case. The worst case is me wracking my brain for odd ways to write subordinate clauses that might make it happier. Applescript should be used as the definition of a write-only language. People like to bag on Perl, but even if you hate everything about Perl, it is still a vastly more human language than Applescript.

function_seven 10y ago
> Applescript should be used as the definition of a write-only language. It’s the opposite. Applescript is a read-only language. Very difficult to write, but easy to read code that’s already done. Whereas Perl is easy(?) to write, difficult to read. So it’s a “write-only language”.

mwfunk 10y ago

I agree 100%. Various attempts have been made to design "human readable" programming languages, where someone who wasn't familiar with the syntax (or with programming in general) might be able to read some code and get a sense of what it was doing. I've heard that COBOL was designed with this goal in mind- make the syntax a little more verbose and English-like, and in theory nontechnical business people could understand what it was doing. AppleScript took this concept and ran with it. The problem is that while this might (or might not) enhance readability, it definitely hurts writability. You end up with a verbose language with lots of extraneous and ambiguous syntax that isn't really well-defined. I've found AppleScript to be much more confusing than other languages, and if I wasn't a developer I would expect that to be 10x worse. I have met a few people who said they got started with programming by playing with AppleScript, but I can't escape the feeling that they got into programming despite AppleScript, not because of it. Maybe they picked it up first because it's always been pitched as a language for non-programmers, but it just doesn't seem to scale beyond something good for copying and pasting tiny chunks of code to tell an app to do something that otherwise can't be automated. It's useful as a tool to create and send Apple Events (which is really all it is- a wrapper around Apple Events), but its usefulness speaks more to the occasional usefulness of Apple Events as a part of the OS, than AppleScript itself as a language.