smarks

I've had some discussions with the author on this topic, some of which might have led to his writing this article.

One of the issues we discussed is trying to do this with Java arrays or collections. As he observes, Java arrays have a maximum size of 2^31 - 1 elements, because they're indexed by a signed 32-bit int. In practice, the Hotspot JVM has a maximum array size of 2^31 - 2 elements. (I'm not entirely sure why this is. I'd guess that it's because the various GC implementations have a maximum memory block size of 2^31 words, and two words are consumed by the object header.)

The author considered trying to store 10B elements in a Java Collection, but there are some roadblocks that make this either difficult or insurmountable.

A Java ArrayList stores all its elements in a single array; thus it has the same limitation as Java's arrays. This is a pretty hard limit.

A Java LinkedList can actually store more than 2^31 elements. It's a non-intrusive linked list, so each element has a separate list node, which is another Java object. Each list node object consumes 40 bytes (including the object header and fields) which means that storing two billion elements in a LinkedList has 80GB of overhead, not including the actual data elements. (And ten billion elements will require 400GB of memory for overhead.) This will probably work if you have enough memory, but this amount of overhead seems prohibitive.

The author instead used the `fastutil` library to work around these limitations.

Pretty impressive that Pharo Smalltalk is able to do this.

Yes, very strange to see this flagged. Doesn't seem controversial at all.

Cool! Yes, that’s been our experience in Java as well. The randomized order of unmodifiable Set and Map (from `Set.of` and `Map.of`) have enabled us to make optimizations to the internals mostly with impunity. We’ve done so twice since their introduction and we might do so again.

(from Feb 2021)

Some of the JDK's unmodifiable collections, such as those from `Set.of()` and `Map.of()`, also randomize iteration order. At the time they were added, Go and Python also randomized iteration order. However, more recently, Python moved away from randomization. Early in the Python 3.x releases, dict iteration order was randomized. In 3.6, iteration order was insertion order, but only as an implementation detail. In 3.7, this was elevated to a guarantee.

https://docs.python.org/3/library/stdtypes.html#dict

(search for "dictionary order")

There are occasional complaints about Java's unmodifiable collections' randomized order, as it can occasionally cause intermittent test failures or even failures in production. However, the advantage of the randomized order is that we've been able to reorganize the internal implementations of these data structures -- twice -- without worrying about compatibility problems caused by changing the ordering. Historically this has been a problem with other structures such as `HashMap`. Even though HashMap's order isn't guaranteed, it's predictable and stable, and changing its ordering has definitely flushed out bugs.

Note the date line on the article:

    Published on Sunday, January 15, 01989  •  35 years, 7 months ago

Specifically, the five-digit year! Also the explicit listing of the age of the article. Most sites have a “human readable” or “friendly” date such as “published yesterday” but only for recent dates. Some sites, such as news sites, add a warning if the article is more than say five years old. Here, it’s as if they’re proud of the age. Since this was published by the Long Now Foundation it seems likely these were done deliberately.

Wow, pretty amazing. I remember playing this game after somebody ported it to Wang 2200 BASIC sometime in the mid 1970s. I didn't figure out how to land it myself, but I remember being shown the technique of coasting for the first several turns before applying maximum thrust. I don't recall the term "suicide burn" though. (Or maybe that term came in later when the Kerbal Space Program became popular.)

I also remember this lunar lander game running on a couple terminals at the Lawrence Hall of Science in Berkeley, California, also in the mid 1970s. I don't know what computer it was running on though.

I never looked at the source code for this program. I had no idea how sophisticated the math was. I wouldn't have understood it anyway, as I was too young in the mid 1970s. Then again, I'm not sure I'd be able to understand it now....

Sun veteran here. There was undoubtedly a "cool" factor to Sun in the 1980s and 1990s which I and a bunch of other people bought into. It had burned off by the mid 2000s though after the dot-com bust and wave after wave of layoffs and canceled projects. Any "cool" was left at that point was only from nostalgia and inertia.

