Hacker News Reader

Comment by ta_ca | Hacker News Reader

my only beef with zig/jai is that they both have strong opinions on things like operator overloading and i am afraid they will end up just like java.

i have nothing against having strong opinions, i am the biggest offender but completely disallowing some features, some of the best features static typing can offer is just nonsense.

every language designer should study common-lisp and start with the operators : and :: these two operators alone tell you that the language designed for practical use.

for me overloading the operator + and function 'add' is exactly same. you should then forbid function overloading as well now. you can argue about the weakness of operator overloading but disabling completely, not even a workaround?

why not just enable oo and have safe alternatives instead? . safe(a + b) . a s+ b

View on HN

quoting myself [1]:

"It's really easy to make fun of C++, but everyone has that one feature of C++ that they like. And they want to put it in Zig. If everyone had their favorite feature from C++ in Zig, Zig would just be C++. But I'm not going to let that happen."

https://youtu.be/Gv2I7qTux7g?t=454

andrew,

a language with first class cross-compilation alone is enough for me to respect you as a language designer and zig have so many features like this. i am a huge fan.

i have only one favourite feature in c++ and it is templates/ctfe. without the function/operator-overloading templates are incomplete, i would then use c instead. i am still using c++ with all its failures, with all its complexity, with all its uglyness|ineleganceonly because c++ got one thing right. you can at least somehow modify the language.

edit: i have to point out that i have never worked in a big team (more than 10) and you can (probably should) safely ignore my ideas/opinions.

My concern about zig/jai and others, is meta-programming.

Meta-programming can be super powerful and practical, and the current trend of reusing the language itself is clearly better than previous attempt.

But meta-programming in itself is not a novel idea, C macros and C++ templates are past well studied examples, and both produced awful results.

I am not sure they can prevent a new cycle of this nightmare.

Maybe I am just a huge dummy, but I have yet to find examples of metaprogramming in the wild that aren't just mind-meltingly hard to grok. (Most of what I have seen is Python and Rust).

I have no doubt about how powerful metaprogramming is, but it makes me feel that understanding and contributing to libraries that use it is out of my reach.

I think what's novel about Zig's approach is that the metaprogramming is just normal code which happens to be executed at compile-time.

I have found that when any project gets to a certain size, it's almost inevitable that metaprogramming will be required, unless you want to make everything super dynamic and sacrifice performance. The idea of being able to do metaprogramming in the language I used to write the program itself is an interesting one.

I don't know if Kelley would agree with my characterization, but I don't see comptime as metaprogramming. Instead it opens the very interesting possibility of having types as values, as long as those values are resolvable at compile time. This lets you do things that feel like metaprogramming (e.g. making a generic container structure) but it seems a better conceptual fit to me that you're programming with types as values rather than generating code from a template or macro.

This is nothing novel. LISP macros is exactly that.

in fact i believe templates are the greatest idea in static typing. they look awful because its design and the implementation is awful not the idea. c++ failed because they didn't know and too late to turn back, and rust just looks same, you should see d-templates.

I think that templates can be practical and readable if used with moderation, just like macros.

> C++ templates are past well studied examples, and both produced awful results.

What's wrong with templates ? They give you a compile-time functional language that operates on types, isn't that great ?

Imagine being able to use C++ to operate on types at compile time instead of using the verbose template syntax.

In my opinion, operators overloading could be safely used if they were explicit.

With something like that:

var x = a [+] b;

There is no possible mistake.

proposed and rejected. I went to a lang meeting and tried to steelman the issue, without having a strong investment either way (I had one use case, where I would slightly prefer the infix operation).

https://github.com/ziglang/zig/issues/8204

Good to see it was discussed :)

It is probably better to have native support for small vector operations, as this can also help to streamline SIMD optimization.

In practice (as a video game dev) I only use operators overloading to have infix notation on vector maths.

Yeah gamedev/simulation is the use-case where I think operator overloading is really a value-add. It's really nice to be able to write linear algebra code which reads like math.

Operator overloading is something that has often been misused, and even if I tend to like syntactic sugar, I understand that being explicit is more important.

When trying to understand a codebase, it is much easier to not worry about hidden indirections.

but you can misuse anything, + vs add was an example for this.

being able to misuse a PL i believe is not a bug but a feature. we really suck at predicting the future.

This is not the role of langage designers to prevent bad programmers to write bad code.

But it is better to avoid giving them too many ways to shoot themselves in the foot.

Forcing the code to be explicit is good design, in my opinion, simply because it is much easier to write code than to read it, we have to put more weight on the clarity side.

Pretty sure jai has operator overloading as it is intended for games and being able to add two vectors is something you want to do all the time.

Is your point with the ':' and '::' operators that by allowing anybody to break package encapsulation at will the language pragmatically allows for situations that the original package designer did not anticipate? I could see that.

that is exactly my point. it has everything. elegance, vision, practicality... it doesn't treat programmers like drones.

Reply on news.ycombinator.com