Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Folk wisdom on visual programming

drossbucket.com

Post reply on HN
Print view View original

61–70 of 168 posts

Re: Folk wisdom on visual programming

#61

Post by SAI_Peregrinus »

lliamander wrote: post #23
ping_pong wrote: post #4

I worked on a visual programming tool from the late 90s to the early 2000s. The same problems apply then as they do now. There's an unwinnable war between keeping things simple and being complex-enough to do useful things. Visual stuff is great for simple things, but simple things aren't very useful. When you really need to do more complex things, you reach a limit very quickly. It becomes pretty unmaintainable very…

In my experience, there are three things that visual programming tools make difficult: * abstraction * version control * test automation Those are also (in my opinion) the three techniques which separate proper "software engineering" from coding/scripting, which is why visual programming tools are pretty much universally unsuited for complicated projects. The one asterisk I would put on that is tools in which the vis…

The really funny bit is that the classic visual programming tool LabView is designed mostly for test automation. But it ends up practically requiring the creation of unmaintainable spaghetti (this[1] being a classic example) and there's no test automation possible for it. It's a test automation platform so complex it needs (but doesn't have) test automation for its automation of your tests.

[1] https://thedailywtf.com/articles/Labview-Spaghetti

Re: Folk wisdom on visual programming

#62

Post by JPKab »

ping_pong wrote: post #4

I worked on a visual programming tool from the late 90s to the early 2000s. The same problems apply then as they do now. There's an unwinnable war between keeping things simple and being complex-enough to do useful things. Visual stuff is great for simple things, but simple things aren't very useful. When you really need to do more complex things, you reach a limit very quickly. It becomes pretty unmaintainable very…

There is most definitely an unwinnable war between simplicity/ease-of-use and more power/customizability.

That being said, Alteryx is an example of a company that has made a ton of money via a data munging tool that is a visual programming language. The users are fanatical as well.

Re: Folk wisdom on visual programming

#63

Post by gridspy »

Zababa wrote: post #48
Jarwain wrote: post #16

I think what the author did here hits hard on why hacker news is such a great resource. To quote: > Most fields have a problem with ‘ghost knowledge’, hard-won practical understanding that is mostly passed on verbally between practitioners and not written down anywhere public. At least in programming some chunk of it makes it into forum posts. I'd be incredibly interested in seeing a series of posts like this, where…

> What other topics do y'all think HN provides unique insight on? Career managment I think (not sure if it's the good term for it). I see lots of people in their 40's or more that quit some FANG job for another job that earns less but is more aligned with how they want to live their life. I see lots of people advocating to quit jobs as soon as you see red flags. I think both of these are good wisdom. On the other han…

Personally I think programming language is about a compromise between performance and convenience.

For instance, I program in Python if speed is irrelevant. Rust if it is very relevant. C# if I want a large project where performance is somewhat important.

I think there are a wide range of languages for each "category" where I put Python, C# and Rust above, but those 3 are my current favorites.

Certain languages are very well suited to specific tasks. You learn these with experience. Initially I loved python because it was a joy to slice and dice strings in it. I understand that Ruby is popular for the same reason. Closure is great if you want lots of agents processing stuff on a network stack.

If I were you, I'd just focus on making fun projects in your favorite language.

Re: Folk wisdom on visual programming

#64

Post by analog31 »

lliamander wrote: post #23
ping_pong wrote: post #4

I worked on a visual programming tool from the late 90s to the early 2000s. The same problems apply then as they do now. There's an unwinnable war between keeping things simple and being complex-enough to do useful things. Visual stuff is great for simple things, but simple things aren't very useful. When you really need to do more complex things, you reach a limit very quickly. It becomes pretty unmaintainable very…

In my experience, there are three things that visual programming tools make difficult: * abstraction * version control * test automation Those are also (in my opinion) the three techniques which separate proper "software engineering" from coding/scripting, which is why visual programming tools are pretty much universally unsuited for complicated projects. The one asterisk I would put on that is tools in which the vis…

An interesting thing about things like version control and test automation is that they are almost like "meta interpreters" that interpret your code, but do so for purposes other than executing it. Syntax checking and linting come to mind too. Those things are possible, not so much because the program is in text format, but because it's in an open format that anybody can parse.

If a visual programming language stored its programs in a human readable or at least open format, then it would be possible for people to create those tools for it. But then, people would start writing and editing the program directly in its storage format, and it would cease to be visual programming.

Re: Folk wisdom on visual programming

#65

Post by im_down_w_otp »

w_t_payne wrote: post #40
im_down_w_otp wrote: post #20

Earlier quoted context omitted.

I'm curious if you've tried Simulink? Because my experience with visual programming tools maps largely to yours. Especially the RAD tools of the late-90's and early-00's. Eventually you get to a place where the "simple" thing is a dizzying array of radio buttons and check boxes to manage that are all hidden away in their own little silos that you can only get to by drilling down through the visual hierarchy. This bec…

