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

We need visual programming. No, not like that

blog.sbensu.com

Post reply on HN
Print view View original

471–480 of 505 posts

Re: We need visual programming. No, not like that

#471

Post by billfruit »

_flux wrote: post #218
billfruit wrote: post #212

Earlier quoted context omitted.

Statechart diagrams are even better than sequence diagrams, because they can encode quite a lot of behaviour visually.

State diagrams are basically visual code, aren't they? And indeed they good for specifying, being the source of truth, but like code, they (afaik) don't really work for representing interactions with multiple actors (other than by sending/receiving messages), and they don't have a time component. But you could generate sequence diagrams from them, or at least verify them. Xstate does have some functionality for inter…

Statecharts are highly useful to represent behaviour. Sequence diagrams do not capture it as much.

Timed behaviour, like timeouts can be represented in statecharts by having transitions on time based conditions. For example an event puts the system in a 'waiting' state, and in the waiting state there is a 30 second transition to a 'fail' state unless some other event happens which pulls the system out of the 'waiting' state.

Also it provides a good indication of what behaviour is valid and what not valid and what are don't cares.

External interactions of a system can be model as the state changes of a system.

They also have 'memory', special elements that remember which substate the system was in before it jumped out of the state last time.

I recommend David Harel's very interesting paper on modelling behaviour with state charts.

Re: We need visual programming. No, not like that

#472

Post by anonzzzies »

ryandv wrote: post #192
anonzzzies wrote: post #182

Far more important is instant feedback and that’s getting worse all the time: with lisp, smalltalk, Delphi, forth things were instant. With typescript or rust etc, if the project is larger than hello world, the feedback is well, far from instant. Bret victor talked about feedback, not necessarily visual programming and for some reason we are making things worse instead of better. When I show a Common Lisp dev session…

With strong, expressive type systems such as those offered by Haskell, Rust, TypeScript, etc... I find that you front-load all of your debugging to compile/typecheck time. Instead of needing to experiment with your code at runtime through either manual or automated (TDD) tests, you are instead having a conversation with the compiler/typechecker to statically guarantee its correctness. There's just as tight a feedback…

