My gut reaction is a combination of, “huh, that’s surprisingly intuitive” and “the horror”. I think it would likely cause more problems than benefits, but I can see the appeal…
3 Likes
It might be one of these things that could have become the norm without shocking anyone, but now the norm is something else, it’s impossible to switch, bistable language design ?
The whole thread was quite “off-track” anyway. Makes no big difference… 
Regarding the idea, an IDE could render
as
But I’m not sure this would still be easy to read in case of more complex expressions.
Maybe with some “grouping markers”? How about something like Chinese quotes? (Maybe only rendered smaller):
1 + 2 - 3 + 「0 / 5」
When I’m thinking more about it: Why not full blow TeX rendering? That would be usually best readable for more complex formulas.
At least this would be easily doable form the technical standpoint if we finally moved away from using raw text as representation for code… “Rendering” (creating the visual appearance) of a languages’s AST locally would be a much more flexible approach!
Bonus: You wouldn’t really need to agree on one “canonical rendering” anymore. It would be an IDE setting, like a syntax highlight theme. Think “style sheets for code” which define the local visual representation (like style sheets for markup).
Switch form spaces to tabs, form braces to indentation, from written out operators to symbolic ones, from parenthesis to spaces—and back, whatever—by the press of a button, without affecting the code on disc.
This is possible for a DOM rendered in a web browser. But why not for an AST rendered in an IDE? (Especially as the actual rendering in something like VSC is already based on a DOM in a web-view…)
The only place where you would need to “hard-code” the rendering is when printing stuff out on dead trees… But this is not how you usually consume code. Even for books dead trees make no sense: The content gets outdated very fast in case of IT stuff. So printing out things on paper is a wast of resources imho anyway.
It took until the third time reading over your post to even notice there was extra spaces between the two groups. This would be an absolute nightmare to read anything non-trivial (and even the trivial stuff would be a pain).
2 Likes
Interesting, for me it really stands out, the question becomes:
Where does the difference come from, our brains, or our computers ?
As both affect heavily how text appears
(You do not need to answer)
One thing is for sure, this forum does not like it, both your quote and inline code like a - b + c have their extra spaces stripped
I typed the following above:
a - b + c
Likely my brain, as I have the same trouble with fewer braces - so if anyone who has trouble with this wants to know what reading Scala 3 with fewer braces looks like to me, this is pretty close.
<rant>Of course, I’m autistic so there’s no real way to know how common this is, but considering how overrepresented we are in the programming community, it might have been a good idea to do an actual study on how a massive change like fewer braces would affect readability once concerns were raised, instead of running it by just the compiler team and students (who have an age bias towards greater visual acuity, and a built-in incentive to talk up their professor’s pet project).</rant>
2 Likes
Our HTML renderers don’t like it. The forum is innocent.
One would need to insert “ ” like so: 1 + 2 - 3 + 0/5.
I didn’t think about that also. Just copy’n’pasted stuff…
Honestly I think it’s largely the community. The early Scala community was all-in on funky operators: databinder dispatch, SBT, scala.sys.process, scalaz, akka streams, scala-graph, play iteratees, lift framework CSS, scalatest, specs2, symbolic folds on collections, ammonite-ops/shell, etc. The swift community, although it has similar flexibility, is focused on making iOS apps. A bunch of iOS app developers would very naturally have a very different usage pattern than a bunch of programming language geeks, even when the underlying tools are identical.
The community has changed (many of these projects have totally dropped their operator-style APIs!) and it’s easy to forget just how incredibly operator-heavy the entire Scala community was back then
val poem =
"Roses are red," ::
"Violets are blue," ::
"Lift rocks!" ::
"And so do you." :: Nil
def render =
".poem" #> poem.map(line => ".line" #> line) &
"a" #> downloadLink
class RobotDetectorSpec extends Specification with DataTables {
def is = "Can detect Google robots" ^ {
"Bot?" || "User Agent" |
true !! "Mozilla/5.0 (Googlebot/2.1)" |
true !! "Googlebot-Video/1.0" |
true !! "Mediapartners-Google" |
true !! "AdsBot-Google" |
false !! "Mozilla/5.0 (KHTML, like Gecko)" |> {
(expectedResult, userAgent) => {
val http = new MockHttpServletRequest()
http.headers = Map("User-Agent" -> List(userAgent))
MockWeb.testReq(http) { r =>
RobotDetector.googlebot_?(r) must_== expectedResult
}
}
}
}
}
I spend a few weeks learning swift using some of the most popular online resources, wrote an iOS app, and didn’t learn about custom operators at all. That is how much the Swift community pushes them to the forefront. In comparison, for decades the top Scala language books were all about using/abusing advanced features, to the point we (i.e. at my work) have documentation to tell people “please skip these chapters, you’ll only get bad ideas from them and will regret using those language features in our codebase”. Not because the language feature is bad, but because the books make them out as some day-to-day utility when they should really be advanced tools used only when necessary
Swift isn’t all roses, and there are plenty of complaints about compiler performance, crashes, etc. But I do think there’s a large space for Scala learning materials that simply skip over the advanced language features to focus on use cases. That’s what Hands-on Scala was all about, and the Scala Toolkit is also in that direction. But the early community set the tone for decades, and it’s a big lift to re-orient Scala in a different direction and a new reputation
7 Likes
That doesn’t sound funny… 
Still I think this is “just” a tooling issue. There should be a switch for that! Computers are all about making things like that possible.
For example the computer allows me to write mostly correct texts, thanks to automatic spell-checking; now even in a foreign language, thanks to AI based aid. (I should use the later more, really helpful with grammar.)
So why the computer shouldn’t help with working with code better? That’s the point of tools in the first place.
Marketing. That’s exactly the marketing I was speaking of.
Scala was sold to the public in a quite strange way. People where all about the most exotic features.
To some degree understandable, because that stuff was something uncommon and new, and people like to play. But the results form playing around with new stuff aren’t often the best possible solutions. It takes time to let things sink in.
At the same time all the “usual”, well know standard features of Scala were neglected. Because “that’s just boring stuff”. Not very shinny. Even the std., “simple” things are actually very well made in Scala. Mostly better than else where. Only all these things aren’t revolutionary, so people took them just for granted.
But I think people now realized that advanced features are for advanced usage. You need them when you need them, but you don’t need them all the time of course.
This!
Not meant to be 
The issue is that this requires either dependence on an IDE with appropriate plugins or a near-perfect bidirectional rewrite tool. The first has vendor lock in issues, and neither currently exist.
Creating a plugin that renders these changes or does the conversion on the fly isn’t really an issue, but making the durable representation less readable than the previous version isn’t great, and pushing for that representation to be common (by, for example, rewriting all the docs to use it) is troubling.
But I’ve burned through my post limit on this topic, so I’ll shut up now.
That’s really interesting, as I also am autistic, and for me it’s completely the opposite:
This would be a lot more readable than relying on the first letter of the symbolic operator
I also really like braceless syntax in general, and I really enjoy it in Scala, but I always get caught on the irregularities, like no colon : after extension (...)
I’m not saying that to diminish your validity or something, I’d just assumed other autistic people would be more similar to me (which was of course foolish)
3 Likes
I agree with the multiplicity of displaying on principle but there are two problems with it:
- Ecosystem fragmentation: Every library website will have a default way of displaying the code, and even if it can be changed, it might be different on each (or even when pair programming !)
- The default matters: If braceless becomes default, it falls on people who have difficulty with it to adapt, and they might have more difficulty than the rest if it was the other way around
No, it would not.
Because the renderer you use in your viewer / editor uses of course your preferred “style sheet”.
That’s the whole point of the idea: You see the code on your devices like you like it best!
Actually not.
The format “on disc” or the one which goes over the wire is an internal detail.
Exactly like it does not matter whether some text on disc is UTF8, UTF16, or UTF32… You don’t use a hex editor to edit it anyway, but instead a specialized tool so called “text editor”, which converts the bits on disc into something readable. Exactly like you also don’t use a hex editor for image manipulation…
Actually the internal representation is anyway just something for the computer. So it should be optimized for the machine, so likely anyway binary. Code needs a lot of meta-data, so it’s likely a database format…
Code in a databases is of course not my “invention”.
This was the future; back in the past… Only that we’re actually now back to stone age!
(People even started again to write spaces instead of proper indentation symbols (called “tabs”), because people apparently still use the big line printer in the office to print out code for reading; and you know, someone always messes around with the tab stops on the line printer, so it’s safer to use spaces… 
)
The joke here: The first thing you usually do with code is to actually put it into a database. GIT is a database!
Only that you put raw text into the database instead of the real thing.
OK, there is at least some movement:
Than, in the stone age approach, the very next thing that happens is your IDE painfully and error prone extracts again the real thing, to—guess what—put it into a database! (Ever seen a message like “indexing complete” in an IDE? 
)
Converting back and forth between the real thing and some lousy textural representation (which nobody actually can agree on) is just mega nonsense!
At least the next generation of code editors go in the right direction: Helix and Zed both use a more or less proper data model underlying the code. (Still it’s not there as there is still back and forth conversion between the lousy string representation and the actual data model. But the next step should be clear: Get rid of the nonsensical conversion; which would allow all kinds of “new” capabilities in code editors; we would be back at least to the state of the art around the end of the 80’s of the last century. Still waiting that we get the capabilities of Lisp Machines back, though…)
People are talking about “great tooling” still we’re back to “editing images in a hex editor”. Wrong tool for the job!
Things should more look like this:
1 Like
Note that I wrote “website”, I’m talking about everything outside your editor !
Totally agree, but that’s not what I’m talking about
On forums and so on, a standard, a default, will emerge, and this default can have big repercussions on those for whom it makes life harder
Think for examples of the many games that now offer modes for colorblind players, it’s really nice, but most of the content made about these games do not use these modes !
1 Like
What? Dead trees?
You would look at code with a code viewer / editor on the computer. Like you use an image viewer to view images, and not look on a hex dump… (Analogy to viewing a code data structure in plain text)
I start to like the idea even more. Just watched:
And found:
Of course both is still more like toys. (Even this Citrus looks quite polished for a research project.)
But build something like that into InteliJ, VSC, EMACS, NeoVim, etc. (which is very possible), polish it, and we’re almost there. LSPs would need to get smarter, sure. But that’s doable.
We could have “syntax-less” programming languages. Pure AST editors. Surface representation would be a matter of a “style sheet” (or better expressed as a bijective tree transformer). This Omni demonstrates how this could look like. “Syntax” are just the rendered decorations around your symbol-object representations.
Again, agree for everything in-editor, but would you need an editor to look at code on a website ?
If yes, what do you do when the person does not have one ?
You go with a default
1 Like
That’s nice! 
Have you seen the video? Really impressive. Something like that would be really cool in Metals.
Well, websites use anyway renderers to show code. You put at least some syntax highlighting JS plugin on it, and if it’s interactive it’s at least something like CodeMirror, nowadays even more often the VSCode editor Monaco.
To compare once more with images: You can render JPEG XL in browsers, even they don’t support this natively. A website can just load a viewer implemented in JS / WASM. And show the binary data even the browser doesn’t recognize it as an image.
So there is no big issue here, imho. The tools just need some improvement to render “code style sheets”.
If you never looked at some specific language you likely don’t have a preferred “code style sheet” installed or configured. Than you need some default, sure.
But the viewer can offer some alternatives, at the press of a button… 
Exactly like you can switch syntax highlighting themes in code viewers.
(Also something like a “universal” style sheet with some language spanning defaults could be thought of. For example it would say things like: “Braces for blocks”, “Function calls with parens”. Stuff like that.)
Not surprising, we’re a highly diverse bunch, and it’s still not entirely clear if sensory/signal processing issues are part of autism itself or just a very common comorbidity . This is part of the reason that a study would have been a good idea, as picking out how many of us are affected by a change like this would be really hard to guesstimate (and that’s aside from the question of how many neurotypical people would also negatively affected by this change, which is still an open question).
To be fair, I mostly don’t do implicit precedence beyond the least controversial subset of the various arithmetic standards (partially because even calculators can’t agree on which to use), so the first/last character of a symbolic operator doesn’t generally matter to me outside of methods like +: and :+ (which are generally well designed enough to “point” in the direction of application).
Replacing grouping with whitespace would tend to cause trouble in situations like this:
a && b || c vs a && b || c
For comparison, this is how I would write them with parens:
a && (b || c) vs (a && b) || c
On the other hand, symbolic vs alphanumeric operators make very little difference to me in most cases, provided the symbols are part of the common language of math (/: didn’t work for me because it was unfamiliar, not because it was symbolic). For example, boolean logic is pretty much the same (other than possibly being easier to visually pick out the symbolic operators, but that’s easily solved with basic syntax highlighting):
a && (b || c) vs (a and b) or c
The one situation where that actually matters is math, and that’s mostly because of how familiar they are. For example, this is easy to parse:
a * b + c / d
While these are comparatively more annoying to write and parse (at least for me):
a.mul(b).plus(c.div(d))
plus(mul(a,b), div(c,d))
(a mul b) plus (c div d)
2 Likes
I think this idea is really good, but it requires more elaboration. There are not only cases when people seeking for solutions on StackOverflow (it is solvable, yes), but also cases when you share snippets of codes in chats, for examples. For this case we will need a plugin for the whole operational system to translate ASTs to a readable code everywhere where it meets an AST object. It should be like an image decoding libraries but with support of potentially infinite personal styles. Of course it is feasible if the whole world collaborates on it.
I really love this idea anyway. Just like I love world peace.