Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We need visual programming. No, not like that

blog.sbensu.com

Post reply on HN
Print view View original

371–380 of 505 posts

Re: We need visual programming. No, not like that

#371

Post by seafisher »

This article really hits home for me. I've been working on a tool called Code Charter, which aims to do exactly what you're advocating for: provide visual representations of code that make it easier to understand.

I'm taking a slightly different approach than some of the tools mentioned here. Code Charter uses successive LLM calls to distill the key patterns (i.e. business logic) in code, creating a semantic map for call graphs in a codebase. This is useful for understanding the architecture of a project and, during development, for moving between the high level and the implementation code.

It is still in development and will be released soon as an extension for VSCode.

Check it out if you're interested: https://github.com/CRJFisher/code-charter

Re: We need visual programming. No, not like that

#372

Post by jayd16 »

amonith wrote: post #184
jayd16 wrote: post #90

Earlier quoted context omitted.

Some are bad but Blueprints is great. Main issue is they don't always play nice with text based coding tools.

And AI - which kind of changed the game in the recent years. A "blueprints copilot" akin to Github Copilot will be very difficult to create because there's no "blueprints text" to train an AI on. Nowadays in my hobby pet projects I find it easier to write C++ with copilot than Blueprints.

There's a JSON format of the blueprints that you can see when you copy/paste. Its just a bit ambiguous than the usual binary format. Its not an impossible problem at all.

Re: We need visual programming. No, not like that

#374

Post by lioeters »

edflsafoiewq wrote: post #30
mapcars wrote: post #8

Earlier quoted context omitted.

That is not a problem, and for sure not a fundamental one. The textual representation is very limited, it's actually 1D with a line breaks helping us read it. 2D gives a lot more possibilities of organising code similar to how we draw diagrams on a whiteboard.

The problem with visual programming is it abandons the fundamental principle of language, whereby to connect two objects it is necessary only to speak their names, in favor of the principle of physicality, whereby to connect two objects it is necessary that they be in physical contact, ie. to be joined by a wire.

> to connect two objects it is necessary that they be in physical contact

I can imagine a way to connect an object to another by selecting the latter's name from a drop-down menu of defined objects. A visual equivalent of a function call.

Re: We need visual programming. No, not like that

#375

Post by jayd16 »

raincole wrote: post #112
jayd16 wrote: post #68

Anyone who mentions visual scripting without mentioning the game industry just hasn't done enough research at all. Its actually a really elegant way to handle transforming data. Look up Unreal blueprints, shader graphs, procedural model generation in blender or Houdini. Visual programming is already here and quite popular.

As someone who works for games, I think the biggest problem of node-based systems is... they're all different (in terms of UI/UX). Unreal blueprints, Substance Designer, Houdini, Blender's geometry node, Unity shader nodes... they all look different and act differently. Different shortcuts and gestures. Different window/panel management. Different programming languages have different syntax rules and libraries, of co…

You know, this is actually really insightful. A standard graph format that all these tools could import/export to could lead to a lot more reusable tooling.

The incentives aren't quite there at the moment but maybe someone like Microsoft or Jetbrains takes a stab at it.

Re: We need visual programming. No, not like that

#376

Post by marcelr »

I have another take on visual programming

We need programming environments that can understand both textual & visual code.

We need a new primitive which I call the visual-ast

encode the AST in html via data attributes, and have a system to ignore irrelevant html nodes, giving space for rich UIs to be developed in place of typical AST nodes.

eg.

  // textual
  1 + 2
  
  // ast
  {
    kind: "plus",
    lhs: { kind: "int", value: 1 },
    rhs: { kind: "int", value: 2 }
  }
  
  // visual-ast
  
  
    
      
        
        2
What you can do this with this AST is create rich UIs which contain the appropriate `data-attr`s, (ignoring the other elements), and now you have a generic system for interweaving textual & visual code.

Re: We need visual programming. No, not like that

#377

Post by jayd16 »

doctorpangloss wrote: post #361
markus_zhang wrote: post #338

Earlier quoted context omitted.

TBH I think Blueprints gets used because it is forced upon the UE developers.

Blueprints gets used because the only alternative in UE, writing decade-old paradigm C++ code with 2 decades old macro DSL on top of it, is a lot worse. Unity has had multiple visual programming packages and people don't really care. Writing 2017 era C# paradigm code with an API resembling 2004 Macromedia Flash is not nearly as bad.

> Unity has had multiple visual programming packages and people don't really care.

People cared enough for Unity to buy one and make it official but Unity doesn't care so it mostly just rots.

Re: We need visual programming. No, not like that

#378

Post by lioeters »

A unique project I saw recently, that is developing a kind of visual programming environment with the goal of unifying design and code.

https://www.pax.dev/

> Pax: Build UIs visually in Rust

> A library for building web & native applications alongside visual creative tools

Meet Pax: https://www.youtube.com/watch?v=crI_raloHgo

Re: We need visual programming. No, not like that

#379

Post by jihiggins »

ejiblabahaba wrote: post #124

As someone with a hardware background, I'll throw in my $0.02. The schematic capture elements to connect up large blocks of HDL with a ton of I/O going everywhere are one of the few applications of visual programming that I like. Once you get past defining the block behaviors in HDL, instantiation can become tedious and error-prone in text, since the tools all kinda suck with very little hinting or argument checking,…

i remember using the falstad sim constantly at university a decade ago. super helpful and so much more intuitive than any spice thing. cool to see that it's still around and used

Re: We need visual programming. No, not like that

#380

Post by outworlder »

marcelr wrote: post #376

I have another take on visual programming We need programming environments that can understand both textual & visual code. We need a new primitive which I call the visual-ast encode the AST in html via data attributes, and have a system to ignore irrelevant html nodes, giving space for rich UIs to be developed in place of typical AST nodes. eg. // textual 1 + 2 // ast { kind: "plus", lhs: { kind: "int", value: 1 }, r…

If we are going that route, why not go with a lisp-like language?
Post reply on HN