The UI of the tool has improved and I like the green black combo. A note on the video: I think it is better presented by showing the problem first and then may be alluding to the kind of solutions that exist in the market and show how Instadeq solves it better, because otherwise, people who don’t have the context will find it a bit random. May be call it recipes or something and show how easy it is to solve the particular problem using Instadeq. In any case, great job polishing this and keeping on improving it.

It lacks a lot of context because I tried to fit it under 3 minutes 😄 still I've noticed that people ask me to explain more and go slower but if I make a video above 5 minutes less people watch it and those who do drop after a few minutes 😢

After I finish some open issues I will make more detailed videos per topic/task 🙂

Yeah, I think a good way to market this would be to cut it short to may be like 1 minute Instagram like videos and then show how it solves a crucial problem. You might want to figure out a way to come up with such problems that can be solved swiftly and cleanly with this environment.

I mean, once you get people hooked and show how it relates to their nagging daily problems, I think it would be an easy way to gain traction. I can see a lot such problems being able to be solved with an environment like this.

yes, I have to find the right balance of "pre set parts" and important steps, like those recipe videos that show you how to cook something in a couple of minutes

and use the short ones to direct users to the long ones where I explain all the details

Yeah, that will be a neat transition. The juicy and wow part of this environment is when there’s a significant problem being solved with this and you get all the nice replay abilities and multiway bindings undergoing, but to sell that part, may be pitch in with simple stuff and gradually build a userbase around it.

I've been thinking along similar lines.

What do the lines between some of the boxes mean?

Are the line numbers useful in this organization?

the lines are part of the path-aware browsing. when you go to definition or drag a symbol to open a new pane, it’ll draw a line from parent -> child. By default, closing a pane will close all its children recursively.

That’s a good question about line numbers. One thing it tells you is that there’s more content above if it doesn’t start at 0 but that can be conveyed in a different way. Thanks!

I see, so by 'path' you mean just the path of a specific browser session. Makes sense!

I've spent the last few weeks trying to clean up and refactor a hugely complex collection of code. Tools like this are what I'm missing. An easy way to make a pin board of the fragments I need to hold in my head, and the relations between them. It's 2020 and tools still don't have good ways to do this! I applaud your efforts! Perhaps a usage video in #two-minute-week ?

Chris Maughan thanks! i totally agree with your sentiment

and i’ll try to make a video soon 🙂

This looks great! I really like these customizable 'slice viewers'. One suggestion I'd have is to connect the line to source window at the the corresponding location in the scroll bar, rather than the top title bar.

BTW, have you seen http://sourcetrail.com?

Historical references that might be of interest down this vein:

• http://cs.brown.edu/~spr/codebubbles/ (here’s a good https://www.youtube.com/watch?v=PsPX0nElJ0k)
• https://www.youtube.com/watch?v=3p9XUwIlhJg
• The original https://vimeo.com/40281991 explored alternative layouts

Me and a couple of other folks were behind 2 and 3, though for 2 they removed a lot of the coolest stuff for whatever reason. It’s really cool and a really neat way to debug, though when we tested it internally, people didn’t like it for writing. This introduced a hard divide between read time and write time and not being able to fluidly transition between the two caused people to rate their qualitative experience with the system fairly low.

Another thing we ran into is that it ended up requiring a fair amount of manual gardening to make it useful and over time people seemed to spend more of their effort on laying things out rather than getting better at it like we thought they would.

This is a beautiful looking implementation 🙂 To take it all the way, it’s worth thinking about how you’ll tackle the tragedy of the commons and fluidity problems. Find reasonable answers to those and you’ll have something really special!

Super job, Paul! This made me really think that the abstraction level at which we usually think about “node-and-wire” programming (typically the AST level) might not be optimal for exploring codebases. Just sort of spewing my thoughts here, but perhaps it would be better to expose different representations at different “zoom levels”: for instance, if I zoomed into a file inside the code browser, it would turn into a graphical editor, but if I zoom out, I get a text representation. Or maybe it would be more reasonable to give the user a choice of which representation they wanted to see at a particular level of abstraction. It just seems like there is no “one size fits all” representation that can encompass all levels of abstraction.

It also made me think deeper about the notion of “incrementalism”, and how we might do well to embrace some of those ideas as a community: don’t get me wrong, there are some things that you can only do by taking a “greenfield” approach to development, but I think there is so much room for improving the status quo, that even “small” changes in representation with existing languages/tools (in this case, JavaScript and the Monaco editor from VS Code) could have on the “near-term future of coding”.

I think it would be really neat to explore breaking out the “show references” functionality into separate editor windows (or “blocks”) as well, something along the lines of what Dark has done in their editor (image below).

Maybe the “find references” command could draw temporary arrows to the files in the file explorer window, or highlight open windows that contain references to the item in question.

Finally, I think this would be absolutely killer for doing collaborative code reviews/pair programming. Stellar work!

Wow I’m blown away by the quality of responses. I’ve found the right place. Thank you all so much!

