Live data from Hacker News

Ask HN: Why does visual programming suck?

news.ycombinator.com

261–270 of 325 posts

Re: Ask HN: Why does visual programming suck?

#261
post #45

The way people have implemented visual programming has turned out to be a bit of an oxymoron. Visual and symbolic are entirely different channels of representation & understanding (for the most part). Representing a program using lines of code and throwing some "visual magic" to spread out lines of code across a screen doesn't take advantage of what EITHER visual or symbolic manipulation has to offer. Visual programm…

I have been working on xol, a graphic based programming language. xoL is a graphic based programming language. It represents programming concepts with graphics instead of text. It is product of a long, painstaking design effort, to get an optimal graphical presentation of programs. A good description of it is available in this blog post: http://lignixz.github.io/blog/posts/17/xoL_graphics_based_pr... A partially work…

I'll take a look, but if I never get back to you I would like to share with you this one important concept that has caused most efforts to fail.

Let me start with a quote from Brian Kernighan "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

When you make a graphic based programming language the debugging better be twice as good as the programming and this includes when things get really difficult with lots of threads, or when the over arching abstraction breaks at some low level and you are exposed to the underbelly of the CPU. At least C++ lets you gracefully traverse from the very high to the very low which is why it is favored in the end, you are never stuck you can always go lower.

Re: Ask HN: Why does visual programming suck?

#262
Visual languages never found a good solution to most of software development tasks.

For example:

1) How do I view diff between old and new version?

2) How do I search for an element in my visual code?

3) How do I email example of visual code to my colleague?

4) How do I message an example of visual code?

5) How do I blog about visual code?

Re: Ask HN: Why does visual programming suck?

#263

Earlier quoted context omitted.

This is, I think, the idea behind IDEs

Yeah. I feel like the depth of OP's writeup blurs the lines between working with an application framework, API, and IDEs. I was under the impression that visual programming is different from IDEs or frameworks...

If you ever want to horrify yourself, google LabView, a truly horrible piece of software.

Re: Ask HN: Why does visual programming suck?

#264
Funny enough, all examples of successful visual tools in this conversation are domain specific (yes, even UI builders are domain specific). The ones mentioned in the 'it's unusable' category are the ones trying to do everything.

That should answer the OPs question better than any specific answer...

Re: Ask HN: Why does visual programming suck?

#265
Programming through typing text has already become 'visual programming', just from an unexpected direction: syntax highlighting, compile error checking while you type, code completion, fuzzy searching, argument type popups and so on. The only thing that's missing is better debugging integration (essentially show how the program state changes while you type).

Re: Ask HN: Why does visual programming suck?

#266
post #217

Earlier quoted context omitted.

I have a dream that one day we'll collectively realize that "buying programmers the best tools" means the most powerful, and not the shiniest. Then we'll all be running ultra-wide monitors with room for many different visual aides on the one screen, backed by the CPU horsepower (overclocked and liquid cooled, if necessary) to make it all fast. And, hopefully, we'll see what an IDE can really be.

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…

I wrote some of my fastest code on a netbook. It's also the gnarliest code I ever wrote and I do not wish to touch it again.

Re: Ask HN: Why does visual programming suck?

#267

Programming through typing text has already become 'visual programming', just from an unexpected direction: syntax highlighting, compile error checking while you type, code completion, fuzzy searching, argument type popups and so on. The only thing that's missing is better debugging integration (essentially show how the program state changes while you type).

Your comment is definitely an interesting take on the question. I would argue, however, that integrated debugging in the way you describe (along with the various programming text editor features) is what constitutes a live programming environment.

Re: Ask HN: Why does visual programming suck?

#268
post #217

Earlier quoted context omitted.

I have a dream that one day we'll collectively realize that "buying programmers the best tools" means the most powerful, and not the shiniest. Then we'll all be running ultra-wide monitors with room for many different visual aides on the one screen, backed by the CPU horsepower (overclocked and liquid cooled, if necessary) to make it all fast. And, hopefully, we'll see what an IDE can really be.

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…

You can have it both ways: power the IDE with a futuristic power hungry beefy machine, and run the programs it produces on a throttled sandbox that match the slower target machines.

I fear cheating would be too easy, though —just lift the restrictions.

Re: Ask HN: Why does visual programming suck?

#269
post #129

I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Managers also tend to like the concept as it would allow them to bypass the pesky code monkeys and just feed their drawings to the computer. For my master's thesis, some 15 years ago, I programmed a syst…

Some good points. But I think your view has become too negative, perhaps due to your experiences. Or at least I see more hope for visual programming. :) > I think visual programming is one of those ideas that intuitively seems like a good idea but never is. Thus, it never really dies, it just gets picked up as a kind of rite-of-passage by new generations of developers. Perhaps the intutition is right, but the problem…

As a believer myself, I think the problem is that visual programming suffers the same problem known as the curse of Artificial Intelligence:

"As soon as a problem in AI is solved, it is no longer considered AI because we know how it works." [1]

Similarly, as soon as a successful visual interactive feature (be it syntax highlighting, trace inspectors for step-by-step debugging, "intellisense" code completion...) gets adopted by IDEs and become mainstream, it is no longer considered "visual" but an integral and inevitable part of classic "textual programming".

[1] http://www.artificial-intelligence.com/comic/7

Re: Ask HN: Why does visual programming suck?

#270
post #187

Earlier quoted context omitted.

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…

The problem with having 2 representations of the same piece of information is maintaining them in sync. If we use text for specific and visual for abstraction, we still need to maintain both and there are no effective tools to do that without creating additional work.

There are solutions to this. A) Let one representation be derived from the other. Easiest by making the derived representation read/view-only. B) Encapsulate the specific/low-level details into a generic black-box, which can then be composed.
Post reply on HN