Julia is moving in the direction of having a static sub-language and even things like enforceable interface/etc. However, if we are not VERY careful, we can lose one big advantage that Julia has, easy generic. Duck typing allows easy, intuitive generic code, for example, if you want to print foo, y…

[image] Tarny_GG_Channie: What Julia offers is fast, generic, easy code. That is something I believe we should hold on for dear life. I don’t know enough about the ongoing interfaces debate, but as an avid end user I pray that Julia doesn’t wind up requiring the kind of clunky syntax I often …

Static interfaces are not at odds with generic code. In fact, the opposite is true: interfaces are how you make generic code safe. Consider function mynorm(v::Vector{Float64}) r = 0.0 for i = 1:length(v) r += v[i]^2 end return sqrt(r) end This is not generic, but perfectly…

That idea could be true in theory. In practice, interface often means you make an overly conservative assumption, or that you need some sort of concepts to capture all sorts of complex assumptions, which require abstract algebra. For instance, there are some things whose assumptions are the associat…

That idea could be true in theory. Very much true in practice, and one of the top things people complain about whenver Julia makes it to Hacker News or some similar forum where people like to complain a lot. In practice, interface often means you make an overly conservative assumption. No, yo…

They do often design things too conservatively sometimes, even if they don’t know it. For example, does the Java type have the information that the foo of bar of baz of something can be multiplied by an integer if baz of something is not always the case? Then you have monad/etc pattern to capture co…

[image] goerz: it makes unspecified assumptions about v (that it is a one-based AbstractVector of numbers) It’s a reasonable guess, but strictly speaking it actually doesn’t make those assumptions. What mynorm(v) presumes is 1) length(v) is supported, 2) getindex(v, i) is supported for i in 1…

Yeah… though you actually didn’t need an abstract vector type either. A dict would also do.

You could, but in my opinion it’s not sensible to expand to non-vectors from Vector{Float64}. Then again, it may not be sensible to expand to nonnumerical element types from Float64. That can be taken care of with function mynorm(v::AbstractVector{T}) where T<:Number, and that can replace the eltype…

I think it’s sensible to expand to tuples for example, in case someone uses tuple to represent a fixed size vector. (or dicts to represent vectors whose dimensions are named.)

How can we maintain easy generics in the face of demand for a “safe” language?

Internals & Design

mbauman February 5, 2024, 3:38pm 3

There’s not too much sense in preemptive hand-wringing here. There’s not even a concrete pull-request or proposal for what interfaces might look like.

Topic		Replies	Views
Could introducing formal interfaces be nonbreaking? Internals & Design speculative	36	1060	June 4, 2025
What interface bugs have you ran into in the ecosystem? General Usage question	35	1743	January 31, 2024
Comparison of Julia with statically typed languages New to Julia question	10	2414	June 9, 2024
Structural subtyping New to Julia question	36	3137	July 14, 2021
How is it that new Julia programmers tend to abuse type annotations? Teaching & Outreach	96	5663	January 15, 2024

How can we maintain easy generics in the face of demand for a “safe” language?

Related topics