We have ignition: an actual implementation of an actual language. Toy-like in the extreme, but it can run the sorts of simple examples I have been discussing the last few years. I think I can take it all the way to a prototype application framework. This is huge progress.
For me, the breakthrough has been finding ways to avoid solving problems. I was paralyzed for years by deep issues in the semantics of effects. I came to realize that settling these issues required first getting getting practical experience with this new style of programming. A chicken-and-egg dillema. The solution was to defer everything I could and go with the simplest thing that could possibly work. So for example I have totally punted on types, and my effect system is computed on the fly at run-time. A compile-time effect system will be essential eventually, and I can’t yet guarantee that it is actually possible, but I don’t need it right now to build a working prototype.
Java has worked out great. I can code in it practically without thinking, which is a good thing, because the problem I am solving already stretches my old brain past its limits. Likewise with language processing tools – I considered Stratego and Antlr, but ended up with parboiled . It is a really nicely done lightweight parsing library, with great Java support through bytecode rewriting magic. The compiler probably would have been a third the size in Scala, but at under a thousand lines it doesn’t matter.
I am going to keep coding until I can demo an actual application. I didn’t submit an Onward paper because I am burnt out on papers talking about what I want to do in the future. My next paper will be about what I have already done. I will probably submit a demo to OOPSLA. I am doing a talk at the beginning of June, and I’ll post the slides here.
Awesome. Congratulations. Give me actuality over possibility any day 🙂
Great news! I feared that you gave up or got stuck. Ignition… and we have a lift-off!
Can’t wait for you to release some source! please do so soon.
Wow! That is exciting news. Looking forward to the demo!!
Kind of reminds me of a comment I wrote here a few years back: http://alarmingdevelopment.org/?p=38#comment-1418
“Maybe do a study. I’m sure you must have a bunch of applications written in Subtext by now. Compare those to what another language would give you. Then convince the reader that in Subtext it’s harder to make mistakes, easier to do the right thing, you write less code, it’s easier to test, easier to maintain etc.
AFAICT the visual paradigm langauges so far failed (among other reasons) because they would not scale past a few trivial functions. One gets tired of drawing boxes for each if statement pretty quickly and it makes you slower rather than faster. I remember a recent OOPSLA (2003 I think) demo that had exactly that problem.
To have a hope of convincing people you need arguments. You need examples, real ones and lots of them.”
and another old comment (from an email exchange we had in 2006)
“I think you really should write a few apps. Otherwise you risk solving problems that are not that important. This should also directly help you to get the “basic paradigm sorted out”. The most elegant language and toolset in the world would be worthless if it can be used to solve only the most trivial problems.
It’s like in type systems research – people present all sorts of type systems. But most often than not, they do not tell you what kind of problems those things solve, why those problems are important and why they are hard to solve with exeisting tools. Typically they do not even have a type checker for the type system, nor any experience using it (converting a bunch of existing apps is a start). They present a few toy examples and that’s it. That is totally unconvincing. For any particular type system, there are examples for which it works very well. But typically, it’d fail for vast number of others – including most real programs.
I think you want Subtext to avoid such traps.”
OK Adam, you told me so. 🙂
If things are already in a working state, would you consider doing the development out in the open, on GitHub? I’m sure there are a lot of us who would love to follow along.
Well “working state” is such a subjective term :-). But yes, I do plan to be fully transparent, maybe once I have a REPL and a few other features done.
Hey, congrats on the well-deserved successes of CoffeeScript. You have good taste.
Jonathan
Hi Jonathan, have you seen this? http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf
In the paper it says something which reminds me of your paper.
“For an answer on the status quo in production systems,
we quote an Adobe presentation from 2008 [43]:
1/3 of the code in Adobe’s desktop applications is devoted to event handling logic
1/2 of the bugs reported during a product cycle exist in
this code”
In your paper
“An analysis[32] of Adobe’s desktop applications indi-
cated that event handling logic comprised a third of the code
and contained half of the reported bugs.
The dif?culties of event coordination are just one of the
more painful symptoms of the disease of unconstrained
global side effects.”
MIT-CSAIL-TR-2009-024 Coherent Reaction, Jonathan Edwards
Clearly you have both identified a common problem.
Yes, thanks Phillip. We are both quoting Sean Parent, and we are both talking about the same sorts of problems. Maier is taking the popular and practical approach of adding a library onto an existing imperative language. There is only so much you can do that way. It will be interesting to see if this evolves into a standard library feature of Scala. Too bad he doesn’t cite LuaGravity Reactors, or John Field’s Reactors.
Hope to see the code soon?
Yes, for some value of soon :-). Are you interested in reading the code or playing with the language?
Interesting stuff. I wonder if you might start by thinking about how to go about writing the visual editor for your language in your language? Taking whatever shortcuts are necessary along the way, of course. But that’s an obvious UI programming problem which might offer good feedback.
To stir the bucket, I’ll counter Adam’s quotes with one from a retrospective on Self I was reading this morning (http://labs.oracle.com/self/papers/programming-as-experience.html section 2.1): “We have learned the hard way that smaller is better and that examples can be deceptive. Early in the evolution of Self we made three mistakes…. Each was motivated by a compelling example…. But each feature also caused us no end of confusion…. We now believe that when features, rules, or elaborations are motivated by particular examples, it is a good bet that their addition will be a mistake.”
The discussion of visual programming in section 3.4 of that paper is rather interesting. I wonder who’s done the best work on the “multiple views” issue they describe? ( I’m tinkering with a project to give a “traditional” language a more tangible expression: http://cscott.net/Projects/TurtleScript/ but I’ve found myself reimplementing a GUI toolkit, which had led me to visit Trellis/Coherence-like ways to reimagine the traditional event-driven architecture…)
Thanks for reminding me about that paper Scott.
I would rephrase the admonition about examples as not expecting that your new language should make everything easier. Some things that used to be easy will get harder, and trying to avoid that just distorts the language. Every language has its own set of pet examples that make it look good.
I’ll have to remember that quote the next time Dave Ungar objects to my non-textual programming ideas.
Hi John,
I’m glad I stumbled upon your website, I had no idea there was a community devoted to creating a non-textual language the way I am.
I have a few questions however about the fundamentals behind this theory; for we have to ask ourselves; ‘what are we building?’ and ‘why are we building it?’.
First: Why are we building it?
I can’t answer for everyone, but my ultimate goal is to be able to create machine logic, in the same way I play guitar. No, not through strings and notes, but the essential idea behind playing music: it as an expression of yourself, NOT carefully crafted by your conscious mind, but very creativly crafted by your subconscious.
The difference here is the feeling of flow. Notes flow out of me when I’m playing a song or melody (melody as in a key of notes, not a predefined sing), but come out slow and irregular when writing music. It’s in this way we create code: we write it, we don’t play it. We should be playing it.
How do we ‘play’ logic you ask? The same way you play a guitar, or a video game, or a sport: Muscle Memory.
Isn’t a keyboard already muscle memory? Yes, yes it is. It’s muscle memory for English however, not logic. You can type English very fast on a keyboard using muscle memory.
So what are we building? A keyboard devoted to logic. This gets complicated because there are many more then 26 possible logic operations. The solution is to break everything down into a series of dynamic buttons. Interestingly enough, this coincides with all the virtual keyboards on touch screens right now, including this iPad I’m typing on. The keys essentially change beneath your fingers based on a breadcrumb trail through a tree of decisions.
Now were not dealing with text, were coding by building specific objects out of the set of all possible objects, and those objects represent and control parse trees of a traditional language. You can write a compiler to display those however you want. As it would appear in text, using recursive diagrams, or as clouds floating in the sky should you fancy. Since were only making parse trees you can also edit the parse trees of any individual traditional language, but more importantly you can edit multiple languages parse trees at the same time. This is why it’s built for the web.
So you see then, the next logical step in computing is an abstraction away from all languages simultaneously, rather then trying to create a new one.
I guess my questions here are: can you prove this hypothesis wrong? Or find holes in it? How many similarities does it share with your work/ideas? I’m interested to why you did not take this approach, and if you will plan to?
I am currently in the process of building such an editor for the web, as I detailed to you in an e-mail. I’ve had great success in muscle learning, and I can code quite fast, it’s missing the visual representation though right now it displays as regular code. I’m scouring the web for inspiration, perhaps you might have some suggestions?
I look forward to reading your papers in the coming weeks.
Regards,
Greg
Greg, check out http://lambda-the-ultimate.org/node/4257
Cool stuff Sean. I think some video might help explain it, like you had in your Superglue paper.
Thanks for the link Sean, it looks like a great resource, I’ll be sure to bookmark it. Actually, it solved my problem: I should represent the code as a tree. Branches are wherever there is an assertion, and functions are included normally but can be expanded inline to include their source (while changing the parameter names to reflect the variables your passing). The tree is dynamically created using each block (and subsequently code between blocks) as visual identifiers with separation.
Minimalistic and Sweet.
That will take some time to write the algorithms to display in the DOM (assuming a canvas overlay to programmaticly draw lines), and an arithmetic grid system that keeps only theoretical positions such that it can remove elements from the DOM as they are moved from their visable range (for obvious speed reasons). This should probably just be more time consuming then anything, the logic is all simplistic.
I’ll try and get a video out when this is done, hopefully it will help you understand. I’d try and explain it more, but I’m not sure that I can, I think its probably something you’d have to use to understand.
Greg, easier said than done. Structure editors are more than 30 years old and they haven’t gone anywhere (start by reading work on the Cornell Synthesizer if you haven’t already). To build a graphical language…that is efficient to use as well as expressive, requires really twisting your mind in knots.
Jonathan, I will when I have time. I’m not yet satisfied enough with the experience and the way constructs are laid out, so I’m doing another prototype. We are aiming for a release this year, though we won’t have decent tablets to run on until…Windows 8.
Greg, you have clearly been thinking hard about how to improve programming. Keep at it. The hardest part is communicating your intuitions and ideas to others. I think I get generally what you are saying, but the details are unclear to me. I suggest you make a short video showing what it is like to program in your approach. Good luck in your efforts.
Dear John,
I agree 100% with you about the state of the development tools and the way you try to tackle it seems very promising. I am eager to see your first results in action, as i found subtext already very impressive. Please release early. Meanwhile, which of your paper do you recommend to read to prepare for an in depth comprehension of your new project(s) ?