Granted, I'm dyslexic and apparently dyslexia only affects characters which are phonetic. This has also been my experience and I love Chinese characters in Japanese text because it's much more comfortable for me to read. So that's why I might prefer symbols.
I'm wondering, though, why people dislike symbols (and I know it's a very common thing). It's just like any other letter, except that it has a meaning. I wonder, it is because it's hard to read phonetically (just the opposite of my problem)? Whenever I've asked people they say "Symbols are ugly", which is kind of an unhelpful response. It's like saying, "I don't like it because it is unlikable". I hope someone has a slightly deeper insight into the reasons.
Most people can detect noise and arbitrarity. But if you are making something really original, giving you are being a pioneer into something, in that case you can define the direction of something, where that direction should serve as a guide to things that will follow.
I dont know about others, but my brain tend to be anti-noise (and i fell this pattern in a lot of other people too), because theres too much information for us to consume, that having to handle some people "cheating" to give a apparent originality, can make anyone who feel its the "noisy arbritrary sort of change" that is being presented, to dislike the "noise" almost immediatly.
Technology should be aiming toward zen-budism, less ego and therefore, less disonesty and less noise.
The more symbols, the harder it is to unpack the code into (and restate in a) human language. Even in your head. IOW, if you're mostly monoligual, and you think about code in English (or whatever your preferred language is), more symbols can actually make it harder to think about the code.
Trivial example: a = a+b is slightly easier to say (and think) in English than a += b
I read this as “the more symbols used, the more it looks like mathematics”. I guess this is really a matter of personal taste :)
Native English speaker here.
"+=" is pronounced "plus equals", meaning that you've got it backwards, with the margin being by the number of mental syllables taken by a - though if a really is "a", then that's only 1.
However, the above considerations only cover recitation.
Comprehension, especially in real-world scenarios, is another matter entirely. "a" might be some other, longer name (and probably amongst a set of long names with a common prefix/accessor). When I read "a = a + b", it takes me some amount of effort to verify whether the lvalue is in fact the same word as the lhs of the operator. When I read "a += b", that effort is not needed. The difference again is proportional to the length of a.
Once I've learned the language and internalized the semantics they mostly fade away, except in cases like C++ where you get multiple asterisks and whatnot.
I'm not the above poster but I also dislike the symbols usage I've seen in Rust. I'm on mobile so I can't show examples (and I don't know the language at all) but it has the same smell as symbols in C++ though not as bad. Like character silhouettes in Team Fortress 2, symbols need to appear distinct. Chains of them should be limited. My first impressions of Rust felt like the symbols or operators were less than ergonomic. Small or blending together.
Disclaimers about preference, solo vs team, personal vs enterprise, APL vs La-Z-Boy.
To be fair, some of these are in Zig too, such as &.
Your "horror example" is actually very readable for most programmers familiar with either Java, C# or c++, I think. In java or C# it would be something like
T largest<T>(T[] list)
The major difference being the reference syntax in rust, but that's the price of explicit ownership/no GC.I love the fact that it's obvious where macros are being used.
_, => and () are originally from ML, so I know it from my university days, but these days you also find some or all of them in C#, Java, Kotlin, ES6. So a lot of programmers have already been exposed to them.
* :: is the same as in many other languages
* & too
* ! is unique, I guess
* The format string stuff is based on ... C#/Python stuff? I forget exactly.
* _ => () is composing three other bits of syntax that aren't unusual on their own
* <> is genrics, like in many languages
* [T] is slices, which are not entirely unique but are also similar to array stuff which uses []s
Thanks for elaborating, it's helpful to understand the perspective.
It also has less or equal amounts compared to other languages, of course, but I dislike that aspect of those languages too :)
Compare these two listings:
http://rosettacode.org/wiki/Stack#Simple_implementation
http://rosettacode.org/wiki/Stack#Nim
You can see directly that Rust has a lot more there. Obviously Nim skips out on braces so that's a gimme, but I don't really count block braces when I'm talking about special characters. It's more stuff like Option<&'a Frame<T>> or &'a mut T or ->
Yeah, thanks, I think this is at the root of a lot of it.
> It's more stuff like Option<&'a Frame<T>> or &'a mut T or ->
Yeah; some of the stuff isn't needed anymore; you can drop the : 'a s, for example. And we have been talking about allowing some more elision, so
pub struct Iter<'a, T: 'a> {
next: Option<&'a Frame<T>>,
}
could be pub struct Iter<'_, T> {
next: Option<&Frame<T>>,
}
when all is said and done. The '_ in the signature is important so that you know it's parameterized by a lifetime, so we don't plan on ever getting more concise than that.I want to say I like you how you guys develop in the open and how you in particular are out and about in the discussions here.
Also, can you make a post someday about your experience with WSL?
Could you expand on this, I don't quite know what you mean, but I'm interested!
> I want to say I like...
Thanks!
> your experience with WSL?
My experience was, "This is pretty cool!" but, in the end, I don't use WSL anymore and just use regular old Windows. I can elaborate more if you'd like, but it boils down to "basically everything has windows native versions anyway and it works a bit better that way."
a::b::c::<T>()? // Rust
try a.b.c(T) // ZigThe :: and <> are also not particularly unusual syntax for their respective features either.
You asked what bothered us, not what was unusual :)