When I say plaintext, I mean like a .c file--a bag of bytes that may or may not parse into the AST you intend. Modern editors dress plaintext up with syntax highlighting, auto-complete, folding, and such--the code has a veneer of structure--but the basic representation remains plaintext. (And for good reason... plaintext is easy to edit with existing editors, tractable, easy to parse, somewhat easy to tool, moderately easy to version control, and hard but possible to transform automatically. But I believe plaintext is only a local maxima in code representation. We just don't have a good enough editor for code ASTs (yet)).

Now in the Wolfram Language REPL they have some rich input capabilities like http://reference.wolfram.com/language/example/BooleanOperati... . I suspect these are still underpinned by plaintext dumps internally, though, judging by http://reference.wolfram.com/language/tutorial/VariablesInPu... .

I should have said that they've gotten farther than anyone else so far, perhaps, but I haven't tried WL yet, so who knows?

Yeah, with respect, I think you're being duped. What you're seeing is plain text being drawn as images, making you think the images are input. You only have to click the code to see the plain text (and its not pretty).

Not only have they not gone farther than others, I cant find a single instance of anything in WL that's not plainly plain text. They have interesting output, not particularly interesting input.

Damn, that's too bad. Oh well. It's a closed source dead end anyway.

Time to dust off the old side project.

I think the great thing here is the output; better than anything we have in open source so far. I takes a very large amount of effort to make something like that for your language of choice. For the input I agree; it's text and not very nice.

> I suspect these are still underpinned by plaintext dumps internally, though, judging by http://reference.wolfram.com/language/tutorial/VariablesInPu.... .

You suspect wrong.