But I guess it depends on what you mean by "respectable" or "decent". It may be helpful to remember that a lot of people hated Sun in the 1980s and 1990s too. DEC (Digital) was a particular rival in those times. Spurred by the successes of NFS and the Sun/AT&T Unix deal, DEC created the OSF to counter Sun. Later on, there was something similar with IBM and Sun over Java. IBM eventually did license Java, but there was a lot of conflict.

I think in both cases the issues were mostly about licensing and business terms. Maybe this was nothing more than corporate rivalry and competition, but it kind of felt more personal than that.

At a Sun reunion a few years ago, Scott McNealy said of Sun, "We kicked butt, had fun, and we didn't cheat." The "kick butt and have fun" had been McNealy's slogan for a long time, but the "didn't cheat" was relatively new. I believe it to be true. I don't think Sun ever defrauded anybody. (It made mistakes, and plenty of them, but didn't defraud anybody.) In a world that has Enron and Theranos and FTX, maybe this is an outlier. But there are probably also many other companies that don't make that news that are making an honest buck and aren't cheating.

In the thread below his preview post, Mashey added the following (edited for typos):

"When I lead tours of Computer History Museum, I usually say there were 3 giants in the early decades of computer architecture:

Gene Amdhal - mainframes

Gordon Bell - minicomputers

Seymour Cray - supercomputers

and I was lucky to know the first two well, never met Cray."

https://mstdn.social/@JohnMashey/112477430691339073

Here’s a link to Mashey’s post on mstdn:

https://mstdn.social/@JohnMashey/112477330642538953

It’s short enough that I’ll quote it here.

“I am very sad to report death May 17 at age 89 of Gordon Bell, famous computer pioneer, a founder of Computer Museum in Boston, and a force behind the @ComputerHistory her in Silicon Valley, and good friend since the 1980s. He succumbed to aspiration pneumonia in Coronado, CA. I'm told there will be a "Celebration of Life" service in August in Silicon Valley. (Another fallen giant, we attended a similar service in April for another, Nobelist Arno Penzias.)”

HN should post the black bar.

I CAN HAZ DOS ATTAK

Does it have an option to park the heads before shutting down?

"Whoa! Stuart blew his air sac!"

Clearly, those are virtual hands.

The link to the video showing how to unwrap an onigiri was very helpful! I’ve encountered that wrapping before but I found it confusing. (I don’t read Japanese and I couldn’t figure it out from the diagrams.)

Every language has its zealots.

What I like about this quote is that it embodies Stroustrup’s personal attitude. He’s ultimately pragmatic. Nothing can be perfect — including C++ by his own admission. It’s aligned well with his other writings and with his commentary on the quotes page, particularly where he says that he tries not to be rude about other languages.

“C++ is a language, not a religion.”

I swear Stroustrup said this at the beginning of his EE380 (CS Colloquium) talk at Stanford around 1986. At the time we (grad students) were all C programmers and we were sure that C was the best language evar, at least, better than Pascal, which was the language Stanford used for teaching back then. So we all wanted to see this person who had the temerity to claim that he had improved C and who had the audacity to call it “C++” of all things! Skilling Auditorium was packed. When Stroustrup took the stage, a tense hush fell over the crowd. He said the above line fairly quietly, and everyone burst out laughing, breaking the tension. The rest of the talk was a pretty straightforward explanation of C++ 1.0, and I came away fairly impressed.

Several years later at another talk I asked him to inscribe my copy of the C++ book with that quote. He claimed not to remember it, but he inscribed the book per my request anyway.

I think the quote holds up well.

This series of puns is macron me ill.

Yep. And 2^20 bytes of unreliable storage is a mebibyte.

So did you take the PowerBuilder job or the Fortran job?

(Nice story, BTW, thanks.)

Thanks for mentioning Joe Darcy. He continues to work on the JDK at Oracle and occasionally works on numerics issues. Notable for this discussion, he recently updated the Java specifications for JDK 17 to remove non-strict FP semantics (which also entailed removal of the `strictfp` modifier, since the default now is always strict). See JEP 306. [1]

