I'm curious if they are really, like, different. All Basic that I've seen in my life was a minuscule bit of VB and some really ancient programming book I've picked up when I was like 7 y.o. and didn't really have access to a computer.
I remember QBasic was notably different from Applesoft Basic in that QBasic did not require line numbers, and one of the demo programs (remline.bas) removed line numbers for you. Of the variants used by this author, the Commodore Basic variant is distinct in being the only one with line numbers. The others all look very similar.
Back in the day, over a decade or so, I wrote a few megabytes of VAX Basic. The language, and the code I wrote, at the end of that period looke nothing like it did at the beginning. So yes, it’s quite likely that the Basics are substantially different.
One thing that email is not the best tool for is back-and-forth dialog. Once an email thread got to be a certain length or spans some number of days, it becomes difficult to follow. The increased roundtrip latency is also unfortunate.
Although the alternative to that is not necessarily voice calls. Text chats would have been great, but which platform do you use? Everyone has got their own instant messaging systems these days.
There is also the perception that voice calls have a reduced likelihood of leaving a record, which is why some people are only reachable by phone.
But how do you organize and recall the transient discussion that happened on a call? Hint: an email summary, or some kind of summary document. And the latter also works with long email chains.
My personal experience is that emails and written documents are how things actually get done, but sometimes we have to go through voice calls and in-person meetings in order to get that far.
Those voice interactions felt like some sort of psychological barrier that couldn't be bypassed any other way, at least initially, but once I have opened up a non-voice channel, that's what we tend to use going forward.
> Hypothetically, you could organize all these people to leave at once, go somewhere else, and re-establish all your social connections. Practically, the "collective action problem" of doing so is nearly insurmountable.
I wonder if we can organize an "alternative social day", where we just all stop using twitter or facebook or whatever for some duration of time, and see what happens.
This idea is based on "World IPv6 Day"[1]. We all knew that IPv4 addresses were going to run out, but we are afraid that something would break if we switch to IPv6. Some big companies got together and say let's just try it for one day and see what would break, and turns out it there weren't significant issues, and IPv6 adoption has been growing since (although it's still not 50%[2]).
Social network effects is not as measurable as IPv6 adoption, but the idea is if a large number of us commit to some date being Mastodon day, Bluesky day, Mixi2 day, etc., and we all tried that for some time to see if nothing breaks, maybe that would be enough momentum to get these other networks rolling.
HN really like these personal blog threads because a lot of us have blogs, and we all appreciate people showing interest in our blogs.
I have a blog because a bit of reflection lets me get more out of whatever experience I just had, and I get a sense of joy if some other human shared my experience through those writings.
For a language like C, I would describe the formatting process as "straightforward" as opposed to "trivial". It's straightforward in that it feels very mechanical, but not trivial in the sense that it's difficult to fully automate the process. (The mechanical part is inserting spaces at the right places, the not so mechanical part is swapping tokens and rewriting expressions so that things line up).
You can see an example recording here of how it's done:
I wonder if they have a specific goal in mind that they use to define success. Maybe it's a more general "we will know we are successful when we get there", or maybe it's a specific metric like the number of views. The latter feels like a real grind.
Maybe these compile time tests are more like `static_assert`, which is valuable for catching incompatible uses of library functions. Pretty good idea in my opinion.
Sure, enforcing invariants is a good thing to do right off the bat. But not "does this code do what it says on the tin?" kinds of tests. Those are better run gradually, at the (current) developer's behest (and most certainly, not blocking compilation).
The core of Java was being written in the late 1990s. I had a machine in 1995 that had 16MB of memory but 8MB was more typical for Pentium machines. By 2000 the AMD Athlon and Pentium 3 were the latest and greatest and Anandtech was testing with 128MB of memory [1].
Java defines an int as 32 signed, it doesn't do anything else it calls 16 bit ints shorts. So it definitely has to be 8GB for the array.
Sun was using Solaris machines rather than PCs and they were higher spec on things like memory but still I doubt they had 2GB let alone 8GB+ needed to run this test. That sort of memory didn't become routine for another decade where Sandy Bridge was being tested with 8GB in 2011 [2].
Also goes to show how much things have stagnated, a desktop computer with 16GB has been standard for a long time. The preceding decade we went from 128MB to 8GB as normal and the next 15 years to today normal is 16-32GB which is no where near the same place of progress of memory density.
Perhaps the worry was that because the observed behavior up until now was that hash never returns -1, if it were possible possible to write a custom hash function that returns -1, that might break some unsuspecting code due to Hyrum's Law.
If the built-in hash function returned -1 when a custom __hash__ method did so, then custom numeric classes following the hashing guidelines in the Python Language Reference designed to maintain the x==y => hash(x)==hash(y) invariant would fail to maintain that invariant on the reference implementation of Python due to a CPython implementation detail, which would be a Bad Thing™.
One thing it shows is how ISBNs are allocated much faster than they are used, judging by the amount of black pixels.
The image contains 1000*800 pixels at 2500 ISBNs per pixel, so it's visualizing 2e9 ISBNs. ISBN-13 contains 12 digits plus one check digit, so we might have expected the image to be 500 times bigger/denser than the current image. The fact that it's at its current size suggests that only ISBNs with 978 and 979 prefixes are included, and since the bottom half is more sparse, that probably corresponds to the new 979 range.
reply