or take the later 80s and the 90s and very early 2000s

Hypercard introduced people to some basic interactive programming techniques, Hyperscript let them level up in an easy way that didn't require lots of fancy knowledge

many people learned to program initially from Hypercard

and if they wanted to extend the functionality of their non-Hypercard software, MacOS had facilities for that too:

AppleScript

and AppleScript was similar to HyperScript, so you could transition from scripting Hypercard stacks to scripting your whole computer, automating huge workflows, with relative easy

eventually AppleScript lead Sal Soghoian developed Automator, a GUI tool to make it even easier

but some time around 2005 or so, Apple the company stopped caring about these AppleScript and Automator, and let them languish, to the point where now, basically nothing is scriptable. HyperCard was also dead by this point.

so routes into end user programmer were dwindling

or take the various WYSIWYG webpage making programs out there. there's a long history of them producing terrible code, except for a handful of them. iWeb was pretty decent IMO

but as blog engines and then various SquareSpace-like web apps became popular, these apps REALLY faded

@beka_valentine a lot of people seem to believe this and I am not sure why. there have been big improvements to the applescript ecosystem, including fine-grained access control inter-app user-consent support added during the gradual tightening of security during the introduction of code signing and notifications. I regularly use applescript. apple’s first party applications still have scripting support, and the mac version of Shortcuts even has applescript actions

@beka_valentine applescript is under-marketed, perhaps, but it’s still right there in macOS I strongly suspect that there is a big element of revealed preference here. users programmed out of necessity but they always kind of hated it; while Apple makes their apps scriptable, relatively few third party developers do, for the same reason that APIs have been falling out of fashion generally. shout out to the ones that make it a headline feature though, such as the Omni Group

@beka_valentine I still use this stuff quite a lot, despite being warned off of it in the early 2010s because if was “all going away soon”. it’s been a solid 15 years of it all continuing to work perfectly well for me. I try to convince others to use it as well, but even other programmers mostly just ignore it since it’s kind of alien to the way programming works on the web now, and that’s most programming

@glyph @beka_valentine

Adding AppleScript to an app used to be quite clunky. There were a bunch of classes encapsulating AppleScript verbs and so on that you had to wire up. About ten years ago, they added some reflection-based things that let you just expose an Objective-C class as a scripting interface. They also did the converse and made it easy to use AppleScript interfaces from Objective-C, which made it easy for one app to drive another without needing to embed AppleScript code as text that Objective-C code would then pass to another parser.

@david_chisnall @beka_valentine I have, admittedly, yet to make an app scriptable myself, so I am not sure how hard it would be, particularly in Python; I should definitely get around to that. I do wonder if this stuff exists in Swift?

@david_chisnall @glyph @beka_valentine
I recently learned Chrome has AppleScript support, and was disappointed that it doesn't seem to support anything similar on Windows.

I think if you expose IDispatch COM objects you can probably build something similar, but of course I'm sure it's a huge pain of fighting with legacy technology.

@KevinOfComputer @glyph @beka_valentine

Windows DCOM is closer to Distributed Objects in the NeXT world. I think one of the largest mistakes Apple made with OS X was not reimplementing AppleScript over DO, which means that you have two completely unrelated ways of vending an object to external users (three once they introduced XPC) in the core system abstractions.

I did some prototyping ages ago in GNUstep with the tooling I wrote for writing scripting languages that shared an object model with ObjC and using DO as a building block for scripting. It worked quite nicely at the time.

@glyph @beka_valentine

I think most of the Objective-C stuff is bridged in Swift, but I’ve never tried using Swift seriously. And SwiftUI is such a huge step backwards that it’s hard to take the ecosystem seriously.

@beka_valentine anyway it does feel like the magic is going away but it is still worth learning; both because it still works and can solve actual problems, and also because it would be good to learn lessons from it while it is still a living system and not just retrocomputing

partially its because they were often just kind of terrible to begin with, and didn't help people become more capable web programmers

and partially its because the people behind these apps didn't want to address the problem of how to make the whole problem easier

making a website is not just about making some HTML and CSS and JavaScript

you have to find hosting, a domain name, etc.

Apple had easy solutions with iCloud, but everyone else making these tools just said nah that's ok

and so web-based complete solutions took over

and those aren't interested in making things that you can learn from and advance in. SquareSpace doesn't want end user empowerment through end user programming, SquareSpace wants end user lock in. they want you to never leave, so they don't help you become empowered

