[HN Gopher] Visual programming should start in the debugger
___________________________________________________________________
Visual programming should start in the debugger
Author : iamwil
Score : 95 points
Date : 2024-07-15 14:32 UTC (4 days ago)
(HTM) web link (interjectedfuture.com)
(TXT) w3m dump (interjectedfuture.com)
| sroussey wrote:
| 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
| jauntywundrkind wrote:
| 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 wrote:
| 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 wrote:
| 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.
| smusamashah wrote:
| 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
| agumonkey wrote:
| 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
| aantix wrote:
| 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/
| ProfessorZoom wrote:
| The debugger? You mean console.log("here") ?
| agumonkey wrote:
| 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 wrote:
| 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.
| 1kurac wrote:
| > a little scripting language built-in to the OS
|
| MacOS has something like this:
| https://en.wikipedia.org/wiki/AppleScript#Basic_concepts You
| can send around events and macro/script GUI stuff.
| owenpalmer wrote:
| Elon needs to sponsor Jonathan Blow to build a Windows
| competitor
| mrkeen wrote:
| What kind of user-space programs would you run on this OS?
| WillAdams wrote:
| I too miss Display PostScript.
| Veserv wrote:
| Those tools exist. Time travel debugging has existed in
| product-ready forms since the early 2000s let alone the
| advancements since then.
|
| The problem is that game development companies are willing to
| invest money in buying quality tools to make their developers
| productive, where as traditional trillion dollar software
| companies prefer to let their developers wallow in filth.
|
| Getting a company to invest 5,000$/yr into making their
| breathing revenue machines that cost 200,000$/yr and produce
| 1,000,000$/yr in revenue is like pulling teeth in this
| industry. Companies with breathing electrical engineer revenue
| machines do not bat an eye at 50,000$/yr in making them
| productive. Think about how much cool and effective tooling you
| could get with that kind of budget. But if you are not willing
| to spend even one coffee worth on your tooling, then one coffee
| of productivity is all you get to have.
| agumonkey wrote:
| It's still strange to see this contrast between game dev
| doing magic for small salaries versus big corps paying huge
| lumps of money for CRUD++ (sorry for being exaggerating
| here).
|
| It's also cultural.. when everybody in the room thinks a REST
| api is state of the art, you'll have a hard time selling them
| more R&D.
| corysama wrote:
| A game dev I know went to work for Google on Android. What
| he found was a team full of people who had given up on gdb
| back in uni, had worked for Google their entire career,
| printf debugged all day every day, took forever to fix
| anything, and everyone was fine with that because that's
| all they'd ever known.
|
| It was a shock because in gamedev debuggers are a Big Deal.
| The vast majority of AAA gamedev happens in Visual Studio's
| debugger or some alternative that is at least as capable.
| agumonkey wrote:
| Interesting. And scary.. and depressing (about Google).
| Gamedev has always had a special relationship with
| ergonomics (dev ux, dx) I assume (due to the interactive
| nature of their product)... Reminds me of Naughty Dog
| developing a whole lisp DSL to be able to try different
| game designs on the fly on PS1.
|
| That said gdb and similar debuggers are still too limited
| IMO, there's so much we could add on top. Well maybe I'm
| not aware of improved variants.
| Veserv wrote:
| The GDB feature set has been largely unchanged since the
| 80s and even then mostly just parroted the design of
| other CLI debuggers from the 70s. Of course it is
| limited, you are talking about technology that was not
| even cutting edge nearly half a century ago.
|
| To be fair, the core components of a low level debug
| agent are still largely the same, so it is not like the
| technology is bad per se. It is just that it only
| constitutes table stakes, a bare minimum foundation,
| these days. Even looking at 20 year old technology like
| time travel debugging that allows you to time travel
| execution back and forth gives a far better idea of what
| people are missing by using primitive tools.
| dgb23 wrote:
| The hard part of game development might be more centralized
| around complex, big programs that simulate game logic and
| push tons of complex and mathematically sophisticated data to
| GPU's.
|
| On the contrary the complexity web development, distributed
| systems emerges from many communicating processes, that
| execute in different environments.
|
| A sophisticated debugger might help the former category more
| than the latter. There's no shortage of monitoring products
| that act on the distributed systems level.
| cyberax wrote:
| 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 wrote:
| 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 wrote:
| 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.
| alfiedotwtf wrote:
| 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 wrote:
| Similar post from a few days ago:
|
| "We need visual programming. No, not like that."
| https://news.ycombinator.com/item?id=40937119
| TuringTest wrote:
| 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/LadderOfAbstraction/
| corysama wrote:
| Shoutout to 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 wrote:
| 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 wrote:
| 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
| donadigo wrote:
| 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/ 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.
___________________________________________________________________
(page generated 2024-07-19 23:04 UTC)