laarcnew | comments | discord | tags | ask | show | place | submitlogin

I think it's true of most proprietary applications, & most applications not intended for use by technical folks.

Even in cases where deep configurability & scriptability exists, it's generally hidden (as though it's embarassing) & 'normal' users never become aware unless using those features has been grandfathered in by a technical community. (For instance, some games are heavily moddable, but most players are not modders & modding is considered something special; as another example, Microsoft Word and Excel are highly scriptable, and many but not most non-programmer users are aware of this in a vague way because they belong to a group that uses existing scripts to make up for missing core features or adapt the program to a particular domain.)

Applications for programmers tend to be extremely scriptable, and tend to expose that extensibility.

(Even so: I'd really like to be able to do real intense modifications to running applications without a separate recompile step, which is something applications don't do outside smalltalk-land. Likewise, I'd love to be able to throw together widgets as casually as I write pipelines.)




"which is something applications don't do outside smalltalk-land."

I thought Lisp's could do live updates. Outside Lisp and Smalltalk, what about apps with Lua scripting like [Luakit](https://github.com/luakit/luakit)?

-----

2 points by enkiv2 541 days ago

For any dynamic language with a REPL, you can expose the language & make it so live modification can be done. GUI toolkits don't tend to expose the language by default, & applications don't tend to go to the effort to expose them themselves (or design their internal structures to be amenable to live-editing by non-programmers as opposed to modification during a normal development cycle).

It's not a problem of missing features generally (though sometimes it is -- like if a language, by default, loses the original source after bytecode compilation, & the compilation step can't be hooked to keep that source around), but of UI (though a whole host of unusual language features can make providing a reasonable UI to do this a lot easier -- like having an image-based system and having that image versioned internally).

Back in high school, I wrote a system intended for exposing live tcl scripting to a Tk-based set of widgets, as part of a 'desktop environment'. Doing such a thing is easy, if you don't mind doing it badly, even with a language & framework like tcl+tk that isn't really intended to support it.

Scriptability is, I think, a different (related but less interesting) version of this. Rarely is the whole application really scriptable -- it's unusual to have an application that can be turned into functionally an entirely different application through the exposed scripting API without a great deal of knowledge and effort (greater than the knowledge & effort necessary to write the thing from scratch in a normal environment); and then, scripting normally operates in the same way as a normal build process (wherein you edit files on the filesystem with your text editor & force a reload), which ultimately means unfamiliar tooling to non-technical users & no support for built-in documentation.

I think the article here describes a spectrum of end-user-programmability where the far end is what I termed 'composable UI' -- stuff that looks like smalltalk environments, in that the programming environment is one pop-up menu away from any widget, with full built-in documentation, and where a non-programmer can stumble into it accidentally & be glad they did because it let them solve their problem.

-----




Welcome | Guidelines | Bookmarklet | Feature Requests | Source | Contact | Twitter | Lists

RSS (stories) | RSS (comments)

Search: