Allowing the object.method(args...) syntax as an alias for method(object, args ...)

To simplify for the sake of conversation that problem that I’m trying to solve is: if I have to start a project tomorrow within a large company, with a team of 100 people, all highly skilled but busy and with very different backgrounds/interests: quality engineers, electrical engineers, ML researchers, software engineers, some physicist, some mathematicians (some with a background in Python, some Matlab, some C, some C++) I want a convincing story of why using Julia would be a good idea and have answers for the obvious questions coming from those people. Nobody will want to start a project and realize after 6 months that the code is a unmanageable mess, and now we are stuck with it for another 18 months, etc etc. Or that I have to babysit 100 people everyday because the learning curve is too steep, etc, etc.

It’s a very “practical” problem of how a group of people wants to invest time/resources and evaluate risk, etc.

Within that “context” I was then trying to build a mental model of the current state of the language, community, etc.

This process prompted the original question of this thread and then of Regarding `getproperty` and public vs. private APIs. I guess similar in spirit to What don't you like about Julia for "serious work"? .

Going back to the specific issue, I guess yes, it’s a combination of encapsulation and auto-completion, for the case where there is a very specialized set of complex objects/blocks. The question about the modules come from the idea that I could sacrifice the ability of having multiple instantiations, if I can have the other 2 properties right now, while we wait for the language to possibly evolve, etc, etc…

PS In the same spirit I was of course looking at the status of the debugger, VS code integration, Pluto vs Jupyter, plotting, loading dynamic libraries in concrete examples, ability of deploying Julia “jobs” on clusters where Julia is not installed, ability to use GPUs, etc, etc