Think of Gadget as a fancy IDE that goes well beyond coding. The platform gives you components like a db, a serverless runtime, GraphQL API + your own NPM package, an auth system, state machines (...) ; all designed to help you build quickly.

This shaping up nicely! The only bit of (superficial, sorry) feedback I've got at this point is that.. I'm not really able to understand what Gadget is, or what it's for, just by looking at the home page.

• I get that it's for building apps — but what kind of apps? Web apps? iOS apps? It'd be helpful to see an example (screenshot, or little video, or whatever) of an app built with Gadget.
• The video shows me a few teases of Gadget UI, plus a huge comment block (which looks an awful lot like a boilerplate :/ )... but it doesn't give me a sense of what is actually happening. There's a brief second where I can see the sidebar on the left, which seems like it might help me understand the hierarchy of Gadget.. but it goes by too quickly to comprehend. (Products? Product variants? Is this Gadget itself, or something built with Gadget?)

I'm sure the home page is not final. It's just hard for me to know if I could be an early alpha user just by looking at it (even taken together with the helpful problem / challenge / solution description you've posted here).

On a lighter note — "An experience where the computer is responsible for all the annoying busywork the developer doesn't want to do" — in this community, you might find that the folks here are a little more interested in building the things that handle (or cause!) that busywork than building things that leverage the absence of it :P

So it might be tough to find people to kick the tires on this. Hopefully you've got a community of folks somewhere who actually want to, you know, build some apps. They'll probably have much better feedback than the meta-level stuff you'll get here.

That's great feedback. The homepage is a placeholder for the time being, we're focusing our launch on a much smaller niche and we're talking to that audience via a separate landing page. But the feedback on the video is great regardless. WE shot it real fast, but it def misses the mark.

I saw that! Very interesting direction.

Is the primary goal to support some existing language or platform as-is? Or will the language coevolve with the tooling?

Yeah, I'd love to see more about what the goals for the format are, and the relative weights between them. Also, it'd be fun to read thoughtful comparisons scathing takedowns of alternative ideas for source representation (like storing all source in a DB rather than in a file, a la Dark / Unison / Isomorƒ).

Interesting blog post! I was very impressed by the earlier Dion demos as well. For comparison, the project with the most overlap that I can remember is http://infra-structure.org/

Kartik Agaram The idea is that the format will act more like an unopinionated data structure like text files do. We'll bring up a new language along with it, but it will just be one possible language for the format. We hope in time that better language designers than us will find the format compelling and build their own languages.

We don't think we'll bother tying to existing languages except in a "foreign function call" kind of way.

Ivan Reese Our plans for future posts will probably satisfy your relative weights question. As for the scathing takedown, I hate to disappoint but I don't think we have one! We will try to get into a lot of the discussions that led us to our current approach.

Hadn't seen this before! I'm also thinking about these exact same problems, but I'm not sure I agree with the solution. Most of the problems you demonstrate in the start of the Handmade Seattle video aren't really problems with the file format, they're problems with the editor interface.

If you've written an editor to prevent certain classes of errors, you can still write the output of that editor to a textual format. As long as you don't modify that file with other tools, all of your invariants still hold.

Once you're thinking in this projectional way, you could, for instance, save to a text format that is simplified (removing braces/other syntax). But I don't see a strong reason to change the underlying format itself. Moving to a binary (or a 'new text') format just sounds like it would obfuscate the actual data, and require an entirely new toolchain to read and manipulate.

That said, I'm all for that goal if you're fine with it taking many years. 🙂 But it's not just about programming -- it would need to consider all of computing, in some sort of holistic way. It'd be interesting to explore a text-like format with just slightly more structure, but I'm not really sure what that would look like.

Could a new syntax be designed if you’re manipulating the structure of the code and not text?

In Clojure everything is nested parentheses. But could overlapping parentheses be represented in a graphical structural editor that could not be represented with parens in a text file? https://twitter.com/cristianvasquez/status/1400111992174698501?s=20

Would a purely structural editor sort of file format allow more effective merge operations?

Yeah, I'd be interested in seeing that direction. And I think that's a good point and example of something that would be hard to represent as text. The editor you presented in the video didn't seem to take advantage of that (or at least not in the first few minutes. 🙂)

It'd be cool to see more use cases, though, as I can't immediately think of a reason to have overlapping parenthesis, other than maybe succinctness of variable definition. Moving off text requires reimplementing every tool in the workflow, so you have to find a justification for that cost.

Semantic Merge has been done before, and is perfectly possible with a text-based format. My understanding is it largely hasn't caught on for pragmatic reasons -- building a productive merge tool with semantic information is a big task that doesn't provide too much of a benefit. Not enough to get people to pay for it.

This is all relevant to my interests because I'm building a visual language, but specifically choosing a text-based file format. 🙂 So far I haven't found much that text can't represent.

Plain text is many things.. it may be useful to discuss the different aspects independently.

• Plain text as a storage encoding: In theory anything can be encoded as text (worst case you just base64 encode it) but I don't think it is useful to call such an object "plain text".
• Plain text as a UI: This is what I think we often mean when saying something is "just text". The UI consists of lines of characters. Often there are symbols and whitespace as special markers. Words and literals often mean something useful in the subject domain. We navigate this space with the cursor and probably many editor shortcuts.
• Plain text diffs: This is an idea within text-as-UI. When comparing two objects, we compare the plain text representations. This means all encoding artifacts are diffed, whether useful or not (whitespace, order of lines, ...)

I agree that you can always store stuff in plain text - even if you want to represent a graph with nodes, metadata, and links, you could figure out a JSON or XML encoding for it. However, if we're giving up #2 above, because all editing will be done via special projectional editors, how much value do we get in preserving #1? Sure you could check it into git and view the line-by-line diffs, but they would be meaningless, no? With some work the plain text encoding could be carefully crafted so the diffs are somewhat meaningful, but I feel this is a losing battle. Richer projections cannot be displayed by line diffing tools. Objects in the text file cannot be given identity (note many clever hacks such as patience-diff, that try and localize linear diffs to the correct function definition). So in the end the line diff might end up being less and less useful, perhaps even hold us back from implementing richer projections ("oh that will ruin the line diff")?

For sure. Diffs are a clear example a general issue. If you encode something to text, you also have to decide if you want the encoded text to be useful in some way that a binary file would not be. If you do choose that, we think you're prone to importing constraints from "text land" into whatever it is you're building. If you want to get away from the constraints imposed by text, you also give up corresponding aspects of text that make it convenient - they seem to go together.

On the other hand, if you're starting out in a whole new world with nothing, you're liable to be stymied at every turn by lack of tools. (I know a little bit about this 🙂) Using text as a stepping stone might help reduce that friction.

On an unrelated note, it occurs to me that exercising a file format like this will likely require multiple test languages. Ideally spanning a large spectrum of paradigms and tooling requirements.

If you feel like signal boosting, here's my tweet about the episode :)

Nice episode! Her name sounded vaguely familiar but I couldn't quite place it in my memory - until you mentioned gitlet.