3 ms·

I can definitely see it might have quite a few problems. Forest [0] and others even attempt to abstract on syntax, which I generally disagree with as it becomes

by slx26 7y ago

I can definitely see it might have quite a few problems. Forest [0] and others even attempt to abstract on syntax, which I generally disagree with as it becomes a problem to learn the language or get help / discuss some things with other people, especially online. I'm not dismissing the default formatter, it's obvious you still need one canonical representation of the code, but I don't think you should view it as "hiding" the formatting. In my view, it's more like opening a web page with one browser or another, or with one device or another. It always looks a bit different. Or maybe I have a theme configured on my main browser or whatever. I like to have my preferences, but if I have to look at the page from another browser, it's not a big deal either. The extra configuration might not be worth it or slightly inconvenient in some cases, but I doubt it's counter productive. The same way as I might prefer to read/write with a certain font or use this or that color palette. Maybe the takeaway is that code is more personal for some people than we like to generally admit. You are talking in a language and you want to be able to express yourself as comfortably as possible. I mean, we have had turing-complete and even "productive/decently ergonomic" languages for a while, and yet a lot of people keeps coming up with new languages, because they are much more than just a tool to get things working. We want to express ourselves as we "think", and formatting may be a small part of that, but it's still a part of it. [0] https://github.com/forest-lang/forest-compiler https://github.com/forest-lang/forest-compiler

davnicwil 7y ago
I definitely agree with most of this but I have to challenge the web browser analogy because that's a scenario where the concept of the view (visual, screen reader, etc) being interpreted from the textual representation is built in - as in, there is no end user who consumes the raw markup as-is. So different end users working with different views is a completey natural and expected thing. I guess that's what's missing to make this work for code. The raw code is intended as the final representation to the end user. Maybe what you'd need to make this work is to build in the concept of formatting to the source control itself, so all the way through the tooling you could 'render' the code as you'd like to see it, and do all operations on it using that view (including diffs, etc). Maybe sort of like you can with syntax highlighting, except with positional formatting instead.

by slx26 7y ago

davnicwil 7y ago

I definitely agree with most of this but I have to challenge the web browser analogy because that's a scenario where the concept of the view (visual, screen reader, etc) being interpreted from the textual representation is built in - as in, there is no end user who consumes the raw markup as-is. So different end users working with different views is a completey natural and expected thing. I guess that's what's missing to make this work for code. The raw code is intended as the final representation to the end user. Maybe what you'd need to make this work is to build in the concept of formatting to the source control itself, so all the way through the tooling you could 'render' the code as you'd like to see it, and do all operations on it using that view (including diffs, etc). Maybe sort of like you can with syntax highlighting, except with positional formatting instead.