Praxis – A live coding environment based on Lua, Lisp and Forth

https://github.com/createuniverses/praxis

63 21 12 years ago

Is a language environment really live if it does not support interaction or encapsulated state (inside rather than outside of the render loop)? Is it really live if you have to manually refresh your code?

Well, I guess it does fit the requirements of live coding.

createuniverses5• 12 years ago

supporting interaction or encapsulated state

I don't know what you mean. Could you give an example of this? What would you like to be able to do?

seanmcdirmid7• 12 years ago

Your render loop looks like:

    while true:
      renderP()

Now, renderP will get executed afresh each time. Assuming no static data, if you want any state at all it must be global to the loop; e.g.

    var state = initValue
    while true:
      renderP(ref state)

Immediate-mode UIs suffer from the same constraint, and really, the author is getting most of their liveness by being immediate.

davvid• 12 years ago

If you're interested in this then you should definitely checkout extempore:

https://github.com/digego/extempore

http://benswift.me/extempore-docs/index.html

pmoriarty• 12 years ago

Also see:

http://www.pawfal.org/fluxus/

sklogic2• 12 years ago

So far all of the live coding demos were about graphics. I wonder if it's possible to do something similar with something of a much less interactive nature - say, number crunching, compilers, linkers, etc.

createuniverses5• 12 years ago

The whole thing is a repl with a graphical and audio engine at your disposal to use as you see fit. As well as writing your program iteratively in the "socratic" repl style, you are free to fluidly create whatever visualizations you wish along the way to help you. As well as this, if you split the process you have implemented into frames (a simple way is with coroutines or closures) you can make whatever visualization you prefer of your number crunching. For example, throw in some yield() calls in your program and every update() do a coroutine.resume(). In render() visualize the state of your program how you wish. The great thing about this is, as you change your program, the effect of your change will be reflected in what is rendered.

sklogic2• 12 years ago

Interesting, it's something to think on. Creating such visualisations manually may be prohibitively complicated, but I can imagine some cases where they can be derived automatically (e.g., for compiler passes, an example IR can be displayed before and after).

CyberDildonics• 12 years ago

I absolutely think so.

My ideal environment would have the ability to pause at a certain point, saving the state. Then I want to run to a another point (maybe only a few lines to a couple dozen lines down) and see the variable values and results in between.

Basically I want to live code with some defined input to section off parts of the program and still be able to iterate quickly by seeing results every time what I am typing will compile.

I also want to be able to visualize more data than just single values. I want to be able to see results of flat arrays, and write custom visualizers for more complex data structures. I have actually done a lot in this area, essentially by having a window in a separate thread that I can pass closures to (that run openGL functions on their data to draw it). This works incredibly well to let you see your software run. I don't know how I would have been able to write and debug some very difficult programs without it.

3838• 12 years ago

praxis makes me think of the dutch diy store chain - if you go to one in amsterdam they play reggae and you can buy a bhudda for your garden (or balcony more likely)

verytrivial2• 12 years ago

More often than not, these interactive / interpreted environments feel like Smalltalk by installment.

createuniverses5• 12 years ago

I certainly had Smalltalk and Lisp Machine environments in mind when I made this, the central idea being to be able to query and manipulate every part of the system while its running, to be able to fix faults and continue.

seanmcdirmid7• 12 years ago

This is actually a law:

Whenever someone brings up any kind of interactive programming environment, no matter how much it does not resembles Smalltalk or Lisp, someone will always say it completely resembles Smalltalk or Lisp with no significant improvement. We call it the "smug smalltalk/lisp weenie" syndrome.

BTW, Smalltalk supports hotswapping without the liveness of course. There is nothing in smalltalk that allows the code to re-execute in its proper context without execution coming back to the code in a refresh loop setup by the user.

verytrivial2• 12 years ago

No smugness intended, sorry. I only ever toyed with it. I am genuinely curious why e.g. Squeak never caught on with the artsy types considering it has many but by no means all of the interactivty and feedback that is desirable in these spaces. And again Squeak at least tried to position itself as a media-rich system. Perhaps performance always has primacy. And I don't seem to follow your point regarding liveness -- a language that supports many aspects of live programming but requires a supporting loop is of no value? That does seem like a very strong criticism.

Praxis – A live coding environment based on Lua, Lisp and Forth

Related Stories