9 ms·

Visual programming should start in the debugger

126 points by iamwil 2y ago

qresf 2y ago
[flagged]
sroussey 2y ago
I see three issues with the nice ideas presented: 1. Incentives. I’ve made my contributions to debuggers (Firebug mostly), and devs are not willing to pay for it (we had donations, but I’ve seen people create projects in the space) and so tool makers (browser makers in this case) eat the cost and see it as a cost center. Because of this, the debuggers are at the abstraction layer of the tool itself. The tools change and the cost of keeping the debugger in sync (usually well after the feature is out there) is already high enough. I put hooks into Firebug to make it better for higher level debugging of frameworks. Later I made a paid extension [*]. It paid for a new computer, and spawned many framework specific extensions over time. I pushed Chrome's DevTools team to add some of the same hooks. Sadly, a decade later, many of those framework level extensions don't use what is available. Again, it is a cost center for the framework development, so just enough gets done, no more. 2. Tools are Siloed. You may have OpenTelementry, etc., but that data is siloed off somewhere. The IDE doesn't have it. But the IDE has extensions, so maybe someone like Microsoft can bridge the gap and put up a sidebar that is a heatmap of the time that that code takes on the CPU. 3. Levels of Abstraction. When you talk about state and data modeling, not only is it siloed, but the levels of abstraction are plentiful. It is somewhat possible, but I refer you back to 1--Incentives. [*] https://vimeo.com/showcase/2541003/video/75271334 https://vimeo.com/showcase/2541003/video/75271334
- jauntywundrkind 2y ago
  The self-intro to wasm project I want to get up to is a service-workers that is a OTel collector/store-and-forward proxy. It is kind of wild, otel has these collection protocols but there's afaik not any enduring access protocols. It's all over the wire protocols, nothing is defined for reading an archive of traces. Otel avoids specifying any common APIs for the storage layers, seemingly.
  - sitkack 2y ago
    Otel is sponsored by cloud providers, they want you to land data in their systems to be queried and visualized by their tools. There is no incentive to provide a common access layer because that is where all the players in the telemetry market see their profits.
gumby 2y ago
People talk about using LLMs to write code, but is there any work on using RNNS (perhaps LLMs) to explain what a piece of code does? Seems like that might be a good feature for a debugger.
- kragen 2y ago
  i've found gpt-4 to be mediocre at writing code but superb at explaining it
- ben_w 2y ago
  I've tried that — copy paste in code, ask it to explain what it does. This worked (with the original ChatGPT 3.5) about as well as asking it to write code if you did the documentation first. Not great, not terrible, misses more precisely when you want the most help. I should try again with 4o.
smusamashah 2y ago
Screenshot at the end of the article is from this video. He calls it spatial programming and mentions some other tools which did that in the start of the video. https://www.youtube.com/watch?v=eQgxFuw8f1U https://www.youtube.com/watch?v=eQgxFuw8f1U
- agumonkey 2y ago
  The Cellpond video was quite mindblowing, and lu wilson throws other similarly mind bending ideas on mastodon semi regularly. I loved the live remapping thing here https://mastodon.social/@TodePond@mas.to/112733298578556294 https://mastodon.social/@TodePond@mas.to/112733298578556294
- humbugtheman 2y ago
  who is he?
  - codetrotter 2y ago
    The person in the video, presumably. Lu Wilson / Luke Wilson. (They said in the video that either name is fine.)
aantix 2y ago
I developed Call Stacking as a visual debugger. It captures everything for a given request - each method call, params/argument/return values, class name/method/line of execution. You can visibly see which method called which, as each method call is nested relative to its parent callee, in a single consolidated timeline. https://callstacking.com/ https://callstacking.com/
ProfessorZoom 2y ago
The debugger? You mean console.log("here") ?
- sroussey 2y ago
  There was a time before console.log existed. In fact, later when it existed in FB if you called it in production code it would cause an exception for your users (console didn’t exist unless you had Firebug installed).
