25 Jan
2023
25 Jan
'23
5:04 p.m.
My personal experience of graphical programming environments (scratch,
matlab, PLCs, Max/MSP - though all in quite trivial amounts) is that
they're dreadful. Painfully slow to use and clumsy compared with straight
C. There are too many possible variants of what you might want to do, so
every simple for-loop block gains a heap of optional parameters which
destroys the point.
One contrary example is node-red, used to design data flows and also for
teensy's audio programming environment. When the main idea is flow and each
block's parameters are either obvious (like filter cut-off frequency) or
inherent in the connections (the lists of parameters that describe where
the data is flowing rom and to) then they can be a help. I'd recommend
playing with the Teensy audio system (you don't need to pay for it) to see
what you think.
On Wed, Jan 25, 2023 at 4:53 PM Steve Lewis via cctalk <
cctalk(a)classiccmp.org> wrote:
I'm familiar with Scratch, my daughter used it in
elementary. I had
forgotten about it though - it seemed focused on the task of depicting and
moving objects on a 2D area, not so much in general information processing
(but still, yes it could be a starting point). One hallmark of a "good
development environment" that someone once told me is that that development
environment can be used to create itself. Like, by Borland Delphi 2, they
used Delphi to create Delphi. Same on the Visual Studio development team
- they compile and develop VS using VS. So, I wonder if Scratch can
create itself? It's not a hard rule, just a casual observation on the
"robustness" or maturity of a given development environment.
There's always been a kind of "two tiers" of software developers - those
who can create reusable routines (libraries) and those who can mold
existing libraries to build applications. Obviously some can do both, but
generally the latter get "stuck" if there isn't some existing
function/routine in an API to do what they need to do -- like open a
socket, start a thread, or query system time. The former tends to need to
sink into OS and HW specifics.
With this "blocked" code floating in VR -- the idea is then "behind the
code" to show a virtualization of the resources needed by that code, to
quickly get an idea of the hardware requirements (relative to how many
resources it is using) and also linkages to other software, to get a feel
for the overall complexity. These are important metric to see the
versatility of re-using that code in other environments/platforms.
And back on the stenography-keyboard like thing -- what about morphing
keys? If a keyboard had actual screens on the keys, and the keys change
(the actual symbol) based on the context of whatever you're doing. I know
we have macros and reprogrammable keyboards, but morphing the actual symbol
on the keys might be neat.
Also, does any processor support a dynamic instruction set? I've wonder if
some instruction-set optimizer might find improvements by indicating your
program could be executed more efficiently if such-and-such instruction was
available.
On Tue, Jan 24, 2023 at 11:49 PM Sellam Abraham via cctalk <
cctalk(a)classiccmp.org> wrote:
with
On Tue, Jan 24, 2023 at 6:41 PM Steve Lewis via
cctalk <
cctalk(a)classiccmp.org> wrote:
> BTW, I've wondered if some form of stenography could be used for
software
development. In my mind, it would make sense to just program directly
in
> a kind of Abstract Syntax Tree (AST) from the beginning - why bother
all the
syntaxic sugar and peddling ascii text characters around a file
to
form a program. So now I wonder if
"building" a program using an AST
might be possible in VR.. you "grab" a FOR loop virtually from a box on
the
left, add it to your program tree, and build out
from there decorating
the
tree....
Are you familiar with Google Scratch?
https://scratch.mit.edu/
Add the VR interface and you basically have what you describe.
Sellam