CL is a strong and often statically typed language; there are more expressive, even Haskell like implementations (https://coalton-lang.github.io/20211010-introducing-coalton/) with instant feedback, robust (old; underestimated how robust things get when some kid didn’t roll your npm yesterday). And yep, an expressive type system, like ts, is often turing complete so it can hang, but that’s not what I am talking about; trivial ts is incredibly slow even with type checking off; now non trivial ts is a joke. Why so many fans while no one can show even 1 example that is not slow?

Re: We need visual programming. No, not like that

#473

Post by bryananderson »

galaxyLogic wrote: post #401
bryananderson wrote: post #387

Earlier quoted context omitted.

Sometime in the early 2000s they generated all the flight code for the James Webb Space Telescope from UML diagrams with Rational Rose. Over a decade later they were still trying to unfuck all of it.

Any link for that? I think it's a good real-life example

Just what I remember from an internship. A quick google search just shows a few puff pieces.

Re: We need visual programming. No, not like that

#474

Post by arendtio »

Currently, I am learning learning cards (like Anki) created by an official publisher. Together with the answer there was sometimes a 'reason'. What I found interesting, and what is actually related to this topic, is that this 'reason' was often just a picture. It helped a lot because the same picture was often the reason for multiple cards.

What I want to say is that pictures can hold a lot more information than text and that creating a coherent image can increase the information density. However, pictures can have even less information density than text.

I think that most visual programming tools fail to increase the information density in a helpful way.

Re: We need visual programming. No, not like that

#475

Post by imtringued »

ejiblabahaba wrote: post #124

As someone with a hardware background, I'll throw in my $0.02. The schematic capture elements to connect up large blocks of HDL with a ton of I/O going everywhere are one of the few applications of visual programming that I like. Once you get past defining the block behaviors in HDL, instantiation can become tedious and error-prone in text, since the tools all kinda suck with very little hinting or argument checking,…

Building block diagrams in Vivado to whip up quick FPGA designs was a pleasant experience. Unfortunately the biggest problem wasn't the visual editor. The provided implementations of the AMD/Xilinx IP cores are terrible and not on par with what you would expect first party support to be. The other problem was that their AXI subordinate example was trash and acted more like a barrier to get started. What they should have done is acquire or copy airhdl and let people auto generate a simpler register interface that they can then drag and drop.

Re: We need visual programming. No, not like that

#476

Post by imtringued »

hnick wrote: post #209
d--b wrote: post #199

> One reason is because we think that other, more inexperienced, programmers might have an easier time with visual programming. If only code wasn't as scary! If only it was visual! Excel Formula is the most popular programming language by a few orders of magnitude and it can look like this: > =INDEX(A1:A4,SMALL(IF(Active[A1:A4]=E$1,ROW(A1:A4)-1),ROW(1:1)),2) Ahem. Excel is one of the most visual programming environme…

As a programmer who had used Excel for years, seeing my accountant start typing a formula, change sheets, select some cells, go back, repeat, was a learning process. I didn't even know you could do that, and also, I hated it. But it worked very well for him. I've more recently been exposed to a few spreadsheets that are used to calculate quotes in major insurance businesses when I was asked to create an online proces…

Oh sweet summer child. You will probably never experience running into the 10 million cell limit on a google sheet with more than a hundred sheets and waiting a quarter of an hour for your spreadsheet to update.

Re: We need visual programming. No, not like that

#477

Post by mike_hearn »

amai wrote: post #369
mike_hearn wrote: post #310

Earlier quoted context omitted.

Well visual programming is standard in Unreal projects and they definitely scale beyond toy projects with a single developer. Although Excel is the most popular visual 'programming language', the second most popular is surely Blueprint.

"if you connect to source control within the editor you can at least diff blueprints to compare changes. though it's currently not possible to actually merge them." https://www.reddit.com/r/unrealengine/comments/1azcww8/how_d... So it seems like basic functionality like merge is still missing from visual coding in Unreal. But yes, there were also huge projects before the invention of distributed version control syste…

Yes, but you don't need merge to scale up things like game projects. You can just carefully partition the work between people. Perforce supports file locking for this reason. And, a lot of merge conflicts in software are thanks to the use of symbolic naming.

Re: We need visual programming. No, not like that

#478

Post by reportgunner »

mapcars wrote: post #266
LeonB wrote: post #42

Programming “via” Visualization — doesn’t scale. Great for demos. Good in limited places. Visualizations “of” a Program — quite useful. Note there lots of different ways to visualize the same program to emphasise / omit different details. The map is not the territory, all models are wrong etc.

Why do you think it doesn't scale?

It gets very messy with scale and keeping it not messy as it's scaling up is hard.

Re: We need visual programming. No, not like that

#479

Post by mlaci »

low_tech_punk wrote: post #384

I think we need to differentiate: Visualize a program vs. Visually program. This post seems to still focus the former while an earlier HN post on Scoped Propagators https://news.ycombinator.com/item?id=40916193 showed what's possible with the latter. It specifically showed what's possible when programming with graphs. Bret Victor might argue visualizing a program is still "drawing dead fish". The power of visual prog…

>I think we need to differentiate: Visualize a program vs. Visually program.

Not necessarily, programming with visual DSL is already a thing in the field of language oriented programming. Visual programming refers to different thing, but not impossible to make a connection between the two fields.

Visual programming is now more like umbrella term for projects (and research) exploring new ways of programming beyond the textual representation. Probably better to call it non-textual programming, because some of its ideas not tied to visuality, like structural editing.

Visual programming enviraments offers a concrete way to program general-purpose code, DSLs offers a very specific language to program in a domain (language orinted programming offers ways to invent these DSLs). Often visual programming applied to a specific domain, as an alternative to textual scripting languages. Maybe this confuses people, thinking they are less powerfull, non general-purpose.

What described in the article is a visual DSL based on diagrams, using as a source for the programming itself (which is exactly the same as UML). But the whole thing are not well thought, and I think only serves the purpose of dunk on visual programming or the people how are working on them for "not understanding what professional programmers need".

Re: We need visual programming. No, not like that

#480

Post by lucideer »

low_tech_punk wrote: post #384

I think we need to differentiate: Visualize a program vs. Visually program. This post seems to still focus the former while an earlier HN post on Scoped Propagators https://news.ycombinator.com/item?id=40916193 showed what's possible with the latter. It specifically showed what's possible when programming with graphs. Bret Victor might argue visualizing a program is still "drawing dead fish". The power of visual prog…

> I think we need to differentiate

My read of this post (especially the title) is the author does differentiate normally but chose to blur the lines here for a narrative hook & a little bit of fun.

Post reply on HN