6 ms·

That reads to me more like a long-winded example of a Julia user refusing to take correctness issues seriously, and instead using an LLM to self-soothe by defle

That reads to me more like a long-winded example of a Julia user refusing to take correctness issues seriously, and instead using an LLM to self-soothe by deflecting onto other projects: > I think there’s also a mindset split, some people just like to have things more strict and avoid bugs by having their compiler proof everything, and others like more freedom and are fine with occasional mishaps. > Just for the fun of it, I put claude on Python, and it also found some eye watering correctness issues (to be fair, I haven’t taken the time to verify and judge them, but it seems like that’s a similar situation for the Julia version) I say "self-soothe" because if the intention were to better understand the correctness situation, presumably one would at least want to evaluate the output before declaring it "eye watering". And then even if the output was real, it would be better to report it to the affected Python projects instead of using it as an excuse to downplay problems in Julia. But most of the supposed "bugs" seem like totally fine/reasonable behaviors to me, often for clearly nonsensical inputs. Seriously, `np.array([1, 'two', 3.0])`? That's not a bug, the behavior is clearly documented on numpy.org, but really no matter what Python does with that, it's not comparable to issues like `prod([Int8(100), Int8(100)]) != prod((Int8(100), Int8(100)))` from that post about Julia. Which again the linked Discourse post downplays as "freedom and occasional mishaps".

jakobnissen 12d ago
You can not be serious in suggesting these aren’t straight up Python correctness bugs. Exactly the same kind that Yuri brought up as damning evidence of Julia unseriousness, but for Python with easily 25x the user base.
- Intralexical 12d ago
  Most (all?) aren't bugs by any stretch of the imagination, no. Let's go over the first 5. 1. random.choices(['a','b','c'], weights=[-1,5,1], k=10000) Negative weight on 'a' silently shifts Python docs say, "Weights are assumed to be non-negative and finite." Garbage in, garbage out. 2. random.choices(['a','b','c'], cum_weights=[5,2,7], k=10000) Non-monotone cum_weights makes 'b' unselectable. ...Those weights aren't cumulative, which the docs say they should be. Again, garbage in, garbage out. 3. statistics.fmean([1,2,3], weights=[-1,1,1]) “Mean” of three values in [1,3] returns 4 — outside the convex hull. This is just straight-up mathematically correct behavior. It preserves linearity. It fits the commonly accepted definition of weighted mean as `(w1*x1+w2*x2...)/(w1+w2...)`. The LLM fabricated a fake/idiosyncratic definition of weighted mean in order to claim it's a bug, because it was instructed to come up with bugs. 4. json.dumps({1: 'a', '1': 'b'}) Produces invalid JSON with duplicate keys; round-trip silently drops one entry. Again, documented behavior/GIGO. Docs say, "loads(dumps(x)) != x if x has non-string keys." 5. urlparse('http://example.com/?').geturl() Trailing ? (empty query) and # (empty fragment) silently stripped This is literally just what geturl() is supposed to do. It's the whole point. Docs say "empty parameters, queries, and fragment identifiers will be removed". The LLM is claiming that geturl()'s primary intended purpose is a bug. So all of these "eye watering correctness issues" so far seem to be either (1) straight-up correct, or (2) doing things Python explicitly tell you not to do. Same deal with the Numpy "bugs", AFAICT, as I touched on in my previous comment. In fact, I would venture that we all know those Python bugs are fake, but (unfortunately) the Julia ones aren't. Because the Julia bugs mentioned by Yuri were reported to the Julia bug tracker, and eventually fixed. Whereas if you really thought these are real bugs in Python, then (IMO) you should be reporting them to the Python tracker, not getting mad at me for doubting them. Moreover, even if they were real bugs in Python (which they aren't), bugs existing in Python still wouldn't change the situation for Julia. The Discourse user who posted it still admitted that they didn't even take the time to verify them. Surely you must realize how bad it makes Julia look, when its users fling LLM slop to attack Python in response to Julia's issues being brought up? A constructive project should instead talk about what's been done and planned to improve Julia's situation, not tell lies to drag Python down. I liked Julia when I tried it! The JIT plus multiple dispatch is so unique. But this so isn't the way.
  - postflopclarity 11d ago