Shalabh Chaturvedi drawing the path to the code line would be ideal. We’d have to listen to the scroll event but it might be doable. I’ll take a look at sourcetrail.

Chris Granger I’ve been linked to code bubbles and debugger canvas so many times now. I think that’s great! The ideas clearly resonate with people and it’s something people want. All 3 products you linked to are packed with good ideas and I admire them all. (i don’t claim to be doing anything new)

That’s really good to know re mixed feedback. My current goal is to explore the best code reading experience (ala github). The write experience seems like it’d be a natural extension but I’m learning why files and text manipulation still reign supreme. We humans are so well-versed in it haha.

I’d love to hear more about the “manual gardening” re debugger canvas. What did “getting better at it” mean in your head? Thanks for your advice!

Chris Rabl yeah! I love the idea of different lenses (e.g. zoom levels) on the same underlying. One thing I definitely want to explore is presenting the outline view somehow (high-level AST - e.g. functions, classes, etc.).

I think your point of “incrementalism” is really important. When I hear “future of code” (or prompts like “what does coding look like in 10 years”), my mind jumps immediately to inventing PL and completely new tools. But you don’t need to convince me that if I tried to built an editor, even I wouldn’t end up using it. Actually another one of my projects was building something Dark-like (something I admire a lot) but with JS and monaco-editor panes on a canvas, very similar to the demo I linked to. Dark has so many good ideas and I love the exploration but I think it’s going to be hard to get people to learn a new language/editor today. Honestly, the most “impactful” thing I could do is probably build a VSCode extension but I want the space to explore for now.

Thanks for the ideas and kind words! Imagine a Github browser and pull request UI that looks more like a canvas. That’s the direction I’m stumbling towards.

my tabled hack of something Dark-like using JS + monaco

Take my money! 💵💵💵

this feels, uh, REALLY good to use

Initial rambles:

one thing I’d think about is getting a little more task-focused (this is already a pretty task-focused interface)

I find myself creating a kind of mise-en-place in iTerm windows where I’m setting stuff up for some larger change or understanding. I think theres some implicit structure here that you’re hinting at with the child-pane relationships, and the notes that are free-floating vs the notes that are implicitly linked to certain views (e.g. “this is the code when useMemo…). I think the structure isn’t so much the code as it is code-and-task. I’d guess/hypothesize that the hierarchy actually goes big note (“let’s look at the hook useMemo”), annotation-style notes (on mount, it calls the given..) -> code symbols. theres a graphy-outlinely thing here (although I prefer these panes to say a workflowy interface, since in my experience stuff looks like a graph when youre working on it and an outline when you’re done)

maybe it’s actually that your notes are suggesting a transclusion— let’s look at the hook useMemo could be a notion-style slashword interface for pulling up code fragments that come immediately after where you typed in a separate pane

I really like the interface in macOS where you can box-select a bunch of files on the desktop and right click to collect them all into a folder. this feels like it could use that kind of a grouping construct

Nice! I'd like to see tiled window manager-style auto layout and the ability to zoom in and out (see: ZUIs).

(Perhaps less usefully, it seems to be broken in Safari.)

Garth Goldwater i’m still formulating my thoughts but I think canvases might not be ideal for knowledge transfer (documentation). Along your lines of thought, I think documentation wants to be in a more linear format (e.g. notion doc or markdown file) so that it’s readable with ability to drill down/explore on the side. The notion-style slashword interface would be cool!

Makes me think of @Raathi’s post https://futureofcoding.slack.com/archives/CCL5VVBAN/p1600909703001500

Here is a "dynamic screenshot" of the result for this POC:

(I assume you're asking @Everett Pompeii — Just posting an @-mention so that they won't miss this new thread in a new channel)

Great thought on a new thread, Nicolas Decoster!

And I’ll also tag @Dan Cook if he’s interested in joining in.

Your demo looks super cool! I think it’s a great visual representation of what the CRDT is doing. I’m still very much a novice in the CRDT space, once I get more up to speed I look forward to digging into the code to help me learn 👨‍💻

I also have Kleppmann’s Designing Data-Intensive Applications sitting on my shelf waiting to be read.

As for my project, TableFlow, I built a basic dummy demo of it in React if you want to check it out: http://tableflow.org/studio/flow/#a

The motivation behind it is to build a “better Excel” for power users and also software developers who would rather not deal with all the incidental complexity of modern app development for a project with complex logic, ie not just some CRUD app.

There are four core concepts: Tables, Flows, Subflows, and Decisions:

• Tables are the core data type. Depending on how they are configured they can be algebraic data types (ADTs/enums), structs/maps, lists, values, and/or an arbitrary nesting of any of these. Sort of like a statically typed version of JS objects with ADTs and a shorthand for tabular data built in.
• Flows are pure functions. A Flow can be called by any other Flow or via a REST (or possibly gRPC) call to an endpoint from outside of TableFlow. A Flow can contain zero to any number of Subflows.
• Subflows are functions just like Flows, but they can only be called once and by their parent. They’re sort of the opposite of a closure in that scope must be explicitly passed into them. They are very similar to Brian Will’s concept of a “use” function. They help break up Flows both visually and in terms of size/scope. At any point in the future a Subflow can be converted into a standalone Flow if necessary.
• Decisions are DMN decision tables on steroids. They are where conditional logic, Flow branching, and auto-iteration over all the rows in a table happen. Good example of the first two: https://docs.appian.com/suite/help/20.3/Appian_Decisions.html

