You are viewing archived messages.
Go here to search the history.

Jim Meyer 🕰️ 2024-03-09 10:29:03

Software products are physical products. That's why they're hard to design and engineer!

The physicality of software is kept at arms-length in a vector-based design tool. Here, the strength and focus is on surface level aesthetics and exploration though mocks — many, many mocks. All needed. All useful. But a mock does not a product make. A mock is an incomplete story of software physics. Which brings us the other side of the spectrum...

The IDEs — the code editors. The product you ship is here, so "I guess someone has to go there". First challenge: To most people it's walls of inexplicable symbols and weird (even hostile?) punctuation. Then, with code, you're essentially play-acting as a computer. You have to "speak computer" fluently to feel at home here. It's a love/hate relationship of running programs in your head. Mostly failing to do so. Then learning to get better at debugging. Eureka moments of finally solving the puzzle that unlocks a bugfix! Endlessly restarting programs to reset state. Today, even after multiple decades of investment in IDEs, coding is still 100 times harder and less fun than it should be! How can we truly move the needle?

A traditional IDE deals with the how to fully describe the physics of a software system. Writing and editing algorithms. Managing data flows. Figuring out logic. Painting pixels. Sending data at the speed of light over the network. But the IDE doesn't actually let you see the program as it manifests to the user in the final medium. It's running somewhere else — the browser, on your phone. This is where vector-tools have the IDEs at least partially beat. Yes, they're just mocks, but the vector-tool tool sees the mocks alongside you. This changes your relationship with the tool. Thinking and touching — moving, dragging, scaling, rotating, duplicating — seamlessly blends on a canvas, and it just feels good, even fun! IDEs and editing code as text offers none of those things with today's tools, and it just feels like... friction!

So the letter to Santa reads as follows:

Dear Santa, give me the best parts of a vector-based design tool, plus the best parts of an IDE, rolled into one — but with none of the downsides. Thanks!

Christmas can't get here fast enough.

Kongwei Ying 2024-03-31 09:48:01

Jim Meyer I'm working on something a bit like what you're talking about. The biggest problem I see at the moment is that the best programmers (and AI to a large extent these days) have developed a meta cognitive layer over plain textual code, that more accurately describes the data structures and flows of information inherent in code.

Simplest example is assignment

let fruit = "banana"

The implicit flow is

"banana" -> fruit

"banana" is also a constant, whereas the variable fruit, is a store of information that may change over time.

So how to visually represent that fruit is possibly changing, and is a store of information, and that the string "banana" is constant, beyond the obvious string marks and let declaration?

We could show a flowing string of information that goes from "banana" to the variable fruit. Fruit could be highlighted with water as a background, and "banana" could be highlighted with concrete as a background. Maybe this isn't the best visual representation but you get what I mean.

Obviously it gets way more complicated than simple variable declarations and variable assignment but imagine if this kind of visual representation was extended to almost every single aspect of the language?

If, we could explicitly show this implicit meta cognitive layer as visually overlaid over the text itself, it would be a revolution for newbies and seasoned veterans. For newbies, they would understand the logic and flow of the code much much faster, and for veterans, their brain power would be freed from trying to visualise this meta cognitive structure, to focusing on even higher abstraction problems.

The main problems I see are:

  • Identifying all the implicit structures inside our programming languages
  • Creating an intuitive visual representation of each, that is easily understandable
Kongwei Ying 2024-03-31 09:48:01

Jim Meyer I'm working on something a bit like what you're talking about. The biggest problem I see at the moment is that the best programmers (and AI to a large extent these days) have developed a meta cognitive layer over plain textual code, that more accurately describes the data structures and flows of information inherent in code.

Simplest example is assignment

let fruit = "banana"

The implicit flow is

"banana" -> fruit

"banana" is also a constant, whereas the variable fruit, is a store of information that may change over time.

So how to visually represent that fruit is possibly changing, and is a store of information, and that the string "banana" is constant, beyond the obvious string marks and let declaration?

We could show a flowing string of information that goes from "banana" to the variable fruit. Fruit could be highlighted with water as a background, and "banana" could be highlighted with concrete as a background. Maybe this isn't the best visual representation but you get what I mean.

Obviously it gets way more complicated than simple variable declarations and variable assignment but imagine if this kind of visual representation was extended to almost every single aspect of the language?

If, we could explicitly show this implicit meta cognitive layer as visually overlaid over the text itself, it would be a revolution for newbies and seasoned veterans. For newbies, they would understand the logic and flow of the code much much faster, and for veterans, their brain power would be freed from trying to visualise this meta cognitive structure, to focusing on even higher abstraction problems.

The main problems I see are:

  • Identifying all the implicit structures inside our programming languages
  • Creating an intuitive visual representation of each, that is easily understandable
