Live data from Hacker News

Type resolution redesign, with language changes to taste

ziglang.org

251–260 of 284 posts

Re: Type resolution redesign, with language changes to taste

#251
post #220

Earlier quoted context omitted.

It is insane and you are completely right. This has been a part of programming for over 50 years. Unfortunately you aren't going to get anywhere with zig zealots, they just get mad when confronted with things like this that have no justification, but they don't want to admit it's a mistake.

But even the solutions would be so trivial - have a separate 'prod' compiler flag. With that, make these errors, without make these warnings. Problem solved, everyone happy.

i think the plan is to make no distinction between error and warning, but have trivial errors still build. that said i wouldn't be surprised if they push that to the end because it seems like a great ultrafilter for keeping annoying people out so they don't try to influence the language.

Re: Type resolution redesign, with language changes to taste

#252
post #219
post #214

Earlier quoted context omitted.

I think the issue is OOP patterns are one part missing features, one part trying to find common ground for Java, Modula, C++, SmallTalk, that it ends up too broad. A much saner definition is looking at how languages evolved and how term is used. The way it's used is to describe an inheritance based language. Basically C++ and the descendants.

> one part trying to find common ground for Java, Modula, C++ The primary common ground is that their functions have encapsulation, which is what separates it from functions without encapsulation (i.e. imperative programming). This already has a name: Functional programming. The issue is that functional, immutable programming language proponents don't like to admit that immutability is not on the same plane as impera…

> The primary common ground is that their functions have encapsulation

You omitted Smalltalk. Most people would agree that SmallTalk is object-oriented.

But that kinda ruins the common ground thesis.

> Language evolves, certainly. It is fine for "object-oriented" to mean something else today.

pjmlp definition is very fuzzy. It judges object-orientedness based on a few criteria, like inheritance, encapsulation, polymorphism, etc. More checks, stronger OOP.

By that, even Haskell is somewhat OOP, and so is C, assembly, Rust, and any language.

---

What I prefer is looking at it as it's used. And how it's used for appears to be akin to using it as an everyday term fish or fruit.

No one would agree that a cucumber is a fruit. Or that humans are fish. Even though botanically and genetically they are.

Re: Type resolution redesign, with language changes to taste

#253

Earlier quoted context omitted.

You are right of course, the solution is trivial. They also made a carriage return crash the compiler so it wouldn't work with any default text files on windows, then they blamed the users for using windows (and their windows version of the compiler!). It's not exactly logic land, there is a lot of dogma and ideology instead of pragmatism. Some people would even reply how they were glad it made life difficult for win…

I'm not sure why you shouldn't make your compiler accept CRs (weird design decision), but fixing it on the user-side isn't exactly hard either. I don't know an editor that doesn't have an option for using LF vs CRLF. The unused variable warning is legitimately really annoying though and has me inserting `_ = x;` all over the place and then forgetting to delete it, which is imo way worse than just... having it be a wa…

I don't know an editor that doesn't have an option for using LF vs CRLF.

And I don't know any other languages that don't parse a carriage return.

The point is that it was intentionally done to antagonize windows even though they put out a windows version. Some people defend this by saying that it's easy to turn off, some people defend it by saying windows users should be antagonized.

No zig people ever said this was a mistake, it was all intentional.

I'm never going to put up with behavior like that with the people making tools actively working against me.

Re: Type resolution redesign, with language changes to taste

#254

Earlier quoted context omitted.

as few footguns as possible There are no destructors so all the memory ownership footguns are still there.

sure, but when I've written zig this has never been an issue for me. `defer` makes memory management really easy. If you want to auto-generate destructors, zig has really good comptime features that can let you do that.

defer is still something you have to consciously put in every time so it destroys the value semantics that C++ has, which is the important part. You don't have to "just write defer after a string", you can just use a string.

The 'not a problem for me' is what people would say about manual memory in C too. Defer is better but it isn't as good as what is already in use.

Re: Type resolution redesign, with language changes to taste

#255
post #237

Earlier quoted context omitted.

If you make up your own definitions things can be anything you want and have or not have any label.

Absolutely. That's why it is best to stick to the already established definitions. Kay was quite explicit about what "object-oriented" meant when the term was uttered for the first time; including specifically calling out C++ as not being object-oriented. And yes, we all know the rest of the story about how the C++ guys were butthurt by that callout and have been on a mission to make up their own pet definition that…

Don't you think it's a bit silly to keep rehashing tribalistic arguments that people moved on from 40 years ago?

Re: Type resolution redesign, with language changes to taste

#256
post #201

Earlier quoted context omitted.

Zig's worth it though. I don't care for libraries that aren't maintained anyway. If they don't maintain it, it's just bad anyway. Why do you always nag about Zig. Stop shilling your C3 here.

