I spent a bunch of time in my 20s and early 30s trying out different organizational systems but I realized I just don't care. I care about doing interesting things, not organizing them.
Also computers are pretty good at full-text searching for things, or tagging so you don't have to come up with a perfect hierarchy. And I think LLMs will make it even easier to find stuff using fuzzy language.
i'm always super impressed by brett victor and highly admire his work.
that said, I have to admit that it doesn't really feel "right" based on what I've seen. there's so many limitations to the physical world that a virtual space doesn't have. i get that physical objects can participate in the UI and that arranging things in 3D space is sometimes nicer than using a mouse/keyboard.
However, the fact that there is still code written on pieces of paper, and that the projector can only show a 2D image (which is only primitively interactable) just looks super awkward. and the question of "what can you do" when you're staring at a blank table seems tough
again, it's super cool research but i wonder if he has plans to resolve some of these fundamental issues with mixing real and virtual
IMO the goal here isn't to replace traditional software engineering. It's to bring computing to spaces. Museums, classrooms, town halls, etc, which requires a different approach.
The mental model I use is professional cooking in a kitchen vs home cooking. Different scale, tools, and approaches but some overlap in core ideas.
A pro cook can criticize a home cook's workflow and tools, but the goals are different!
I think their goal is similar to what smalltalk's goal originally was: To allow for regular people to do complex things with a computer.
Ultimately, it didn't succeed in that goal but I believe inventing the first spreadsheet software can be counted as achieving some success there.
I admire this project and hope they can one day move beyond simply typing code on a sheet of paper to creating tools that actually make our compilers/IDEs look like using punch cards.
I think Decker is just wonderful, but it's retro. That isn't a criticism of it at all, that's what it wants to be and I don't think it should try to be something else.
But it isn't what I meant. A HyperCard reboot would be a modern GUI builder with a deck-of-cards drag-drop metaphor, deployable as desktop, browser, and mobile apps for any platform. Mobile poses some problems, particularly iOS, but I don't think those are unsurmountable.
Decker is a love letter to the HyperCard which was. But if HyperCard had survived as a product, today's version wouldn't look anything like that.
Decker runs natively on a variety of platforms as well as on web browsers, and it fully supports touch devices like tablets. It isn't designed with small cellphones in mind, but I'm told that it's quite usable on phones that include a stylus. Just as touch support has improved over time, I have some ideas for providing a degree of fluid layout in the future without onerous impositions on deck authoring.
Decker is not a carbon-copy of HyperCard frozen in the past; it's a continuously evolving platform with many interesting innovations and experimental ideas. It has a distinct aesthetic, but I see this as a strength rather than a weakness: "modern" just means "in fashion", and fashions are always in flux.
It's great work what you've done, and as I said, I have no criticism of it at all.
But it's more than a distinct aesthetic, it is a distinctly retro aesthetic. Modern means contemporary, more than it means fashionable (sometimes retro aesthetics are in fashion, after all).
But terminological nuance is not very important here. The fact remains that, as wonderful as it is, Decker is not what I meant, and I don't think you're trying to make it into that either. For one thing you'd need a rather large marketing budget.
But to be sure, I wish you all success, whatever that might mean to you. If that includes transforming Decker into something which looks and feels like HyperCard might today, if Jobs hadn't put it out to pasture when he did, then more power to you.
I like the ideas around the interface where physical objects are part of the UX, but I think putting everything into paper takes it too far.
Putting things on paper means you cannot share things outside of your immediate community which I think is one of the main advantages of computing and the internet.
Creating a place for physical community is great, making a UX which allows sharing that experience is great. Firewalling your ideas off from the rest of the world, not so great.
I could see a world where these communities are federated. Maybe your local computing community is connected to other locales as well as somewhere else which is far away (like we do today with sister cities).
I think the (interesting) output we see as the different UI is a side-effect of the actual research mentioned at the end of the video: how can we teach everyone how to do spatial programming, just like we teach everyone to write and calculate. The end result is not a finished product, but new knowledge about how to spread this new knowledge to everyone.
Seriously, just ask ChatGPT and tell it you are an experienced developer and don't need to be told the basics. It can then give you a helpful overview and get you oriented. then you can read code, docs or other detailed sources to deepen your knowledge (and make sure the LLM didn't make something up)
There's no reason they can't have amazing documentation, but I imagine they don't because people are going to use the platform anyway. People are basically forced to use it because that's where so many of their customers are, so they can just treat their users like crap and get away with it. Why spend time on documentation when it will probably only cost them money to do so?
This is great for what it does, but I want a more generic LLM integration that can do this and everything else LLMs do.
For example, one key stroke could be "complete this code", but other keystrokes could be:
- send current buffer to LLM as-is
- send region to LLM
- send region to LLM, and replace with result
I guess there are a few orthogonal features. Getting input into LLM various ways (region, buffer, file, inline prompt), and then outputting the result various ways (append at point, overwrite region, put in new buffer, etc). And then you can build on top of it various automatic system prompts like code completion, prose, etc.
> Getting input into LLM various ways (region, buffer, file, inline prompt), and then outputting the result various ways (append at point, overwrite region, put in new buffer, etc).
gptel is designed to do this. It also tries to provide the same interface to local LLMs (via ollama, GPT4All etc) and remote services (ChatGPT, Gemini, Kagi, etc).
From what I see, gptel is more interested in creating the best and least intrusive interface - it doesn't concern itself too much about which model you're using. The plan is to outsource the "connection" (API, local) to the LLM to another package, eventually.
Breaking backward compatibility should be reserved for extreme cases, and this doesn't sound like one. It's possible the way the author handled it was poor and caused part of the dispute, but I think the right thing would be to make such behavior opt-in or at least very easy to disable.
I'm thinking through the ethics of this myself, but I think it's a reasonable argument that you can have the freedom to do what you want with things that you own _assuming you don't impact others_. The issue with a dangerous car is that it puts others at danger.
That'll make the hypothetical parents of the hypothetical kid you just ran over very happy I'm sure. "I fucked up but it's on me!" and they lived happily ever after
Yes? Society is actually completely fine with that arrangement. Every single year tons of people get drunk, get into accidents, get people actually killed and are held accountable for it. Yet nobody dares to infringe on their freedom to drink. They tried once and it just didn't work out.
This "give up freedom because kids" nonsense is seriously tiresome. I'm not engaging with these arguments anymore.
Really, come on: you can do much better than this. The hypothetical kid might be the one that was saved because some random hacker figured out why the latest generation radar based cars keep phantom braking. That argument works both ways, and typically what is fixed stays fixed.
And of course none of these hotshot programmers would ever be seen near the following bit of code[1], which probably impacted a lot of actual children and their health in a very direct way:
// in case of an emissions test ensure that we pass
// with flying colors
if (emissions_test_detected()) {
// we're sooo environmentally conscious
lean_burn();
}
else {
// roll that coal
regular_burn();
}
[1] cribbed from VW/Porsche AG's internal repository ;)
I know about the developer who, instead of building their game, decides to build a game engine. But that appears to have not been enough for you - this appears to be a game meta-engine! :)
It sounds like quite a technical achievement to accomplish that, but it also sounds like it would fill only a very tiny niche of developers who actually want this and are willing to build assets in entirely different engines just so they can transition to different aesthetics during the game.
Not to knock on the idea though - it would certainly be very cool to see. Curious if you have any other use-cases in mind for such a technology?
> Curious if you have any other use-cases in mind for such a technology?
Yes. In fact, the collage thing is the secondary pie-in-the-sky non-MVP use-case.
The primary use-case: a Mario Maker-like UX for playing cloud-hosted ROMhacks, where each ROMhack's game engine has been carefully cut down so that the experience is of just playing a level in isolation, with some state (e.g. life counter) managed by the runtime and passed in/out of the running core; where, just like in Mario Maker, the UX takes over between executions of the "per-level simulation", and so it's the UX, not the game, that determines whether you retry on death; and that determines what happens next when you "complete" a given level. So it can do various things like run you through playlists of experiences, shuffle a filtered set of all experiences, etc.
That "cutting down" of ROMs into game engines would be automatic/generalized, and would involve the classic techniques of "program-slicing", applied to the domain-specific tooling of emulation: input-movie control-path tracing + memory-watch rules for where the "boundaries" of the sub-engine in the game are, followed by unreachable-code and data elimination; then base memory-state capture to kick off the game at a given point + overlay-state synthesis to control what it looks like when it kicks off. Jumping control "out of bounds" ends the emulation, with memory rules to then determine whether that constituted a "win" or a "game over."
Also, the base "game engine" ROMs would have all IP "assets" (art, music, etc) removed / factored out; these would instead ship as [modder-provided] "game asset" packs, of which there could be multiple used in a single game project, and which would synthesized into ROM memory-bank files at publication time.
End-user supplies base-game ROM images locally; client synthesizes "game engines" from these ROM images. Or clean-room reversed "game engines" can be distributed, given that they're an alternative compilation from the reversed source, that doesn't contain any of the original game's assets — those all being wholesale replaced by the mod! — and so (I believe) don't violate copyright. In which case, the end user having the original ROM image available, only unlocks the ability to (potentially) "change the asset theme" of the game from its custom one, back to the original game's IP assets.
The core user-story, would be sitting there with a controller in hand, continuously consuming free-to-play "experiences", presented to them through playlists / recommendations / shuffle. (Game jams would be playlists!)
But there'd also be a store — for buying experiences that artists want to charge for, yes†; but also for buying asset packs, or for licensing the use of "engines" that others have put their hard work into developing, since the same UI that lets you play the games, is also the UI for publishing the games. (I'm not sure if I want to get involved with it being a UI for developing games, though. Maybe for the multi-module stuff; but I'm more expecting tooling like GB Studio and Lunar Magic to step in on the development side, allowing export to a package format that you'd use to publish on this thing.)
† (Paid experiences could have "demo versions" that show up in the free-to-play shuffle; where at all times while playing the demo, there'd be a little unobtrusive UI element that could take you to the store page for the paid version of the experience.)
You could add whatever "game engines" you want to this platform — as these aren't just limited to being ROMs, but rather can also contain a "native layer" (I'm currently thinking a PPAPI executable, even though it failed in its original browser use-case.) Engines can be designed "on top of" other engines; all the extracted-from-game-ROM game engines would actually be running on top of a set of native emulation-core engines that ship with the runtime. But "RPGMaker-compatible runner" is an engine. Love2D is an engine. RenPy is an engine. StepMania is an engine. The early Win32 GameMaker engines are engines. The Macromedia Flash projector is an engine. Etc. You can publish experiences with these, too; and there would be porting tools to take finished projects from these runtimes and shift them onto the platform.
And, perhaps less obviously, big third parties (e.g. Adobe, Unity) could publish pay-to-license engines on the platform, where you could design your more domain-constrained engine to run on top of their engine, and the whole licensing/royalties aspect would be handled automatically.
---
One of the key things I actually want from this project, is to "commodify" these other engines, in the way that MAME/RetroArch/etc "commodify" emulators into cores. I want to "containerize" all the old Flash games, old visual novels, RPG Maker 95 projects, etc. such that you could just pick-up-and-play them the same way you can pick-up-and-play a ROM on a modern multi-core emulator. And with all the same modern niceties, e.g. cloud-based save-states, super-resolution, etc.
The other, perhaps less obvious trick here, is that you can slice up the actual original games themselves — the ones whose game engines are the basis of the mods — and allow the bits and pieces of these original titles to be listed as these same kind of bite-sized "experiences" on the platform — but where these "experiences" are only accessible to owners of the original game (i.e. to people who have the ROM image locally, or maybe who have bought the game from its IP owner(!) through the platform; or who can prove they have paid some other licensing fee to the IP owner, e.g. by SSO-binding an account of that IP owner's platform that proves they have access to a subscription tier that comes with leased licenses for those titles.) Sometimes I just want to re-play a particular small section or mini-game from one of my favorite old games. This platform would treat that section/mini-game as its own addressable resource that I can navigate to and play.
You're right; but also, I had actually never put any of this to paper before; it was mostly just shower thoughts. The GP comment prompted me to actually make a lot of these whimsies concrete and coherent, while I had a moment between things at work, and a good reason to do so. The design docs will cite this comment thread! :)
I spent a bunch of time in my 20s and early 30s trying out different organizational systems but I realized I just don't care. I care about doing interesting things, not organizing them.
Also computers are pretty good at full-text searching for things, or tagging so you don't have to come up with a perfect hierarchy. And I think LLMs will make it even easier to find stuff using fuzzy language.
Life's too short to spend it organizing.