[akkartik]

Do you have any thoughts on how automated tests would work in this world? You mentioned email filters and responders in the OP, and I remember that everytime I start creating filters I quickly hit a point at which debugging or changing them becomes fraught.

[ibdknox]

We do! One neat thing about our architecture is that literally everything is just data and side-effects happen outside of the system itself. This means if you disconnect the "watchers" that do things like send email based on the presence of rows in the email table, you can safely do anything you want. This resolves a bunch of issues around testing for us.

The overall plan is to provide a bunch of really interesting generative testing facilities. For example, we can generate data based on your integrity constraints that tries to sneak values into the system that would break them. Being a live language also helps a lot here - you're inherently testing as you build things. We want to make it easy to just capture that while you're doing it.

[akkartik]

That resonates. I've been trying to teach programming by teaching testing first: http://akkartik.name/post/mu. My basic idea is that the hardest thing about programming is learning to consider all the different situations your program might be thrown in. Static code gets 'uncoiled' into many different dynamic 'traces' at runtime. I try to focus on that hard thing right from the start.

[darkmighty]

I have to ask: are you familiar with Blizzard's GUI script programming? It introduced me to programming and allowed 10 year old me, terrible at logic (and never before programmed!), to make games without reading much external references (it is completely self-explanatory).

For example, by reading those I think you get immediately an ideal of what it does:

http://i221.photobucket.com/albums/dd195/thehelper-andrewgos...

http://i221.photobucket.com/albums/dd195/thehelper-andrewgos...

You can build those from a predetermined set of Events (if you're advanced you can create custom events), so just by reading from a list of events/actions you an figure out how to do whatever you want. I think it's similar to Scratch but it does away with the clutter -- it's not exactly trying to make programming "visual", it's more just merging documentation and code, so you have all the building blocks needed to build any application right in from of you.

I think this kind of rethinking you're doing can truly change how programming is like for beginners or people who want to make specific tools/application (and not learn a plethora of things they'll never use)!

[joshuafcole]

Yep, I've had some good experiences with the old StarCraft editor. It had a surprisingly good first user experience because it was immediately useful (terrain editing was very intuitive, and stock games could be played on custom maps) and had a gentle learning curve (new game features could be added in progressively to the base game).

One of our past examples worked on a similar principle to the SC trigger system [1] but we unfortunately found that it didn't scale as well to larger systems. While it was very easy to write in, it was hard for a stranger to read and intuit the implied data flow. We've had a lot of fun experimenting with different query editors, and I hope to find the time soon to do a more in depth write up on our research.

[1] https://camo.githubusercontent.com/f24714bf6429fa21ca91e4987...