Live data from Hacker News

Ask HN: Why does visual programming suck?

news.ycombinator.com

281–290 of 325 posts

Re: Ask HN: Why does visual programming suck?

#281

This was an active area of study in the 80s, with many journal publications. The goal was to make programming intuitive. Then one day someone published an article explaining that we need words to represent variables, doing it visually runs out of abstractions too quickly to do anything useful. There were no journal publications after. It's been about 14 years since I last looked at these publications and my memory is…

In dataflow programming, and some variations of functional programming, variables are pretty rare.

But I'd be interested in reading the study you refer, do you know how to find it?

Re: Ask HN: Why does visual programming suck?

#282
post #166

Earlier quoted context omitted.

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

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.

Re: Ask HN: Why does visual programming suck?

#283

Earlier quoted context omitted.

My dream is the opposite. Constrain programmers to hardware that's 2 generations old. That will force us to make our programs run fast in this environment which is much closer to what actual users will use to running it. I do understand the implication that lowering the need for always faster hardware for end users will slow down the pace of development of new hardware. But with the end of Moore's law upon us, that's…

After being stuck with a really, really bad laptop for the past 4 years, I can't disagree more whole-heartedly. I wouldn't wish that experience on my worst enemy, heh. Though I wish more time was spent on some tools to make them more memory efficient(I'm looking at you, scala and friends), that's just not how it is today. I just bought a new laptop with 32 gigs of ram, and hopefully that is future-proof for the next…

What was the laptop? And what were the 3 things that you found most annoying?

Re: Ask HN: Why does visual programming suck?

#284
But, isn't text just abstract signs and symbols? Why can't we, programmers, make new or better symbols? Why can't the language be augmented to incorporate concepts of computing?

I never desired visual programming until recently. I never had the need for it. Plus, I always found the existing visual languages and tools to be clunky.

But, lately, I often find myself with just my tablet and stylist. And, during these times, I want to 'sketch' out programs. I have some ideas on how this would work in practice. There would have to be detection of gestures, and instant feedback that provides visualization of the changes.

Re: Ask HN: Why does visual programming suck?

#285
post #221
post #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 c…

> Because Paragraph told the completion system that it needs at least font and text values set. If the class needs at least all those arguments it shouldn't have an empty constructor. It should have those as arguments to the constructor and then most good ide today would be able to help you at least a bit better. Have you tried intellij? Boolean return values without context is also an antipattern, how am I supposed…

Okay, "paragraph told that non-default font is often used and empty text is not very useful". These are just examples, I'm not pretending this to be final form. How about non-construction?

  foo(string s, string p)
  {
    fin
  ---
    int i = s.find(p);
    if (i ;
    _
Also, if it appended { on if-line when I press Tab, that would be great.

>There is no way

Really? I clearly see how to do this without any sort of AI. That's graph path weighting problem based on key words. If it gives you a false positive, just add words (or put more useful hints and >>use case snippetsBut I got your point, let's walk on the same rakes for life. There was a time when I was amazed by programming, now after two decades I'm tired of it to death (and yes, it seems that I'm "10x" from the feedback around). Programmers create and solve problems that mere mortal cannot even understand and this cool process is far from "cheap". Everyone talks about no-brain easy programming, but no real steps are done in this way. You know, when you're doing something often and for years, you just get used to it, know it all, and see no need for a change, forgetting the learning curve. You can write all of above snippets with closed eyes. The same happens to the entire profession -- you are professional and that's your value. We doomed to raise professionals again and again. In what areas? C++, SQL, etc... But wait, these are no areas! Areas are: medicine, building, etc. I don't want "cee pulse" programmer, I want a guy who understands my area.

I'm attributing these "no need for this" attitudes to the simple fact that such a system would be first step to programming without paying a programmer who solves non-existing problems. You simply put words and the system analyzes best practices and use cases from selected github projects or templates to produce a result, and you only need 0.1 of your development forces. Professional experience is bound to a programmer, but this thing would allow to change that. The same friction we seen when computers appeared. People hated them simply because their professions ceased to exist.

Lyrics off, software libraries are graphs. And graph is a thing that can be processed, if not in generic, then in specific way. There is algorithm that produces the most wanted result for known specific case.

Re: Ask HN: Why does visual programming suck?

#287
post #283

Earlier quoted context omitted.

After being stuck with a really, really bad laptop for the past 4 years, I can't disagree more whole-heartedly. I wouldn't wish that experience on my worst enemy, heh. Though I wish more time was spent on some tools to make them more memory efficient(I'm looking at you, scala and friends), that's just not how it is today. I just bought a new laptop with 32 gigs of ram, and hopefully that is future-proof for the next…

What was the laptop? And what were the 3 things that you found most annoying?

Not OP, but I had a similar experience. Low end development machines suck because they put the developer in a worse position than the end-user, not an equal one. Modern dev tools, plus common side-utilities like slack/spotify/skype, and accessories like Insomnia, tend to use a lot of memory and cpu. It makes the development experience terrible, and that affects your output. Developing and designing is going to be ~90% of your time spent on a dev box, actually running the dang thing won't take long at all.

A better solution would be for testing, particularly UAT, to be done inside resource-constrained VM's, instead.

Re: Ask HN: Why does visual programming suck?

#288

Earlier quoted context omitted.

you win the prize for asking the right question. the answers are like with AI, where once it's done in a certain domain, then that's not AI anymore. that is, with visual programming, once it's done in a particular domain, people don't think it's programming anymore. the big examples i have in mind are: * spreadsheets -- very visual, everything's in a grid. the relationships are spatial. * electronic music -- people l…

Sooo... Minecraft is a visual programming tool, then?

Well, in light of the fact that someone built an emulator of the 6502 processor in Minecraft [0], it would be difficult to argue that it's a not visual programming tool! (of some kind at least ;)

[0] https://www.theverge.com/2012/5/21/3032765/minecraft-emulate...

Re: Ask HN: Why does visual programming suck?

#289
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.

then why does everyone sketch a picture when trying to convey an idea? text is obviously useful but so is visual information. the complete dismissal of visual programming by text-based programmers is often infuriating. visual programming can provide an immediate indication of structure and dataflow, something that text-based languages struggle with. in my mind, the best case scenario is some sort of hybrid, where vis…

A picture is better than 1000 words. But, which words? or for programming, which code?

Most visual programming efforts focus on representing algorithm logic with diagrams. But I think the difficulty to understand most complex programs (from my own experience) lies in the complexity of data structures, not the code logic. Reasoning about the algorithm is like reading a story, it is kinda intuitive; but for a large data structure (say a big struct with more than 20 fields), it's very hard to keep all those in your memory, you always have to go to its definition to refresh your memory, very frustrating. One of my tricks for reading a large open source project is to first find all the key data structures, draw them and the relationships on paper, then reading the code becomes easier and more pleasant. So maybe if a visual programming UI displays data structures with a visual format always on screen, it can help boost coding productivity.

Re: Ask HN: Why does visual programming suck?

#290

Earlier quoted context omitted.

I quite often use UI mockups to show an example of the end result (or ask others to do the same). It doesn't even matter if it's correct, but it's a useful way to start a discussion. I've tried to do this in words but often different people have different interpretations and it simply doesn't work without a picture. I've also found it very useful when people are asking for things that don't entirely make sense, such…

I consider UI mockups the perfect usage for visual programming environments. Obviously a visual product compliments a visual development interface. However, it's a very narrow realm compared to the rest of the programming universe. It's the same as saying that drawing a picture is easier for most people than programming a picture, and it doesn't really have to do with the topic of visual programming, but rather visua…

> I consider UI mockups the perfect usage for visual programming environments.

It can be, though the type of mockup I find more useful for discussion is much lower fidelity than that.

The feedback and discussion around a mockup is related to the fidelity.

Low fidelity, such as whiteboard or large sharpie drawings, will garner feedback that discusses whether this UI even makes sense at all, if there's a different approach, or how feasible it is to present everything this way.

Mid-fidelity, such as digital mockups, will often focus more on the actual layout, text labels and contents.

High-fidelity, such as a working prototype or something done in the actual environment (visual programming environment, or even as working HTML+Javascript+CSS), will often get into a discussion about font sizes and icon choice.

If you build a high-fidelity mockup when you really want to have the low-fidelity discussion you're doing everyone a disservice. Even if your team can see past it and still has the appropriate discussion, it's a waste of time.

For that reason, even when my mockup is basically a small modification to something that exists already, I'll often screenshot it, and then freehand draw (MS Paint style) overtop of it with my modifications, using ugly 2-4px wide lines. I've tried both, but consistently found the feedback is better that way -- even when the target audience is a bunch of developers that should be able to see past it.

Post reply on HN