This kind of thought is popular in the web world where browsers get an update every 3 days and you don't control the hosting services, so constant maintenance is unavoidable. But in the world of desktop development it's possible for a library to be "done", having a 100% stable codebase going forward and requiring no maintenance. And it's not bad, it's actually good. Requiring every dependency to be constantly maintai…

Once Zig hits 1.0 it will essentially be done. They don't plan on making further changes to the language, so they want to get it right while they can.

Re: Type resolution redesign, with language changes to taste

#257
post #62

Earlier quoted context omitted.

Zig is a modern C, Rust is a modern C++/OCaml So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.

It is kind of interesting that the Linux kernel is slowly adopting Rust, whereas Zig seems like it would be a more natural fit? I know, timelines not matching up, etc.

It is not about timelines. Linux Torvalds doesn't spend nights reading bunch of books with crabs on their covers rewriting random bits and pieces of the kernel in Rust. It is basically a dedicated group of people sponsored by megacorps doing the heavy lifting. If megacorps wanted Zig we could have had it in the kernel instead (Linux might have rejected it though, not sure what he thinks of it).

Re: Type resolution redesign, with language changes to taste

#258
post #231

Earlier quoted context omitted.

This kind of thought is popular in the web world where browsers get an update every 3 days and you don't control the hosting services, so constant maintenance is unavoidable. But in the world of desktop development it's possible for a library to be "done", having a 100% stable codebase going forward and requiring no maintenance. And it's not bad, it's actually good. Requiring every dependency to be constantly maintai…

Looks like all the 2 users of C3 came here to complain about Zig. Why should we listen to you?

I've never even heard of C3, I use C++ and Jai.

I've never used Zig either, I just disagree that requiring constant maintenance is a good.

Re: Type resolution redesign, with language changes to taste

#259
post #250

Earlier quoted context omitted.

It seems hostile to you, but surely you can see what he's replying to is way more hostile and passive aggressive?

Yes, seems clear, right? It was an extremely hostile pompous criticism of something he didn't understand at all, and the questions were rhetorical, not asked sincerely or in good faith: > Is this a “this dev” thing, a Zig thing, or am just out of touch with modern language (or even larger scale development) projects? No, none of those, it's him making numerous rash assumptions. But my snarky post was probably poor ju…

Yea, it's better to not feed the troll. I'm kind of shocked AndyKelley took the bait.

Re: Type resolution redesign, with language changes to taste

#260
post #252
post #219

Earlier quoted context omitted.

> one part trying to find common ground for Java, Modula, C++ The primary common ground is that their functions have encapsulation, which is what separates it from functions without encapsulation (i.e. imperative programming). This already has a name: Functional programming. The issue is that functional, immutable programming language proponents don't like to admit that immutability is not on the same plane as impera…

> The primary common ground is that their functions have encapsulation You omitted Smalltalk. Most people would agree that SmallTalk is object-oriented. But that kinda ruins the common ground thesis. > Language evolves, certainly. It is fine for "object-oriented" to mean something else today. pjmlp definition is very fuzzy. It judges object-orientedness based on a few criteria, like inheritance, encapsulation, polymo…

> You omitted Smalltalk.

Exactly. It isn't functional. It doesn't use functions. It uses message passing instead. That is exactly why the term "object-oriented" was originally coined for Smalltalk. It didn't fit within the use of "imperative" and "functional" that preceded it.

> But that kinda ruins the common ground thesis.

That is the thesis: That Smalltalk is neither imperative nor functional. That is why it was given its own category. Maybe you've already forgotten, but I will remind that it was Smalltalk's creator that invented the term "object-oriented" for Smalltalk. Smalltalk being considered something different is the only reason for why "object-oriented" exists in the lexicon.

Erlang is the language that challenges the common ground thesis: It has both functions with encapsulation and message passing with encapsulation. However, I think that is easily resolved by accepting that it is both functional and object-oriented. That is what Joe Armstrong himself settled on and I think we can too.

> What I prefer is looking at it as it's used.

And when you look you'll soon find out that there is no commonality here. Everyone has their own vastly different definition. Just look at how many different definitions we got in this thread alone.

> No one would agree that a cucumber is a fruit.

Actually, absent of context defining whether you are referring to culinary or botanical, many actually do think of a cucumber as a fruit. The whole "did you know a tomato is actually a fruit?" is something that made the big leagues in the popular culture. However, your general point is sound: The definitions used are consistent across most people. That is not the case for object-oriented, though. Again, everyone, their brother, and pjmlp have their own thoughts and ideas about what it means. Looking at use isn't going to settle on a useful definition.

Realistically, if you want to effectively use "object-oriented" in your communication, you are going to have to explicitly define it each time.

Post reply on HN