Loving that concept of the @ symbol. Sadly I don't see that scaling to enterprise large applications, where you have little clues about what's calling your library with what values.
As opposed to telling us that 2 + 2 will indeed produce 4, research money should be spent on separating pure code from state, I/O, etc. in languages like C#. That would be a huge advancement forward and cutting down the cost of bugs around the globe.
My previous live programming language [1] focused on separating out state, but it was not very scalable from an expressiveness standpoint. I'm of the opinion today that state exists and we should deal with it in place as opposed to trying to factor it out. The approach I'm working on (with a programming model I call Glitch) seems very promising, but the proof will have to be in the pudding. Stay tuned!
Thanks for your response. And I'm agreeing with you that state should be dealt with and not pushed out. I'm not advocating some harsher functional programming designs.
What I meant was there needs to be constructs that guarantees that "this is going to be pure" and that "state can live here, not there".
D-lang has a start I believe, with a "pure" keyword.
I find that, as an enterprise developer working on large code base, most of my time is chasing bugs of silly null pointer exceptions and objects that are in unexpected state causing issues. Separating the grok of the code from the state eventually helps. And sadly there is little research spent in there, which is direct value to developers.
Increasing the quantity of pure code (and enforcing it) per class will reduce costly bugs.
I am amazed with what you can do though. I've had my shot at designing a language and miserably failed multiple times... But this why I'm raving about it... You may be able to solve this global problem that I never could.
Even if we factor state into a monad and/or pass it in as a parameter, imperative updates still exist and must be dealt with! Try writing a type checker or even a parser with pure functions, and you get to a point where you are passing in your state from the top anyways (either as a monad or explicitly). Many interesting computations simply aren't pure.
> Separating the grok of the code from the state eventually helps. And sadly there is little research spent in there, which is direct value to developers.
I would argue that there is plenty of research in this direction in the functional programming community. This is what monads seem to be about, at any rate. The problem is that developers don't want to adopt these solutions because they are way too inconvenient or even unworkable from an expressiveness standpoint. So maybe we should look for a better way to temper state without throwing it into a ghetto...
> I am amazed with what you can do though. I've had my shot at designing a language and miserably failed multiple times... But this why I'm raving about it... You may be able to solve this global problem that I never could.
We will see; I went through my purity stage relatively early and am being extremely pragmatic these days. The secret sauce in my current approach is to have state, but limit how it can be updated: operations in Glitch must be undoable and commutatively ordered, which are huge restrictions but the result is very compelling (re-execution is possible AND re-execution can occur in arbitrary orders).
So state would be dealt with in a similar approach than the command pattern?
Sounds exciting.
I guess where I come from is the scare when a pure function gets littered with impurity much later on, and all we have to warn us is a unit test. No matter how big the comment is above the method, nothing stops a developer from sticking a global variable in it, and it's out the window.
This forces code reviews to be lengthy, etc. If on the other hand we had a @pure section and @everything_else section, I feel this would make things easier to reason about... We could also measure the % of pure vs non-pure code, as code quality. All of this in an object oriented language of course. I'm no fan of Haskell.
You might want to check out Koka [1], which includes an effect system to separate pure and effectful computation. I believe there is also a demo of it online [2].
What you mean is a non-deterministic programming language?
Similar to SICP 4.3? But different and expanded?
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-28.html...
Code where expressions has success and failure paths, where the failure simply is reversal?
I'm not sure if the initial use of this is large enterprise applications. It's a fairly unexplored paradigm it'll be interesting to see where this goes with a company like Microsoft exploring it.
I am glad to see this finally coming to fruition, I've been interested in this guy's work ever since this post about the type inference engine: http://lambda-the-ultimate.org/node/4660
I'm going to talk more about type inference soon (before the end of this year anyways), as this is the other cool thing about YinYang! You can see a bit of this type inference going on in the video clips, but it is not closed to finished yet.
Any language can support edit and continue, its more a matter of your debugger than programming model. Live programming goes beyond edit and continue in that your program execution is repaired retroactively with respect to edits made.
I am planning to port Glitch and my entire language stack over to Javascript eventually, if just to provide someway of releasing a prototype to the public. Right now, everything is done in C#/WPF, which is an awesome environment, but means Windows only.
Smalltalk only supports fix and continue (changing code while programming is running), but you still have to manually re-execute your changed code unless you are editing objects directly (in which case, those changes must be saved in an image). Did the Pharo folks add anything more responsive over this?
Comparisons to Smalltalk as well as REPLs are discussed in the essay.
All these live demo applications (like http://livecoding.io/) are interesting and may be useful for teaching the basics of a language, but I don't see them being used at anything bigger than small demos.
A real innovation would be finding a practical use for this type of technology (or a spin of it) in large-scale projects.
I basically agree, but live programming is not live coding. Live coding is about programming while the program is actively running (we can argue if performance is involved in live coding or not). Live programming, on the other hand, is about creating a live feedback loop between the programmer and artifact being programmed with the aim of making development easier.
Scalability will take some time to achieve, but I think we will get there with some hard work.
Sort of. But if my reading of the manual is correct, interlisp only allows for manual undo and replay; YinYang traces dependencies and repairs program executions automatically after every keystroke. Not sure what is limiting the interlisp environment from doing the same thing.
REPLs allow for interaction with programs (running processes), not code. With direct manipulation, you get a very different kind of liveness: sure you can change the program but their is no repeatable record of doing so (unless Smalltalk style images are used). For code, you just get feedback on the line you just entered and executed.
Live programming allows one to change code to change fate; the running program isn't so much changed as remade, and is completely repeatable.
I think you're mixing up different kinds of feedback, then..
In a REPL, execution feedback can be continuous, not only line-by-line as you said earlier.
If we're talking about 'code feedback', in general yes you do just get feedback on the line you entered.
There's complexity here though. I think of any editor where you execute lines or blocks of code at a time as a REPL, mainly because they're often implemented by piping said blocks to a commandline..
I'd include IXI Lang in this category, and it certainly does have code feedback. You might 'execute' one line, which could set a process going which periodically changes another line of code (and therefore its associated running process).
Perhaps at this point IXI Lang stops being a REPL, and starts just being a live programming language, but I'm not sure at what point that happens. Or maybe REPL is just an outdated term, as they do tend to do a lot more than a linear read-eval-print loop.
> There's complexity here though. I think of any editor where you execute lines or blocks of code at a time as a REPL, mainly because they're often implemented by piping said blocks to a commandline..
This is the crux of a REPL: what would you execute a line of code in the editor though? What does it mean to execute a line of code in a method? Or even an entire method? Development via REPL requires a certain program structure and an aversion away from abstraction (at least in code being developed), and even then the programmer must be manually involved in decided what to re-execute, performing dependency tracking in their head. Smalltalk too actually, where "liveness" often comes from manipulating objects directly.
> Perhaps at this point IXI Lang stops being a REPL, and starts just being a live programming language, but I'm not sure at what point that happens. Or maybe REPL is just an outdated term, as they do tend to do a lot more than a linear read-eval-print loop.
Ya, the concept of a REPL is kind of outdated, but its the term people prefer to start from (e.g. LightTable has an Insta-repl) if they are coming from LISP. I've even heard Smalltalk environments described as a REPL before, even though the metaphors that they depend on are completely different (there is an explicit line-based re-eval though...so maybe they are similar?).
Yes and good point about abstraction - I was surprised when Mark Guzdial noted that live coders don't do abstraction, but I think that's generally true during live coded music performance. I'd like to work on making abstraction more accessible to live coders, and moving away from REPLs should help.
I think we abstract (generalize) much slower than we can usually react with functionality. In machine learning, we actually find that abstracting IS comparable to learning,
Perhaps practicing is a form of abstraction; you practice something now to perform it later...the prepared parts of an otherwise improvised performance?
Yes I agree with your implication that improvised performance requires preparation, and interesting to think of this as abstraction. I think of it as developing a personal 'style', which I suppose is abstract.
I do like to prepare for a performance by making a new abstraction (i.e. a new combinator) but then learn how to use it during a performance. So yes, I make new abstractions in preparation offline, but I'm still working out what that abstraction 'means' online.
I think listening to music is more akin to abstraction in machine learning, as Whitehead puts it, "Art is the imposing of a pattern on experience, and our aesthetic enjoyment is recognition of the pattern." [1]
When I'm performing I think I'm listening to my own music in this machine learning sense, recognising musical abstractions which might not be explicit in the code which generates it.
Also if it's group improvisation there's learning from each other..
[1] I use this quote out a lot, but ironically it's taken from a passage that is protesting against soundbites.
Right. They are completely orthogonal, and you can have one without the other. This isn't about nitpicking, this is about asserting a clear definition and bring some clarity to this new area, which is just going to flounder if we keep calling orthogonal topics as the same.
I think you're complaining about someone calling a live programming environment livecoding.io. I think that's nitpicking.
The feedback loops are not orthogonal, because programming a running process is rather difficult if not impossible without that programmer feedback loop. The program feedback loop exists within the process feedback loop. A change in programming feedback is highly likely to profoundly affect the wider feedback loop with the running process, and perhaps vice-versa.
In this case livecoding.io only seems to be for coding fixed media. Is the program actively running or not? In terms of UX it doesn't really matter either way, so our live coding/live programming distinction is pretty much irrelevant.
If it was possible to do animation in livecoding.io then it would be a clearer case of live coding by our definition, but obviously that wouldn't stop it from also being a live programming environment.
The program feedback loop doesn't need to exist in the process feedback loop...often they don't, and even in live programming the program is not running in the production real time sense.
>In this case livecoding.io only seems to be for coding fixed media. Is the program actively running or not? In terms of UX it doesn't really matter either way, so our live coding/live programming distinction is pretty much irrelevant.
Agreed. Such simple systems (like khan academy) tend to be single trick ponies around live refresh. One mechanism doesn't make a story, and so it doesn't even make sense to put it in a story bucket.
>If it was possible to do animation in livecoding.io then it would be a clearer case of live coding by our definition, but obviously that wouldn't stop it from also being a live programming environment.
Agreed, they can overlap, but how animation was dealt with could lead down either path to the exclusion of the other (does it support improvisation or development). From me on LtU:
> In that sense, I'm not working on a new way of programming, just speeding up the feedback loop of our current programming practice. If some new way of cybernetic programming eventually emerges from the faster feedback (unexpected benefits of improved tooling happen all the time), maybe live coding will make more sense to me. Maybe that is the key difference of our approaches.
Mechanism is perhaps less relevant than the experience trying to be achieved. In this essay, I described a live programming "make development better" experience. Someone could probably take my videos and describe them with a very different improvised live coding story on top of them also, focusing on activities I don't understand and definitely did not design for, but since the mechanisms involved overlap...
This is why terms are so powerful: the use of "live coding", if it stands for something, is a brand that allows us to quickly decide what we are going to see and experience when we click on the link. It will also elicit strong denial from those who don't want to be in that brand, since their problem spaces and approaches are very different.
"Live coding is about programming while the program is actively running"
"Live programming [Hancock03] promises for much more fluid feedback between the programmer and a program that is executing while it is being edited."
These statements are connected.
Yes software engineering is a different activity from making music. But, if I want to address live coding of music in particular I just add a word or two. I'm often interested in cross-disciplinary discussion though.
We've been around this a couple of times though, and I think can probably predict each other's points by now. :)
As I've come to understand it, live coding is about programming while the program is actively running, changing the program's flow and behavior in real time as part of a cybernetic melding between programmer and program. Live programming is about better feedback between the programmer and program, which also involves execution, but the program is undergoing development by the alone programmer in a dark room somewhere and is not actively being used, program execution is just to collect data to present to the programmer so they can develop the program!
Whereas live coding has been presented as a new experience that transcends programming as we know it, live programming is just a new twist and substantial incremental improvement on the old programming experience, boring and pragmatic. In much the same way, Victor's Learnable Programming provides similar feedback to improve how programming is taught, and not to revolutionize what programming is.
I used to read a lot of Shadowrun in High School; the decking experience was about hacking through heavily secured computer systems by creating and customizing programs in real time. But when I started doing this, programming turned out to be more of a cerebral experience where real-time problem solving is neither necessary nor (yet) very effective. I'm quite OK with improving on that experience.
> We've been around this a couple of times though, and I think can probably predict each other's points by now. :)
Surely. We need to have a formal debate sometime if we ever attend the same conference.
He says in that same note that he was goaded into writing his "learnable programming" essay by people relating his work with live coding. It seems that for him, discussing improving programming tools was a diversion from his long term aims of uncovering a new way of thinking with computers. His disassociation from live coding seems to be a direct criticism of Khan Academy's approach but maybe he has a more general criticism of live coding... In any case, I wouldn't claim him for my cause either.
I wouldn't dare to claim Victor for my cause, and I'm only reflecting on what he said in his learnable programming essay.
> It seems that for him, discussing improving programming tools was a diversion from his long term aims of uncovering a new way of thinking with computers. His disassociation from live coding seems to be a direct criticism of Khan Academy's approach but maybe he has a more general criticism of live coding...
I don't think this is indicated in his essay. i.e.
> Programming is a way of thinking, not a rote skill. Learning about "for" loops is not learning to program, any more than learning about pencils is learning to draw. ... Thus, the goals of a programming system should be: (1) to support and encourage powerful ways of thinking; (2) to enable programmers to see and understand the execution of their programs
He very much is concerned with programming not as a new way of thinking, but as an existing way of thinking. The examples in his essays then go on to elaborate on programming with better tools to understand execution; it is not a re-invention in any sense. We could try to interpret this passage:
> We change programming. We turn it into something that's understandable by people.
I think this means: we make programming into something that's understandable by people. Comprehensible. Is it change, or is it augmentation? His words imply the former, but his actions (features) imply the latter. Finally we get to:
> Likewise, a well-designed system is not simply a bag of features. A good system is designed to encourage particular ways of thinking, with all features carefully and cohesively designed around that purpose. This essay will present many features! The trick is to see through them -- to see the underlying design principles that they represent, and understand how these principles enable the programmer to think.
Yep, it is about design. He is just scratching the surface of a field I refer to as PXD (programmer experience design) :). The essay then goes onto to present design principles useful in helping make programming more understandable, and examples of those principles at work through various demoed features. Some of those features include some form of liveness; but many don't.
Yes his learnable programming is about improving existing programming tools, but he treats that as a diversion, his other stuff seems quite different.
His recent talk calls for a break from established norms and a return to the free thinking of the early days of computer science. His work combining geometry with syntax (which is also an interest of mine) follows on from that early work, it's as though he's treating the last few decades of software engineering as a diversion.
To me it's quite clear that Victor is calling for something more akin to augmenting and extending human thought, maybe your 'cybernetic melding'. He argues that this software will be used in ways which we cannot yet understand -- he thinks it'll be future generations who develop use and understanding for such technology, he's just chipping away at the possibilities.
But maybe your more approach is more optimistic in this regard, in that you're finding ways that could improve programmers' lives now.
I think my approach is optimistic too, in developing technology through use, taking communities of practice as a starting point, not an end goal.
> He argues that this software will be used in ways which we cannot yet understand
I feel the same way.
> But maybe your more approach is more optimistic in this regard, in that you're finding ways that could improve programmers' lives now.
I'm actually pessimistic that we have much time to innovate. I see programming as a viable profession only for at most another 20 years; by then speech dialogue based systems (aka AIs) are advanced enough to take over on what were programming these tasks before.
I don't see a need for pessimism there. If speech is text plus prosody, then I see adding a prosodic channel to the programming interface as augmenting/enriching programming languages, not replacing them. I also don't think speech is 'special' in terms of intelligence (e.g. Deaf people are just as intelligent), so enriching text could just as easily come in a different form of imagery (prosody being a form of mental imagery) such as drawing. And that is the area that Victor is working in.
This is sort of possible with any language, in the sense of unit testing. You can even setup a file watcher to run your unit tests automatically whenever the code changes, and some IDEs save the file while being edited, only when the syntax is correct. In effect, you get real time testing of your code that tests the logic.
Continuous execution and testing is useful, but its just not good enough. You want to also provide programmers with a decent debugging experience as well, which doesn't happen in a continuous testing framework (something is broken, but what?).
Unit tests each have an assertion message that states what's wrong, and the frameworks should each print the line # & stack trace. My IDE parses that output & highlights the errors in my code too.
Something that would be cool is a purely functional programming language with an interpreter and editor that can give feedback on the execution of the code as rewrites. If "purely" starts to ring alarm bells for you, I guess you could let this interactive editing be 'purely functional', with the output of the editor as side effects, while having a separate mode of execution that is compiled (you might want to actually compile the code instead of running it interpreted, anyway) which is truly pure.
As opposed to telling us that 2 + 2 will indeed produce 4, research money should be spent on separating pure code from state, I/O, etc. in languages like C#. That would be a huge advancement forward and cutting down the cost of bugs around the globe.
This is cool though.