agumonkey 2y ago
I'm still shocked how limited our tools are. People in the early 2000s could animate complex 3d scenes in real time with physics and soft body dynamics. But tracing a few variables feels like an herculean effort. Maybe it's time to flip the game on its head. Bring reactive, lispmachines, responsive UIs.. I don't know.
- 7thaccount 2y ago
  Windows, Linux, and Mac desktop OS are so limited still. I'd like a little scripting language built-in to the OS that allows you to do stuff like draw to the screen. No, Python + turtle graphics doesn't count :) There are simply far too many hurdles to do basic computing things. I think Microsoft could do some minor additions to powershell and maybe get something like this. I wish some billionaire would put up some money and fund a modern lisp machine or something like that. I know it'll probably never work, but I can dream.
  - owenpalmer 2y ago
    Elon needs to sponsor Jonathan Blow to build a Windows competitor
    - mrkeen 2y ago
      What kind of user-space programs would you run on this OS?
      - 7thaccount 2y ago
        I honestly think the desktop and web need a redo. This will never happen, but this is my naive dream: I want to open my laptop to an operating system with no advertisements or 1000 programs running in the background. It should be pretty simple with basic application support like a text editor, office suite,: database...etc. It would have a super powerful scripting language built-in with DSLs for graphics, UI, mathematics/science, OS, sound, hardware...etc. It would also have some good hardware peripherals you could control. Basically an ideal work and hobby computer that has some centralized/integrated way of accessing all the tools you need with minimal fuss. It just makes me wonder why in some respects there are still many things that the Xerox Alto or Commodore 64 can do that I can't easily do in Windows. Need to write a simple videogame? That should just involve opening the shell and typing in some high level primitives instead of downloading some crazy big software and libraries If(Foo){ Draw-Circle -Vertex [100,25] -Radius [2] } Want to do some linear algebra work? Invert-Matrix -FileInput 'example.csv' -Sparse 'True' Maybe you want to read some data from some kind of hardware device that has a sensor (e.g. measuring air quality) and send it to a chart? ForeverLoop(Get-Data -Port [0]) | LineChart The commands above are obviously made up, but that is kind of what I'm thinking about. With modern OS, I have to download, install, and configure many tools to typically do these things and it is so messy and cumbersome. I often can't share with anyone else either without them installing all the same apps (e.g .maybe they have to download anaconda Python and postgres). The Web is also just way too complex now. Ideally there would be a much simpler way to build beautiful and simple sites similarly to the hypothetical apps above.
cyberax 2y ago
Yeah. Debugging is getting _way_ less attention than it should. I know some people who _boast_ that they don't use a debugger. To me it feels like a doctor saying: "We don't use new-fangled X-Rays here, you should be able to find problems with just a stethoscope". And good debugging support doesn't need to be some fancy "Minority Report" style 4D animated UI. Just give us good type rendering support, an easy ability to chain breakpoints and set conditional breakpoints, "watch variable" support. Some other things: "where did this value came from?", "watch for value use". Go is an especially bad example. Its debugger doesn't even allow custom type rendering, so if you have something like a custom generic map container, you can't inspect it at the debug time.
- mrkeen 2y ago
  For me, not using a debugger is kind of like not using valgrind. If you stop operating on memory directly, you forget you ever needed valgrind. Likewise, if you write functions instead of methods, then you can just take the problematic input, and evaluate your function on it, and inspect the output - without needing to get the whole program into the right state for stepping through. I kind of gave up on step-through right around the same time I started writing multithreaded code as well.
  - cyberax 2y ago
    Debuggers allow to "look around" the running code. This is really helpful in large systems, where you don't necessarily even know all the components. It's fine when you're working in a nice segregated part of the system, where everything is well-defined. But it's not always the case. Also, single-stepping is a nice mental tool, kinda like rubber-ducking. You single-step and explain to yourself what is going on.
  - randomdata 2y ago
    Well now you have us curious: What programming language treats methods as something other than what is ultimately a function with an additional implied parameter? Whether a parameter is implicit or explicit doesn't really change anything with respect to the state of the program. You need to construct the state either way.
