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

211–220 of 505 posts

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

#211

Post by ambyra »

thedevilslawyer wrote: post #169
ambyra wrote: post #166

I always thought excel could do this, and everyone already knows excel. Toss out the vba, replace with python, every cell is a function, have a regular view, a relationship view that shows which cells connect to the current selected cell, have a run, stop pause, step/break button. Everyone would use this.

This is possible today with google sheets and javascript. The appscript integration is kind of amazing and allows for these flows effectively.

I had no idea. This sounds amazing. Do you know of any companies using this?

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

#212

Post by billfruit »

_flux wrote: post #210

Sequence diagrames (that seems not much different swimlane diagrams) are great, so much so that I created a tool that generates them from appropriately built TLA+ specs representing message exchange scenarios: https://github.com/eras/tlsd However, while they are good for representing scenarios , they are not that good for specifying functionality . You can easily represent the one golden path in the system, but if yo…

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

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

#213

Post by lomase »

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…

Stil impossible to know what a Excel sheet does only by looking at it. The 2d grid obfucates the relationships between data.

Power BI does (almost) everything Excel does but better.

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

#214

Post by nox101 »

anonzzzies wrote: post #202
FireInsight wrote: post #194

Earlier quoted context omitted.

I don't know what TypeScript projects you have worked on, but every one I have worked on is instant reload all the way down. Rust, on the other hand, is pretty miserable.

I don’t know; I am a programmer but more of a trouble shooter (it makes far more) and projects passing 100k LoC in ts which I see 100s a year, are not instant, in any way. I would love to see one, but I contribute to open source projects, and it’s all slow, very very slow.

I'm working on 250k LoC TS project. It's instant during dev. We don't bundle during dev so the server just has to compile which ever files changed.

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

#215

Post by danielovichdk »

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…

I do not consider neither TDD or tests being about finding or solving bugs. They are about regression and refactoring safety. They are my guardrails for when I must change or add things, or need to discover how something works.

The rest of your comment I found to be a really good point in terms if feedback justification. The IDE checking your code before compile or runtime is faster than both. Good point.

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

#216

Post by nottorp »

ben_w wrote: post #203
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…

I think that's also true, but not the thing they're writing about. My experience as an iOS developer has been mixed between places that use Interface Builder and those who create the UI in code. Something like Interface Builder is obviously a great idea for UI creation, which is why it survived so long and why Figma exists, but the actual tool itself (IB) isn't really useful for desigers who want one thing that works…

Haven't worked with the iOS interface builder but i worked with Delphi ages ago.

Question: how well does the interface builder thingy mix with interface in code?

Can you easily lay out the basics of an UI graphically and then add code where the builder is too limited for what you need?

Or it's the kind where if you start with the graphical builder you're stuck with just what the graphical builder can do?

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

#217

Post by manbash »

billfruit wrote: post #212
_flux wrote: post #210

Sequence diagrames (that seems not much different swimlane diagrams) are great, so much so that I created a tool that generates them from appropriately built TLA+ specs representing message exchange scenarios: https://github.com/eras/tlsd However, while they are good for representing scenarios , they are not that good for specifying functionality . You can easily represent the one golden path in the system, but if yo…

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

State diagram and sequence diagram complement each other, rather than competing.

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

#218

Post by _flux »

billfruit wrote: post #212
_flux wrote: post #210

Sequence diagrames (that seems not much different swimlane diagrams) are great, so much so that I created a tool that generates them from appropriately built TLA+ specs representing message exchange scenarios: https://github.com/eras/tlsd However, while they are good for representing scenarios , they are not that good for specifying functionality . You can easily represent the one golden path in the system, but if yo…

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 interacting with the specified state machine, but I haven't played with it a lot. The idea of generating—or at least verifying—Xstate state machines with TLA+ has come across my mind, though.

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

#219

Post by whywhywhywhy »

> 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...

I'd argue Excel is actually a visual programming language, the formulas might look like just messy text programming when written out of context but in Excel each part is highlighted to a spatial and visual environment and can be constructed by clicking and selecting in that environment.

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

#220

Post by pjmlp »

frou_dh wrote: post #190
pjmlp wrote: post #161

Earlier quoted context omitted.

I would vouch a different take, visual programming makes it quite clear the mess of programs some people create when they don't follow modular programming. Complex flows can be packaged into functions and modules representations, instead of dummping everything into a single screen.

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

Yes, very much so.
Post reply on HN