Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Correctness and composability bugs in the Julia ecosystem

yuri.is

Post reply on HN
Print view View original

361–370 of 419 posts

Re: Correctness and composability bugs in the Julia ecosystem

#361

Post by sdfhdhjdw3 »

wnoise wrote: post #161
sdfhdhjdw3 wrote: post #116

Earlier quoted context omitted.

No... in those cases you're starting with 0 because that's the lowest exponent of a polynomial.

You're saying no while explaining my reasoning. What index to start with only strongly matters when the indexes have semantics. Otherwise you should just treat it as an opaque index, i.e. eachindex(), keys(), etc. In math when there are semantics, the indices usually include 0. When not (vector components, matrix indices, etc), they usually (but not uniformly) don't. The one nice side-benefit of Julia's mistake in ad…

I'm not "explaining your reasoning" because I don't agree with a single work you just said.

> In math when there are semantics, the indices usually include 0

Complete nonsense. For example, in a Laurent expansion you start in the negatives and go up. Now you're gonna say "but that's an exception, I said _usually_". But it's not, this is the general case.

Re: Correctness and composability bugs in the Julia ecosystem

#362

Post by JustFinishedBSG »

HelloNurse wrote: post #356
KenoFischer wrote: post #108

So this one is a tough one for me, because Yuri has certainly spent significant time with Julia and I think he's a very competent programmer, so his criticism is certainly to be taken seriously and I'm sad to hear he ended up with a sour opinion. There's a lot of different issues mentioned in the post, so I'm not really sure what angle to best go at it from, but let me give it a shot anyway. I think there's a couple…

> there are a number of "flagship" applications that are really pushing the boundary of what Julia can do, but at the same time also need a disproportionate amount of attention. Disproportionate effort is an obvious sign that hacks to keep such flagships seaworthy are prioritized over a good language and a good library. > Basically, Julia tries very hard to make composability work, even if the authors of the packages…

> Disproportionate effort is an obvious sign that hacks to keep such flagships seaworthy are prioritized over a good language and a good library.

I do not think this is true; from my limited Julia experience the reason the flagship features need disproportionate efforts is precisely because they are research project and the developers make sure they are not hacks.

Re: Correctness and composability bugs in the Julia ecosystem

#363

Post by jerome-jh »

Sukera wrote: post #226
StefanKarpinski wrote: post #222

Earlier quoted context omitted.

The big language design problem that I think this post highlights is that the flip side of Julia's composability is that composing generic code with types that implement abstractions can easily expose bugs when the caller and the callee don't agree on exactly what the abstraction is. Several of the bugs that Yuri reported are a very specific case of this: there's a lot of generic code that assumes that array indexing…

To expand on the "interfaces are not enough" part: Defining an interface on an abstract type only gives you that a implementation exists, not that it is correct , i.e. that the specific implementation for a subtype guarantees the same properties the interface specifies. On top of this, you really want to be alerted to when you expect more of an interface than the interface guarantees - this is what happened in the ca…

I think the OP specifically complains about the use of @inbounds and that the documentation was advocating an invalid use of it. Some libraries may not have been updated to handle AbstractArray: that's normal SW rot. But the out of bound access being unreported is the actual grief of the OP.

Re: Correctness and composability bugs in the Julia ecosystem

#364

Post by ModernMech »

nickm12 wrote: post #348
ModernMech wrote: post #229

Earlier quoted context omitted.

The reason why this 0 vs 1 based indexing debate is never resolved is because all of the arguments are subjective. You've claimed definitively that "humans got it wrong", but to back up this argument you've pointed to vague notions of "elegance" and "understandability". Even Dijkstra in his argument relies on a notion of "ugliness". All such arguments fall squarely in the realm of "preferences". Just think about what…

There are non-subjective arguments. See EWD831: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...

I referenced that one in my post. It hinges on a concept of “ugliness” which as I said can mean anything to anyone. It also presumes that this argument based on ugliness is the only one; even if we take his entire argument at face value, that the method he proposes is more “beautiful” than the rest and we agree on what that means, we still can’t say it’s the preferred methods in situations where beauty or ugliness of code doesn’t matter, because Dijkstra doesn’t even acknowledge they exist.

Re: Correctness and composability bugs in the Julia ecosystem

#365

Post by ModernMech »

IshKebab wrote: post #335
ModernMech wrote: post #274

Earlier quoted context omitted.

It's subjective because you haven't defined or quantified elegance or understandability. I could say that zero based indexing is not in fact understandable based on the amount of confusion I encounter explaining the concept to new users. I could say it's inelegant based on the fact it makes algorithms I use harder to implement. Others argue it's more elegant because it makes algorithms they use easier to implement. S…

You encounter confusion explaining it to new users because they've learned it wrong their whole lives . Nobody has any trouble in the UK with lifts where the ground floor is 0 - one of the few places where humans got it right.

Right but the existence of confusion cuts against your argument it’s more understandable. What you really mean is your brain works differently than everyone else’s, and you find something straightforward which they find confusing, therefore they are just thinking wrongly and it turns out your brain is the one with the correct worldview.

That’s certainly a perspective.

Re: Correctness and composability bugs in the Julia ecosystem

#366

Post by ThenAsNow »

pron wrote: post #358
ThenAsNow wrote: post #250

Earlier quoted context omitted.

We can trade anecdotes on this topic, but I've written numerical code in OCaml and also Julia. The strictness of OCaml's type system is painful in a numerical context but for virtually all other things it is awesome to pass code into the interpreter/compiler and catch structural problems at compile-time rather than maybe at runtime. OCaml's type system is almost certainly not the right model for Julia but the ad-hoc…