alfiedotwtf 2y ago
Paper and pen. Sure might not work on LARGE projects, but when I’m reverse engineering something or trying to debug, I always start with a control flow diagram… works a treat! But in the past 6 months I’ve started to use graphviz and other tools to quickly document code paths for others
skobes 2y ago
Similar post from a few days ago: "We need visual programming. No, not like that." https://news.ycombinator.com/item?id=40937119 https://news.ycombinator.com/item?id=40937119
TuringTest 2y ago
I've always said so. The essence of visual programming is watching code and runtime values juxtaposed, not connecting code primitives with fancy connectors. Modern IDEs have lots of visual features, specially tailored to support production languages. Inspection panels, tooltips with variable values and function definitions... Surely we could add more spatial visualization tools to them. But the step up from printf to a debugging inspector panel was on its own a great advance in building a mental model of the program state and making sense of its behaviour, which is what visual programming is all about. For programmers interested in advanced visual tools tailored to software creation, see Bret Victor's essays on notations: https://worrydream.com/MediaForThinkingTheUnthinkable/ https://worrydream.com/MediaForThinkingTheUnthinkable/ https://worrydream.com/LadderOfAbstraction/ https://worrydream.com/LadderOfAbstraction/
corysama 2y ago
Shoutout to https://whitebox.systems/ https://whitebox.systems/ It only really works with C-with-Classes style C++. But, the fact that it works at all is pretty neat.
hcarvalhoalves 2y ago
Agreed. Visual programming focuses on visualising the structure of the _program_, but what matters more is visualising the structure of the _data_ and, even more importantly, what the program is doing to the data (visualising in the time domain). A major bottleneck for people learning programming is developing a mental model of what is in the memory during the runtime and what it looks like. The most successful introductions to programming start by making drawings or small games since it's more intuitive for beginners to iterate and have immediate feedback.
andoando 2y ago
I had a similar idea. I was working with some complex recursive functions and it was impossible to figure out what was going on. Trying to parse through 1000 console logs was nearly impossible so I had the idea of rendering the function call stack and attaching the logs to where in the stack it was called from and rendering it as an interactive graph. Its mostly just a demo but I think something like this a standard tool would be really helpful. https://github.com/ando818/Svelte-Logger https://github.com/ando818/Svelte-Logger
- kmoser 2y ago
  I know this is after the fact but I've gotten much of the same functionality by indenting each line in the log to a level commensurate with how far down in the call stack it's happening. Just being able to see the indentation tells me most of what I need to know. On a related topic, what would really help debugging in most languages is more consistent functionality for built-in introspection, which allows devs to write sophisticated analysis tools. Just being able to access things like the call stack, argument count, etc. is super important, but unfortunately every language has its quirks about what can actually be accessed, and in what contexts (function vs. method), etc.
deleted 2y ago
[deleted]
donadigo 2y ago
I sympathize a lot with this post. Today, modern IDE's still don't provide automatic ways to inspect program execution and nicely visualize it. Instead, they rely on having you place all the breakpoints, step-step-step and restart everything again if you did not inspect something in time. I don't want to insert print statements that end up clogging the console completely. This workflow also quickly breaks with a lot of logging. I'm quite a bit into developing more tooling around that, and it's really hard - developers particularly want tools that completely integrate with existing IDE's. Debugger infrastructure is usually not built to be very exstensible or accessible. For my extension for Visual Studio https://d-0.dev/ https://d-0.dev/ I had to put serious effort into making sure it all still works correctly with VS breakpoints which is extremely difficult when the debugger expects all of the code to be in the same place all the time.
diegof79 2y ago
If you search for the keywords “program understanding” and “program visualization” in Google Scholar, you’ll see a lot of research on how to visualize and comprehend systems. Around 2007, one visualization that caught the internet’s attention was CodeCities by M. Lanza, and there is also Moose[1], which is based on Pharo and provides abstractions to query and visualize code bases. But, for some reason, none of these tools catch the attention of the most popular IDEs. I hypothesize that there are major roadblocks to implementing this in a generic and useful way. The first one is the variety of languages, frameworks, and build tools. For example, analyzing a TypeScript+React code base is not the same as analyzing a TypeScript+Vue code base, even when both use TypeScript and the TSC API is very easy to use. The second roadblock is that useful visualizations also depend on the characteristics of your system, and creating them is not easy. Maybe things will change with the addition of AI to analyze code bases, but so far, all the tools I’ve seen are either very niche or very short-lived. [1]: https://moosetechnology.org/ https://moosetechnology.org/
rpcope1 2y ago
Having actually partially designed and maintained a visual programming product with I guess what would be called a time travel debugger (among many other fascinating and strange features) inside of a major technology company, the biggest push back was always from developers themselves. These things sound good, and often they're very useful to those without strong programming backgrounds, but inevitably developers are pretty aggressive about poo-pooing tools like this as lots of things are much harder to implement, like diffing for example. The tool itself was honestly very radical (we were able to do a ton of really cutting edge things around resource scheduling, containerization pre-Docker, real actual shared time travel debugging at massive scale), but in the end, I think the company shitcanned it for something much simpler.
- brandonmenc 2y ago
  I can't be the only one here who would love to hear more about this.