[1]: https://openjdk.org/jeps/306

The model of a Java String, as presented via the API, is as an array of 16-bit unsigned integers. Strings use a UTF-16-like encoding to represent non-BMP Unicode characters. The main difference from UTF-16 is that illegal sequences of 16-bit values (such as unpaired surrogates) are permitted.

The "UTF-8 by Default" refers to the default character set used for decoding and encoding, when Java Strings are read and written. Prior to JEP 400, the default character set was "platform specific." It was often UTF-8, but sometimes it was not, in which case hijinks ensued.

As noted elsewhere the internal representation of Java Strings is either UTF-16-like or is Latin-1, if all the characters of the String can be encoded in Latin-1. We think about using UTF-8 as an internal representation constantly. Doing so would potentially save space and reduce decoding/encoding overhead.

Unfortunately doing this is difficult. The key issue is that tons of code out there treats a String as a UTF-16 array (since that's what's in the API) so there are coding patterns like this:

    for (int i = start; i < end; i++) {
        char ch = str.charAt(i);
        // do something with ch
    }

If the internal representation were UTF-8, simplistically, `charAt(i)` would change from O(1) to O(N). Of course there are cleverer things one could do, such as converting to UTF-16 lazily. Now `charAt()` allocates memory and has variable latency. Well then partial conversion could be done and the current iteration point could be cached. This might work, but now String has state, and it's thread-specific as well. Etc.

Everybody kills JavaScript on their first trip.

> Wut? It sounds like you're talking more about dip pens than fountain pens?

No. These things don't happen all the time with fountain pens, but they can happen much more frequently than with ball point pens.

The practical tradeoffs all cut against fountain pens: they run out of ink quickly, they dry out quickly, the ink smudges until it dries, the ink will run or be erased if the paper gets wet, they are very sensitive to the quality of paper, they can leak easily in your pocket, etc.

Nonetheless I have several fountain pens, and I enjoy writing with them. There is a bit of ceremony about it. It slows you down somewhat; this is good. It's rather like kneading bread dough by hand instead of plopping the ingredients into the bread maker and pushing the button. It puts me in touch with the craft of writing instead of its mere utility.

Thanks for raising this issue. What you describe as "local theories" (I'd say "mental model" but I think we're talking about the same thing) is quite important. We expect beginners to come up with erroneous models as they're exposed to stuff; revising and even discarding such models is intrinsic to learning. One of the benefits of this JEP is to minimize the opportunities for beginners to create erroneous mental models.

Yes. Absolutely. One of my favorites is this video that shows a robot she built to argue with people on <strike>the Internet</strike> Hacker News. (7 seconds)

https://youtu.be/PJiRijiLwbQ

Click on the link to skip the delay.

The model of a String, internal to the JVM, as manifested in the `java.lang.String` API, is still UTF-16-like. The internal representation has changed to be either UTF-16-like or Latin-1. JEP 254 didn't change the API. This is invisible to Java programs, and they can't tell which internal representation is being used. If a Java program wants a byte array from a String, it still has to go through the APIs that involve codeset conversion. There are suitable fast paths, though. For example, if the program requests Latin-1 and the internal representation is Latin-1, the result is just a straight copy of the internal array.

Internally, the model of a String is UTF-16-like, a sequence of unsigned 16-bit `char` values. However, it's not strictly UTF-16 because a Java String permits unpaired surrogates and invalid code points.

Externally, Java has historically dealt with whatever character set was in use on whatever platform it was running on. As time as gone on, most platforms have converged on UTF-8 for external data storage and interchange. Time for Java to do that too, at least by default.

Yes, this. The files in the source repo are 99.9% ASCII. Anything that's not ASCII should be encoded in UTF-8 instead of some other encoding. The mailing list discussion refers to some issues we've had where characters in Shift-JIS (CP932) crept into the code base.

I don't think anyone is advocating using non-ASCII characters, such as accented characters or emoji, in identifiers.