alt Hacker News" the C-like for programmers who like C."
Sounds intriguing. But then, the first thing I noticed in their example is a double-colon scope operator.
I understand that it's part of the culture (and Rust, C#, and many other languages), but I find the syntax itself ugly.
I dunno. Maybe I have the visual equivalent of misophonia, in addition to the auditory version, but :: and x << y << z << whatever and things like that just grate.
I like C. But I abhor C++ with a passion, partly because of what, to me, is jarring syntax. A lot of languages have subsequently adopted this sort of syntax, but it really didn't have that much thought put into it at the beginning, other than that Stroustrup went out of his way to use different symbols for different kinds of hierarchies, because some people were confused.
Source: https://medium.com/@alexander.michaud/the-double-colon-opera...
Think about that. The designer of a language that is practically focused on polymorphism went out of his way to _not_ overload the '.' operator for two things that are about as close semantically as things ever get (hierarchical relationships), simply because some of his customers found that overloading to be confusing. (And yet, '<<' is used for completely disparate things in the same language, but, of course, apparently, that is not at all confusing.)
I saw in another comment here just now that one of the differentiators between zig and C3 is that C3 allows operator overloading.
Honestly, that's in C3's favor (in my book), so why don't they start by overloading '.' and get rid of '::' ?
Replies
As a long time lisper I can't stand how much syntax languages have and I think of excess syntax as a sign of a childish mind, but what can you do?
Namespaces to me are more about naming conflict resolution and code readability, and I think of them more as prefixes to namespace member names, as opposed to those member names being part of a hierarchy.
It also helps code readability to know that a::b is referring to a namespace, without having to go lookup the definition of "a", while a.b is a variable access.
Two reasons, the second being the important: (1) If I read "io.print", is this "the print function in the module io" or "the print method for the variable io". There tends to be an overlap in naming here so that's a downside (2) parsing and semantic checking is much easier if the namespace is clear from the grammar.
In particular, C3's "path shortening", where you're allowed to write `file::open("foo.txt")` rather than having to use the full `std::io::file::open("foo.txt")` is only made possible because the namespace is distinct at the grammar level.
If we play with changing the syntax because it isn't as elegant as `file.open("foo.txt")`, we'd have to pay by actually writing `std.io.file.open("foo.txt")` or change to a flat module system. That is a fairly steep semantic cost to pay for a nicer namespace separator.
I might have overlooked some options, if so - let me know.