Wooclurs 2y ago
The article is missing all industrial visual programming.

126 points by iamwil 2y ago

[flagged]

I see three issues with the nice ideas presented: 1. Incentives. I’ve made my contributions to debuggers (Firebug mostly), and devs are not willing to pay for it (we had donations, but I’ve seen people create projects in the space) and so tool makers (browser makers in this case) eat the cost and see it as a cost center. Because of this, the debuggers are at the abstraction layer of the tool itself. The tools change and the cost of keeping the debugger in sync (usually well after the feature is out there) is already high enough. I put hooks into Firebug to make it better for higher level debugging of frameworks. Later I made a paid extension [*]. It paid for a new computer, and spawned many framework specific extensions over time. I pushed Chrome's DevTools team to add some of the same hooks. Sadly, a decade later, many of those framework level extensions don't use what is available. Again, it is a cost center for the framework development, so just enough gets done, no more. 2. Tools are Siloed. You may have OpenTelementry, etc., but that data is siloed off somewhere. The IDE doesn't have it. But the IDE has extensions, so maybe someone like Microsoft can bridge the gap and put up a sidebar that is a heatmap of the time that that code takes on the CPU. 3. Levels of Abstraction. When you talk about state and data modeling, not only is it siloed, but the levels of abstraction are plentiful. It is somewhat possible, but I refer you back to 1--Incentives. [*] https://vimeo.com/showcase/2541003/video/75271334 https://vimeo.com/showcase/2541003/video/75271334

jauntywundrkind 2y ago
The self-intro to wasm project I want to get up to is a service-workers that is a OTel collector/store-and-forward proxy. It is kind of wild, otel has these collection protocols but there's afaik not any enduring access protocols. It's all over the wire protocols, nothing is defined for reading an archive of traces. Otel avoids specifying any common APIs for the storage layers, seemingly.
- sitkack 2y ago
  Otel is sponsored by cloud providers, they want you to land data in their systems to be queried and visualized by their tools. There is no incentive to provide a common access layer because that is where all the players in the telemetry market see their profits.

gumby 2y ago

People talk about using LLMs to write code, but is there any work on using RNNS (perhaps LLMs) to explain what a piece of code does? Seems like that might be a good feature for a debugger.

kragen 2y ago
i've found gpt-4 to be mediocre at writing code but superb at explaining it
ben_w 2y ago
I've tried that — copy paste in code, ask it to explain what it does. This worked (with the original ChatGPT 3.5) about as well as asking it to write code if you did the documentation first. Not great, not terrible, misses more precisely when you want the most help. I should try again with 4o.

smusamashah 2y ago

Screenshot at the end of the article is from this video. He calls it spatial programming and mentions some other tools which did that in the start of the video. https://www.youtube.com/watch?v=eQgxFuw8f1U https://www.youtube.com/watch?v=eQgxFuw8f1U

agumonkey 2y ago
The Cellpond video was quite mindblowing, and lu wilson throws other similarly mind bending ideas on mastodon semi regularly. I loved the live remapping thing here https://mastodon.social/@TodePond@mas.to/112733298578556294 https://mastodon.social/@TodePond@mas.to/112733298578556294
humbugtheman 2y ago
who is he?
- codetrotter 2y ago
  The person in the video, presumably. Lu Wilson / Luke Wilson. (They said in the video that either name is fine.)

aantix 2y ago

I developed Call Stacking as a visual debugger. It captures everything for a given request - each method call, params/argument/return values, class name/method/line of execution. You can visibly see which method called which, as each method call is nested relative to its parent callee, in a single consolidated timeline. https://callstacking.com/ https://callstacking.com/

ProfessorZoom 2y ago

The debugger? You mean console.log("here") ?

sroussey 2y ago
There was a time before console.log existed. In fact, later when it existed in FB if you called it in production code it would cause an exception for your users (console didn’t exist unless you had Firebug installed).

agumonkey 2y ago

I'm still shocked how limited our tools are. People in the early 2000s could animate complex 3d scenes in real time with physics and soft body dynamics. But tracing a few variables feels like an herculean effort. Maybe it's time to flip the game on its head. Bring reactive, lispmachines, responsive UIs.. I don't know.

