[munificent]

> the culture of not prioritizing correctness in computation.

In a language with pervasive use of generic methods, I don't know what actually means. If I write a function like:

    function add3(x, y, z)
      x + y + z
    end

Is it correct or not? What does "correct" even mean here? If you call it with values where `+` is defined on them and does what you expect, then my function probably does what you expect too. But if you pass values where `+` does something weird, then `add3()` does something weird too.

Is that correct? What expectations should someone have about a function whose behavior is defined in terms of calls to other open-ended generic functions?

[hatmatrix]

I should have been more precise in my language - it's not numerical correctness but composability correctness. They won't appear in a simple example like the one you provided, but more complicated ones are provided in the original post - in the example it partially centers around how getindex should be used with a particular struct and so on.

[munificent]

There's nothing numerical in my comment. There's just arguments and function calls, which happened to be named "+".

My point is that there is an implied contract that `add3()` only does what you expect if you pass it values where `+` happens to do what you expect. When you have a language with fully open generic methods like Julia, it's very powerful, but the trade-off is that every function is effectively like middleware where all it can really say is "if you give me things that to delegate to the right things, I'll do the right thing too".

When I'm writing `add3()`, I don't know what `+` does. I'm writing a function in terms of open-ended abstractions that I don't control, so it's very hard to make any promises about the semantics of my function.

[yurivish]

Your perspective tracks with mine. Without contracts, either specified in documentation or as static guarantees, it is hard or impossible to build robust programs.

In Julia it's almost as if every function is an interface, with (usually quite terse) documentation as its only semantic constraint. For example, here is the full documentation for `+`: https://docs.julialang.org/en/v1/base/math/#Base.:+

I love Game Programming Patterns, by the way! Laughed out loud when I first saw the back cover.

[munificent]

> Without contracts, either specified in documentation or as static guarantees, it is hard or impossible to build robust programs.

Right. I think a big part of this is expectation management. Julia lets you compose unrelated libraries much more freely than most other languages do. That's very powerful, but if you come into it expecting all of those compositions to magically work, I think you just have an unrealistic expectation.

There's no silver bullet when it comes to code reuse and Conway's Law can't be entirely avoided.

> I love Game Programming Patterns, by the way! Laughed out loud when I first saw the back cover.

:D

[yurivish]

> Julia lets you compose unrelated libraries much more freely than most other languages do. That's very powerful, but if you come into it expecting all of those compositions to magically work, I think you just have an unrealistic expectation.

Yep, and it is unfortunate that this unrealistic expectation is explicitly encouraged by the creators of the language:

> It is actually the case in Julia that you can take generic algorithms that were written by one person and custom types that were written by other people and just use them together efficiently and effectively.

It seems worth reiterating that on a personal level I really like and appreciate the vast majority of the folks I’ve met in the Julia community. I’m glad I got to hang out with them and learn from them. But in my opinion setting expectations like this fosters bad science.

[munificent]

Agreed 100%.