bogs wrote: ↑Wed Mar 03, 2021 10:49 pm
Hokey, as I was using it, was an adj. describing the "do as script / alternate language" feature of Lc.
And that's why I shouldn't try to reply here without my reading glasses. I had misread that as being on-topic, like some of the hotkey utilities that rely on system-wide mandated scripting conventions. FWIW I don't think shell or other scripting solutions are hokey.
BTW, the 1.1 is I assume pointing to Rev, but it could just as easily be pointing to Mc 1.1
If it runs on any hardware you can still turn on, it's probably Rev. Their versioning began in the 20th century with 1.0, based on MC v2.4.2 or later, IIRC.
3. I sure wish the current release pace was at least half as conservative , although I can understand why it isn't.
Ah, but it wasn't so much pace that changed as the numbering scheme applied to each release.
The current versioning seems more in keeping with contemporary
semantic versioning conventions, where three decimal-separated components are used to convey scope: left-most is for major changes; middle is for minor features; right-most for bug-fix-only releases.
Most companies stray a bit from those general guidelines now and then, and LC Ltd is no exception. But MC was in its own world, where even big features with a file format change were delivered in a point release. This gives an artificially low perception of scope to the audience, less communicative to both experienced devs who become surprised to discover the new file format, and to the market as well who then underestimates progress done on the code base.
Um, YOU brought up stdIn/stdOut, remember? The way you put it sure sounded like you were saying that OSX 'n Win have "alternateLanguage" capability because they don't have stdIn/Out, and 'nix *doesn't* have alt.lang.
What I wrote was:
The shell function was and remains the solution on platforms that support stdIn/stdOut, such as Unix on which this engine was born.
The alternateLanguage option was added much later, originally to accommodate Apple's AppleScript, which (like so much from Apple in those days) didn't use common conventions like stdIn/stdOut.
viewtopic.php?f=18&t=163#p202408
I didn't refer to either AppleScript or shell as "hokey" or necessarily inferior to one another. But since Apple switched from their own isolated set of OS conventions where AppleScript was born to adopting Unix conventions, we see them increasingly suggesting shell-oriented solutions to automating workflows where practical.
They're not apples-to-apples, though, despite early efforts from some corners within Apple to suggest ditching AppleScript altogether after the OS became Unix with OS X. They quickly discovered that a lot of publishing workflows are based on programs heavily invested in AppleScript, and automation is a must-have in some segments of that industry.
So Apple has come to understand that AppleScript must be at least maintained, and they don't mind where new apps adopt it. But you'll notice that a lot of automation solutions they suggest these days are shell apps glued together with bash.
It really *probably* would have been better to say what you said this time around...
Maybe. But whether I take the time to carefully craft a reply or thumb something together on my phone, the outcome is often the same: most of what I write here is ignored, and much of the remainder manages to be seen as wrong, whether it is or not. So I've just come to accept that the only people who think I'm a good writer are the book and magazine editors I've worked. Beyond that I just do what I can here in my spare time, sometimes it's helpful, sometimes not. No worries. It's just a forum post.