The visual representation could be improved and made easier to customize over time. What truly matters is the concept and the interaction approach, which enable the creation of a general-purpose VPL that can be used for any programming task.

It was a horrible, slow ordeal.

IntelliJ’s structural search / editing is very powerful, but also arcane enough that few people I know actually use it.

I suspect there are better ways for coding in those scenarios. Like perhaps the kind of word entry that Stephen Hawkin used.

Or if you were to go totally touch UI (I’ve known one individual with motor disabilities use an old touch screen CRT with a stylus in their mouth) then you’d want those blocks a little taller but with something more akin to Miro’s infinite zoom. Rather than a text UI with mouse input.

That said, every project has to start somewhere. So this might be that proof of concept needed to fully flesh out accessibility tweaks.

We can all agree that keyboards are a) large b) necessitate being able to type (need hands) but we don't have that many high-frequency out-of-the-way input methods in computing, generally. I want to see an editor that can a) re-use existing code (libraries, concepts, etc) but that can b) use mouse, keyboard, touchscreen, hand gloves, <insert new input method here>.

Drawing boxes on screens and sticking text inside them is just not impressive, and its clunky to boot. Any worth is whatever input method is provided, and TBH I wouldn't expect this to be any easier on e.g. mobile, probably worse, in fact.

This video demonstrates how to use LLMs to generate code that can be directly used in PWCT2: https://www.youtube.com/watch?v=Fx--dNZvncc

See this is where this falls over.

Syntax highlighting + autocomplete already handle this, and where this actually works against your language, you have the problem every GUI has, inflexibility.

A "coding" language can evolve, structures change, be expressive or verbose. Much like a language.

I doubt your UI can benefit from these abilities, whereas an IDE already provides visual cues etc. that reduce this development time, while preserving the expressiveness of the language.

So, it probably does not reduce the development time, because the tools already solved this problem, and you just have a more clunky verbose, harder to develop language instead.

And the types that aren't coding in the first place are still going to struggle with things like edge cases, etc., so this isn't really democratizing anything either.

Blueprint in Unreal is the best example where you can try to dig through a tree of thousands of nodes (where hierarchies inherently start to become counter intuitive in at least some cases) or you can just start typing the node names.

And then once you start also specifying the parameters you end up, more or less, typing out the calls anyhow - but with the downside that visual programming rapidly becomes inscrutible at scale with size + flow control/branching.

To run the software without steam, install Ring language (Windows/Linux/macOS) then run it directly from the source code: https://github.com/PWCT/pwct2?tab=readme-ov-file#running-pwc...

In terms of adding more graphical/symbolic elements, we will address this in PWCT3. Additionally, publishing the PWCT2 source code will enable developers to extend the software in various directions based on their vision.

This part would be interesting, I perennially wish I could code on my tablet, but the IDEs there are just too awkward.

The big issue is, I still want a touch-type interface (like a keyboard) so that I can rapidly access many different concepts, but the Android UI is just too constrained by me having to peck slowly one key at a time.

I.e. the problem (there) is not the code, it is the input method. What I really need is the ability to access my idioms with multiple fingers, but without smudging my feedback loop (the mobile screen).

Perhaps some method of inputting code as symbols with a stylus could work better? Although it might still be very awkward...

One of the most interesting parts of grasshopper is how components operate over tree based data structures - ie the equivalent of numpy broadcasting.

The term "coding" in computing originally referred to encoding a program in the language of the machine: "machine code". Machine code was probably called that because it is cryptic, not allowing calculations to be specified in ordinary notation and in a machine-independent way.

Programming was the overall activity of designing a program, which could have involved planning it on paper; coding was the manual translation of the design into machine code.

Early programs that translated higher level statements into machine coders were called "automatic coders" and not "compilers", because they helped with the step that was already called "coding". The idea was that when you prepare input for the "automatic coder", in the higher level language like Fortran or whatever, you are programming, but not yet coding: the automatic coder is the thing that is coding for you; i.e. making machine code.

(The term "compiling" also existed, but it had a meaning similar to the dictionary meaning: something like accumulating multiple library functions into a single image. I think, something similar to producing a .a archive from .o files. The way we use "compiling" and "compiler" today doesn't make sense in regard to the ordinary meaning of the word.)

Eventually, writing in a high level language became "coding". The idea is that as soon as you begin steps which communicate your solution to the computer, which the computer will take as-is and execute, you're coding: you're encoding the abstract idea into a form which the machine understands, whether that be assembly language or Prolog.

Those aspects of programming that are not coding have to do with clarifying requirements and planning the solution (and, later, testing and debugging). Once you have clarified the requirements and planned the solution, and have started using a GUI to hook up functional blocks to make it happen, you are coding the solution.

There is no need to go back to the old terminology whereby you are programming the solution, and the "automatic coder" then takes your graph and turns it into computer code. Not even if we think that the terminology was good. It was good for "compiling" to just refer to sticking things into a bundle, rather than translating in a complex way, but we are not going back to that, either.

We will just have to see how the language develops. Maybe developers will prefer not to call any graphical manipulation of functional blocks "coding". Especially if it's in a paradigm where the graph is translated into code that they often look at and perhaps edit, because you then might want the word "code" to unambiguously refer to that code.