We need visual programming. No, not like that • Hacker News Board

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

#261

Post by emporas » Mon, Jul 15, 2024, 10:40 AM UTC

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…

Eventual or gradual typing could leave everyone happy.

On the premise of the article, maybe the key to representing a program visually is a very expressive (and strong) type system. There could be a way to derive some Visual Types from good old regular types, and diagram the visual types in any level of granularity one desires.

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

#262

Post by gabigrin » Mon, Jul 15, 2024, 10:42 AM UTC

Merge sort (the first example countering visual programming's value) is a great demonstration of something that doesn't make sense to convey visually. I strongly believe algorithms in general are best conveyed using good ol' textual programming.

However, most dev's work isn't writing merge sort, but gluing up databases, third-party vendors, and internal microservices to perform some business logic. The amount of "low-level" coding done is low, and getting even lower with the emergence of LLMs.

With that in mind, visual programming as a way to orchestrate different components together can shine!

That's why I built Flyde - https://www.flyde.dev. An open-source visual programming language that integrates seamlessly with existing code, and doesn't replace it.

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

#263

Post by mapcars » Mon, Jul 15, 2024, 10:43 AM UTC

trashburger wrote: post #254

I simply have to recommend Glamorous Toolkit to anyone interested in visual programming: https://gtoolkit.com It focuses on the kind of visual programming the article argues for: Class layout, code architecture, semantics. It's one of the best implementations I have seen. The authors are proponents of "moldable development", which actively encourages building tools and visualizations like the ones in the article.

The "issue" with it is that it is tied to a Smalltalk, so it's hard to imagine it being more or less practical.

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

#264

Post by danbruc » Mon, Jul 15, 2024, 10:43 AM UTC

Having diagrams and code is bad, they are redundant, they will get out of sync, you will have to figure out whether the code or the diagram is correct. That leaves us with code generation from the diagrams, or more accurately from the languages describing the diagrams, or creating diagrams from code. For understanding a code base it is the later that you want, you do not want visual programming but code base visualization. There are tools for this - for example NDepend [1] for .NET - but they are not really what you want, they are not capable of abstracting enough, summarizing a million lines of code in a handful good diagrams is a very difficult task, for humans as well as for machines.

The other way around - code from diagrams - also does not really work. Those diagrams are domain specific languages in disguise, build to concisely express a very specific programming task. This was tried in the 90s under the label of model-driven programming, you just draw all kinds of diagrams which probably meant that under the hood you were producing XML documents, those could then be fed into code generators and you are done without the need for any real coding. But as we all know, once you step beyond the complexity of hello world, essentially nothing fits any model perfectly, there is always this weird edge case or completely nonsensical requirement. And now you start messing with your code generators or wrapping the generated code in another layer to get the edge cases adjusted. Or you are writing your own visual designers and code generators.

[1] https://www.ndepend.com

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

#265

Post by guappa » Mon, Jul 15, 2024, 10:44 AM UTC

arethuza wrote: post #233

DixieDev wrote: post #230

Earlier quoted context omitted.

I would like to see improvements in the speed of feedback - particularly from language servers - but the value of those 'basic' guarantees is more than worth the current cost. Unexpected side effects are responsible for almost every trip I've taken with a debugger in any large Java or C++ project I've ever worked on.

I can remember about 20 years ago a colleague getting quite frustrated that a bug he had been looking at for quite a long time came down to someone doing something bizarre in an overloaded assignment operator in C++.

I've seen methods with names like "get_value()" have extensive side effects.

No type system can fix bad programming.

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

#266

Post by mapcars » Mon, Jul 15, 2024, 10:46 AM UTC

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?

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

#267

Post by arethuza » Mon, Jul 15, 2024, 10:48 AM UTC

gabigrin wrote: post #262

Merge sort (the first example countering visual programming's value) is a great demonstration of something that doesn't make sense to convey visually. I strongly believe algorithms in general are best conveyed using good ol' textual programming. However, most dev's work isn't writing merge sort, but gluing up databases, third-party vendors, and internal microservices to perform some business logic. The amount of "low…

I can see why you might want to explain something visually but not build it visually - that merge sort example IMHO being a great example of the latter.

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

#268

Post by mapcars » Mon, Jul 15, 2024, 10:50 AM UTC

edflsafoiewq wrote: post #30

mapcars wrote: post #8

Earlier quoted context omitted.

That is not a problem, and for sure not a fundamental one. The textual representation is very limited, it's actually 1D with a line breaks helping us read it. 2D gives a lot more possibilities of organising code similar to how we draw diagrams on a whiteboard.

The problem with visual programming is it abandons the fundamental principle of language, whereby to connect two objects it is necessary only to speak their names, in favor of the principle of physicality, whereby to connect two objects it is necessary that they be in physical contact, ie. to be joined by a wire.

> only to speak their names

> in physical contact, ie. to be joined by a wire.

I don't really see how that is different, in any given language the name alone is not enough to refer to the object, in general case you have to import it. For me the process of name resolution and connecting by a wire is the same thing with different representations.

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

#269

Post by frou_dh » Mon, Jul 15, 2024, 10:50 AM UTC

jampekka wrote: post #260

frou_dh wrote: post #190

Earlier quoted context omitted.

Much like designing Integrated Circuit chips, vs. only doing basic breadboard-ing.

The spatial (usually largely 2D in IC) constraints are a huge limitation for circuit design. I'm quite sure chips (or breadboards) wouldn't be designed like this if the physical world wouldn't force the geometry.

I meant more that the very concept of an IC is a good idea, and like a good abstraction in programming.

I think pjmlp was getting at is that when using visual programming, a lot of people seem to turn off (or not cultivate) the part of the thought process concerned with creating good abstractions, despite it at least being possible to do so.

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

#270

Post by arethuza » Mon, Jul 15, 2024, 10:55 AM UTC

guappa wrote: post #265

arethuza wrote: post #233

Earlier quoted context omitted.

I can remember about 20 years ago a colleague getting quite frustrated that a bug he had been looking at for quite a long time came down to someone doing something bizarre in an overloaded assignment operator in C++.

I've seen methods with names like "get_value()" have extensive side effects. No type system can fix bad programming.

Of course I think we have all seen horrors like that - what I remember was his completely exasperated response not the technical details of the bug.