what about more professional uses of LLMs tho? is this ALSO true in the context of professional programmers?

i think so!

lets consider a common explanation for what professional coders use LLMs for: boiler plate

i often hear coders say "oh yeah, LLMs suck overall, but they're REALLY GOOD for boilerplate"

and this is pretty true!

but, well.. people have been talking about Boilerplate Code since at LEAST 1981, with a popularization happening in 1990

the programming world has known about boilerplate for a while, and had ample opportunity to try to address it. there are even some great ideas!

but instead of making languages more useful, there's a non-stop stream of trash

i mean, consider Go, a language that came out in 2009, and which ignores around 41 years of language design progress and research, to create a thin reimplementation of Algol 68

Go was designed INTENTIONALLY to be feature-sparse because the people who made it wanted to make sure that any schmuck hired by google could write Go without having to learn fancier techniques

so because google's corporate environment was hostile to TRAINING, they made Go

Go is an intentionally feature-sparse language because it needs to be used by people who have low skill levels, because improving people's skills is not a priority

but while it's not Google's priority, it also isn't anyone elses, either

we can't lay the blame at just Google's feet, because you see this across languages, including ones that aren't primarily pushed by large corporations

open source developers, for instance, have a well documented hostility toward helping people learn

and to improving the usability of languages because its good enough like it is and why bother making it better!

in open source, there's low regard for good documentation -- documentation isn't running code so it's a distraction, plus its hard to write b/c no one knows how

and user-friendliness is seen as synonymous with powerless, useless, etc.

so language after language has the most abysmal features, and tools, that are hard to use. and one of those persistent problems is boilerplate

but its not just opensource devs who are to blame here, because the research about this stuff isn't the best either

i mean, there's lots of research on techniques, sure, but academics aren't exactly fantastic at communicating these things in ways average devs understand

the routes into the techniques of PLT are rather limited and sparse

and on top of that, there is also a general tendency for PLT research to avoid the empirically-linked dimensions of theory, such as the issue of boilerplate and similar things

a lot of theoretical work is done on PURELY theory internal things, and so places where theory can touch reality tend to be neglected

more PLT people are probably working on homotopy type theory right now than are working boilerplate

the broad trend here in all of this is that there's a general lower regard for things that make users more capable and more skilled

from the person who isn't a programmer, to the programmer who isn't a language dev, the things that cause them frustrations go ignored

and so lots and lots of things which COULD be done are simply replaced by things that mask over the problem

few people write their own software these days, you just buy a million apps until you find one that suffices

few people make their own websites these days, ...

... you just pay SquareSpace-like companies to get something good enough

few people use skills and tools to augment their programming to get more efficiency, reduce boiler plate, etc. they just ask an LLM to do it

as the support for doing the learning, skill development, and so forth has vanished, people have come more and more to accept tools that completely paper over their lack of skills, and the lack of support

tools which "solve the problem" in a way that make their users worse off

to some degree this is a uniquely software-driven problem, because software is SO powerful and SO capable, that it's capable of supplementing what used to be whole personal skillsets while ALSO being capable of preventing you from leaving the software behind

i mean like, take a completely out of left field example: drafting/CAD

now, CAD is an absolute boon, don't get me wrong!

but no drafter 100 years ago was trained to only use Esterbrook dip pens and stuck using them for all their projects once they used it once

you draw a line on a document using an Esterbrook pen and anyone can read it, and if you need to modify the document later, you can use shitty Bic ballpoint for all anyone cares!

now try doing that with a design made in Fusion 360

or even Freecad

sure you MIGHT technically IN THEORY be able to export files that other programs MIGHT in THEORY be able to make use of

but in practice, you're stuck in that one program unless you want to completely re-implement the design

the most open source un-corporate un-malicious-intent CAD programs out there, like FreeCAD, are VERY convenient but also in a way completely incapable of replicating the end-user-power of pen and paper

and while you might use FreeCAD and then manage to export to some other program successful, you now have to learn that other program

whereas, when you pick up a shitty Bic pen to do your drafting, constructing tangent circles is the same geometry Euclid was using 2500 years ago

software has this tendency to ensnare people with conveniences, even if we don't intend it to, even if we make it very user friendly and end user programmable and provide abundant learning resources

you're still learning _this_ program, or _this_ programming language

which means that it's even MORE important for software folx to emphasize training/skill development, end-user programmability, ease of use, and openness. because those are the only things that currently can reduce the likelihood of people getting trapped