7thaccount 2y ago
Windows, Linux, and Mac desktop OS are so limited still. I'd like a little scripting language built-in to the OS that allows you to do stuff like draw to the screen. No, Python + turtle graphics doesn't count :) There are simply far too many hurdles to do basic computing things. I think Microsoft could do some minor additions to powershell and maybe get something like this. I wish some billionaire would put up some money and fund a modern lisp machine or something like that. I know it'll probably never work, but I can dream.
- owenpalmer 2y ago
  Elon needs to sponsor Jonathan Blow to build a Windows competitor
  - mrkeen 2y ago
    What kind of user-space programs would you run on this OS?
    - 7thaccount 2y ago
      I honestly think the desktop and web need a redo. This will never happen, but this is my naive dream: I want to open my laptop to an operating system with no advertisements or 1000 programs running in the background. It should be pretty simple with basic application support like a text editor, office suite,: database...etc. It would have a super powerful scripting language built-in with DSLs for graphics, UI, mathematics/science, OS, sound, hardware...etc. It would also have some good hardware peripherals you could control. Basically an ideal work and hobby computer that has some centralized/integrated way of accessing all the tools you need with minimal fuss. It just makes me wonder why in some respects there are still many things that the Xerox Alto or Commodore 64 can do that I can't easily do in Windows. Need to write a simple videogame? That should just involve opening the shell and typing in some high level primitives instead of downloading some crazy big software and libraries If(Foo){ Draw-Circle -Vertex [100,25] -Radius [2] } Want to do some linear algebra work? Invert-Matrix -FileInput 'example.csv' -Sparse 'True' Maybe you want to read some data from some kind of hardware device that has a sensor (e.g. measuring air quality) and send it to a chart? ForeverLoop(Get-Data -Port [0]) | LineChart The commands above are obviously made up, but that is kind of what I'm thinking about. With modern OS, I have to download, install, and configure many tools to typically do these things and it is so messy and cumbersome. I often can't share with anyone else either without them installing all the same apps (e.g .maybe they have to download anaconda Python and postgres). The Web is also just way too complex now. Ideally there would be a much simpler way to build beautiful and simple sites similarly to the hypothetical apps above.

cyberax 2y ago

Yeah. Debugging is getting _way_ less attention than it should. I know some people who _boast_ that they don't use a debugger. To me it feels like a doctor saying: "We don't use new-fangled X-Rays here, you should be able to find problems with just a stethoscope". And good debugging support doesn't need to be some fancy "Minority Report" style 4D animated UI. Just give us good type rendering support, an easy ability to chain breakpoints and set conditional breakpoints, "watch variable" support. Some other things: "where did this value came from?", "watch for value use". Go is an especially bad example. Its debugger doesn't even allow custom type rendering, so if you have something like a custom generic map container, you can't inspect it at the debug time.

mrkeen 2y ago
For me, not using a debugger is kind of like not using valgrind. If you stop operating on memory directly, you forget you ever needed valgrind. Likewise, if you write functions instead of methods, then you can just take the problematic input, and evaluate your function on it, and inspect the output - without needing to get the whole program into the right state for stepping through. I kind of gave up on step-through right around the same time I started writing multithreaded code as well.
- cyberax 2y ago
  Debuggers allow to "look around" the running code. This is really helpful in large systems, where you don't necessarily even know all the components. It's fine when you're working in a nice segregated part of the system, where everything is well-defined. But it's not always the case. Also, single-stepping is a nice mental tool, kinda like rubber-ducking. You single-step and explain to yourself what is going on.
- randomdata 2y ago
  Well now you have us curious: What programming language treats methods as something other than what is ultimately a function with an additional implied parameter? Whether a parameter is implicit or explicit doesn't really change anything with respect to the state of the program. You need to construct the state either way.

alfiedotwtf 2y ago

Paper and pen. Sure might not work on LARGE projects, but when I’m reverse engineering something or trying to debug, I always start with a control flow diagram… works a treat! But in the past 6 months I’ve started to use graphviz and other tools to quickly document code paths for others

skobes 2y ago

Similar post from a few days ago: "We need visual programming. No, not like that." https://news.ycombinator.com/item?id=40937119 https://news.ycombinator.com/item?id=40937119

TuringTest 2y ago

I've always said so. The essence of visual programming is watching code and runtime values juxtaposed, not connecting code primitives with fancy connectors. Modern IDEs have lots of visual features, specially tailored to support production languages. Inspection panels, tooltips with variable values and function definitions... Surely we could add more spatial visualization tools to them. But the step up from printf to a debugging inspector panel was on its own a great advance in building a mental model of the program state and making sense of its behaviour, which is what visual programming is all about. For programmers interested in advanced visual tools tailored to software creation, see Bret Victor's essays on notations: https://worrydream.com/MediaForThinkingTheUnthinkable/ https://worrydream.com/MediaForThinkingTheUnthinkable/ https://worrydream.com/LadderOfAbstraction/ https://worrydream.com/LadderOfAbstraction/

