This is something I've been thinking about for a while. Why are we creating programming languages for humans, rather than for an IDE, allowing the later represent the program in human-readable format?
If you're doing math, text sucks.
c = sqrt(pow(a, 2) + pow(b, 2))
is just not as legible as
It gets worse with non-primitives such as vectors in language that pass structs around by reference. If you want to avoid expensive memory allocations, you're stuck with:
add(c, pow(temp1, a, 2), pow(temp2, b, 2))
These are just the simplest formulas. Shader code I wrote back when I did graphics engine development was a nightmare to debug because it was so obtusely represented.
Then there's variable naming. Taking an example from math again: P(A|B) has a precise and well-understood meaning, plus it's concise and easy to recognizable. Unfortunately the majority of programming languages don't allow us to name a variable P(A|B). Similarly, camelCase vs snake_case is a debate centered entirely on the inability of using spaces in variable names.
Another problem, posted a while ago: how can we code on a smartphone? Virtual keyboards are not great for code, and graph-based solutions might work, but I'm pretty sure not many people like drawing graphs on their desktop.
Tabs vs spaces is another debate based entirely on the assumption that code is text. Meanwhile, either approach is a severely outdated alignment tool.
In each of these cases, the key problem is that there is a tight coupling between formatting and semantics. I.e. we display the code as plain text, and that's what it is.
Ligatures and custom operators offer some help but are ultimately tacked-on solutions that fail to address the core problem.
So what if we changed our files from being plain text to something richer and more structured? By removing the coupling of formatting and semantics this way, we can also use wildly different formatting (e.g. a graph editor) on different systems, but modify the same underlying semantics.
What do you think?
Oldest comments (51)
What makes you say that? Obviously you must have some different experience from mine that makes you dislike this idea.
Colors are not really part of the argument.
I'm talking more about what .doc files are to .txt files, but noting that part of the final look should be determined by personal settings. Like in the text vs graph editor example. Or in your case, having or not having syntax highlighting.
This sounds a lot like the structure editor Facebook was working on, but extending the idea further so that limits on what the contents of a node (eg. a variable name) are are removed - very intriguing!
I think what you need is complex and fancy plug-in on the IDE side. Programming languages should be on raw condition. IDE and the extensions make it good product and ready for consume. It is easier to add plug in than plug-out from programming language
Donald Knuth described Literate Programming in 1979.
One of my coworkers at a previous company was Raymond Chen. As a grad student under Donald Knuth, he got to program using Donald Knuth's Literate Programming.
Raymond recommends against that style of programming.
Why does Raymond recommend against that style of programming?
Tooling is very poor. Debugging is very difficult. Documentation-and-code still become out-of-sync just as comments-and-code become out-of-sync, despite proximity (in both scenarios).
As yet-another-alternative to traditional text-based source code files, there are some potential novel ideas from Bret Victor, some alternative IDEs such as found in Lego Mindstorms that are visually oriented rather than text-oriented, Smalltalk style IDE where the code is in the general environment, old DEC Forté style (pre-JavaScript) IDE where the code was in a database backing store, and novel ways of having text-based source as in Light Table.
So there are people working on the leading edge. Maybe one of those concepts will become mainstream.
I'm currently learning iOS development with xcode and Swift and the whole code-generator stuff feels kinda ugly to me
Plain text is still the only universally available format.
It will load on any device you can possibly think of, and there's only one single thing that can cause incompatibilities between platforms and that's line endings which is a problem that is trivially solved.
Tabs vs spaces? CamelCase or snake_case? These are all inconsequential in the grand scheme of things. If I write some plain text code on this phone then I can share it with literally anyone in the world and it will load and compile/run on their machine.
The only way a new code format can become a replacement for plain text is by achieving the same ubiquitousness.
Good luck with that :)
Plain text code still needs to be executed some way, so it isn't really ubiquitous. And even if it were, why would you need that in practice?
I think looking at Smalltalk will answer a lot of your questions. Smalltalk is exactly what you're describing: a language built for an IDE. It can't be used outside the IDE, as it doesn't store its data in plain text, but rather an image format. The IDE provides all sort of nice features and analysis to the user, and ideas from Smalltalk have influenced many other languages and IDEs since its creation in the 1970s. So why aren't we all using Smalltalk? I think the key lies in interoperability. Smalltalk is a world of its own. It doesn't interoperate well with tools that exist outside of the Smalltalk world. For example, you can't really benefit from git when you can't understand how to merge code in a binary image format. When I need to accomplish a specific task (say, some sort of build task), I need to know how to accomplish everything I need in the Smalltalk world, using its tools. Smalltalk goes against the unix philosophy: it doesn't do one thing, it does everything because its a mini virtual machine.
I don't have the authority to say if this is the entire reason we don't code in Smalltalk-like languages, but I think its part of it. There are plenty of new languages trying to push programming languages in new, interactive directions (ex: Eve), but none of them have gained critical mass or mind share. There must be some intrinsic reasons that languages like this don't take off. Hope this provided some insight!
I've honestly never used Smalltalk, guess I will have to take a look at it.
I haven't used it much either, but what I've seen has been interesting. Pharo is a pretty modern implementation pharo.org/.
I'm not an expert in the question, but as far as I know the main reason of SmallTalk failure was licensing model - it was very expensive. I consider Ruby the closest reincarnation of SmallTalk OOP model (which is widely used). Ruby doesn't have "forced" IDE though.
You're missing the point: text files are easy. They can be a little verbose sometimes, but as a 'substance of expression', if you will, they're unmatched. You can create or modify text with the single most common human-interface device metaphor in existence, which children now learn to manipulate in or even before schooling. You can read text with a million different programs and style it, filter it, format it, cut and paste and perform a billion different operations on it. A certain clunkiness in writing out equations is a small price to pay for that kind of flexibility.
If you were to "decouple" formatting and semantics like you propose, you wouldn't be able to avoid coupling the semantics to the editor instead. And there'd only be one editor, until you developed something else that could interact with your structured representation of a syntax tree. This isn't to say it can't or shouldn't be done -- APL had its day, educational tools like Scratch do well, and there are of course a variety of "no programming experience required" flowcharting and modeling languages -- but it's an idea that can only compete against text files in some pretty specific niches.
Not necessarily, css/html is also a decoupling of formatting and semantics. The main point here being that the semantics on their own are no longer supposed to be read by humans.
HTML and CSS also aren't programming languages as such but markup and styling languages (although HTML5+CSS3 are evidently Turing complete if you're willing to put in the effort). But this is actually an interesting point: WYSIWYG markup editors which truly decoupled formatting or visual layout from the semantics of data binding and interaction were a thing in the 00s before everybody realized they were terrible and concentrated on building better plain-text templating languages instead.
True, but I wasn't suggesting using exactly those. In most languages, a program has a certain structure (rather like an AST, but not entirely). That is the "meaning" of a program. Where HTML has an <img> tag, an imperative program has a while loop.
Indentation, variable names, operators, import statements... those are all styling for humans. You could drop all of them and the language would be just as expressive, but not as readable.
This separation already exists. The source code defines the semantics, and the configuration of the editor describes the styling.
Text-format math is harder to read, but it is much easier to edit and write.
Navigating a one-dimensional line of text can be done with two buttons; add two more and you can add line-oriented editing, but that's optional. Editing a multi-dimensional equation, like your version of the distance formula, means you have to come up with an interface for selecting just the radical, or just the equation that you're taking the root of; you can't do that with normal arrows and drag-select.
It's the same set of problems that any kind of WYSIWYG has, now that I think of it. Just because source code is read more often than it's written doesn't mean you can completely neglect the editing experience.
A very good point!
I do think this is solvable. E.g. if you write latex markup, there is a line-based counterpart to the formulas in the compiled pdf. If the relation between markup and formula is isomorphic, navigating with arrow keys in the formula is possible, because it is in the markup.