Hello! I'm looking to exchange ideas about programming paradigms in uxn.
I've been studying old and forgotten ideas and paradigms (See Joe
Armstrong's Forgotten Ideas of CS). One theme I've noticed is the
analogy of computing to biology. Living systems exchanging messages
and acting on one another, rather than top down hierarchical command
structures (as is typical with most programs).
I've been thinking a lot about how this could be achieved in practice,
and I've written a couple of POCs. I wrote the mechanism pretty
simply, code and memory is encapsulated into "cells". These cells can
take inputs and emit outputs (sounds like OOP, but it's quite
different). Cells must be connected explicitly to external inputs and
outputs, and with other cells.
For my second POC, I'm attempting to write this language on top of
uxn: https://git.sr.ht/~kylep/beans (I started the project this
weekend, it's still in its early stages)
I called it beans just for fun, so each cell is a bean, and a program
is a set of beans in a beanpod. I think uxn is the perfect seeding
ground for my new experiment, as it's so simple and portable. I'd love
to hear any thoughts, feedback or ideas.
Kyle
Hi Kyle,
Your timing is pretty good, as it's also something I've been exploring
too. First, I'd like to say that I'm very excited for a flow-based env
in Uxn. You'll be the first person to build an actors system in uxn,
I've done a few experiments toward this myself but nothing to the
scale of where you want to go with beans, or what you've done with
VCL.
I've got to ask, since this is precisely what I've been diving into
these past few days, would it be something that can be evaluated
concurrently? Because if that's the case, you might like to see what
I'm working on, would you be game to come and waste some time on IRC
this week? I'd like to bounce ideas with you if you're wiling.
In any case, I'd love to help you if you need to bring the graphical
environment into Varvara. I have a couple of graphing routines that
might help you out!
I was wondering, looking at your website now, if you ever looked into
graph reduction schemes in relation to visual programming? Some
reading that might be of interest:
http://sro.sussex.ac.uk/id/eprint/54469/1/Sato%2C_Shinya.pdf
Keep me posted :)
Dll
On 5/1/23, Kyle Perik <kyle@periks.net> wrote:
> Hello! I'm looking to exchange ideas about programming paradigms in uxn.>> I've been studying old and forgotten ideas and paradigms (See Joe> Armstrong's Forgotten Ideas of CS). One theme I've noticed is the> analogy of computing to biology. Living systems exchanging messages> and acting on one another, rather than top down hierarchical command> structures (as is typical with most programs).>> I've been thinking a lot about how this could be achieved in practice,> and I've written a couple of POCs. I wrote the mechanism pretty> simply, code and memory is encapsulated into "cells". These cells can> take inputs and emit outputs (sounds like OOP, but it's quite> different). Cells must be connected explicitly to external inputs and> outputs, and with other cells.>> For my second POC, I'm attempting to write this language on top of> uxn: https://git.sr.ht/~kylep/beans (I started the project this> weekend, it's still in its early stages)>> I called it beans just for fun, so each cell is a bean, and a program> is a set of beans in a beanpod. I think uxn is the perfect seeding> ground for my new experiment, as it's so simple and portable. I'd love> to hear any thoughts, feedback or ideas.>> Kyle>
I'm excited to hear this is prevalent to your work recently!
Theoretically yes, it should be able to run concurrently, as the
processes can be fully isolated (or even run across machine boundaries
potentially). I have many ideas for the practical use cases, but for
now my personal challenge is just to get it running and use it to
create games I can play on my playdate :)
I would love to chat more about this! I just need to get set up with a
good IRC client.
A graphical interface is an ideal representation or editor, because I
think it can help naturally conceptualize the messages going along on
conveyor belts. I wasn't sure how feasible this would be, any help
would be much appreciated.
Only recently have I learned about interaction nets, through your
blog. I have yet to wrap my mind around it, but it looks like some
really novel concepts there. I'll have to do some more reading.
Kyle
I've been chipping away at this problem for a while, and I'm happy to
report, beans lang is suitable enough to write some simple toys. My
current goal is to create an environment that can compile fragments on
the fly for more interactive development, but that's still on the way.
Besides the bean programs, it's all written in uxntal. I've documented
a quickstart guide, along with a spec for writing basic programs, and
the philosophy behind the language. All can be found in the project
readme:
https://git.sr.ht/~kylep/beans
So the ideal visual environment is still on the way, but for now
there's a high level language that enables constructing a graph of
nodes. Within each node is a set of i/o ports and handler code to
reactively process inputs, manage local memory, and emit new messages.
This kind of message passing system feels similar to unix pipes, but
multidimensional. For me I've already felt the increased modularity
and reusability of code, and it has made data flow easier to reason
about and debug.
I drew a mascot as a flower in an ol' can of beans, but I couldn't get
the flower right, I am not an artist :'( forgive me. If anyone has a
minute, I will gladly accept an improved flower.
Devine -
It was good to meet you briefly in person at strangeloop! I hope you
find this little project interesting, sorry it's likely
under-documented and still a bit cryptic.
Kyle
Hi Kyle,
I've just tested and it works well :) It'll make more sense once the
visual editor is going I think. A lot of the examples in etc don't do
anything, like particles.bean? what's the trick to run those?
I saw in your README "After switching to the drifblim assembler, I'm
having some trouble assembling using uxnasm, so drifblim is
required.", I was able to assemble with uxnasm and drifblim, the
resulting rom is the same, are you still having that issue?
On 10/1/23, Kyle Perik <kyle@periks.net> wrote:
> I've been chipping away at this problem for a while, and I'm happy to> report, beans lang is suitable enough to write some simple toys. My> current goal is to create an environment that can compile fragments on> the fly for more interactive development, but that's still on the way.> Besides the bean programs, it's all written in uxntal. I've documented> a quickstart guide, along with a spec for writing basic programs, and> the philosophy behind the language. All can be found in the project> readme:>> https://git.sr.ht/~kylep/beans>> So the ideal visual environment is still on the way, but for now> there's a high level language that enables constructing a graph of> nodes. Within each node is a set of i/o ports and handler code to> reactively process inputs, manage local memory, and emit new messages.>> This kind of message passing system feels similar to unix pipes, but> multidimensional. For me I've already felt the increased modularity> and reusability of code, and it has made data flow easier to reason> about and debug.>> I drew a mascot as a flower in an ol' can of beans, but I couldn't get> the flower right, I am not an artist :'( forgive me. If anyone has a> minute, I will gladly accept an improved flower.>> Devine ->> It was good to meet you briefly in person at strangeloop! I hope you> find this little project interesting, sorry it's likely> under-documented and still a bit cryptic.>> Kyle>
Glad it's working mostly!
particles, tictactoe and others are purely graphical, so they must be
run with uxnemu like so:
uxncli bin/beanasm.rom etc/particles.bean > out.can
uxnemu bin/uxnbean.rom out.can
You should see something on screen right away with most.
I will check again tonight to see if uxnasm is working, it's been a
while since I've checked.
On Mon, Oct 2, 2023 at 8:26 AM Hundred Rabbits <hundredrabbits@gmail.com> wrote:
>> Hi Kyle,>> I've just tested and it works well :) It'll make more sense once the> visual editor is going I think. A lot of the examples in etc don't do> anything, like particles.bean? what's the trick to run those?>> I saw in your README "After switching to the drifblim assembler, I'm> having some trouble assembling using uxnasm, so drifblim is> required.", I was able to assemble with uxnasm and drifblim, the> resulting rom is the same, are you still having that issue?>> On 10/1/23, Kyle Perik <kyle@periks.net> wrote:> > I've been chipping away at this problem for a while, and I'm happy to> > report, beans lang is suitable enough to write some simple toys. My> > current goal is to create an environment that can compile fragments on> > the fly for more interactive development, but that's still on the way.> > Besides the bean programs, it's all written in uxntal. I've documented> > a quickstart guide, along with a spec for writing basic programs, and> > the philosophy behind the language. All can be found in the project> > readme:> >> > https://git.sr.ht/~kylep/beans> >> > So the ideal visual environment is still on the way, but for now> > there's a high level language that enables constructing a graph of> > nodes. Within each node is a set of i/o ports and handler code to> > reactively process inputs, manage local memory, and emit new messages.> >> > This kind of message passing system feels similar to unix pipes, but> > multidimensional. For me I've already felt the increased modularity> > and reusability of code, and it has made data flow easier to reason> > about and debug.> >> > I drew a mascot as a flower in an ol' can of beans, but I couldn't get> > the flower right, I am not an artist :'( forgive me. If anyone has a> > minute, I will gladly accept an improved flower.> >> > Devine -> >> > It was good to meet you briefly in person at strangeloop! I hope you> > find this little project interesting, sorry it's likely> > under-documented and still a bit cryptic.> >> > Kyle> >
Devine-
Looks like uxnasm works again, thank you! I switched it out in the
build script + docs
Also I'm happy to announce I have a function tester working! It's like
a beans version of bicycle! This doesn't show off the full extent of
routing messages, this way you can pretty easily type out short bits
of beans function code to play around with it.
Short Demo: https://stuff.kyleperik.com/beans/beans-fn-tester.mp4
Code: https://git.sr.ht/~kylep/beans/tree/master/item/etc/fn-test.bean
Controls: left+right arrows to navigate, "/" to execute
[A-D]MT means emit "QUE"d bytes ports A thru D. In this tester, these
are the assigned ports:
A = raw console, B = hex console, C = draw sprite, D = draw pixel
Kyle
On Mon, Oct 2, 2023 at 9:11 AM Kyle Perik <kyle@periks.net> wrote:
>> Glad it's working mostly!>> particles, tictactoe and others are purely graphical, so they must be> run with uxnemu like so:>> uxncli bin/beanasm.rom etc/particles.bean > out.can> uxnemu bin/uxnbean.rom out.can>> You should see something on screen right away with most.>> I will check again tonight to see if uxnasm is working, it's been a> while since I've checked.>> On Mon, Oct 2, 2023 at 8:26 AM Hundred Rabbits <hundredrabbits@gmail.com> wrote:> >> > Hi Kyle,> >> > I've just tested and it works well :) It'll make more sense once the> > visual editor is going I think. A lot of the examples in etc don't do> > anything, like particles.bean? what's the trick to run those?> >> > I saw in your README "After switching to the drifblim assembler, I'm> > having some trouble assembling using uxnasm, so drifblim is> > required.", I was able to assemble with uxnasm and drifblim, the> > resulting rom is the same, are you still having that issue?> >> > On 10/1/23, Kyle Perik <kyle@periks.net> wrote:> > > I've been chipping away at this problem for a while, and I'm happy to> > > report, beans lang is suitable enough to write some simple toys. My> > > current goal is to create an environment that can compile fragments on> > > the fly for more interactive development, but that's still on the way.> > > Besides the bean programs, it's all written in uxntal. I've documented> > > a quickstart guide, along with a spec for writing basic programs, and> > > the philosophy behind the language. All can be found in the project> > > readme:> > >> > > https://git.sr.ht/~kylep/beans> > >> > > So the ideal visual environment is still on the way, but for now> > > there's a high level language that enables constructing a graph of> > > nodes. Within each node is a set of i/o ports and handler code to> > > reactively process inputs, manage local memory, and emit new messages.> > >> > > This kind of message passing system feels similar to unix pipes, but> > > multidimensional. For me I've already felt the increased modularity> > > and reusability of code, and it has made data flow easier to reason> > > about and debug.> > >> > > I drew a mascot as a flower in an ol' can of beans, but I couldn't get> > > the flower right, I am not an artist :'( forgive me. If anyone has a> > > minute, I will gladly accept an improved flower.> > >> > > Devine -> > >> > > It was good to meet you briefly in person at strangeloop! I hope you> > > find this little project interesting, sorry it's likely> > > under-documented and still a bit cryptic.> > >> > > Kyle> > >