@lltp: Sorry, I have misunderstood your point somewhat. The writing without IDE
is one thing, because that's possible even if not currently defaults, and to me
that doesn't seem like a super-important thing to design around (ymmv).
> I, as a developer, don't want to ever think about interactions with other's
> code.
However I can see what you're saying with this in the context of the Julia
threads, now I've had time to read the linked discussions. With regard to type
clashing in particular, I've experienced this myself in Nim, IIRC with SDL's
Color type and Color in the graphics module, many moons ago. Having said that,
prefixing the module to the type seemed like a bit of a wart to me as I never
had to do it elsewhere.
> But all that said putting namespaces everywhere, especially in small or
> "well-designed" programs, brings very little value with regard to the
> potential increase in verbosity.
And as vsajip shows out it's not so simple to force implicit imports.
However, do the Julie issues apply to Nim in the same way? Nim seems to
encourage overloading and auto-resolving, implicit self being an example of
this moving forward. I wonder if the patterns Nim encourages ameliorate this,
or not.
> I can keep the same code and just import the relevant map implementation. The
> compiler will use the correct overload based on the type of collection ... In
> Nim, dynamic dispatch is only used for methods, and relying on overloads of
> static dispatch is fundamental to get this kind of polymorphism ... [Julia]
> may suffer from this issue more than Nim because types are not fully
> determined ahead of time.
This is how I feel when about this issue. Compile time overloading seems to be
part of Nim's makeup. I've never felt the need to disambiguate things. However
I do wonder if there are limits to this.
>From a random one of the Julia GitHub issues: WARNING: New definition
>(Images.AbstractImageDirect, AbstractArray) is ambiguous with: (AbstractArray,
>Union{DataArrays.PooledDataArray, DataArrays.DataArray}, AbstractArray...)
Nim's typing is pretty strict and whilst I don't know Julia, these sort of
things don't seem like they'd clash. On top of that there's distinct types
which I'm not sure if Julia utilises, and provide another mechanism for
enforcing explicitness. On the other hand, because of this I'm used to
post/prefixing type conversions much more with Nim so I don't know if others
would find this a visual 'wart' (in this case the enforced explicitness is a
feature to me, though).
> usually the types are unique enough that this will not be an issue anyway,
> and if it happens final users are warned of the ambiguity at compile time, so
> that they can qualify
This is what I clumsily tried to express in my first post. It seems like a
fairly rare situation where you'd have code with the same signature and name
doing different things, and in these cases it's often easier to use a type
which allows you to leverage structural typing as well as disambiguating, but
again I'm not sure if this is just because of the smaller number of libraries
in the community.
