
Show HN: YinYang, a usable live programming language - seanmcdirmid
http://research.microsoft.com/en-us/people/smcdirm/liveprogramming.aspx?iedz00
======
keyle
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.

This is cool though.

~~~
seanmcdirmid
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!

[1]
[http://research.microsoft.com/apps/pubs/default.aspx?id=1793...](http://research.microsoft.com/apps/pubs/default.aspx?id=179365)

~~~
keyle
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.

~~~
seanmcdirmid
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).

~~~
keyle
Glad we're on the same page. I think.

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.

~~~
seanmcdirmid
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].

[1] [http://research.microsoft.com/en-
us/projects/koka/](http://research.microsoft.com/en-us/projects/koka/)

[2]
[http://www.rise4fun.com/koka/tutorial](http://www.rise4fun.com/koka/tutorial)

------
untothebreach
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](http://lambda-the-
ultimate.org/node/4660)

~~~
seanmcdirmid
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.

~~~
untothebreach
Can't wait!

------
teyc
I've been looking at whether it's possible to implement Edit and Continue in
javascript. Your Glitch paper is very interesting.

~~~
seanmcdirmid
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.

------
Mikeb85
Here's a live code editor in Javascript. It's pretty cool...

[http://www.mrdoob.com/projects/htmleditor/](http://www.mrdoob.com/projects/htmleditor/)

------
taliesinb
Very cool. I'm hoping we can do similar things in the Wolfram Language.

------
philippeback
Well, looks like Pharo can do all of this for a while. [http://pharo-
project.org](http://pharo-project.org)

Type inference is an object of interest:
[http://gsoc2013.esug.org/projects/type-inference-
tools](http://gsoc2013.esug.org/projects/type-inference-tools) and here are
some results :
[http://concretetypeinference.blogspot.be](http://concretetypeinference.blogspot.be)

The posts are pretty nice to read.

~~~
seanmcdirmid
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.

------
granttimmerman
All these live demo applications (like
[http://livecoding.io/](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.

~~~
seanmcdirmid
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.

~~~
adamwk
Isn't this already achieved with a REPL? I mean other than GUI programming,
which something like this would be useful in the same spirit as a REPL.

~~~
seanmcdirmid
A REPL provides no code editing experience, you can at best just add code
progressively one line at time and advance (never rewind) execution.

~~~
fsck--off
I'm not quite sure what you mean. By "rewind execution" do you mean something
similar to Interlisp's "undo" function?

[http://www.softwarepreservation.org/projects/LISP/interlisp-...](http://www.softwarepreservation.org/projects/LISP/interlisp-d/3100186-Interlisp_Oct83.pdf)

~~~
seanmcdirmid
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.

------
joshribakoff
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.

~~~
seanmcdirmid
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?).

~~~
joshribakoff
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.

~~~
seanmcdirmid
Lovely but nothing very new. Does your IDE also allows you to poke around
local variables and the call stack while changing code in realtime?

------
integricho
This very much reminds me of Chris Granger's LightTable.

~~~
seanmcdirmid
It's definitely mentioned in the essay.

------
lcnmrn
I think this can be done as “a preview mode” in Python too.

~~~
_random_
With static type inference?

------
theboywho
The Scala IDE already does this.

~~~
seanmcdirmid
I wrote the original version of Test Pad for the Scala IDE; and no it doesn't.

------
Dewie
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.