corysama 2y ago

Shoutout to https://whitebox.systems/ https://whitebox.systems/ It only really works with C-with-Classes style C++. But, the fact that it works at all is pretty neat.

hcarvalhoalves 2y ago

Agreed. Visual programming focuses on visualising the structure of the _program_, but what matters more is visualising the structure of the _data_ and, even more importantly, what the program is doing to the data (visualising in the time domain). A major bottleneck for people learning programming is developing a mental model of what is in the memory during the runtime and what it looks like. The most successful introductions to programming start by making drawings or small games since it's more intuitive for beginners to iterate and have immediate feedback.

andoando 2y ago

I had a similar idea. I was working with some complex recursive functions and it was impossible to figure out what was going on. Trying to parse through 1000 console logs was nearly impossible so I had the idea of rendering the function call stack and attaching the logs to where in the stack it was called from and rendering it as an interactive graph. Its mostly just a demo but I think something like this a standard tool would be really helpful. https://github.com/ando818/Svelte-Logger https://github.com/ando818/Svelte-Logger

kmoser 2y ago
I know this is after the fact but I've gotten much of the same functionality by indenting each line in the log to a level commensurate with how far down in the call stack it's happening. Just being able to see the indentation tells me most of what I need to know. On a related topic, what would really help debugging in most languages is more consistent functionality for built-in introspection, which allows devs to write sophisticated analysis tools. Just being able to access things like the call stack, argument count, etc. is super important, but unfortunately every language has its quirks about what can actually be accessed, and in what contexts (function vs. method), etc.

deleted 2y ago

[deleted]

donadigo 2y ago

I sympathize a lot with this post. Today, modern IDE's still don't provide automatic ways to inspect program execution and nicely visualize it. Instead, they rely on having you place all the breakpoints, step-step-step and restart everything again if you did not inspect something in time. I don't want to insert print statements that end up clogging the console completely. This workflow also quickly breaks with a lot of logging. I'm quite a bit into developing more tooling around that, and it's really hard - developers particularly want tools that completely integrate with existing IDE's. Debugger infrastructure is usually not built to be very exstensible or accessible. For my extension for Visual Studio https://d-0.dev/ https://d-0.dev/ I had to put serious effort into making sure it all still works correctly with VS breakpoints which is extremely difficult when the debugger expects all of the code to be in the same place all the time.

diegof79 2y ago

If you search for the keywords “program understanding” and “program visualization” in Google Scholar, you’ll see a lot of research on how to visualize and comprehend systems. Around 2007, one visualization that caught the internet’s attention was CodeCities by M. Lanza, and there is also Moose[1], which is based on Pharo and provides abstractions to query and visualize code bases. But, for some reason, none of these tools catch the attention of the most popular IDEs. I hypothesize that there are major roadblocks to implementing this in a generic and useful way. The first one is the variety of languages, frameworks, and build tools. For example, analyzing a TypeScript+React code base is not the same as analyzing a TypeScript+Vue code base, even when both use TypeScript and the TSC API is very easy to use. The second roadblock is that useful visualizations also depend on the characteristics of your system, and creating them is not easy. Maybe things will change with the addition of AI to analyze code bases, but so far, all the tools I’ve seen are either very niche or very short-lived. [1]: https://moosetechnology.org/ https://moosetechnology.org/

rpcope1 2y ago

Having actually partially designed and maintained a visual programming product with I guess what would be called a time travel debugger (among many other fascinating and strange features) inside of a major technology company, the biggest push back was always from developers themselves. These things sound good, and often they're very useful to those without strong programming backgrounds, but inevitably developers are pretty aggressive about poo-pooing tools like this as lots of things are much harder to implement, like diffing for example. The tool itself was honestly very radical (we were able to do a ton of really cutting edge things around resource scheduling, containerization pre-Docker, real actual shared time travel debugging at massive scale), but in the end, I think the company shitcanned it for something much simpler.

brandonmenc 2y ago
I can't be the only one here who would love to hear more about this.

Wooclurs 2y ago

The article is missing all industrial visual programming.