Hacker News Reader

Comment by david927 | Hacker News Reader

Your example is strange. Changing the text and changing the data would require the same amount of time. And a graph would, in fact, instantly put that change into context.

Right, code is data.

Not now, though. Currently, code is text -- it's not data. That's the problem. And, yes, currently, drawing it instead of typing out the text is a horrible idea. We agree.

But remember, currently, we're failing. Software is a disgrace of an industry, in all honestly. It's mired in undue complexity. It's a Rube Goldberg contraption that we all, somehow, take seriously.

Imagine a better future. Imagine visualizing a complex set of rules and seeing all the places where a change would cause knock-on effects. Imagine being able to manage your code base in a way that doesn't require you to download it all into your head. Hell, imagine a decent IDE. The first step for all of that is to move it from text to data.

View on HN

I think you are chasing something that does not exist.

While i submit to the idea that programs are "data", and could be represented not just like text, the expressiveness when using a visual representation is small, but the exactness is as high as normal languages.

I've seen large visual-programming programs, and they explode into complexity, and I think there is a reason for that, the expressiveness of a symbolic language using text is so much higher.

Could we increase the expressiveness even further? English have high expressiveness but is inexact.

I don't think it's possible to increase the expressiveness and keep the precision - at least without some sort of intelligent agent that can reject interpretations that makes no sense.

So - when general AI is invented, we can probably soon write programs that are very inexact, highly expressive, but still work.

Until then, we will have to continue wrestle down the computer to obey our if-statements, one by one.

Visual programming does not have to mean 100% not text.

https://joshondesign.com/2014/08/22/typopl

Yes, there are probably lots of useful interaction methods to be found in between text files and the "boxes and arrows" visual programming (circuit design) model.

You talk about the compiler having to be sufficiently smart, but I think you actually just need good IDE support, then you can store the code as text but display a nicer rendering.

E.g. the image literal could actually be Image.loadFromPath("../.../image.png"), but you don't see the code unless you want to; and if you drag and drop a file into your program, the IDE automatically inserts the corresponding code.

> Changing the text and changing the data would require the same amount of time.

Really? really?

Open up powerpoint, openoffice, or whatever you use to make infographics. Also open up vim, atom, or whatever you use to edit text.

Time yourself clicking and dragging to make a graph in one and then typing to write a number in the other.

> Imagine a decent IDE

I'm imagining something where you are able to select visual elements without either clicking and dragging or doing an O(n) walk by hitting alt-tab. But I can't imagine how you acheive that, much less efficiently specify how you connect things up and how you write automated tests.

Some of this is my failure of imagination, but its still on you to provide the sketch of a proposal if you want to convince.

How do you navigate code now? Do you walk through code line by line or do you search or use some kind of navigation that relies on the structure of code?

I agree that a concrete product is probably going to be required to convince people who aren't good at thinking outside of what already exists, but these kinds of comparisons just feel absurd. Maybe a better way to think about this sort of thing is "how can the structure of code be used to simplify and improve working with it"; the term visual programming is just too loaded in negative ways.

Edit: I don't mean to sound insulting when I talk about thinking outside of what exists. It's not always an easy thing to do. But it becomes an issue when you it causes you to let previous attempts narrow your views on what something is.

Visual programming doesn't have to be, say, exactly what's scratch is today. It doesn't even have to be close. The two keys IMO are utilizing the structure of code as well as the inherent visual processing power humans have.

This doesn't mean no text, it means expanding how we think about operating on and viewing code in a way that makes it easier (and thus more productive) to do.

Okay. I'm on board with you there. I suspect that SQL or data-model rendering would be the easiest place to start there--allowing you to auto-generate a visualisation from SQL. If that got widespread enough, then it would become a standard way of representing the data that is currently represented by text. That means you can build interactions on top of that understanding.

Reply on news.ycombinator.com