I don't think you can improve on the combo of: 1) slider/knob 2) text input

What you can do depends on if the range is known, and what precision you want:

• Less/More: for steppers with < ~15ish value
• Min/max: for defined ranges where the user wants short bursts
• Accelerating hold: when the user wants precision in the beginning but the range is wide so holding is a good indicator they wanna go farther raster.
• Copy from or value suggestion: when the user wants this value to match another (maybe something recent)
• Speedometer/pie: when the range is well known and there's some tradeoff to another value (ex: two values are constrained to equal 1). Often mixed with locking if > 2 values are part of the constraint.

So lots of ways, have fun!

Wow, great list @Don Abrams!

I am building an editor with integrated version control github.com/uprun/lisperanto

github.com/akkartik/lines.love#mirrors-and-forks

Most of these sites are hosted versions of gitea.io. Gitea is also interesting because they're working on federation features: nlnet.nl/project/Gitea. If they succeed you'll be able to send PRs from one site to a repo in another, stuff like that.

(I'm ignoring good questions here about whether git is good, whether PRs are good, etc.)

Gitea federation looks promising! In my little universe of computational science, I see people and institutions move away from GitHub and GitLab towards institutional forges (typically GitLab), making collaboration a real pain. With sometimes surprising consequences, such as me being administrator of a repository which I am not allowed to fork (so I cannot do merge requests).

gerrithub.io uses the stacked commits idea, I think it's based on how they do work at google. Still git based, just need a plugin and a slightly different workflow

What about mercurial? Ive never tried that. Should I? Are there other new models as well?

I used Mercurial many years ago, before switching to git because everyone else used git. There are good an bad aspects to both, but the similarities outweigh the differences in my opinion.

Something I am tempted to try one day is Pijul. Looks interesting theoretically, no idea how well it works in practice.

Have any of you tried fossil? I haven't tried it yet, but if the claims on their site are true, it sounds like it's more well-suited than git for most people's personal projects: fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

I am running a small document server plus task management system for my condo as a Fossil repository. Trying out Fossil was one motivation, the simplicity of the setup another one. Fossil contains a Web server and an issue tracker, all in a single executable, so that's all I need to run on my little server.

But I haven't used Fossil for code so far. The main reason is that it doesn't have decent Emacs integration. Git has Magit, which is the best UI I have ever seen for a VCS. I'd rather fight git now and then than give up Magit.

Not sure this is an issue of live vs. batch. It's more an issue of dependency handling in the Open Source world. In the world of artisanal and industrial products, clients deal with a single supplier, who is responsible for the product sold, including all its components from the supply chain. Commercial software works much like that as well. In Open Source, everybody is responsible for their piece of code but not for its dependencies. In theory, it's the end user who installs everything who is responsible for the correct working of the assembly, but the typical end user can't really do much about technical problems.

Ultimately, it's the ambiguous self-image that Open Source developers (both individuals and communities) have. They want to be part of a network of like-minded developers who share code, but they also want large-scale adoption by end users. They end up advertising their products to end users while at the same time proclaiming in the small print not to be responsible for any problems. That's a mismatch between advertising and hard promises that's not so different from commercial vendors.

At a very abstract level, I want to say: the problem is that this is a build time warning expressed as a runtime warning.

Exactly. But the point of live program folks seems to be that we should care about such distinctions less ...

I... mostly don't care about extra warnings? Also, agree with Konrad Hinsen that this looks like a deps thing, not a live/batch thing.

@Justin Blank Yes, exactly. But technology follows incentives. If someone (person or institution) profits (making money, not being sued) from a software assembly working fine for end users, then that someone will create the tools to deal with potential runtime warnings at build time.

Kartik Agaram The live programming environments from the 1970s and 1980s were indeed designed in a context where the person using the system was both the end user and a competent developer. So it's the user who is the manager of the top-level software assembly. BTW, the idea of free software (Stallman's famount printer driver story) goes back to the same context. Neither free software nor live environments have been adapted to today's context of software as an industrial product for non-expert users.

Konrad Hinsen I don’t agree that OSS developers aren’t responsible for their programs’ dependencies. They may not care about such responsibility, but then they’re irresponsible (and are making low-quality software). What is a true end-user’s problem is assembling independent programs into one they need, and that’s where the real hard-to-resolve impedances kick in (the OSS developers don’t have much incentive to cooperate, unless their userbases overlap totally; end-users usually don’t have the specialty to harmonize the programs). Note that these aren’t problems with dependencies, as the constituent programs can (and are meant to) function independently.

@Jan Ruzicka Assembling software is an issue both for library dependencies and for "independent program" dependencies. In fact, there is little difference between the two other than the interface technology (linking vs. process calls). In both cases, the issue is not bad will nor incompetence, but insufficiencies in both the social structures and the technical infrastructure for software development. The only way an OSS developer can take full responsibility for dependencies is by maintaining forks of everything, and that's beyond most developers' means (but I suspect that this is what Microsoft etc. do).

Konrad Hinsen When some software has an explicit dependency, then surely the developer uses it consciously (of course, it often gets impractical for some transitive dependencies burrowed under many others). Now, assuming that such a dependency is used only by that one program (it's properly isolated, not being a shared library), then any defect should only come from the dependency itself or from the interaction between the dependency and the program. In the former case, the programmer should have chosen something that works; in the latter, it's probably his fault it doesn't work (unless it's a bug, in which case he unfortunately has to work around it). Yes, I know that in some environments, even isolated dependencies might clash (I've seen this happen with npm packages), but then, why bother using such environments?

@Jan Ruzicka The main issue in practice is dependencies evolving, breaking compatibility intentionally or through bugs creeping in.

An example from my own past: in the 1990s, I was part of the team that launched the Scientific Python ecosystem. Our main sustainability worry was "what if Guido is hit by a bus?" We had doubts about Python's survival chance for lack of community support. That turned out to be no issue: Python became immensely popular in the 2000s and developed a large developer community.

But then... Python 3 came along, and the Python developer community ended up actively killing Python 2. Lots of domain-specific scientific libraries (including one of my own: github.com/khinsen/MMTK) have become very hard to use because of everyone dropping support for Python 2. And we typically don't have the means for a porting effort to Python 3. So were we negligent in the 1990s for adopting Python 2 as a dependency?

I see. Developing libraries is a risk in this regard (your userbase isn't really "your"). I had standalone "binaries" in mind (usually some pipeline utilities, but also more robust programs). These then depend only on the OS (or the shell).

To clarify, the "direct manipulation of code" needs to be supported as a visual canvas that shows the running product you're working on. The design tool needs to work back from there to materialize any direct manipulations you've made as corresponding code changes in real time.