But why should it resolve it? “maybe an undocumented quirk” is not too far from “probably shouldn’t work”.
It has the same functionality as Nigel’s code but it’s safer and closer to how dictionaries should work, it works no matter what the string of the key contains. After all pretty on topic to me.
:/property list suite is something else, it is to read and write to property files, not to work with it as associative arrays. So I don’t see your point in writing that right now 
Hello.
I actually did see your point in posting that right now, and therefore I edited that sentence away from my post.
I am not sure in the moment, if you have to create the property list file at disk, in order to manipulate the contents, but once you have the structure in memory, you can certainly add and retrieve keys -at constant time.
A property list in itself, at least contains a dictionary, therefore, I posted that as yet an example of a dictonary, which has been around for a while, and also to illustrate the example, that I just didn’t make a sour remark, that we had dictionaries in AppleScript already, when you posted your hashmap, even with inbuilt persistent storage.
Edit
Albeit somewhat slower since properties are stored on file immediately, I believe the items to be retrieved from memory however, during lookup.
I was posting while while you were editing
For MS maybe, but not for work.
Using a limited supported file, a wrapper application and some custom code required in order to make it work like a dictionary is not something I would call “dictionaries in AppleScript” but just another self implemented approach.
However to create records on the fly you can simply turn a list alternating key (string) and value (any object) into a record using the AppleEvent manager.
First of all, you are actually dead wrong in that, for work too, I mean if you work in a garage or something, then that may be true, and I am not saying that one shouldn’t judge the quality of the end product, but the process of achieving something better be open minded.
Secondly, I am dead sure that the property list file implementation of System Events rely on NSPropertyList, which in turn uses NSDictionary, so I am pretty sure that it is good enough for work.
The culprit, or boon in other situations, is that the keys/values are automagically written to disk, and not in a batch. This lowers the usability, if you have to store many keys at once, but has the advantage of the values written to storage asap.
So, it is a speed versus robustness approach.
Rhetorical question:
What constitutes an abstract datastructure? -Is it the implementation that should govern, or the properties it provides?
My answer to that questin would be that we have abstract datastructures to provide for implementation independency, so that we can implement them they way we see best fit in some problem solving situation.
To me someone who can’t handle critics or remarks about his quality of work isn’t open minded at all. Someone who is open minded does respect another’s opinion and will listen to what the other person has to say, even if the subject of the conversation is his own written code.
At least practice has showed me right.
Edit: last post, unless topic is getting on-topic again.
I agree with you in that in general, of course, but when the critique is expressed in an overbearing, or condescending tone, then there may be reason to react.
I didn’t not critisize your code in any way: You expressed your opinions, and I expressed mine.
I am also finished with this, unless it gets on track again.
Edit
My view on Computer Science in general, is that it is all about tradeoffs, and that there are very often parameters, that governs which solution is right, and that there at least very seldom exists solutions, that is a “cure-all” for a particular problem.
There is no class NSPropertyList, you probably mean NSPropertyListSerialization.
And the root object of a property list is not required to be an NSDictionary, it can also be an NSArray.
Sorry for the inaccuracy regarding NSPropertyListSerialization, when referring to the dictionary, I was more into the PropertyLists of System Events, I’m quite sure that using an array as a root-object, isn’t a solution there (but I’m not betting on it).
Thanks for the correction Stefan.
No, no. Not blaming you for missing it. Everyone learns by mistakes. This is why practice.
It’s useful info to skim over. Even if you don’t understand the half of it (which is fine; I certainly didn’t), it gives you an idea of what patterns to look for and where to go to fill in the rest of that know-how when the time is right.
Except the implementation doesn’t do that, nor does the documentation caution users to do it themselves. And even if it did, what happens if you then pass in another key that already contains NUL characters of its own? And, like I say, there’s other concerns like how performance goes down the toilet as the correction grows large, and what about deletions and stuff too? Five-minute hacks are all very well, but they have a terrible habit of biting you in the butt come minute six, and blossoming into a five-hour/five-day/ongoing PITA thereafter. Which you might accept as Just One Of Those Things if it’s some unique task that nobody else in the world has ever done before, but for something as humdrum and ubiquitous as this it’s really unforgivable that we’re still at this stage in AppleScript after 20 flipping years when the rest of the world had it solved 40-50 years ago.
This is why I’m so pissed at Apple: people use AppleScript because they’ve got immediate problems that they want to solve, not because they’ve nothing better to do than teach themselves a whole CS degree. You don’t empower users by forcing them to scrabble in the dirt day-in, day-out. This is why everyone but us has reusable libraries, so that basic, generic, everyday operations such as “store a whole bunch of values under arbitrary keys so that they can be retrieved again later” do not require an academic education or deep technical skills to perform: just the ability to read a few lines of documentation and type a couple commands verbatim.
That’s the power of programming: stuffing all the boring, tedious, micromanaging BS completely out of the way, so you can get on with the things you’re actually interested in. And it’s something that AppleScript’s keepers have not only failed to promote and support, they’ve actually encouraged the opposite: hand-to-mouth exchange of “priceless technical knowledge”, that’s actually just a load of self-aggrandizing garbage: Dunning-Kruger egotism and clueless, incompetent amateurism raised to high art.
Not clear what you mean. Caveats with different key-value data structures are things like performance characteristics when adding/removing/searching keys, and what type(s) of keys are accepted.
Again, the nice thing about having a prebuilt library like Cocoa or whatever is that the folks who’ve built it have already considered these issues and optimized and tested the total crap out of it, which they can afford to do because that’s their job, and by doing so they’ve just made millions of users’ jobs that much easier: because for 99.9% of day-to-day tasks, what they’ve provided is more than good enough to meet those users’ needs. Which means those users now have much more time to devote to solving the original parts of their problems, rather than just rebuilding the same old dreary wheels Every Single Time they want to get anything done.
This is true, but there are original problems and there are problems that have already been solved a myriad times before by folks much, much smarter than you or I. Trying to re-solve the latter is just so much make-work, not to mention excellent opportunity to introduce exciting new mistakes of your own. Better to reuse what already exists, and dedicate the time saved to the parts of your problem that are original. Having the ability to think algorithmically ought to be a complement, not an alternative, for plain common sense and ability to deliver on budget and time.
This is why I love working around end-user programming and end-user programmers so much: dealing with folks whose heads are still bolted on really keeps you grounded in timely serving real-world solutions to real-world problems, lest one disappears up one’s own indulgently playful but practically useless abstract ass. 
[edited for clarity]
Traditionally, a [get] SPECIFIER as TYPE request kicks the job to the specifier’s owner - in this case ASOC - to resolve as it sees fit. And ASOC is fine with specific type names like integer, string, list, and so on, so assuming it’s using Apple Event Manager mechanisms as they were designed to be used, as opposed to doing weird, janky, everything-a-special-case nonsense (which I’ll admit is something a helluva lot of developers do do), then there should be no problem with anything as well, since that’s just one more type name that the AEM already knows how to deal with.
For instance, if you want to extract an Apple event’s direct parameter and don’t need it to be a specific type:
AEDesc directParamDesc;
OSErr err = AEGetParamDesc(theAppleEvent, keyDirectObject, typeWildCard, &directParamDesc);
This is a standard documented AE feature, working exactly as designed, ever since System 7.
Yeah, I’d be happier too to have the absolute official word from ASOC’s authors that it is indeed working exactly as designed, but a. they almost never speak to me (I do their egos no favors at all), and b. I strongly suspect I understand this stuff better than they do (a thought no-one finds more terrifying than me!). So I’m about as confident as I can be after a decade of trying to black-box reverse-engineer AppleScript’s inner workings to the best of my limited abilities. Caveat Emptor, E&OE, and so on.
The fact that “as number” fails suggests there’s more to it.
Really? I wonder why that is.
So you keep telling us.
Hello hhas.
First of all, Nigel whipped up his associate array, that is more of a typeless bag of unique values.
unlike associative arrays, or NSDictionay, it can hold anything, and I am pretty sure that if you store the list as an AppleScript Object, then it serializes quite nicely too!
I hadn’t expected that one, if it came from Paul? Berkowitz, which have had some pretty amazing solutions to problems in the past. He couldn’t have spent so many hours on it, so you have to give some slack.
I agree with you in most of what you write, but with AppleScript version 2.3, our world really took a great step forward, with the ability to use ASOC libraries in our scripts. Just learn cocoa, and you have all the power you need, (not ironic). Other than that, there has been much reusable code around, and many good libraries, but not a central one. But then again, I don’t complain about that, as good as google are nowadays, you’ll usually find some code, you at least can tailor to suit your needs.
Problem is that people who want to solve immediate problems with AppleScript doesn’t have the prerequisites for using the libraries anyways. They didn’t teach you algorithms and datastructures at school because you were supposed to implement them, it was really so that you should learn a little about them, and how to use them. (Too build Algorithms, you should have a course in Discrete Mathematics really, so you understand the underlying fundamentals.)
AppleScript is supposed to be simple, easy to learn and use, and without libraries and other overhead, it has been more or less so.
(My first script, was to start up, or kill “Hack” when run in X11 during Christmas 2006 it was a great kick to have it up and running via the contextual menu plugin I used under “Tiger”.) Realistically, you don’t need much datastructures for everyday tasks, until you start with more complex scripting, like scripting Indesign and the like, and I have no idea how many end users has any ambition in that direction.
Being a bit realistic, if you Script apps: ties together, or extracts/arranges data the way you need them, most of the time in my scripting career, I haven’t had the need for some stdio.h or other library, because the standard suites, comes with most scriptable apps (but with fallacies like collapsed/miniaturized), and from thereon, there are little reusable stuff to be had, since I work directly onto the object models of the apps most of the time.
My point is, that AppleScript was really meant to be “glue-code”, and when used as glue, there aren’t such a need for libraries, than in other languages, since the object model itself is the library kind of in a Small-talkish way. That may have been Apples rationale for not creating any stand alone libraries. I like the freedom this entails, then you get rid of the Nazis and high priests, who can point to some standard, and the “one right way” of doing stuff.
And, it isn’t so, that libraries are a cure all for all problems in other languages, there are always some dark corners, and spots that needs some special treatment. Look at other languages, Python 2.5 versus 2.6 for instance, or Perl version 5. versus verion 5.6, there may be problems with using libraries written for one version, from the other.
Some languages like C, have a good library, but sometimes, even that isn’t sufficient, and you have to come up with your own stuff for memory manangment for instance, or you need something tailor made for some hardware.
Some of all of this may be a reason for any reluctance from Apple to build libraries for end users in the past, is that it is hard to make stable libraries, in an environment that constantly change. Scripting dictionaries, are really volatile creatures, that may undergo significant changes between versions of an app due to the process where the object model of an app is made.
I guess most of us have the handlers for any datastructures by now, but it is still fun and interesting to implement algorithms that leverages the internals of AppleScript.
If I really wanted good stable libraries, I guess I’d be programming Java a long time ago, being in an environment without such gives a creative freedom, without a bunch of “Soup Nazis” and High Priests, that tells you that you are defecting from the “One and Only True Way”.
Well, I also think that libraries, really means finding cure-alls to problems, when we Script, we are on the top of the food-chain, which means that we are capable of burning off a lot of resources, so it is important to find solutions, that gives most bang for the buck, like with embedded systems, this may indeed favour specialized solutions for the task at hand.
Implementing algorithms may be boring, tedious, and micromanaging, but I find that interesting, and a much better approach, than having one library you just use out of laziness, like some of those rather expensive javascript libraries that are in use nowadays. People just grabs the first and best library, it solves the problem, but in a mediocre way, at the expense of battery and processing time.
And hand to mouth exchange of knowledge, works for me, I have to mention it.
The caveat with respect to an associative array, from an abastract data structure user’s point of view, is that it it is only capabale of holding unique keys.
I agree with you on Cocoa, but it wasn’t built with AppleScript in mind, I have no qualms using Cocoa, as long as it is easy to use it from AppleScript, and I can get at the error messages, without too much work. One of my parameters for finding solution, is like you said above, I want to be done with something and move on, and if I then have tried and tested solution in AppleScript, then I use that solution, because it is easier for my to debug with ScriptDebugger.
I will just comment your second post with the fact that I enjoy exploring, it happens that I explore first, and figure out what it can be used for afterwards.
I wouldn’t get too exercised about this (or as personally abusive as you were above, which is strictly against this forum’s Posting Guidlines and mustn’t happen again). The original poster was trying to concatenate two variable labels to make a third. Stefan gave the correct answer in post #2: this can’t be done, although there are workarounds. My script was just an illustrative example. It was only intended for someone who thought it necessary to stick one or two variable labels together to achieve a particular end. It wasn’t intended as a full-blown hash-table system and didn’t assume the OP would be eccentric or stupid enough to use returns in the variable names.
This is a help forum, not a script distribution centre. It’s not the responsibility of anyone here to post complete scripts with all the 'i’s dotted, 't’s crossed, and errors trapped, although obviously they may care to include a few safeguards or warning comments where they feel it necessary. In the context of the top of this thread, I didn’t feel it necessary. If you disagree, you’re welcome to say so ” but politely. If you have a better script, you’re welcome to post it. But merely saying you have a better script that you’re too busy to post, preferring instead to use the time to post several long invectives against various people and their scripts, that won’t cut it at all.
Well, I’m glad I didn’t bet on it, I did satisfy my curiousity, and I could indeed make a root item of a property list file as an array. Not sure if I can convert a property list file into well formed XML though then, as I believe an XML file are specified to have a dictionary as its root element.
Edit
Actually, an array with two dictionaries, ran fine through an XML Validator.
Nigel, please indicate precisely where I was “personally abusive” - I’ve read over my previous replies and the only issue I see is some use of the second-person pronoun “you”, which is purely colloquial so shouldn’t be interpreted as referring to any specific person (and apologies if anyone has read it that way). I’ve already edited one of my earlier posts to make this clear; if there are any others that need attention then folks are welcome to point them out.
Believe me, if I decide to lay down some personal burn on someone specific, then that recipient will know all about it. In fact, the most egregious offender I can find is this one; perhaps you should have words with that poster as well?
One of the challenges in providing help and support is understanding what the user’s actual problem is, not merely what they think it is. If they fully understood the problem themselves, they wouldn’t need to be asking for help with it!
Eh? I posted a script that did exactly that, using a ready-made solution (NSMutableDictionary). I even indicated that there were caveats to it, but none that should be issues in the OP’s use case (unless they’re on an older OS version in which case something else can be devised). [1]
Nowadays, the ability to mix Cocoa and AS code to compensate for their relative weaknesses means it’s not how I’d implement key-value collections in AS now, but I’d need to write that code from scratch before I could make it available to anyone else. Which I’d be totally willing to do as a favour to the AS community, as I’ve said earlier, but I simply cannot keep throwing hundreds of hours of my own time down the drain. There’s no point me or anyone else in the AS community developing a high-quality standard library for AppleScript unless it can be made ubiquitously available to all users. [2] That means getting it into the OS, and the only people who can make that happen are the AppleScript team. But then, if they knew what they were doing none of us would have to think about stuff like this, because they’d have done it themselves years ago. So if anyone else here can propose a workable solution to the problem then I’m all ears, because I’m all out.
The whole person of AppleScript is horribly dysfunctional, and the head - which should be the greatest part of it - is actually the worst. I get nightmares about what’s going to happen when some Apple beancounter decides to ask what they’re getting in return for their half-million dollars budget, because the only thing beancounters care about is bums on seats generating revenue - something the AppleScript team has consistently failed to deliver on for years now. So apologies if I sound angry and frustrated, but that’s because I am. As all of you should be too.
[1] Alternatively, if you fancy some amusement, feel free to dig out the old Types module I wrote for AppleMods way back; it’s not great code, though still by no means the worse. And there’s also the associative list examples in the Apress book, although I’m a little embarrassed pointing to those as there a couple of problems (one compatibility issue with Script Editor due to SE being ass, and one big honking bug which was entirely my fault for not testing the code to make sure it actually worked as it was supposed to do). (Source code from the book is available here, but I don’t know how much use it’ll be without the book to accompany it.) Heck, you can go through my last 15 years’ posting history and find code of mine that’s far worse than anything else posted here, and was no doubt terribly proud at the time, being as full of Dunning-Kruger as the next noob. But that’s why I bang on about the importance and value of self-education and self-improvement: You [3] don’t know what you don’t know, least of all what you’re missing!
[2] Various folks in the AS community, including me, have tried independently to bootstrap library support over the years, and have all failed for the same reason: it requires committed support and leadership coming right the top.
[3] Damn colloquial second-person pronouns again…
<value> as anything is an Apple Event Manager coercion. <value> as number is an AppleScript-only coercion.
Because I call them repeatedly on the rotten quality of their work. And do not pull any punches in doing so: they’re the ones who are supposed to be the top-of-the-line professionals, after all, so I do not think it unreasonable to hold them to some standard. Some of us herre have livelihoods that hinge on the continued existence of OS X’s AppleScript technologies, yet while everyone fears that some senior Apple PBH will one day bring down the ax and kill it off quick and hard, few notice that the AppleScript team are doing a pretty good job at slowly driving it into the dirt by themselves.
I mean, how does the AS team expect to attract new users (especially amongst programmers, a traditionally AS-hating sect who are nevertheless desperately needed to keep AS alive) when they pump out garbage technology, produce worse documentation, provide no support, and lose key evangelists, educators, and supporters in their own user community? I’ve often said Shane Stanley is the greatest member of Apple’s AppleScript team that they’ve never had to pay a cent for: without you to do all their education, evangelization, and support work for them, ASOC would’ve been Dead On Arrival.
The appscript project, despite my lousy mismanagement of it, managed to turn something like a thousand programmers who hated AppleScript into a thousand programmers who still hated AppleScript but absolutely loved Application Scripting. Please explain to me why the AppleScript team failed to steal that audience for its own included-for-free-in-the-OS-itself Scripting Bridge and build it into a ten-thousand strong army of professional programmers who absolutely love doing desktop automation themselves. And then imagine what gaining thousands of Mac developers who both understand and adore application scripting technologies would do for everyone in the AppleScript community. (Or have you forgotten who writes all your scriptable apps for you?;p)
So yeah, add in a professional “f-y’all” from Chris N by way of Apple’s skeezy patent sharks, Sal going right ahead and wasting 250 hours of my unpaid time last year after I explicitly asked him upfront please not to do so, Chris P asking me for feedback then not even bothering to respond (rudeness I am often also guilty of, btw, and rightly castigated for too), and you wonder why I get peeved? It’s very difficult to maintain a positive attitude when everything I try to do to help both them and us gets tossed back in my face - not because my work is bad or my attitude worse, but simply because they just don’t care very much.
“God helps those who help themselves”, but in the AppleScript team’s playpen we’re not even able do that.
I care deeply about end-user automation technologies. I care deeply about empowering users (not least myself!;). I deeply appreciate the vision and work of the original AppleScript team, and feel greatly for them that they were denied the opportunity to see it through and make it everything it could and should have been. I do not care for the current AppleScript team at all, not because they aren’t nice folks (which they are) but because they’re even more rubbish at their jobs than I am, and gods know I wouldn’t want me in charge of a key technology that many tens of thousands of users daily depend on to make their own lives not suck. It was my respect, confidence, and goodwill in them to lose; and guess what, they lost it.
Given that my own work (appscript, JavaScriptOSA, even the AppleMods libraries) demonstrably kicks the absolute tar out of theirs (Scripting Bridge, JXA, 10.9/10.10’s non-existent stdlib) quality-wise, I’d say that’s strong evidence to back up this assertion. And don’t take my word for it: all my work is out there, in the open, for all to see, use for themselves, and freely kick the holy tar out of (something that I, unlike some, totally encourage and demand). So instead of repeatedly insinuating I’m blowing smoke from my ass, next time why don’t you spend a couple months doing all your professional automation work in appscript vs SB/JXA, and then we can talk about who does and doesn’t understand this stuff. I may be a prickly ass but I always put my money where my mouth is, so please do likewise or kindly cut it out.
Nonsense. Using libraries is no harder than using scriptable apps - easier, even, as their functionality and user interfaces tend to be much, much simpler. AppleScripters have been using scripting additions for a couple decades now, almost since the very first release of AppleScript itself, and I don’t recall them ever having any fundamental problems in grasping the purpose or usage of those. AppleScript libraries are just a slightly less hackish successor to osaxen; you’re inventing imaginary barriers where none exist. What barriers do exist are purely practical ones: missing standard library, missing repository for hosting third-party libraries, missing direction from the Apple team in charge, and missing motivation amongst community leaders who’d rather panhandle for cheap praise than raise a solid, true, permanent platform upon which everyone can stand.
It really isn’t, you know. Believe me, I’ve documented the bugger: it’s a nightmare. When it takes hundreds of pages just to explain the core language, never mind all the extensions - scriptable apps, osaxen, etc - that actually make it useful, something is seriously wrong. Seymour Papert was teaching eight year-olds, on computers that had typewriters for terminals, a couple decades before AppleScript was even born.
Desktop Broom. 2000. Wins!
Fallacy argument again. Apps give us coarse-grained glue for complex tasks. For simple, fine-grained tasks like find-and-replace, sort list, format date, and so on, they are at best far too slow, expensive, and intrusive; and most of the time they can’t even do it at all. I’ve been doing this stuff over fifteen years now, and “How do I do?” those same three tasks come up again and again and again and again and again, on this and every other AppleScript forum in existence.
No it’s not. It’s really way simpler than that: the original AS team was greatly under-resourced and time-constrained for the task they were given, and after putting in a herculean effort to get something built and out the door on time, Apple management rewarded them with a 50% cut in time and manpower, in response to which Cook and Harris, AppleScript’s head designers and team leads, quit Apple in protest. A quick-n-dirty adaptation of HyperTalk extension technology, scripting additions, were lashed in as a stopgap measure, but starved of resources and with no management support, what few folk were left on the AS team could do no more than keep what they already had on life support.
Had Apple management not gutted the original AS team to, as one wag memorably put it, “get OpenDoc ready to throw away”, who knows what it would’ve grown into over those critical early years. Starved, beaten, and abused, it seems remarkable that this red-headed stepchild ever survived at all. That it did is testament to the terrific value of AppleScript even in crippled form, and can only hint at what true power might’ve been unleashed had Apple not screwed it so.
Go read Dr William Cook’s HOPL paper on the early history of AppleScript. I totally recommend it.
Ironically, it’s not having reusable libraries that creates your high priests and enriches and empowers them at the expense of everyone else. Libraries are where you stick all the boring, humdrum, make-work, house-keeping crap so you never have to shovel any of that garbage yourself ever again. And making those libraries freely available to everyone means that they don’t have to either. It is by not providing that mechanism that you create artificial scarcity, by which the “enlightened elders” get to sit on high above everyone else, receiving veneration for tossing the little people the same endlessly chewed old scraps that they’ve been recycling for as long as anyone can recall. They are kings of their hill; what motivation do they have to tear down that very small hill and stand shoulder to shoulder with everybody else in building a much larger mountain upon which everyone can comfortably stand?
Commoditization is the users’ champion: make it cheap (or free!), make it ubiquitous, make it barrier-free, and no individual or special-interest group can ever control it all at everyone else’s expense.
It’s the same with the World Wide Web, incidentally: did you know the world’s first “web browser” was not a read-only web viewer but a full WYSIWYG web editor? The web was designed as egalitarian platform where everyone could publish, everyone could share, and everyone kept ownership and control of their work. Now look at it: a rabble of high priests - “web programmers” - and a handful of absolute feudal lords - Facebook, Google, Amazon, Apple, et al - dictating to all of us lowly proles precisely what we can and can’t do, and where we can do it, and just what it’s going to cost us all this time, oh yes.
That’s how you disempower people: you strip them of the means to build, share, and use their own tools as they like; then you sell them back crappy, crippled tools of your own devising at extortionate price, and then dictate exactly what you can and can’t do with those tools as well. (Hey, whaddaya think iCloud’s for?) Give the peons just enough back to have them think they’re getting their money’s worth, when in reality what you’re doing is teaching them learned helplessness, and they’ll be totally dependent on you for so much as tying their shoelaces for eons to come.
But I’m just one more of those lowly users, so what do I really know? (Apart from why I’m always feeling a chill: all those previous lifetimes being burnt at a stake.
Not all of it directed at this forum’s posters, but abusive nonetheless at not welcome here:
“That’s a rather shlonky map/associative list/dictionary/etc implementation. (I’ve done somewhat better ones in the past, but even those weren’t great so I’m not going to bother posting them here.)”
“Crack a book, dude. A little education does a power of good. Stumbling around in the dark because it never occurs to you to turn on the lights, then congratulating yourself for occasionally managing to walk into a door instead of a wall/coffee table/trash/cat/etc. is just dumb times two.”
“Stand on the shoulders of giants: that’s what they’re there for. Declining to do so does not make you a giant too, it makes you a twit with a giant ego but none of the actual talents to match.”
“. the AppleScript team are clueless goobers who never think to do such useful, practical, simple things for their users; or just botch it when they do try because they never, ever eat their own dogfood, never mind listen to the users who do telling them precisely how foul it actually tastes.”
“When you don’t know enough to recognize a solved problem when you see one, what makes you think you know enough to invent a reliable solution yourself?”
“You may think I’m being cruel, pissing on your parade, but honestly I’m trying to do you a kindness here. If you think your super awesome AppleScript skills now make you powerful, imagine what you could achieve with just a little more awareness of what you don’t know.”
“.I pull that sort of callous, lazy crap on other folks too.”
“.that’s actually just a load of self-aggrandizing garbage: Dunning-Kruger egotism and clueless, incompetent amateurism raised to high art.”
“I do their egos no favors at all”
“I strongly suspect I understand this stuff better than they do”
Your apologies are welcome. Your pained innocence, continuing to argue the toss, and attempt to turn the table on the forum moderator are not. Nor is your continuing failure to stop ranting and being insulting:
“Because I call them repeatedly on the rotten quality of their work.”
“.few notice that the AppleScript team are doing a pretty good job at slowly driving it into the dirt by themselves.”
“So yeah, add in a professional “f-y’all” from Chris N by way of Apple’s skeezy patent sharks, Sal going right ahead and wasting 250 hours of my unpaid time last year after I explicitly asked him upfront please not to do so, Chris P asking me for feedback then not even bothering to respond (rudeness I am often also guilty of, btw, and rightly castigated for too), and you wonder why I get peeved?”
“So instead of repeatedly insinuating I’m blowing smoke from my ass, next time why don’t you spend a couple months doing all your professional automation work in appscript vs SB/JXA, and then we can talk about who does and doesn’t understand this stuff. I may be a prickly ass but I always put my money where my mouth is, so please do likewise or kindly cut it out.”
As I said before. This is a help forum. It’s intended to be a friendly environment where people of all ages and abilities can feel confident of at least getting a sympathetic hearing for their scripting problems. It’s not a place for lengthy, foul-mouthed, abusive ranting. Be friendly, be enthusiastic, help OPs with their problems, or shut up.