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

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

#241

Post by jcelerier » Mon, Jul 15, 2024, 10:00 AM UTC

sbensu wrote: post #72

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.

[post author] I am familiar with those and have used a couple. There are similar examples in music, where visual programming dominates. The implied audience of this post (not clear) is people writing business applications, web dev, etc. The examples are picked to reflect what could be useful to those developers. In other words, all the examples you mentioned are great but they are not how a "software engineer in a so…

> In other words, all the examples you mentioned are great but they are not how a "software engineer in a software company" does their job.

creating blueprints or max/msp programs is definitely software engineering, it requires you to think about correct abstractions, computations, data flow and storage, etc.

also, there's currently 398 Rust jobs worldwide advertised on linkedin, vs. 1473 for "unreal blueprints"

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

#242

Post by anonzzzies » Mon, Jul 15, 2024, 10:04 AM UTC

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/

On what hardware? I have a m3 and yeah, it’s terrible with ts. Instant (milliseconds) with cl (of el even). Go is not terrible.

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

#243

Post by szundi » Mon, Jul 15, 2024, 10:04 AM UTC

aftoprokrustes wrote: post #201

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…

While I prefer expressive type systems by a long shot, I would be much more careful about it "guaranteeing correctness". Types can act as good documentation and as a safeguard for stupid mistakes. But the worst bugs are due to logic mistakes, wrong assumptions or non-foreseen corner cases. Here, either types do not help, or designing the type system is so difficult it is not worth the effort, and makes many future ch…

It guarantees certain correctness it is having conversations with you about - this way more correct

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

#244

Post by hnick » Mon, Jul 15, 2024, 10:09 AM UTC

constantcrying wrote: post #239

hnick wrote: post #207

Most times in my career that I've seen people talking about visual programming, it's not about the developers - it's about lowering the bar so that (cheaper) non-developers can participate. A Business Analyst may or may not have a coding background, but their specifications can be quite technical and logical and hopefully they understand the details. The assumption is that if we create our own Sufficiently Advanced O…

>it's about lowering the bar so that (cheaper) non-developers can participate. I think that is a terrible approach to anything. Programming isn't that hard and without a doubt anyone who can do business analysis is mentally capable of writing Python or whatever other scripting language. Instead of teaching people something universal, which they can use everywhere and which they can expand their knowledge of as needed…

> you are teaching them a deeply flawed process, which is highly specific, highly limited and something which the developer would never use themselves.

That kind of lock-in can be a feature from the employer's perspective. I did actual coding for years in an environment where what I learned was not very widely applicable at all, for similar reasons. I'm now happily in recovery :) But it makes it harder to leave when you feel like you lag behind where you should be in your career.

I don't think tools like Zapier are condescending. I can and have written code to connect APIs, but Zapier made some stuff way easier, and it lets people like my wife get the same stuff done with far less effort. She has no interest in learning programming. There will be stuff the tool can't do, so then the programmers can step in.

And in my prior job, many people became BAs from a coding background specifically to get out of writing code. They can do it - they don't want to. They're happier in MS Office or similar tools.

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

#245

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

aftoprokrustes wrote: post #201

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…

While I prefer expressive type systems by a long shot, I would be much more careful about it "guaranteeing correctness". Types can act as good documentation and as a safeguard for stupid mistakes. But the worst bugs are due to logic mistakes, wrong assumptions or non-foreseen corner cases. Here, either types do not help, or designing the type system is so difficult it is not worth the effort, and makes many future ch…

Just encode your business logic in types first! Coq, Idris, or F* will certainly get the job done for you!

/s

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

#246

Post by anonzzzies » Mon, Jul 15, 2024, 10:12 AM UTC

tossandthrow wrote: post #245

aftoprokrustes wrote: post #201

Earlier quoted context omitted.

While I prefer expressive type systems by a long shot, I would be much more careful about it "guaranteeing correctness". Types can act as good documentation and as a safeguard for stupid mistakes. But the worst bugs are due to logic mistakes, wrong assumptions or non-foreseen corner cases. Here, either types do not help, or designing the type system is so difficult it is not worth the effort, and makes many future ch…

Just encode your business logic in types first! Coq, Idris, or F* will certainly get the job done for you! /s

Yes, you do if you want to make money on decades timescales instead of some grifter vc 2 year thingy.

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

#247

Post by e1g » Mon, Jul 15, 2024, 10:13 AM UTC

anonzzzies wrote: post #242

e1g wrote: post #238

Earlier quoted context omitted.

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/

On what hardware? I have a m3 and yeah, it’s terrible with ts. Instant (milliseconds) with cl (of el even). Go is not terrible.

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

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

#248

Post by Pamar » Mon, Jul 15, 2024, 10:14 AM UTC

al_borland wrote: post #4

The issue with every one I’ve used is that it hides all the parameters away in context aware dialog boxes. Someone can’t come along and search for something, they need to click every element to via the dialog for that element to hunt for what they are looking for. I found every time the lead dev on a project changed, it was easier to re-write the whole thing than to try and figure out what the previous dev did. There…

Yes, definitely this. I have worked for a couple years on webMethods, where programs can ONLY be created by "drawing/composing" sort of flowcharts (see https://stackoverflow.com/q/24126185/54504 ) and the main problem was always trying to search for stuff inside the "Codebase". And... another benefit of purely text-based code is that you can always run a diff-like utility and quickly zoom in on what has been changed.

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

#249

Post by caseyy » Mon, Jul 15, 2024, 10:19 AM UTC

> I have never seen any of these visual programming systems even be mentioned while trying to solve problems.

Unreal Engine’s Blueprints and Material Graphs are visual programming tools used heavily in indie to AAA games. So that’s one visual programming language used to solve problems all the time.

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

#250

Post by nottorp » Mon, Jul 15, 2024, 10:20 AM UTC

Speaking of visual anything. I once ran across an experiment* where instead of leaving non programmers with the GUI, they encouraged them to experiment with a CLI to do their tasks. Guess what, everyone got more productive and preferred the CLI after they figured it out.

So do you have to waste resources on pretty graphs, or is it more efficient to stick a text based DSL in there for your non programmers?

Is the current fetish for meta meta meta programming a feature or a bug?

Can't you give your business analyst a BASIC like DSL that they can use to script most of their specific problems away? Like, you know the stuff in ms office?

Of course, to do that you need to unlearn your C++ and Rust and even python while designing the DSL :)

* With web search being what it is these days, I'm not going to even try and find a citation.

** Even what TFA is talking about can be considered a DSL. A DSL for debugging and software maintenance. They say it should be graphical, but a good part of the stuff that's mentioned would work as well in text reports.