This does explain the problems nicely, and I think illustrates well how doing nothing is basically the solution.
As someone who has made many compilers now, I always used to reach for method syntax as a must have.
But as soon as you start to get into things like wanting a function in another package to define some behaviour on a data type in a different package, you suddenly get yet another naming conflict problem to solve, where the solutions end up with having one blessed function for the data type and all the other functions have to just use convoluted ways of selecting which method you want to use to the point where you may as well just use the normal procedural way anyway.
And that's a problem that immediately comes up even if you're only using things like methods as a simple namespacing mechanism.
Method syntax really is something that only works if a goal of your language is to support OOP in the sense that a data type is the owner of a function, which is actually pretty limiting...
And an example of a language that is "mentally living in the 20s" is what exactly? And let me guess, it's going to be even worse in practice to what you are insulting.
Packages are scoped and you can have declarations within procedure bodies, but beyond that, there are not extra levels of "namespacing". That is by design, and the article is trying to explain the problems of having such an idea in a language and how it isn't as good as you think it is as a project grows.
I went down this song and dance with Odin as well, and just like Karl reached out on the Discord to find out it was by design.
Since coming to accept that, I've found it offers far nicer ergonomics and indeed solves the code navigation problem. It puts onus on developers to not be lazy though, and actually think about naming things consistently.
I think the only other related feature people may use namespaces (well... C++ classes as namespaces) for, is the ability to mark something(s) as private to a package, which last I checked Odin can do just fine.
Yeah. It's really hard to explain this to people without the experience. The neat-idea of taxonomical namespacing that people do seems like a good idea for small projects, but becomes a problem as you scale. And that is not something you can usually convince any one of without subjecting them to code bases that love doing that.
So the "Welp that's a hard no-use" from /u/crusoe is a common one I see. It's a gut reaction rather than understanding the problem that Odin is trying to solve (or even probably reading the article). And if they want to present a better approach to problem of scale, I am open to ideas.
I feel like this is describing not problems with namespacing, but problems with trying to do C++-style namespacing with the assistance of C++ tooling, these things are just plain horrible on their own, you are not going to get anything too useful by combining these two. I still have to encounter any significant issues while using C#, Rust, Java or even Python. Even with Odin's packages which are not really meant for internal organization, you can still get your project organized because anything beyond toy examples eventually evolves into a codebase with internal mini-libraries, even if the boundaries are not implicitly set, and then the package system of Odin is just fine. For this to work properly, you have to actually think about your project's architecture properly, which for a hobby project you might not want to do and it's totally understandable, but then you can't also really complain that a system designed to push you towards designing library-esque API-s doesn't allow you to create things that would be atrocious as libraries
i feel like the argument "i cant type world_add with namespaces" doesn't work because with even mediocre tooling you can search for a symbol in a specific namespace. maybe i missed something that addresses this in the post though.
to me, having project-local modules allows me to control the dependencies between different things a lot more easily, and to keep them consistent and logical. this applies to games less, because usually everything influences everything (thats why i dont like using rust for games)
As he was working in another part of the code base, he actually needed to look at the implementation of add in the world namespace. So he pops up a “find symbol” window and types add. Enter. He gets 23 hits and it is not very easy for him to find the one he needs.
In my previous life as a PHP programmer, I had just about this same reaction when PHP added namespaces. "Oh neat!" followed by "This makes things a bit harder to search for" and "I don't think I need them after all".
So I continued writing Package_Package_ClassNames with underscores.
Technical-Fruit-2482@reddit
This does explain the problems nicely, and I think illustrates well how doing nothing is basically the solution.
As someone who has made many compilers now, I always used to reach for method syntax as a must have.
But as soon as you start to get into things like wanting a function in another package to define some behaviour on a data type in a different package, you suddenly get yet another naming conflict problem to solve, where the solutions end up with having one blessed function for the data type and all the other functions have to just use convoluted ways of selecting which method you want to use to the point where you may as well just use the normal procedural way anyway.
And that's a problem that immediately comes up even if you're only using things like methods as a simple namespacing mechanism.
Method syntax really is something that only works if a goal of your language is to support OOP in the sense that a data type is the owner of a function, which is actually pretty limiting...
crusoe@reddit
So no internal namespaces in Odin? Welp that's a hard no-use.
simon_o@reddit
It feels like I lost brain cells reading that blog post.
gingerbill@reddit (OP)
And an example of a language that is "mentally living in the 20s" is what exactly? And let me guess, it's going to be even worse in practice to what you are insulting.
gingerbill@reddit (OP)
Packages are scoped and you can have declarations within procedure bodies, but beyond that, there are not extra levels of "namespacing". That is by design, and the article is trying to explain the problems of having such an idea in a language and how it isn't as good as you think it is as a project grows.
IDazzeh@reddit
I went down this song and dance with Odin as well, and just like Karl reached out on the Discord to find out it was by design.
Since coming to accept that, I've found it offers far nicer ergonomics and indeed solves the code navigation problem. It puts onus on developers to not be lazy though, and actually think about naming things consistently.
I think the only other related feature people may use namespaces (well... C++ classes as namespaces) for, is the ability to mark something(s) as private to a package, which last I checked Odin can do just fine.
gingerbill@reddit (OP)
Yeah. It's really hard to explain this to people without the experience. The neat-idea of taxonomical namespacing that people do seems like a good idea for small projects, but becomes a problem as you scale. And that is not something you can usually convince any one of without subjecting them to code bases that love doing that.
So the "Welp that's a hard no-use" from /u/crusoe is a common one I see. It's a gut reaction rather than understanding the problem that Odin is trying to solve (or even probably reading the article). And if they want to present a better approach to problem of scale, I am open to ideas.
da_supreme_patriarch@reddit
I feel like this is describing not problems with namespacing, but problems with trying to do C++-style namespacing with the assistance of C++ tooling, these things are just plain horrible on their own, you are not going to get anything too useful by combining these two. I still have to encounter any significant issues while using C#, Rust, Java or even Python. Even with Odin's packages which are not really meant for internal organization, you can still get your project organized because anything beyond toy examples eventually evolves into a codebase with internal mini-libraries, even if the boundaries are not implicitly set, and then the package system of Odin is just fine. For this to work properly, you have to actually think about your project's architecture properly, which for a hobby project you might not want to do and it's totally understandable, but then you can't also really complain that a system designed to push you towards designing library-esque API-s doesn't allow you to create things that would be atrocious as libraries
beephod_zabblebrox@reddit
i feel like the argument "i cant type world_add with namespaces" doesn't work because with even mediocre tooling you can search for a symbol in a specific namespace. maybe i missed something that addresses this in the post though.
to me, having project-local modules allows me to control the dependencies between different things a lot more easily, and to keep them consistent and logical. this applies to games less, because usually everything influences everything (thats why i dont like using rust for games)
RecursiveServitor@reddit
Apparently language designers have to cater to people who use notepad. Or something.
TOGoS@reddit
In my previous life as a PHP programmer, I had just about this same reaction when PHP added namespaces. "Oh neat!" followed by "This makes things a bit harder to search for" and "I don't think I need them after all".
So I continued writing
Package_Package_ClassNameswith underscores.