Oh yeah, that was a slip. I've clearly spent more time posting links on Lobsters than HN recently. Yeah, Markdown or a HTML subset would be nice. Embedding the links is an advantage Lobsters has over HN since it reduces clutter.
My `tangle` currently inserts `#line` directives, which helps with error messages. But inserting them into the git history is noisy. Another reason to create the repo from scratch on demand, using it only for browsing convenience, not as a source of truth.
"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)?
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.
> Below you will find a Redis clone, pydis, written in < 250 lines of idiomatic Python code, providing a subset of redis' functionality for which there are official benchmarks.
> Briefly, pydis is ~60% as fast as Redis measured in number operations per second.
In otherwords it's 40% slower than Redis and doesn't need to account for probably half of the things redis needs to account for.
> pydis is an experiment to disprove some of the falsehoods about performance and optimisation regarding software and interpreted languages in particular.
I don't think the results of this experiment proves anything accept that interpreted code will always be somewhat slower, which is pretty obvious.
Note that, as they say, "I don't have fucking brain damage; if you send us recommendations to pin posts with blatant ads for garbage affiliate sites, I will personally come to your house and stab you in the dick."
Oh yeah, that was a slip. I've clearly spent more time posting links on Lobsters than HN recently. Yeah, Markdown or a HTML subset would be nice. Embedding the links is an advantage Lobsters has over HN since it reduces clutter.
