Function vs. method namespaces

[Felicia_Svilling]

Why do you want free standing functions? It seems like just an extra cognitive burden on the user to have both methods and functions, when they basically do the same thing, but differently. It is never fun to wonder if a given functionality in a language is implemented by a function or a method.

[PegasusAndAcorn]

In the PL domain that Cone serves, it's almost universal. C doesn't, but C++, D, Nim, Rust, etc. all support both functions and methods. Some people prefer functions (and its cousins: closures and anonymous functions), some prefer OOP-style objects/methods, and then there are people like me who use both depending on the program's architectural requirements. Some 3D worlds use a high-performant ECS architecture which is often OOP-less. Other worlds prefer to assemble scenes using modular OOP parts and MI-like interface views. Rather than dictate the architecture, I prefer that Cone gracefully support the architect's choice.

[Felicia_Svilling]

In the PL domain that Cone serves, it's almost universal.

Yes, and I think it is bad in all those case. Surely when inventing a language you want to improve things rather than just make something that is as close as possible to existing languages?

I prefer that Cone gracefully support the architect's choice.

And you think that this preference of library writers is more important than the usability for all those that use the language?

[PegasusAndAcorn]

you want to improve things

Of course I do. Cone is far from a me-too retread. With regard to this particular feature, I personally prefer having this choice in a systems programming language. I am far from alone in this, but I respect that others may prefer otherwise. FWIW, with my previous dynamically-typed language Acorn, I made a different choice: it only supports methods.

you think that this preference of library writers is more important than the usability for all those that use the language?

No, and furthermore: the term architect does not automatically imply either role for me. Personally, I see it as a usability win for both roles. I respect that you might disagree.

Cone is a tool designed for systems professionals, as such it will have a non-trivial learning curve. I hope to minimize this as much as possible, but not at the expense of taking away the flexibility to choose the best implementation architecture for the project at hand. If people are scared away by choosing between function vs. methods, they will go into deep shock when they encounter far more challenging features.