"Awesome", i.e. more enjoyable for you, and "more correct", i.e. fewer bugs in production, are two very different things. I also prefer typed languages for the software I tend to write and find them more enjoyable, but that still doesn't make me claim that types lead to more correct software.

I am not familiar with the studies you are relying on to make the point that statically-typed languages have no significant difference in terms of number of bugs in production compared to dynamically-typed. Measuring such things is challenging, and the most useful measure may not be in terms of "bugs in production" but by a number of other measures, such as how long it takes to surface bugs after the code is accepted by the interpreter/compiler, how much time is spent on writing the implementation vs. writing & running tests, how many bugs occur on major refactorings, etc. If you have citations for studies you like, I'm certainly interested.

My use of colloquialism aside, it is strictly more rigorous to catch equivalent bugs through the interpreter/compiler than through testing or other runtime-dependent approaches. In my own experience, despite being a more experienced programmer in my Julia-writing phase than in my OCaml-writing phase, it takes much more time to surface bugs in my "running" Julia code than OCaml. The lack of determinism in surfacing these bugs does not suggest as much confidence in the Julia code. You could counter by saying I'm probably able to implement more functionality in Julia per unit of up-front development time than the equivalent development time in OCaml, which I'd probably have to concede, but that just highlights measuring these things in a directly-comparable way is not easy.

In the physical engineering disciplines, we often have disagreements about the level of sophistication of physics-based models that should be used for design and analysis. It's very reminiscent of these static vs. dynamic typing discussions in software development. There isn't a "one size fits all" answer, but generally, the more complex and expensive the system, the more important the models incorporate greater physical fidelity. My analogous conclusion here is a lot of technical/numerical code is complex enough that more rigor enforced by the language would likely be the right tradeoff for a net win on up-front correctness (vs correctness as a result of testing).

Re: Correctness and composability bugs in the Julia ecosystem

#367

Post by pdeffebach »

wnoise wrote: post #193
pdeffebach wrote: post #167

Earlier quoted context omitted.

What semantics are expected in other languages? This seems solidly in the realm of undefined behavior as far as I can tell.

The obvious semantics for these functions is that f!(a, args...) should do the same thing as a .= f(args...). It's only undefined behavior because the simple implementations don't do that in the presence of aliasing. I brought up memcpy() and memmove() (which in C are copying identity functions on bytes) exactly for this point. memcpy() has undefined behavior when the source and destination ranges overlap (implementa…

Thanks for the detailed response.

Yeah allocation seems like the biggest hangup here. I would rather have a function stick to a "no allocating" contract and allow for some undefined behavior than have a function unexpectedly allocate to preserve safety.

Re: Correctness and composability bugs in the Julia ecosystem

#368

Post by adgjlsfhk1 »

JonChesterfield wrote: post #352
cleandreams wrote: post #334

Unfortunately this is not a feature but a bug, and the worst kind, a bug at the language design level: Basically, Julia tries very hard to make composability work, even if the authors of the packages that you're composing don't know anything about each other. That's a critical feature that makes Julia as powerful as it is, but of course you can easily end up with situations where one or the other package is making im…

It's an interesting point in the language design space. Composing unrelated projects gives a rapidly increasing state space of interactions which noone is directly responsible for. I can't decide if that's brilliant or broken by design.

why not both?

Re: Correctness and composability bugs in the Julia ecosystem

#369

Post by jolux »

pron wrote: post #357
jolux wrote: post #318

Earlier quoted context omitted.

> You have not seen me argue anything along those lines. I have, however, said the converse, that we try not to adopt features in Java until they've proven themselves elsewhere. You’ve definitely argued that not enough software has been written in Haskell to know whether it’s the right tool for anything and whether strong types are actually a good idea. > But the implication is reveresed! From A => B, i.e. types prev…

> to know whether it’s the right tool for anything and whether strong types are actually a good idea. Nope. I don't know what you mean by "a good idea", and I prefer typed languages myself (mostly for tooling support), but I do often point out that the claim that types improve correctness — let alone the claim that they do that better than other approaches — is an empirical claim that is not supported by empirical ev…

> Types certainly eliminate various kinds of errors, yet studies did not find that they reduce bugs

Right, but this is why I asked about structured programming. These things are hard to study by their nature. I understand there’s not a consensus on this, but there are a lot of programmers who feel quite strongly that static types reduce bugs. Maybe that’s not good enough for you! But it’s clear that you accept other practices as beneficial on insufficient evidence. Or maybe you don’t — maybe you don’t think writing correct unstructured programs is harder.

> most catastrophic crashes in distributed systems occur not because programmers fail to consider certain exceptional situations

This is irrelevant though. The question is not whether static types prevent the most common types of bugs, or the most dangerous (it’s clear that memory safety is more important than static types in that regard.) If static types narrow the problem space to situations where you explicitly made the wrong decision, that’s significant. If there are any bugs caused by not handling exceptional conditions (and we both know that there are), then static type systems help reduce those.

Re: Correctness and composability bugs in the Julia ecosystem

#370

Post by cestith »

my123 wrote: post #107
mcv wrote: post #70

Earlier quoted context omitted.

Is C/C++ really such a better choice in safety-critical systems? It's notorious for having all sorts of buffer overflows and memory issues on unexpected input.

MISRA C or MISRA C++ are used, enforcing much stricter guarantees than what the C or C++ specs provide.

IMO MISRA C, CERT C, and CERT C Secure should be standardized together into a compiler with a different language name. I'm aware there are other tools. If the compiler itself enforced everything to do with those standards and rejected violations as invalid code, we could have a much improved grounding for that language. There are already languages similar to a safer C, so we know there's a demand.
Post reply on HN