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

331–340 of 505 posts

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

#331

Post by NortySpock »

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…

> You can paint arrows that give you the whole dependency tree.

Sorry, is that a manual process, or is there a option in Excel to show multi-ancestor dependencies?

I'm aware that you can double click to see a single cells inputs, but I want to go deeper.

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

#332

Post by RHSeeger »

danielovichdk wrote: post #215
ryandv wrote: post #192

Earlier quoted context omitted.

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.

Tests for me also help me write better code. When writing tests, I'm forced to switch from "how do I implement the behavior I want" to "how can this fail to do the right thing". Looking at the code from _both_ of those mindsets helps me end up with better code.

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

#333

Post by brabel »

anonzzzies wrote: post #251
e1g wrote: post #247

Earlier quoted context omitted.

Same, M3. The DX within a modern frontend stack is indistinguishable from Bret Victor’s ideas (even if a decade late).

Ok, when can we meet? I have never seen it work, and, as said, I review 100s of project a year; everything ts is super slow so far. Maybe you have something.

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, esbuild will only rebuild what changed, which usually is a few files only).

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

#334

Post by causal »

tliltocatl wrote: post #138

The social problem with visual programming is indeed the same as with "Mythical Non-Roboticist". But there is quite some issues on it on the technical side too: - Any sufficiently advanced program has non-planar dataflow graph. Yes "pipelines" are fine, but anything beyond that - you are going to need labels. And with labels it becomes just like plain old non-visual program, just less structured. - Code formatting be…

+1

I'd add versioning and diff tools as another critical advantage for text. If your visual tool can't provide a superior diff experience, then it's dead on arrival for most serious projects.

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

#335

Post by galdosdi »

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…

Honest question as a java lover-- do rust and TS have slow compile times or something?

Because java has a robust type system and yet I've never had any issue with it's compile times. And the parsing in the IDEs is so fast and good I can pretty much get all the feedback in real time.

Ah, that's the luxury of using a battle tested language that other people have invested billions of dollars of effort into optimizing.

Do you guys not have that in Rust and TS? Bummer man. Hope you get there someday. This is exactly why I abandoned scala btw.

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

#336

Post by d--b »

NortySpock wrote: post #331
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…

> You can paint arrows that give you the whole dependency tree. Sorry, is that a manual process, or is there a option in Excel to show multi-ancestor dependencies? I'm aware that you can double click to see a single cells inputs, but I want to go deeper.

https://support.microsoft.com/en-us/office/display-the-relat...

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

#338

Post by markus_zhang »

jayd16 wrote: post #68

Anyone who mentions visual scripting without mentioning the game industry just hasn't done enough research at all. Its actually a really elegant way to handle transforming data. Look up Unreal blueprints, shader graphs, procedural model generation in blender or Houdini. Visual programming is already here and quite popular.

TBH I think Blueprints gets used because it is forced upon the UE developers.

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

#339

Post by markus_zhang »

snarfy wrote: post #319
jayd16 wrote: post #68

Anyone who mentions visual scripting without mentioning the game industry just hasn't done enough research at all. Its actually a really elegant way to handle transforming data. Look up Unreal blueprints, shader graphs, procedural model generation in blender or Houdini. Visual programming is already here and quite popular.

I used blueprint's predecessor 'kismet' quite extensively. I absolutely hated it. Give me unrealscript any day. Blueprint is popular because that's all you have. They removed unrealscript. To do anything even slightly complex you have to use C++ now.

I wonder the sweet point between BP and C++. One of my friends is making a commercial indie game in UE and he is doing everything in BP because he is an artist, so C++ is particularly daunting for him. He did complain about the spaghettis hell he eventually came upon, without anyway to solve it, but from the number of wishlistings (targeting 10K), I'd say it is probably going to be a successful game, judging by first indie game standard.

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

#340

Post by pgris2 »

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…

So, paraphrasing:

Any sufficiently complicated Ruby program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Java

Post reply on HN