Hacker News new | ask | show | jobs
by mattstir 43 days ago
> But the difference in memory is fundamental. The JVM can now store the values themselves in the array, laid out densely one after another: 8 bytes per point (plus a possible null flag), in a contiguous block. No headers per element. No pointers. No jumping around the heap.

How much was this article proof-read? Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit representations? Their `Point` is at least 65 bits (two 32-bit ints plus the null flag). The "plus a possible null flag" and oddly short following statements seem to suggest this was some AI that got sidetracked by trying to make emphatic statements... oh and also the "[IMAGE: the same Point[] array in two variants..." block halfway down the page is unfortunate.

8 comments

> No headers per element. No pointers. No jumping around the heap.

that smells of AI [1], and thus lazy writing. I'm all in for using AI to help you write, but if you don't put your voice to it then there's no reason to read it.

[1] https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing#...

> I'm all in for using AI to help you write

Don't be all-in. It's important for humans to be able to write for themselves, and also to stand by what's been written in their name, which is much less likely if someone/something else has done the writing.

(proofreading is another matter though.)

Also, the images were ruinously far off from what they intended to convey. Dude, just draw a picture by hand & take a picture of it.
That particular section is indeed AI, though other parts of the article aren't: https://www.pangram.com/history/89b28cd1-58e6-4065-9f1d-111a...
You see this in all the AI generated Tik Toks. What causes AI to use such a weird construction.
I learned that exact style of writing in a marketing workshop, pre-AI. It's effective, satisfying, and a random third thing I can't be bothered to come up with right now.

As a proportion of all easily crawled text on the internet, a lot of it will be random marketing copy. That influenced the writing style of early AIs, and since then everyone has trained at least partially on transcripts from every other AI chatbot

Oh my god did we inadvertently train AIs on idiotspeak.
It seems to be called the Rule of 3. see https://en.wikipedia.org/wiki/Rule_of_three_(writing)

Like Caesar's supposed "Veni Vidi Vici" saying, people seem to prefer and remember items when grouped in three.

I recall a public speaking film shown to my management science class starring John Cleese mentioning this rule of 3.

No, we actually trained it on standardised tests https://marcusolang.substack.com/p/im-kenyan-i-dont-write-li...
Thank you for sharing this. It brought together things I had suspected but not from his perspective. Also pleasant to read something that used rhetorical devices in a cohesive way instead of just as sprinkled on flavor packets.
In-advert-ently?
There was nothing inadvertent about it. A decade of cultivating and harvesting millions of examples of this kind of pseudo-writing from underpaid internet piece-workers preceded LLMs.
Given that this specific style is the result of being reinforced over and over again via RLHF, "inadvertently" isn't really the word I'd use.
> did we inadvertently train AIs on idiotspeak.

Nope! That is - training on lowest-common-denominator, low-signal high-noise "idiotspeak" was not at all inadvertent.

It's engaging and I doubt it happened by accident.
* Checks notes *

Reddit

Twitter

Facebook

4chan

Call of Duty chat logs

Every public marketing site

SlashDot

UseNet

...

Verdict: Yes idiotspeak was part of the training set, but no, it was not inadvertent. There's a smattering of Shakespeare in there, at least.

Wait until in 5 year's time all kids speak in rule of 3
Didn't you know? Evenly divisible numbers are infelicitous. That's why Atevi don't use them in polite conversation.
Not rule of one. Not of two. But three.
Exactly! But AI is here to stay. Sooner or later, even comments on HN will be 100% AI generated. And we won't be here to read them - our AI agents will. /s
That’s right. Because at some point, the volume of AI-generated posts and comments on sites like Hacker News or Reddit will overwhelm the ability of humans to read them all. So the only reasonable way for humans to participate will be to have our own AI readers summarising them, and posting furiously on our behalf!
I had that until I used Opus 4.8.

It stopped being infuriatingly sloppy and took time to ensure the article had integrity.

It did having said that I did burn through a lot of tokens trying to do a deep analysis cross data pipeline debug.

I really wanted to read this, it seems like a really interested subject. I can even forgive the AI generated images. But after a few paragraphs it became clear this was either fed through an LLM or worse.

Please, if you write a technical blog, or anything really: Stop. Stop letting the AI write for you. Nobody wants to read this.

18446744073709551616 possible values and you can't spare 1 for null? :)

TIL that Rust has NonZeroU64 which you can combine with Optional to get the required behaviour with only 64 bits per entry. [1]

[1] https://doc.rust-lang.org/std/num/type.NonZeroU64.html

Especially because signed integers aren't symmetrical. Reserve INT_MIN and you get 8 billion NaN values and multiplying by -1 always gives you a valid location.
Ah, INT_MIN. If I had a nickel every time I saw an implementation of inttostr/strtoint that don't properly handle it, I'd probably have about $5. So I too thought about possibility of it serving as a NaN of signed integers... but I doubt we'll see it any time soon.

Also, apparently, shifting a negative number to the left is UB in C.

Left shifting a large positive number is also UB. C made a lot of things undefined that would make much more sense as implementation defined.
Yep. Basically, if you take a signed int/long/etc. and a set bit shifts left into the sign bit — UB.

