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 <> 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 <
>> wrote:
> > On Tue, Jan 24, 2023 at 6:41 PM Steve Lewis via cctalk <
> >> 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
> with
> > > 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?
> >
> >
> >
> > Add the VR interface and you basically have what you describe.
> >
> > Sellam
> >

Reply via email to