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

Where should visual programming go?

tonsky.me

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Where should visual programming go?

#71

Post by lhamil64 »

bccdee wrote: post #31
hinkley wrote: post #3

When this last round of discussion of visual programming happened I had a minor epiphany. For a little background, I’ve maintained that visual programming goes absolutely nowhere until we have visual diffs that work (work as in workflow). I’ve been saying that since before the UML Trough of Disillusionment kicked into high gear. Without diffs, without analysis, we are going nowhere fast. Almost every other link of th…

> Without diffs, without analysis, we are going nowhere fast. The victory of plaintext coding over visual programming is another example of worse is better. Semantic, language-aware diffs exist, but I see them much less frequently than dumb plaintext diffs. Intelligent code search exists, but in many cases grep is just as good. IDEs come with very advanced refactoring tools, but I still prefer to refactor using vim m…

I work with a few proprietary languages and many tools don't have semantic information but it's still tolerable as plain text. I suspect I'd be stuck using awful tools if these were visual languages.

Re: Where should visual programming go?

#73

Post by turtles3 »

TYPE_FASTER wrote: post #8
hinkley wrote: post #3

When this last round of discussion of visual programming happened I had a minor epiphany. For a little background, I’ve maintained that visual programming goes absolutely nowhere until we have visual diffs that work (work as in workflow). I’ve been saying that since before the UML Trough of Disillusionment kicked into high gear. Without diffs, without analysis, we are going nowhere fast. Almost every other link of th…

The challenge with visual programming from my perspective is how to get the abstraction level just right. It's like Terraform/HCL modules: too granular, you wind up passing in a billion parameters, and the module adds little value. Too high-level, too many assumptions, also adds little value. I have an idea that I think would be suitable for visual programming. Every time I think about it, I come to the conclusion th…

Having spent an unhealthy amount of time thinking about this, I think it's even worse than an abstraction _level_.

I suspect that the fundamental problem with visual languages is that you have to reify _something_ as the objects/symbols of the language. The most widely used text languages tend to be multi-paradigm languages which have significant flexibility in developing and integrating new abstractions over the lifetime of projects and library ecosystems.

It's not clear to me how this can be overcome in visual languages without losing the advantages, and instead ending up with a text language that is just more spread out.

Re: Where should visual programming go?

#74

Post by eternityforest »

hinkley wrote: post #3

When this last round of discussion of visual programming happened I had a minor epiphany. For a little background, I’ve maintained that visual programming goes absolutely nowhere until we have visual diffs that work (work as in workflow). I’ve been saying that since before the UML Trough of Disillusionment kicked into high gear. Without diffs, without analysis, we are going nowhere fast. Almost every other link of th…

We already have a good way to do visual diffs: Just store the visual code as text and use Git.

Anything else breaks the ability to use Git, or requires adding plugins which you might have to compile yourself or something, and I'm a big fan of just using Git and having VCS be a solved problem.

If this then that rules map nicely to LISP-like expressions in JSON or YAML.

Freely positionable elements are a pretty bad idea for a lot of things. They make extra noise in the diffs and can't be automatically formatted in a fully satisfying way, short of making an AI for it, plus they can't be edited easily on a mobile device, and they can easily become a literal picture of some spaghetti.

Re: Where should visual programming go?

#75

Post by eternityforest »

turtles3 wrote: post #73
TYPE_FASTER wrote: post #8

Earlier quoted context omitted.

The challenge with visual programming from my perspective is how to get the abstraction level just right. It's like Terraform/HCL modules: too granular, you wind up passing in a billion parameters, and the module adds little value. Too high-level, too many assumptions, also adds little value. I have an idea that I think would be suitable for visual programming. Every time I think about it, I come to the conclusion th…

Having spent an unhealthy amount of time thinking about this, I think it's even worse than an abstraction _level_. I suspect that the fundamental problem with visual languages is that you have to reify _something_ as the objects/symbols of the language. The most widely used text languages tend to be multi-paradigm languages which have significant flexibility in developing and integrating new abstractions over the lif…

I think the solution is just to stop trying to allow Real Programming in visual languages.

Make the abstractions purely high level, and let people write Python plugins for new blocks with an app store to share them.

Visual can easily provide enough flexibility for gluing blocks together.

IFTT, Excel, and lots of others do it perfectly well.

The issue is programmers like to program. Mostly they like "programming in circles", making little apps to help make more other little apps to explore ideas.

They see it mathematically, as a human centered activity all about understanding, while users see machines as a box you put stuff in to make it not your problem anymore.

They're always talking about empowering users to create their own fully custom ways of using computers... But.... I like apps that have a canned, consistent workflow that I don't have to fuss with or maintain or reinstall.

Software like Excel has the appropriate amount of power for working on a project that uses computers but isn't really related to programming or done by developers.

Re: Where should visual programming go?

#76

Post by kazinator »

behnamoh wrote: post #27

It's interesting to see how different programming languages approach building software. Languages like Lisp are all about planning out the whole program structure (the "Abstract Syntax Tree") upfront, kind of like a blueprint. But modern tools and visual programming often take a more piece-by-piece approach. You build smaller parts first and then connect them together, gradually building up the whole thing. This bott…

> Languages like Lisp are all about planning out the whole program structure (the "Abstract Syntax Tree") upfront

Languages in the Lisp family are good for prototyping and exploratory, interactive programming in situations when you don't know the solution upfront.

Bottom up from small pieces is ancient; it is not a modern technique.

Re: Where should visual programming go?

#77

Post by kazinator »

behnamoh wrote: post #42
davexunit wrote: post #35

Earlier quoted context omitted.

> Languages like Lisp are all about planning out the whole program structure (the "Abstract Syntax Tree") upfront, kind of like a blueprint. Lisp seems like a poor example because the emphasis there is building incrementally in an interactive REPL session. I think this style of programming would be very amenable to visual programming.

I was referring to the fact that in Lisp everything is an expression, so technically Lisp doesn't stop you from writing something like this, whereas in Python you'd have to define distinct variables and nest them afterwards: ((if ( Now imagine if this were a bunch of deeply nested expressions...

You seem to be supporting your original comment about Lisp code requiring a lot of upfront planning by arguing that it is Python that requires more planning.
Post reply on HN