> a lot of things... would make much more sense as implementation defined.

Or even just defined. Apparently, the fact that shifting right a signed number is done arithmetically, not logically, is implementation-defined too.

Well, at lest bitwise not/and/or are (almost) fully defined even for signed integers, so that's something.

Well at the time it made sense not to force two's complement. But I would try harder to trim the UB list over time.
Java has always had this juxtaposition in language design where they don't want you to think hard about value types (hence no unsigned types), but the types themselves are precisely defined down to the specific bit pattern representation in bytecode. This is essentially hardcoded into the JVM and its bytecode specification and is too hard to change for compatibility concerns.

Luckily we have Valhalla, which is an admission that Gosling was partially wrong, and programmers who want to have an unsigned nullable non-zero 64-bit integral value type can just make one, and not have to pay outsized memory costs to do so.

If we're done paying homage to Gosling, can we get operator overloading for our fancy value types please? I have no idea if this is on the radar for Valhalla.

In many cases, NonMaxU64 and NonMinI64 (aka SymmetricI64) would be much more useful though. But Rust is aiming to eventually add a more general way to create types with user-defined ranges, such as the "pattern types" feature currently being prototyped.
The obviously used too much AI, I stopped after 2 paragraphs
The first two paragraphs are

> On June 15, Oracle engineer Lois Foltan confirmed what a good chunk of the industry had stopped believing: JEP 401: Value Classes and Objects will be integrated into the main OpenJDK repository and is targeting JDK 28.

> The change is so large that the remaining committers were asked to hold off on bigger commits during the integration. The pull request alone adds over 197 thousand lines of code across 1,816 files.

What in those paragraphs is obviously AI?

These days I'm having second thoughts about pictures that I am pretty certain can't be AI but just have that look. It's strange but I've noticed it happening more and more.
I mean I’m only answering that because you’re asking, nothing set me off personally there, but now that you ask:

« The pull request alone adds over 197 thousand lines of code across 1,816 files. »

I noticed that both Claude and GPT are fond of those kind of stupid accounting statements that don’t mean a lot in and of themselves, but look impressive in a « wow numbers » way. Which is kind of ironic since counting remains one of their weak points

Yeah its definitely inconsistent level of specificity. It's "roughly" 197 thousand files, and yet at that scale a human would call it 200 thousand lines of code, and then an exact count of files at 1,816 instead of a similar level of estimation.

For instance I might write this "The pull request alone adds nearly 200 thousand lines of code spanning almost two thousand files", or even better just "The pull request alone adds nearly 200 thousand lines of code" because really who cares how those are broken up into files.

As a human (as far as I know...) there is a decent chance I'd write it like that, depending on the exact numbers.

It said "over 197 thousand". That's what I'd probably say for a number in [197000, 197999], or maybe "under 198 thousand depending on where it is in that range.

Saying "nearly 200 thousand" is still 3 digits so doesn't save any space over 197 or 198, and I think with it only being 3 digits most people will assume only the last digit is rounded. 200 ending in a string of 0s does suggest it might be rounded to the nearest 10 or nearest 100, but it just could easily not be.

I'd almost certainly fully write out 1816. If it were common to spell out groups below 1000 like 100s and were going to that I might write it as something like "just over 18 hundred" or "almost 19 hundred", but I almost never see anyone use grouping sizes of less than 1000.

I understand ai hate but I would rather avoid a future where everybody talks in purposely weird and unstructured sentences to avoid being similar to ai

By necessity a lot of people write very similarly to how llm do

I'm tired of people jumping in to point out "AI, AI". The article is very good and informative. That is the only important thing. Geez.
No, it’s not the only important thing. The complaints about it should tell you that.

People care about provenance a lot.

Whether it’s a drawing my daughter did of her mother, a Picasso napkin sketch, a worn 1960s Stratocaster, or an blog essay, the provenance is value on top of the correctness of the item.

Strange comparison, the Strat has sentimental and historical value. I don’t collect and cherish articles about Java.
Yep, I used an example where the provenance value was obviously large to make it very clear.
>The article is very good and informative.

But you don't know which parts of it are true.

> Didn't they just get finished talking about how heap flattening won't work for objects with > 64-bit representations

In this initial commit. As was made clear in the JEP, this is just the first deliverable of a huge feature that, like all Java features in recent years, is being delivered piecemeal. Obviously, the point is to flatten larger values (the mechanism is already in the JVM; what remains is exposing the intent of "I allow tearing" in the language).

> This is exactly the moment where non-nullability stops being cosmetics and becomes a lever for performance.

Looks like they just missed the `!`. It should be `Point![]`.

I'm confused about the 2008 Bloomberg article image in the first slot... right after implying the effort started in 2014. With nothing mentioning anything in there.

Is there a way we can request a "flag as AI garbage" downvote for articles? Or should we just flag them?

I thought this was an ad bugging out. I use an adblocker. Very confusing.
I initially took it for an ad too, and just didn't bother looking at it. Then I noticed it was oddly small, and the more I looked the stranger it got.

It adds a fair bit to that "did anyone proof-read this? pretty obviously no?" vibe.

I've been sadly using too much Claude not to immediately recognize this verbal construction...