Jeffrey Tao 2024-03-26 19:31:02
Jeffrey Tao 2024-03-26 19:34:07

This is how I write code (at least in Python). Almost every source file I work with, prior to check in, has import pdb at the top and pdb.set_trace() somewhere in the body of a function. I oftentimes develop by writing the start of a function, getting stuck/unsure of how to write the next step, and running the unfinished code and dropping into the REPL to experiment. In compiled languages, I miss this workflow and replicate it poorly with println "debugging" (is there a name for this? prinln-driven development?)

Jeffrey Tao 2024-03-26 19:34:37

(to clarify, I am not the original author of this blog post, but the message resonates with me)

Kartik Agaram 2024-03-26 21:06:44

Could you elaborate on your workflow for print-driven development?

I sometimes write out pseudocode in comments. Does that seem similar?

Ivan Reese 2024-03-29 02:44:13

I've heard some tell of what Joshua Horowitz is up to, and it's exciting. He's set his sights on fixing some of the issues with shell scripting — and is looking for shell script users to interview: assemblag.es/@qualmist/112176567677282801

📝 Josh Horowitz (@qualmist@assemblag.es)

Do you use shell scripts? :shell: :scroll:

I'm conducting a study of how new tools might help. I'd love to talk with you about your shell experiences, and to run our new shell-scripting prototype by you.

Interested? Heck yeah you are, here's a form:

https://docs.google.com/forms/d/e/1FAIpQLSd3a-PckXgqNcXhodsgos_rQF5g5qpT1-PA0lNBD08z2dB7XQ/viewform

(Novices & experts plz!)

🕰️ 2024-01-22 10:10:01

...

Fredrik 2024-03-30 08:42:22

Excellent find. This deserves reposting. This explains why we can't have good software.

The first thing this makes me think of is Chromium. Obviously Chromium has a recently formed sidebar team that by accident has the privilige to push a new and poorly thought through feature of the month to a billion users with every release without checking if any of the other teams has thought of a better way to do it in the last 15 years of Chromium.

The second thing it makes me think of is Gnome Text Editor, which is the default text editor in Ubuntu. It's based on the faulty idea that one team can make a shared library of GUI components that are universally applicable to all apps, and other teams can make apps by composing shared components and not making their own. As a result, Gnome Text Editor is based on the source view component in GTK, and it's terribly buggy, and the bugs cannot be fixed, because the text editor team and the GTK team don't communicate with each other.

Kartik Agaram 2024-03-31 05:11:08

A new category: infinite canvas apps

infinitecanvas.tools/gallery

jsoncanvas.org

canvasprotocol.org

📝 Infinite Canvas app gallery

Explore infinite canvas tools that work the way we think

Maikel van de Lisdonk 2024-03-31 07:46:00

A very nice initiative! I've been reading this too and watching the recording of the first meeting of the OCWG.

Some thoughts that I had (from my visual-programming project perspective):

  • I am missing meta information in the canvas jsonschema like a schemaVersion
  • In my visual programming system the nodes and edges get stored together but not directly on the root level and allow for layers and separate node-compositions (which is not the same as groups)
  • For visual programming depending on the node-task-type (which in my case can be something like "expression" , "condition" , "merge" , "map" etc..) different ports are available and the edges connect to these ports. But perhaps this is also implementation specific.
  • Different node-task-types have different properties, so a custom property-bag per node is also missing for me
Justin Janes 2024-03-31 14:20:24

This reminds me of sprout.place sprout.place

📝 Sprout | Your space, your call

Meet, create & play in customizable spaces. Video chat. Take notes. Browse together. No login needed.

Kartik Agaram 2024-03-31 05:11:08

A new category: infinite canvas apps

infinitecanvas.tools/gallery

jsoncanvas.org

canvasprotocol.org

📝 Infinite Canvas app gallery

Explore infinite canvas tools that work the way we think

Maikel van de Lisdonk 2024-03-31 07:46:00

A very nice initiative! I've been reading this too and watching the recording of the first meeting of the OCWG.

Some thoughts that I had (from my visual-programming project perspective):

  • I am missing meta information in the canvas jsonschema like a schemaVersion
  • In my visual programming system the nodes and edges get stored together but not directly on the root level and allow for layers and separate node-compositions (which is not the same as groups)
  • For visual programming depending on the node-task-type (which in my case can be something like "expression" , "condition" , "merge" , "map" etc..) different ports are available and the edges connect to these ports. But perhaps this is also implementation specific.
  • Different node-task-types have different properties, so a custom property-bag per node is also missing for me
Justin Janes 2024-03-31 14:20:24

This reminds me of sprout.place sprout.place

📝 Sprout | Your space, your call

Meet, create & play in customizable spaces. Video chat. Take notes. Browse together. No login needed.