I've used Simulink a lot in the past, and the things that it gives you (as well as it's limitations) are a big driver for my attempts to build tools in this space (I think I'm trying to do a similar thing to you -- causal reasoning using data flow information and other graph-structured engineering data such as requirements traces).

Yeah, that's the first half of our stack. Ultimately it exists in service of the second half of our stack which is for automatically stressing and analyzing system behavior to localize root causes, uncover emergent properties, and auto-optimize system parameters.

On the way toward building everything we needed for the analysis we wanted to do we realized we had a distributed tracing system suitable for continuous system lifecycles & embedded systems (as opposed to transactional lifecycles & IT systems) and a spec/query mechanism over what amounts to a logic model derived from system executions. That sort of thing tends to be valuable to folks who aren't as far along in their development or use case maturity to need bleeding out all the corner cases & "unknown unknowns" from their systems, so we exposed many of our building blocks as features themselves.

Somewhat ironically, given the thread this is all related to, everything we build today is for CLI consumption on Linux and Windows. We will build out a kind of IDE/Workbench UI this year to fulfill some of our vision around the category of CAE tools we're angling toward, and to access additional kinds of customers, but predominantly folks have preferred CLI shaped tooling because it's easier for them to bake our continuous verification & validation capabilities into their existing processes when we don't force them into a siloed GUI.

Re: Folk wisdom on visual programming

#66

Post by Jarwain »

Zababa wrote: post #48
Jarwain wrote: post #16

I think what the author did here hits hard on why hacker news is such a great resource. To quote: > Most fields have a problem with ‘ghost knowledge’, hard-won practical understanding that is mostly passed on verbally between practitioners and not written down anywhere public. At least in programming some chunk of it makes it into forum posts. I'd be incredibly interested in seeing a series of posts like this, where…

> What other topics do y'all think HN provides unique insight on? Career managment I think (not sure if it's the good term for it). I see lots of people in their 40's or more that quit some FANG job for another job that earns less but is more aligned with how they want to live their life. I see lots of people advocating to quit jobs as soon as you see red flags. I think both of these are good wisdom. On the other han…

> I don't know if it's because I'm too young in this field, because I don't understand/missed something, or because there is no big truth to find.

I'm pretty young in the field as well, but my impression so far is that there aren't really any big truths, just a lot of little ones

Re: Folk wisdom on visual programming

#67

Post by Zababa »

gridspy wrote: post #63
Zababa wrote: post #48

Earlier quoted context omitted.

> What other topics do y'all think HN provides unique insight on? Career managment I think (not sure if it's the good term for it). I see lots of people in their 40's or more that quit some FANG job for another job that earns less but is more aligned with how they want to live their life. I see lots of people advocating to quit jobs as soon as you see red flags. I think both of these are good wisdom. On the other han…

Personally I think programming language is about a compromise between performance and convenience. For instance, I program in Python if speed is irrelevant. Rust if it is very relevant. C# if I want a large project where performance is somewhat important. I think there are a wide range of languages for each "category" where I put Python, C# and Rust above, but those 3 are my current favorites. Certain languages are v…

> Personally I think programming language is about a compromise between performance and convenience.

That's one dimension, but what about popularity, maintainability, being able to hire, productivity, being able to tackle precise problems, etc.

Re: Folk wisdom on visual programming

#68

Post by jpindar »

mikewarot wrote: post #52

For completeness, I feel compelled to mention GNU Radio. It is a node based visual programming tool. It has its quirks, but you can do fairly complex digital signal processing with it, and it will do I/O from your sound card, as well as RF stuff.

And its one of the more common ways to make those little Software Defined Radio boards do something.

Re: Folk wisdom on visual programming

#69

Post by galaxyLogic »

What I find interesting is that the human society and economy at large is able to function without there being any genius programmer who designed it all. If you look at roads, there is a road everywhere and still people don't get lost. But in a big chunk of source-code I do feel I get lost.

I believe that may be because there are too few constraints when programming textually. Whereas when designing roads and bridges we have the constraints of physical space. It is possible to draw a 2-dimensional map of all the roads and thus easily understand it all. I think visual programming was inspired by this notion, how physical and geometrical constraints make things simpler because we know those constraints intuitively, which thus helps us reason about the structure of the whole thing. It can not violate physics, nor geometry. Textual programs can, do anything their syntax allows. That makes their full structure hard to understand

Re: Folk wisdom on visual programming

#70

Post by jpindar »

taeric wrote: post #27
forinti wrote: post #18

Visual Programming is great for selling: look how simple it is to do this simple task!

The cynical side of me thinks that is the basic pitch for every framework and methodology.

Look at the kinds of examples people are using to demo Copilot.
Post reply on HN