Live data from Hacker News

Ask HN: Why does visual programming suck?

news.ycombinator.com

161–170 of 325 posts

Re: Ask HN: Why does visual programming suck?

#161

One size does not fit all. UI creation is best handled by a WYSIWYG editor, animations are nice to visualize on a timeline, and math formulas are clearest when written as is. Picking the wrong model creates a mess. Try to express a sorting algorithm as a flowchart. It would be too difficult to follow. Yet a business process is great to model as a flowchart. A picture is only sometimes worth a thousand words. Take a l…

> UI creation best handled by a WYSIWYG editor, a business process is best modeled as a flowchart

I disagree with those two. UI creation has generally evolved away from WYSIWYG, composing a UI with code is a much better approach and is now nearly the universal way of doing it. For the business process, the flow chart only works as an extremely high level overview, the implementation is always done in something like code.

Re: Ask HN: Why does visual programming suck?

#162
post #145

Earlier quoted context omitted.

I agree with what you're saying, except the last part. Using ASTs as the source of truth (embedded in a source control forest) has benefits that are worth the difficulty.

What's the benefit? If your tooling already requires lossless round-trips to and from text, why invent a funky storage format that doesn't interoperate and can't be fixed with a text editor when it all blows up? You already have a perfect serialisation of the AST, in a format every other tool understands - that is, source code. (And heaven forbid you should want to make a checkpoint commit that doesn't parse...)

Some potential use cases:

- Using Merkle trees, we can assign every node a hash-based ID. So now we can refer to other nodes by ID. This lets us store a graph whose vertices are all the tree nodes.

- With the graph, we can now reference bindings not by string literal, but by ID. This eliminates shadowing problems and missing imports.

- There is now one source of truth for the names of variables and functions. As a result, in source control, a commit that renames something is a one-line change.

Re: Ask HN: Why does visual programming suck?

#163
post #52

I think the reason is that text is already a highly optimized visual way to represent information. It started with cave paintings and evolved to what it is now. "Please go to the supermarket and get two bottles of beer. If you see Joe, tell him we are having a party in my house at 6 tomorrow." It took me a few seconds to write that. Imagine I had to paint it.

I think this is exactly right, but I would add that when we start using computers to analyze and help write programs, faster, more intuitive ways of programming will emerge.

Re: Ask HN: Why does visual programming suck?

#164
My pet theory: Code is N-dimensional - every set of braces, every nested function call, increases the execution by a dimension and humans are really only good at visualizing in 2 or 3 dimensions. Specific domains that are constrained to 2-3 dimensions are suitable for visual programming, but it's hard to generalize.

Re: Ask HN: Why does visual programming suck?

#165
post #161

One size does not fit all. UI creation is best handled by a WYSIWYG editor, animations are nice to visualize on a timeline, and math formulas are clearest when written as is. Picking the wrong model creates a mess. Try to express a sorting algorithm as a flowchart. It would be too difficult to follow. Yet a business process is great to model as a flowchart. A picture is only sometimes worth a thousand words. Take a l…

> UI creation best handled by a WYSIWYG editor, a business process is best modeled as a flowchart I disagree with those two. UI creation has generally evolved away from WYSIWYG, composing a UI with code is a much better approach and is now nearly the universal way of doing it. For the business process, the flow chart only works as an extremely high level overview, the implementation is always done in something like c…

> composing a UI with code is a much better approach and is now nearly the universal way of doing it

Why is it a better approach? Universal does not always mean better. Javascript was built in 10 days and it's now universal.

> the flow chart only works as an extremely high level overview, the implementation is always done in something like code

I agree here. The core point I am trying to make is that one size doesn't fit all and we have to mix and match approaches based on the problem.

Re: Ask HN: Why does visual programming suck?

#166

Earlier quoted context omitted.

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 d…

> 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 e…

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.

Re: Ask HN: Why does visual programming suck?

#167

Earlier quoted context omitted.

