|
|
|
|
|
|
by afarrell
3308 days ago
|
|
|
> 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. |
|
|
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.