``` >>> x = [2*53, 2*53 + 2] >>> statistics.covariance(x, x) 4.0 >>> statistics.variance(x) 2 ``` python has plenty of bugs like these too. is this example also "LLM slop" ? I think it's frankly delusional to somehow believe that these issues are unique to Julia.
postflopclarity 12d ago
> But most of the supposed "bugs" seem like totally fine/reasonable behaviors to me exactly. and the same is true for many of the bugs that have been presented as indictments of Julia. but when the same is said of those, the community is called "defensive." so it's a lose-lose.
- Intralexical 12d ago
  There is no equivalence here. The Julia bugs were real. They were reported, accepted, and fixed. The Python bugs you linked to are fake LLM slop, see my other comment right above/below this one. [0] If anyone really believes the Python bugs are real, they should report it to Python, not use it to deflect from Julia's issues. What's been presented as an indictment of Julia (in Yuri's own post and after) is the fact that members of the Julia community have vocally downplayed problems and played the victim when quality concerns have been raised, as I think you're doing. Do you want to convince everybody you've "won" "a lose-lose"? Or do you want to write correct programs? I like Julia, the language and the tech. I really hope this hostile attitude towards criticism and growth fades eventually, because I'd like to be able to use and trust it at some point. [0] https://news.ycombinator.com/item?id=49570973 https://news.ycombinator.com/item?id=49570973
  - postflopclarity 12d ago
    I am not hostile to criticism. > If anyone really believes the Python bugs are real, they should report it to Python I have reported several bugs, both to Python and to Julia. I'm not going to engage further in this thread, but if you want to continue discussion I'd be happy to chat somewhere else that's a little less clunky

jakobnissen 12d ago

You can not be serious in suggesting these aren’t straight up Python correctness bugs. Exactly the same kind that Yuri brought up as damning evidence of Julia unseriousness, but for Python with easily 25x the user base.

Intralexical 12d ago
Most (all?) aren't bugs by any stretch of the imagination, no. Let's go over the first 5. 1. random.choices(['a','b','c'], weights=[-1,5,1], k=10000) Negative weight on 'a' silently shifts Python docs say, "Weights are assumed to be non-negative and finite." Garbage in, garbage out. 2. random.choices(['a','b','c'], cum_weights=[5,2,7], k=10000) Non-monotone cum_weights makes 'b' unselectable. ...Those weights aren't cumulative, which the docs say they should be. Again, garbage in, garbage out. 3. statistics.fmean([1,2,3], weights=[-1,1,1]) “Mean” of three values in [1,3] returns 4 — outside the convex hull. This is just straight-up mathematically correct behavior. It preserves linearity. It fits the commonly accepted definition of weighted mean as `(w1*x1+w2*x2...)/(w1+w2...)`. The LLM fabricated a fake/idiosyncratic definition of weighted mean in order to claim it's a bug, because it was instructed to come up with bugs. 4. json.dumps({1: 'a', '1': 'b'}) Produces invalid JSON with duplicate keys; round-trip silently drops one entry. Again, documented behavior/GIGO. Docs say, "loads(dumps(x)) != x if x has non-string keys." 5. urlparse('http://example.com/?').geturl() Trailing ? (empty query) and # (empty fragment) silently stripped This is literally just what geturl() is supposed to do. It's the whole point. Docs say "empty parameters, queries, and fragment identifiers will be removed". The LLM is claiming that geturl()'s primary intended purpose is a bug. So all of these "eye watering correctness issues" so far seem to be either (1) straight-up correct, or (2) doing things Python explicitly tell you not to do. Same deal with the Numpy "bugs", AFAICT, as I touched on in my previous comment. In fact, I would venture that we all know those Python bugs are fake, but (unfortunately) the Julia ones aren't. Because the Julia bugs mentioned by Yuri were reported to the Julia bug tracker, and eventually fixed. Whereas if you really thought these are real bugs in Python, then (IMO) you should be reporting them to the Python tracker, not getting mad at me for doubting them. Moreover, even if they were real bugs in Python (which they aren't), bugs existing in Python still wouldn't change the situation for Julia. The Discourse user who posted it still admitted that they didn't even take the time to verify them. Surely you must realize how bad it makes Julia look, when its users fling LLM slop to attack Python in response to Julia's issues being brought up? A constructive project should instead talk about what's been done and planned to improve Julia's situation, not tell lies to drag Python down. I liked Julia when I tried it! The JIT plus multiple dispatch is so unique. But this so isn't the way.
- postflopclarity 11d ago
``` >>> x = [2*53, 2*53 + 2] >>> statistics.covariance(x, x) 4.0 >>> statistics.variance(x) 2 ``` python has plenty of bugs like these too. is this example also "LLM slop" ? I think it's frankly delusional to somehow believe that these issues are unique to Julia.

postflopclarity 12d ago

> But most of the supposed "bugs" seem like totally fine/reasonable behaviors to me exactly. and the same is true for many of the bugs that have been presented as indictments of Julia. but when the same is said of those, the community is called "defensive." so it's a lose-lose.

Intralexical 12d ago
There is no equivalence here. The Julia bugs were real. They were reported, accepted, and fixed. The Python bugs you linked to are fake LLM slop, see my other comment right above/below this one. [0] If anyone really believes the Python bugs are real, they should report it to Python, not use it to deflect from Julia's issues. What's been presented as an indictment of Julia (in Yuri's own post and after) is the fact that members of the Julia community have vocally downplayed problems and played the victim when quality concerns have been raised, as I think you're doing. Do you want to convince everybody you've "won" "a lose-lose"? Or do you want to write correct programs? I like Julia, the language and the tech. I really hope this hostile attitude towards criticism and growth fades eventually, because I'd like to be able to use and trust it at some point. [0] https://news.ycombinator.com/item?id=49570973 https://news.ycombinator.com/item?id=49570973
- postflopclarity 12d ago
  I am not hostile to criticism. > If anyone really believes the Python bugs are real, they should report it to Python I have reported several bugs, both to Python and to Julia. I'm not going to engage further in this thread, but if you want to continue discussion I'd be happy to chat somewhere else that's a little less clunky