[recursivedoubts]

not a well thought out take, but i think visual programming should stop trying to encode application logic and focus on:

- building good UIs rapidly (e.g. improving & simplifying layout options, look & feel, etc.)

- make debugging trivial & powerful

- make deployment trivial

Visual Basic was on the right track in almost every way except as a language. Hypercard maybe had the language thing figured out: use english as a base?

Hooking up loops and conditionals visually is a waste of type, people can type it out with a little instruction with a good IDE & code completion that caters to non-coders. Focus on the tooling around the code & the things visual development has proven good for (laying out UIs, debugging) and then the stuff that people don't want to think about (deploy)

[toast0]

> Hypercard maybe had the language thing figured out: use english as a base?

I wrote some stuff in applescript, which is similar / descended from HyperTalk. I would say it's the worst language I've used; it's so hard to use because of pretending to be natural. It doesn't help when Apple forgot how to write documentation somewhere around 2008, so there's no authoritative docs, and it's unsearchable because it looks like english words.

Literally anything else would be preferable, but applescript is the best way to automate MacOS. Thankfully, I only had to use it once.

[recursivedoubts]

applescript was a nightmare with zero autocompletion and a ton of magical strings and bad syntactic choices, some inherited from hypertalk, some not

i don't think an english-derived scripting language would be a bad thing (well, I wouldn't, since I created https://hyperscript.org, now would i?) if the tooling was good, I don't see a huge difference between someone dragging and dropping a for loop and an if statement and just typing

  for thing in whatever
    if the thing's field is false
      do something

[KMag]

The problem with Hypercard is that it used an extremely restricted subset of English constructions. Once you got used to the limitations, it was fine, but could be very frustrating for users learning what sorts of phrasing Hypercard expected.

Allowing too large a subset of English ends up allowing more ambiguous statements and more user surprise. Also, more complex grammar increases the chances of mistakes in implementation.

My current experience with LLM hallucination makes it clear that at present, we can't just throw an LLM at the parsing and semantic analysis side of programming language implementation.

[recursivedoubts]

i really think a strong auto-complete/auto-correct could help here

the old hypertalk (and, later, appletalk) writing environments were terrible, that's where technology could really help

[lagniappe]

Visual Basic nailed it, for me. Nothing has felt that intuitive for me since.

If I were to build a poor man's effigy to visual basic today, I'd use Go as the underlying language, and Fyne for the visual kit.

- Go has strong concurrency that is easy to understand

- Go has easy syntax that makes errors very obvious and debuggable

- Go is multi platform, truly, from OS to hardware, right out of the box

- Go with Fyne can produce a single binary .exe just like visual basic.

- Fyne retains the same look and feel across different environments

[CRConrad]

> Visual Basic nailed it, for me. Nothing has felt that intuitive for me since.

Ever tried Delphi (or nowadays, Free Pascal / Lazarus)?

I first encountered Visual Basic, and it felt... Almost there. Then i encountered Delphi, and it was love at first sight.

[datavirtue]

Non-coders will cease to exist about a half hour into building their first visual program. Even non-coders are going to want a place to put some code. They will get sick of all the clicking, clicking and dragging and wonder if there is a better way.

[jarsin]

Something I have seen in the unreal community is heavy blueprinters develop wrist issues.

[narnarpapadaddy]

Yeah, I feel like this blog post misunderstood the original post it was responding to. The argument wasn't simply "add visualization where it makes sense". It was "diagrams are more effective for dynamic analysis, as opposed to representing static structure, which code already represents effectively." Debugging being the #1 candidate, as you pointed out.