Apple Dylan IDE (2014)

In case people don't know, this is often referred to as a "projectional editor" and the paradigm is also known as "Intentional Programming" in the sense that the programming environment helps capture the intent of the authors.

Popularised (if we can call it popular!) by Charles Simonyi of Microsoft's fame who created the company called Intentional Software that was recently purchased by Microsoft.

There was interesting editor called Isomorf that demonstrates the benefits of a non-text-based editor.

(site is down https://isomorf.io/) (youtube demo https://www.youtube.com/watch?v=awDVuZQQWqQ)

I would really like to see something like this take off.

I firmly believe we can only unlock the next generation of software engineering by breaking free from plaintext. Think about it, how many more ASCII symbols can we mangle together to create meaning and context?

A structural editor takes all of that away. Suddenly syntax becomes a choice just like the colour theme of your editor.

Plaintext programming puts us into a fight with the computers because on one hand we need to keep the syntax parsable and on one hand humans need to read and write it.

It's a huge conflict of interest. You want to provide information to the compiler now the syntax becomes hard and complicated (rough example: Java). You want to keep the syntax human-friendly now the program becomes weak from the compiler's point of view (rough example: Python).

Our editors need to be context aware so they can hide/show relevant information and to encourage the people to provide as much information about the context/domain as possible.

If you look around you see we have been doing a lot of this stuff in the past decades but for some reason we just half-ass it by baking stuff on top of plaintext.

For example embedding documentation or even unit tests (python "doctests") in comment blocks in ad-hoc languages.

Or we embed naming conventions and so on to relate concepts with each other.

For example a "User.js" file and "User.spec.js" file for a test.

If we kept information in a structured manner suddenly so many of our problems would go away.

For example we will get structured version control. No need to have something like git tracking lines in files.

We will get unit testing that is always correctly tied to its relevant components.

We will get documentation that is structurally accurate. The editor could switch between programming and "documentation" mode. But the documentation would be a first-class object of the program not just some text that is shoved into it somewhere.

We will get much smarter re-factoring.

We will get much better compatibility across versions. Because there's no syntax to worry about breaking from a textual perspective. Because the program becomes a semantic tree and older programs can be "transformed" to fix them or make them compatible or something similar.

Because we are text-free the environment can encourage the programmer to provide a lot more information because it can get folded/hidden/etc.

The "units" will all have unique identifiers so confusion in naming and so on will be significantly reduced.

Perhaps you could create and publish modules/units in some central repository then use them in your projects. Kind of like NPM for example but a lot more structured.

So you could import a bunch of "units"/functions from someone else's catalogue.

Because everything could have metadata attached to it you could imagine for example "security advisories" could be attached to certain units such as a function and published.

The environment would know exactly in which places you are calling that exact function and it could alert you to the fact.

You could do semantic find and replace ("show me all sql queries", "show me all untested functions", "show me all functions modified by John Smith since last 14 days", "show me all undocumented functions", etc...).

You could do smarter CI/CD by way of defining rules and constraints on the structure of the program.

Made-up Examples: - If the changeset involves objects tagged with "security" require approval before deploy - If the changeset introduces new SQL queries ping the DBA team - If the changeset introduces more than 1 function without corresponding documentation show warning - If more than 50% of the new objects introduced in the changeset lack corresponding test cases fail the build - You get the idea..

The point is, all the cool stuff we'd like to do depends on us having a lot more structured information and context about our programs and a plaintext environment is not suitable and is hostile towards that.

MCL had its own interface builder. Didn't Dylan just use MCL's?

No, it had its own - at least in the 'released' technology preview. The Dylan Interface Builder was written in Dylan itself and was loaded directly into the running Dylan application. The Apple Dylan IDE itself was running as a separate MCL application. You can see from the screenshots that the IB also had a different look&feel.

This is what Lighttable aimed to do - create an extensible, abstracted code editor for many languages. See also CodeBubbles (Java) and most Smalltalk environments.

http://lighttable.com/2012/04/12/light-table-a-new-ide-conce...

Me too.