The old answer is twenty years of semantic file systems and GNOME Shell where it's one of the first things people turn off once installed. So you're right, but not about what you expect to be.
-
-
Replying to @squidlord @Conaw
My own feeling is that the previous attempts AND Mercury both try to usurp too much. They try to replace and not adjunct, which provides no on-ramp. They forget people already have jobs to do.
1 reply 0 retweets 2 likes -
Replying to @squidlord
Agree here too iPads arent computers iOS isn't an empoweding OS MercuryOS is a good conceptual framework for **something** related to (programmable attention)TM-
@andy_matuschak2 replies 0 retweets 2 likes -
Replying to @Conaw @squidlord
My broad sense is that the desired end-state is an inversion, a dual of the current structure: instead of apps-as-nodes, we have apps-as-edges. Roam and LiquidText are nouns/places; I think their ideal form is as verb. Roam/etc-as-OS is roughly what’s necessary for this, I think.
2 replies 1 retweet 9 likes -
Replying to @andy_matuschak @Conaw
We've tinkered with "apps as service providers" (not in those terms, of course) before. Plan9 took it pretty far down into the Mach kernel, even. It has some useful bits but the multiplicity of desired ways to touch ANYTHING means things get unpredictable fast.
1 reply 2 retweets 4 likes -
Replying to @squidlord @Conaw
Indeed. I don’t know a workable model for this. It’s interesting to see TimBL try it again with Solid. The “no-code”/“Zapier-driven” trend is interesting to watch, too, since there’s a greater emphasis on end-user-usability. But I’m not optimistic here.
1 reply 0 retweets 3 likes -
Replying to @andy_matuschak @Conaw
Maybe there's not a workable model -- at least while maintaining continuity with current workspaces and actual work getting done. The idea of externally-hooking pipes is probably the best possibility but dealing with API limitations will hurt them, always.
1 reply 0 retweets 0 likes -
Sooner or later, it BECOMES code, even if it's dragging lines and connecting pipes with filters and transformers and not writing text.
2 replies 0 retweets 2 likes -
Replying to @squidlord @Conaw
Yes, and then it devolves to solving the end-user programming problem, which AFAICT we’ve not made much progress on in decades. The more interesting question may be how to move the 80/20 line, and I do think some of the no-code projects have made useful progress there.
1 reply 0 retweets 1 like -
Replying to @andy_matuschak @Conaw
Looking into things like Blender and other video compositing/FX systems that use box-and-pipe abstractions for building complex systems, or things like Blueprints in Unreal (game engine), there's been a _lot_ of that progress.
1 reply 0 retweets 1 like
Yes, Blueprint is amazing. It’s telling that there are full-time employees who use it exclusively, all day, as their primary environment—but who cannot “code” in a traditional sense.
-
-
Replying to @andy_matuschak @Conaw
I'd say they code all day, every day, but I've never been of the "ascended priesthood" class of programmer. Programming is the detailed specification of intent to a machine; the symbols used are immaterial. Machinists "code" both digital and analog computers to produce pieces.
1 reply 0 retweets 0 likes -
Replying to @squidlord @Conaw
I agree, of course, was using “code” ironically there.
0 replies 0 retweets 1 like
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.