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

271–280 of 505 posts

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

#271

Post by brabel »

ta_1138 wrote: post #186
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…

As projects get bigger, things might get sadder. I worked at a certain large SF company that uses a lot of ruby, so most development was repl-based too. But this wasn't a boon but a curse, as the total lack of data format guarantees on the very large, critical monorepo meant a lot of uncertainty. What does this method really do? I guess we have to run it! It worked for this specific input... but will it work for any…

Common Lisp has always allowed you to specify types anywhere you want. It's not a statically typed language but it supports types (and SBCL and other impls do static checking where possible).

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

#272

Post by ozim »

danbruc wrote: post #264

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 visualiz…

Most of the time it is hard to convince "normal" people that text is the end game.

Text is all powerful, because you can encode any level of abstraction with text only. If you need access to nitty gritty details having text is god send, having to work on high level also fine you can just do that wrapping lower level stuff in descriptive abstractions.

We also already have tooling for dealing with text that go as far back as computing and if we leave a bit of space for interpretation even longer.

With GIT/VIM/AWK/GREP/SED you can be in charge of vast universes created in you mind and share/collaborate on those with others. While image is worth 1000s of words - options to manipulate/share/collaborate on text are so much better in every conceivable way.

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

#273

Post by brabel »

e1g wrote: post #238
anonzzzies wrote: post #223

Earlier quoted context omitted.

Well, I would love to learn how it’s possible: you have a blog or YouTube or something?

Our front end is ~200k LOC of TypeScript and all changes are instant ( TypeScript compiler is too slow for hot module replacement so it’s used only for IDEs. During development, all transformation happens via esbuild/swc and is abstracted away with Vite https://vitejs.dev/

esbuild does not do type checking. You must invoke tsc explicitly to do that.

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

#274

Post by az09mugen »

anonzzzies wrote: post #235
fwsgonzo wrote: post #227

Earlier quoted context omitted.

I have a 1,5M LOC game codebase, where both the server and client builds and starts nearly instantly. Probably < 3sec total iteration time just because of typing stuff in the terminal. Build system is just a casual ccache + mold. But you have to do a lot of stuff in the background during startup.

Let’s see it. To not be a total gobshite, go download these things and see what ‘instant’ really doesn’t mean. Instant means not wait 1 second; it means when I type code, it has results in milliseconds. None of these have that. Or show me a non trivial open source ts project that’s instant; doesn’t exist and I have literally no clue why people keep defending this stuff; you didn’t make it right? I would be embarrasse…

While I totally agree with you, I'm looking for a counter example. The only one which comes to my mind, is non trivial and quite fast for js/ts is this : https://github.com/tsoding/raycasting An implementation of raycast in a 2D canvas The dev tried to implement hot reloading, and you can see all the process there https://www.youtube.com/playlist?list=PLpM-Dvs8t0VZ08cYW6yqN...

Even though I didn't measured the loading time, an effort has been made to accelerate everything that could be accelerated.

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

#275

Post by brabel »

anonzzzies wrote: post #206
IshKebab wrote: post #195

Earlier quoted context omitted.

Typescript is pretty fast no? I've worked on the VSCode codebase a fair bit and the intellisense seems pretty fast. Like under a second, which is fine. You don't need to resort to Lisp to get instant feedback. Try Dart - it's basically instant. Rust I will give you...

Agreed, I just prefer lisp. We use flutter a lot, but we do it in cl -> dart; it makes everyone here (again taste, not gospel) happier.

What do you use to compile CL to Dart? Or you compile to JS?

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

#276

Post by brabel »

mapcars wrote: post #263
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.

It's not tied to Smalltalk, at least not completely: the standard distribution comes with a JS and Java parser and you can use those to create Smalltalk model of their ASTs, making it look like they're just Smalltalk objects too.

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

#277

Post by mapcars »

dimask wrote: post #60
lolinder wrote: post #28

Earlier quoted context omitted.

Why does laying out code on a line not cause a problem with spatial reasoning but a plane would? Are we somehow incapable of applying spatial abstractions when we move up into a higher dimension than 1?

The spatial reasoning on reading code does not happen on the dimensions of the literal text, at least not only on these. It happens in how we interpret the code and build relations in our minds while doing so. So I think that the problem is not about the spatial reasoning of what we literally see per se, but if the specific representation helps in something. I like visual representations for the explanatory value the…

> If anything, the more complex a problem is, the more cluttered the visual language form ends up being, and feels overloading my visual memory

I feel like you are more concerned about implementation than the idea itself. For me it's the opposite - I find it's easier to understand small pieces of text, but making sense of hundreds of 1k lines files is super hard.

Visual programming in my understanding should allow us to "zoom" in and out on any level and have a digestible overview of the system.

Here is an example of visual-first platform that I know is used for large industrial systems, and it allows viewing different flows separately and zooming into details of any specific piece of logic, I think it's a good example of how visual programming can be: https://youtu.be/CTZeKQ1ypPI?si=DX3bQSiDLew5wvqF&t=953

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

#278

Post by WillAdams »

nottorp wrote: post #216
ben_w wrote: post #203

Earlier quoted context omitted.

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?

A quick overview of Interface Builder is Steve Job's demo for NeXT --- perhaps:

https://www.youtube.com/watch?v=dl0CbKYUFTY

where they discuss how dragging/drawing allows one to make 80% of the app, and the balance of 20% is one's own code.

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

#279

Post by ben_w »

nottorp wrote: post #216
ben_w wrote: post #203

Earlier quoted context omitted.

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?

It mixes well.

Apple has two UI frameworks, UIKit and SwiftUI, and Xcode's Interface Builder handles each differently. The Interface Builder for each is built into Xcode, but the UI they present when editing is quite different — I'm unclear if they're both officially called "Interface Builder" or if people like me stuck with the same name for the new one because it's a thing for building interfaces.

The older system is UIKit, where Interface Builder produces some XML files — .xib or .storyboard — and once those are loaded, they result in objects which are fully manipulable in code.

The newer system, SwiftUI, the source code is the source-of-truth for a WYSIWYG editor — any change made in the editor immediately updates the code, any change in code immediately updates the editor. That said, in my experience at least, this editor falls over quite often if you do that.

Post reply on HN