There would be live data supplied to a Flow by filling in the input Tables. There would be a slider at the top of this input to time travel through the input history. Some of these inputs can be saved as “snapshots” along with their corresponding outputs. TDD would be built in, so every time a change is made, all applicable snapshots are run against the change and its outputs.

Once a run occurs, there would be a built in time traveling debugger. Each piece of computed/output data would have its own slider that jumps between when there was actually a change to that piece of data in the last run. Recursion is possible so there may be multiple time points.

I also want Tables to be reusable between Flows. The software engineer in me really wants to add public and private “Table Subflows” (ie methods) and then I’m like, well why not interfaces too!

I will probably settle for reusable Tables with methods. Having interfaces would be great, but then I remind myself that even power users of Excel aren’t use to being able to write their own functions natively!

The eventual goal would be to build a TableFlow config => Rust compiler that would spit out a production grade Rust server.

Can you see me drowning in my own ambition yet? 🏊‍♂️🦈

I played around with doing the UI in Elm, looked at ReasonML, and I’m currently giving Seed (seed-rs) a spin. I like The Elm Architecture for the frontend, but I’m just going to try doubling down on the Rust->wasm ecosystem and hopefully the wasm DOM API becomes a thing down the road and closes the performance gap.

Can you see me drowning in my own ambition yet?  > 🏊‍♂️> 🦈Yes! I guess people here knows that feeling. 😅 I guess we are a bunch of futurists swimming or sailing the seas of programming. Sometime feeling like drowning, sometime like surfing.

The motivation behind it is to build a “better Excel” for power users and also software developers who would rather not deal with all the incidental complexity of modern app development for a project with complex logic, ie not just some CRUD app.I also think it is an interesting target audience. Not really all end users, but some that want to do a bit more programming. And trying to create tools for them and also for some "expert" developers is something very interesting.

I like your idea to keep history to make things more explorable by keeping the time dimension. I guess this can become very tricky. I guess you have to find a way to manage the space limit for the history, i.e. when it takes too much resources. For simple use case it can be fine, but when you manage big tables that changes often you will have to remove part of the history.

sometime like surfingI’ll try and get there! 🏄‍♂️

And trying to create tools for them and also for some “expert” developers is something very interesting.This honestly comes from me being a big personal finance nerd, and I once made a spreadsheet that calculates all of my finances, think a personal double sided balance sheet. Coming back a year later though, it made the engineer side want to cry. It was impossible to maintain efficiently, but I also didn’t want to manage an app to do it either. Then as I learned more about the adoption of Functions-as-a-Service, it seemed to really extend the upper limit for the use cases.

I guess you have to find a way to manage the space limit for the history, i.e. when it takes too much resources.Yeah, this is definitely an outstanding question. I imagine I will just do a simple set sized FIFO cache to start out, and then down the road I could push to something like IndexedDB (once those bindings actually exist in Rust -> wasm).

I think of the end of the function as the beginning of the return value's lifetime, not the end. Maybe you could find a way to "initialize" the output variable at/near the end, or maybe just take that perspective as a vote for explicit returns.

What are the intended semantics of example 4, where you seem to have x and out mapped to the same register in the same scope. Or is out spilled during the body block, and the assignment to out is targeted at the stack, then popped between the body block and the "actual" function block? It looks like I answered my question while writing it, but I'll leave this just in case I got it wrong...

Yeah, that's a good insight. I wish I'd thought of that a year ago..

If you first ignore outputs, the semantics of a var B in a new block are that it shadows any var A in an outer block. However, a second var C to the same register in the same block simply clobbers the register. There's no way afterwards to get the first var B.

Now reintroducing function outputs in example 4, the assignment to out would write register eax. Then the break would increment the stack pointer to skip the saved value of x before jumping to end of function.

Does this make sense?

I think I understand your description. So at the write to out, x2 is "shadowing" x in eax, x is on the stack, then out clobbers x2?

My instincts say, if you're doing it this way, out should be spilled to the stack like other vars when you enter $foo:body. Then the break would in principle pop x, immediately pop out, and ret. If you're treating output vars as a special case wrt storage management, I don't see how you're getting any benefit from making them syntactically look like regular vars.

Is anything sensible supposed to happen if you don't immediately follow a write to an output with a break or something? Is that verboten, and if so is it checked?

Maybe you should just ban mapping multiple vars to to same register in the same block, and consider out mapped at the function level. x isn't allowed to be in eax until you push a new block.

Hopefully this is semi-useful, but it's late here. :) FWIW, I didn't invent the idea about returns being the start of a new lifetime. It's mostly derived from Single Static Information IR, which has a similar relationship to SSA as Plan9 does to Unix: even more idealistic, and no one uses it.