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

491–500 of 505 posts

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

#491

Post by jrm4 »

Gormo wrote: post #490
jrm4 wrote: post #456

Earlier quoted context omitted.

I feel like I ought to be able to plead the "porn definition" thing here. YOU KNOW IT WHEN YOU SEE IT, COME ON. :) (fair question, I'd have to think about it some more)

The point is that "modern" doesn't actually mean anything at all -- all you're saying is that something seems to you, subjectively, to be somehow newer in relation to older things, but you're (a) talking about yourself, not about the thing you're evaluating, and (b) not even describing any of the concrete qualities of the thing itself that may be informing that subjective impression. When someone describes something…

Oh no. I think all I mostly mean here is "plays more nicely with current stuff."

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

#492

Post by pstric »

wpm wrote: post #427
dgb23 wrote: post #423

Earlier quoted context omitted.

The dead fish metaphor is so interesting because programs aren’t static objects, they move. Most visual programming environments represent programs in a static way, they just do it with pictures (often graphs) instead of text. Perhaps there is something to be discovered when we start visualization what the CPU does at a very low level, as in moving and manipulating bits, and then build visual, animated abstractions w…

Yes, most diagrams are frustratingly static, even those that over lay step by step information on top. I've found "diagrams" in my head, the mental models I use to reason about a problem, are not static. They are abstract machines, with cogs and gears and clutches and input shafts and output shafts, colors and arrows and action and movement, that work like a map for finding the solution, either directly, or at least…

> Yes, most diagrams are frustratingly static

Most source code is static. In case you want to show a diff, you normally do this with a side-by-side view, regardless of whether you show the diff as textual source code, or as two diagrams.

The transformations you sometime see in Youtube videos of moving and removing small bits of code to e.g. show the differences between a piece of functionality in an object oriented vs functional language are only useful because they require your eyes to follow relatively few points of interest.

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

#493

Post by SonOfLilit »

Nathanba wrote: post #31
SonOfLilit wrote: post #15

Earlier quoted context omitted.

Code is 1d with named links. Visual languages trade named links for global wiring, which is very cluttered for serious problem solving.

Code is not 1d, a single if() already creates another line that makes it 2d

Mathematicians like to use parametrizations to measure "how |any dimensions" something has. If you need two indexes to traverse it (x and y), it's 2d, if a single index works best to describe it, it's 1d.

Another way to think of it is "there is semantic meaning to 'the character to the right/left of this one', but is there to 'the character above/below this one'?" In most programming languages, there isn't at all.

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

#494

Post by Andrex »

dhosek wrote: post #442
yoelhacks wrote: post #391

Earlier quoted context omitted.

I think there's a very important real-world nuance here. What you want with a programming language is to handle granular logic in a very explicit way (business requirements, precise calculations, etc.). What this article posits, and what I agree with, is that existing languages offer a more concise way of doing that. If I wanted to program in a visual way, I'd probably still want / need the ability to do specific ope…

My son who started programming at 7 pretty quickly moved on from languages like Scratch and Tinker. To the extent to which he uses them at all, it’s mostly to play games that are available in them. I’m not entirely convinced that he couldn’t have just started with Javascript or Python. It’s not like learning the syntax for a for loop¹ is that much harder than arranging the blocks in one of those block languages. ⸻ 1.…

Is Visual Basic still a thing? That was my start and it always felt like a good intro language. It was limiting but you could still make "real" desktop apps.

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

#495

Post by stcredzero »

whilenot-dev wrote: post #458
stcredzero wrote: post #416

Earlier quoted context omitted.

Bret Victor might argue visualizing a program is still "drawing dead fish". The power of visual programming is diminished if the programmer aims to produce source-code as the final medium and only use visualization on top of language. I disagree. We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are described using diagrams, like flowch…

> We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are described using diagrams, like flowcharts or state transition diagrams, etc. We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are documented using diagrams on a high level (like flowcharts or state t…

> but are not executable.

Fixed it for you.

Dude, if you say the flow in the diagram is not executable, blanket in any fashion, then are you saying all of the programming projects you've been in are either monolithic systems, or have all failed?

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

#496

Post by e1g »

anonzzzies wrote: post #468
brabel wrote: post #333

Earlier quoted context omitted.

Their hot reload cycle is fast because esbuild doesn't type check the code, it just removes types from Typescript so it turns into JS (it may do minification and tree shaking but in dev, they probably remove that). I've written some esbuild plugins and can confirm that on incremental builds, esbuild will probably never take more than a few ms even on larger projects (because it doesn't matter how big your project is,…

No one wants to show me though. Is that not weird? Fanbois say it is, but not one person even sends an open source project that demonstrates it. I don’t understand that? Please show me a non trivial project on GitHub that does this in ms like you say. All I try are slow af. Emacs is notoriously slow as a lisp; it is always faster, for me, than anything ts and definitely not trivial. Sbcl/cl blows it all away. Please…

You are asking for someone else to do a demo of something trivial that takes 15 minutes to setup yourself (with Vite). Nobody is biting because it’s a strange (and, frankly, lazy) request.

If you tried and still think such a setup is not possible, send me an email (in profile) and I can do a 10-15 minute show&tell.

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

#497

Post by Quiark »

AtlasBarfed wrote: post #445
jayd16 wrote: post #375

Earlier quoted context omitted.

You know, this is actually really insightful. A standard graph format that all these tools could import/export to could lead to a lot more reusable tooling. The incentives aren't quite there at the moment but maybe someone like Microsoft or Jetbrains takes a stab at it.

You think Microsoft is going to make a format that's cross-platform? I guess that leaves jet brains

You mean like for example the Language Server Protocol?

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

#498

Post by usrbinbash »

mapcars wrote: post #321
usrbinbash wrote: post #204

> But why do people keep coming back to visual programming? Because real programming languages are free. That's it. That's the main reason. Sure, there are hobby projects, yes, but almost every visual "programming language" in use in the industry, is a proprietary product, being licensed or sold. It's a way to make money, and a pretty smart one to be honest: Once people invest time, resources, training, and build act…

> The first thing the devs of it didn't anticipate, or anticipated but implemented badly. And you build around that. And then the next thing happens. And then next. And the next. Its interesting to get a perspective from someone who actually has experience with these things. Do you think there is a middle ground where the flexibility can be kept, like allowing manual code edits or use visual part for larger structura…

> like allowing manual code edits

That's just another escape hatch tbh. Don't get me wrong, if the system actually allows me to define what some of them call "code blocks", "logic blocks", or whatever, where I can run actual, arbitrary, code, I am the first whos gonna thank the developer, regardless what it runs, python,lua,js,ruby, whathaveyou. (Not that it is all sunshine and rainbows with these, they usually have other limitations, like not being able to deal with actual packages, have weird ideas how external libraries can be installed, or not allow them at all...)

But while this is a really good escape-hatch, it still is just that: An escape hatch making up for a fundamental limitation of the idea behind the whole thing, and that is inflexibility. If I have to write parts of the logic in arbitrary code anyway, then usually it's more work to do that and integrate it with the rest of the flow, than just simply writing the whole thing as a python or go service.

So as for an answer to your question: No. I don't think so. If someone makes it happen somehow, I'll be very interested in how they do it, because I don't see how, other than making the exact visual-proglangs the article talks about where where we put a GUI on an actual proglang, and at that point the question is "what's the point".

> One of the reasons is it just happened to come first with technology progress

Sure, but a long time has passed since visual programming was first tried as a concept, and IMHO, if it were possible to build that tooling, it would have been done by now.

The problem, I think, is that textual code, for all the differences between languages, still shares common properties between all languages, that make it much much easier to develop tooling for it.

For example: `git` works for every kind of plaintext. No exceptions. LSP needs to be implemented for different languages, sure, but it is a common concept, relying on commonalitis between languages; e.g. all programming languages have some kind of identifiers, subroutines, types, etc. The same is true for a lot of other tools as well, e.g. patchfiles and diffing.

Visual Proglangs do not share these commonalities, not just with textual code, but with each other. Every one of them brings entirely new and different ways of doing things, and while that is beautiful on the one hand, it makes it really (and I actually think impossibly) hard to develop common tools to deal with them.

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

#499

Post by rbanffy »

causal wrote: post #489
rbanffy wrote: post #488

Earlier quoted context omitted.

I have a hard time trying to convince people to use things like PlantUML to “write” diagrams, but Gliphy is much too popular.

I wish Github READMEs had native PlantUML support. My go to is MermaidJS for that reason.

Mermaid is a bit more limited.

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

#500

Post by Gormo »

jrm4 wrote: post #491
Gormo wrote: post #490

Earlier quoted context omitted.

The point is that "modern" doesn't actually mean anything at all -- all you're saying is that something seems to you, subjectively, to be somehow newer in relation to older things, but you're (a) talking about yourself, not about the thing you're evaluating, and (b) not even describing any of the concrete qualities of the thing itself that may be informing that subjective impression. When someone describes something…

Oh no. I think all I mostly mean here is "plays more nicely with current stuff."

Interoperability seems very "classic" to me -- the "modern" trend is to try to turn everything into a walled garden that diverges from common interface conventions and stops supporting standard protocols.
Post reply on HN