Comment by gugagore | Hacker News Reader

Comment by gugagore | Hacker News Reader

Parent Full thread

> If you can't trust gradients or probability distributions / sampling to be correct, that's a pretty damning verdict for a language aimed at numerical calculations.

If you draw the distinction between Julia the language and Julia the ecosystem, then that's not a damning verdict for the language, even if we accept the premise that you can't trust the computations you mentioned.

The way that Julia composes is unprecedented. Typical examples include computing with measurement uncertainty, or big floats through functions that were not explicitly designed to support those types. This is great, but the correctness of this composition cannot be assumed.

One good proxy for how this composition occurs is in many type combinations. As Here is a concrete, made-up example. There is a function you've been using without any problem that takes an argument of type `DenseArray{Float64, 2}`. (Meaning, the function gets called with an argument of that type. The function definition is not constrained to work on that type.)

If you've never focused on the correctness (e.g. reviewing the code, unit tests) of this function to see what it does on `SparseArray{BigFloat, 2}`, I would not take it for granted that it works.

This is perhaps too big a burden on a user. Some might say they rather not have the compositionality unless it's guaranteed to be correct. But, if you're actually asking me to imagine using Julia in a situation where I really want to be sure about the correctness of a Julia program, I would at the very attempt to characterize all the expected types to go into any function. If at runtime a function is called with a new type, I would log that, and possibly error out.

Note this is related to, but not equivalent to what's necessary to do "static" compilation in Julia.

> This is perhaps too big a burden on a user. Some might say they rather not have the compositionality unless it's guaranteed to be correct.

I think this is it. Or rather, I think to some people, myself included, compositionality should imply correctness. If you /can/ compose things, but the result is wrong, can you really say that you've got composition?

How useful it is really to be able to plug in your own types in other peoples libraries if you have to trace through the execution of that library, figure out which libraries they transitively use, to ensure that all of your instantiations are sound? How do you even test this properly?

It's a really hard problem, and from what I can tell, Julia gives you no tools to deal with this.

[0] is probably relevant here, although I'm not sure I share the positive outlook.

[0]: http://www.jerf.org/iri/post/2954

I don't have experience with using Julia in really large code bases but my intuition has always been that the combination of these design characteristics in one language:

- easy unrestricted composability

- lack of well-defined interfaces

- lack of an effective way to use the strong typing system to validate correctness

is not a very good idea.

I think Julia (mostly meaning pervasive multiple dispatch, which is unprecedented at that scale Julia has it) unlocks a new way to organize programs.

Some formalized notion of "interface" is certainly important, but it seems no clear formulation has emerged.

I think it's fairly consistent with the dynamic nature of Julia and fairly inconsistent with the static nature of Julia. I don't know what a good solution to the interface problem is.

I think one can get pretty far with writing tests to check interfaces. If you are a library that expects user-defined types, you can expose an interface to these tests so that a user can check if they've implemented everything.

This is a very generic approach, and aside from the key limitation of only giving results at runtime, is much more powerful.

Testing is certainly general but it's high-effort and it's easy to miss corner cases. I think type checking + some testing is going to beat testing alone in most scenarios.

We need to think about alternatives. It's easy to find issues and weaknesses in what Julia does, but we should consider what we would do with a different language to make a fair comparison.

If you don't want composition, then there's no issue and Julia can be as weak/strong as other languages.

If you do want composition, then I see two ways (but I'm sure there are others): you do the "typical" thing with glue code or you use the more "automatic" way that Julia provides. Which one is better? If this is too subjective: Which one is more correct?

Yes, Julia can propagate errors in unexpected ways, but how would you implement this in another language? You'd probably have to spend X hours writing glue code and Z hours writing tests to make sure your glue code is working. This also raises issues with maintainability when one of the two packages you're connecting /composing changes.

Julia offers a reduction on the X hours for writing glue code (sometimes with X = 0) and maybe a similar time Z writing test code. The maintainability, I'd argue, becomes easier.

The cost is the unknown unkowns that might creep up when doing this composition. My (extremely) subjective sense is that this doesn't happen that often to me (I don't usually pass approximation intervals to sparse matrix to auto differentiation to neural networks), which means the benefits outweight the cost in this regard. YMMV

Edited a few things for clarity

'Pro: saves X amount of coding hours. Con: may silently return wrong results.' is a terrible philosophy. It's like saying 'well, the surgeon messed up, but at least the surgery was cheap'.

There's nothing more silent about it than any other bug that arises in a similarly dynamic language. People use Python over C++ in large part because it saves X amount of coding hours, and comes with different kinds of bugs that can "silently return wrong results".

It seems you've picked the weakest version of what I said (which means communication becomes less likely)

Two points

1) the glue code you HAVE to write to make the composition in other languages and the mantianability issues you get also may introduce wrong results 2) MAY doesn't mean it will and we trade-off speed / convenience and risk in many other areas. Surgeons (or the health system in general) do trade off % of success for cost / speed, just because they don't have the resources to do everything / spend 100 hours on everyone

> If you draw the distinction between Julia the language and Julia the ecosystem

Language and ecosystem are so intertwined that I almost never do this. Maybe when there are multiple well developed ecosystems, but when there’s only one, then it and the language are inseparable to me (for any language, not just Julia).

I wonder if you feel that way as equally about C and Lisp as you do about Julia.

I remember Julia being pitched as a competitor especially for Matlab, but also R,... much more so do than for C or Lisp. So it seems like a fair comparison, and those are definitely to some extent seen as identical with their package ecosystem (in Matlab, most packages actually come from the same vendor, and base R utility is a tiny fraction of the utility of its packages).

Thanks for the explanation. Yeah, that is an interesting feature. Sounds like you'll have to do a lot of reading documentations and testing other packages yourself then. A typing system that allows defining accepted, rejected and 'other' data types for functions (and a compiler flag for either warning about the latter or not) would be interesting.

But the original critique also mentioned several correctness issues in the core language itself, so the issue does seem to go deeper.

There are several correctness issues lurking about in virtually all software. That part of the critique is uninteresting to me. If I want to pull up a blog post about several correctness issues in any programming language, I bet I could.

Also depends what you count as correct, see undefined behavior.

> Also depends what you count as correct

I feel that should be the job of the authors to think about what correctness means for their application, and under what circumstances they can give a correct answer. Ideally, also warn the user when the inputs don't fall within that domain or give them options to handle such cases.

Let's talk about an example: say you have a neat algorithm for fast multiplication of sparse matrices, approximately correct up to a defined Frobenius error. Say we have some reasonable treatment of dimension mismatch and NaN, inf,... with option flags already. Now if I wanted to know whether your algorithm has the same numerical guarantee for a dense matrix, I'd have to read your paper, run some tests, ask around, and I might never be quite sure.

It seems much more sane to put the onus on the authors to be explicit about the behaviour in that case. Your and others' comments seem to put the onus mostly on the user for thinking about the behaviour of others' code. That does not seem like a good practice, especially in the context of complex math and nested composition.

You could do something like this:

  plus_one(x::Number) = x + 1
  function plus_one(x)
    @warn "untested type usage of plus_one"
    x + 1
  end

That's cumbersome, but a macro could make it less annoying.

That is not a full solution to the problem of detecting untested types. What if "plus_one" works for Int, Float32, etc. but not with MyNumber, all of which would dispatch to "plus_one(::Number)".

Reply on news.ycombinator.com