So do you use text files for storage or a database? Is your company's accounting system in Word or Oracle? Are programs text, like a novel, or is it data? And to find out, would you query Moby Dick? Not really -- at least that's not how it's meant to be consumed. You read it from beginning to end. Would you read your program from beginning to end or would you query it? You query it, exclusively. I submit that program…

> Is your company's accounting system in Word or Oracle? Accounting uses numbers, which in this context is text. If you replace a spreadsheet with a graph, your accountants will murder you.

So, to be clear, you're saying a spreadsheet is the same thing as Word or vim?

Re: Ask HN: Why does visual programming suck?

#168
post #97

Earlier quoted context omitted.

> then why does everyone sketch a picture when trying to convey an idea? Does everyone do that? I think I very rarely do. When I need to convey an idea on a whiteboard, it's still almost completely text, with a few extra symbols like directional arrows that I think are still effectively just symbolic written language. Literally the only time I can remember sketching a picture to convey an idea is while playing Pictio…

Sometimes they do. In my view the most prominent example is documentation for installing computer hardware and software on Windows computers. The instructions will be a series of pictures, with circles and arrows, and a paragraph on the back of each one (sic). This goes on for page after page. And when the OS is updated and the dialogs all change a bit, the documentation becomes confusing or even obsolete. In contras…

[deleted]

Re: Ask HN: Why does visual programming suck?

#169
What really annoys me in text programming is that I have to write constructs again and again, referring to manual for method names constantly. Completions may be smart typewise, but IDEs never assume what I am writing. Let's take a function:

  static string defaultFamily = "Sans";

  bool
  foo(string s, Alignment a, int height)
  {
    Par_
Okay, it began. What can be done with all the available values? Seems that I'm going to create a paragraph and fill it with some arguments. One of autocompletion suggestions:

  bool
  foo(string s, Alignment a, int height)
  {
    Font f(defaultFamily, height);
    if (!f.isValid()) return false;

    Paragraph p;

    p.setAlignment(a);
    p.setText(s);
    p.setFont(f);

    _

    return true;
  }
How is it obvious? Because Paragraph told the completion system that it needs at least font and text values set. Height goes to font, other arguments go to paragraph. Names are selected from the style around. Since we return a boolean and few objects can be invalid after initialization, it assumes that it is a status. p is local, so there is something to be done with it, and another block is created.

Even better, you could just throw items together and get the result:

  // this->points is double[20];

  {
    frame inset 0.5 red stroke;
    add points black stroke;
  ---
  {
    Rect r = this.frame();
    r.inset(0.5, 0.5);

    Painter p;
    p.setColor(Color::red());
    p.addPath(rect);
    p.stroke();

    p.clearPath();
    for (point in points) {
      p.addPoint(point);
    }
    p.setColor(Color::black());
    p.stroke();
But the completion style that we have everywhere just sucks:

  int
  foo(string s, Alignment a, int height)
  {
    ParadoxDatabaseProvider_
    ParadoxDatabase...
    ...
    Paragraph
    ParamsManager
I can't point to good visual programming tool, but our "powerful" text IDEs are simply prehistorik typewriters.

Re: Ask HN: Why does visual programming suck?

#170
One thing that nobody seems to notice is that big thing in front of you with the tons of buttons: the keyboard. The main input device we use to enter stuff in our computers are based on typewriters, so everything more advanced than clicking widgets with the mouse revolves around typing stuff. Most visual languages feel like you are fighting with their code editors because the editors are not following the typewriter model that the main input device of our computers use.

Perhaps this will change in the future with other input devices, touch devices like tables could provide for a different environment - currently programming with a tablet feels slugggish but this is because everything about programming revolves around typing. Touch is different. But it needs to be designed from the ground up for the interface you work with.

Whatever that is, i don't think text is the only way to go. I believe our keyboards have shaped the way we think about programming - and interacting with computers in general - and if we are to explore other ways to program, we need to also explore other ways to communicate with the computer.

Post reply on HN