mjw1007

Every now and again I see someone on this site saying things along the lines of "it's a shame that programmers in general are so unwilling to pay for quality tools", and I feel myself tempted to agree.

Then something like this comes along and it becomes clear why it's so important that everything we rely on is, at the least, free from "I changed the deal" events.

Here are some notes on the later history of GC in Rust:

RFC 256, 2014-09. https://rust-lang.github.io/rfcs/0256-remove-refcounting-gc-...

Includes « I (and I think the majority of the Rust core team) still believe that there are use cases that would be well handled by a proper tracing garbage collector. »

https://news.ycombinator.com/item?id=8312327 A core developer says

« I wouldn't be so quick to give up on GC support yet! "We have a plan!" But I don't think we'll have it in for Rust 1.0. And it's true that, even if we never do get it to work in a satisfactory way, the language works just fine without it. »

By 2015-04 ("Fearless Concurrency"), "Memory safety without garbage collection." is a "key value proposition" (this isn't quite the same as saying "we never want Garbage Collection", of course).

2016-08 https://manishearth.github.io/blog/2016/08/18/gc-support-in-... « Recently we (Felix, Niko, and I) have been working on getting compiler-level GC support for Rust. »

2018-10 withoutboats has a research garbage collector as a library: https://boats.gitlab.io/blog/post/shifgrethor-i/ The intro post includes « I do not expect we will ever “add GC to Rust” ».

2021 summary of options: https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe...

The good news is that the Rust project has recently agreed to write a specification, and has a budget to hire an editor for it.

The less good news is that it's likely to take a long time before anything resembling a complete description gets written.

You can follow its status at https://github.com/rust-lang/rust/issues/113527

https://ai.eecs.umich.edu/people/conway/Retrospective2.html#... has a more technical description of her work on (ie, invention of) out-of-order execution, including a link to this very readable paper: https://ai.eecs.umich.edu/people/conway/ACS/DIS/DIS.pdf

I think Master Kaimu agrees with you: http://www.thecodelesscode.com/case/97

In cases like Android, the reason for having an internal codename is that you need a way to refer to the next release before the marketing department has made the final choice of the next version number.

Of course in Android's case this broke down when the marketing department started broadcasting the codenames, and even changing them. But I think they've got bored of that now.

I think the Stanford Encyclopedia of Philosophy article is better.

https://plato.stanford.edu/entries/intuitionism/

The filter configuration for an account is in a text file in your profile, in a location like ImapMail/imap.example.org/msgFilterRules.dat

Copying these files around and editing them by hand works fine.

Well, part of the reason Linux documentation often isn't very good is that Red Hat doesn't treat documentation work as something that should be submitted upstream.

Their incentives favour creating Red-Hat-specific documentation, and this then reduces their users' incentive to improve upstream documentation.

At a minimum there'd have to have been a free-as-in-beer cross-platform compiler.

I think Ada had a brief chance to take off around 2000 when gnat was added to the main gcc distribution, but the GNU maintainer was also the head of Ada Core Technologies and had very little interest in making the free version of the compiler useful for general purpose programming.

I wrote a few small things using it, but the "ecosystem" just wasn't there, and there was nobody trying to coordinate a community that might have built it up.

Even calling libc functions that didn't correspond to anything in the Ada standard library was no fun at all.

Unlike the way some languages' package systems work, Rust crates don't cleanly separate the public interface from the private implementation.

In practice a crate's public interface is effectively scattered throughout a number of modules. There's no separate textual interface definition that you could diff to see what you changed without also seeing changes to the implementation. Clients importing your library compile against the whole source.

So in practice if you want to check whether you changed your public interface unintentionally, your best bet is to compare the old and new output of Rust's automated documentation system, which by default is describing only the public interface.

Cargo-semver-checks attempts to automate that.

Hyrum's "law" may claim that somebody out there will run into trouble if I change the internals of my library, but it certainly doesn't say that I have any obligation to care about it.

If you're working for a big company with a monorepo where everyone is trying to live at head, maybe you have to care.

But if I'm giving away my software for free to anyone who cares to use it, I'm entirely comfortable in saying that if you relied on undocumented internals you get to keep both pieces when it breaks.

I don't think the jokey book-long tutorial is a new phenomenon.

I learned Fortran in the 80s from the Fortran Coloring Book.

I think the biggest weakness with the four-document model is that it doesn't have a proper place for rigorous documentation of the system's concepts and model.

The biggest problem I find with software documentation is that the only rigorous part is a "Reference" which is organised as a list of functions or configuration options or commands or whatever, and while each individual item looks OK, they don't add up to a full description.

One clue that you've got this problem is having reference items which use technical terms which aren't defined, or are only defined in the informal part of the documentation.

Another form of this problem is a reference that's heavy on how options modify behaviour but omits any promises about the parts of the behaviour which are unconfigurable.

The four-document model's division of "Explanation" and "Reference" doesn't help avoid this problem. The "Explanation" is for teaching and is apparently not intended to be rigorous, and it doesn't tell you to make the "Reference" more than lists of individual items.

I think the existence of Scientific Linux was one of the things keeping RH honest until then.

In 2019 the Scientific Linux developers announced they would stop development and collaborate on CentOS instead.

At that point Red Hat had captured the RHEL-clone world, leaving them in a position to destroy it.

> these certificates were already being rejected by Chrome and Safari for having invalid SCTs

What's a good way to make an equivalent check from a script, if I want (in future) to be able to check whether I have a website whose certificate has such a problem?

Maybe it's worth one more section near "Any Ideas On Why It Is True?", something like:

Are you beginning to doubt whether it's true?

Try to think of a counterexample.

Is there something that keeps getting in the way of a counterexample working? Can you prove that that always happens?

I think it's more likely that if that paper had never been published the government would have advertised a different pretext for the decision they wished to make anyway.

> Over 15% of Black drivers experienced an escalated outcome such as a search, handcuffing, or arrest, while less than 1% of white drivers experienced one of those outcomes.

So I think they had 2 "escalated" cases with white drivers, which I would agree is too small to do any statistics with.

Yes.

Storing a timestamp (rather than a timestampz) and documenting that it represents a time in UTC is as sensible as storing a numeric type and documenting that it represents a distance in metres.

That's because find's principal documentation is in info.

https://www.gnu.org/software/findutils/manual/html_mono/find...

As long as these are external tools, IDEs and things like github's default file renderer aren't going to understand what's going on.

If I use block comments like that in most contemporary IDEs, I find that by default they show the main text in flat "this is a comment" styling, even though they're in principle capable of using different kinds of highlighting for different parts of the file.

Similarly, if I preview such a file on github I get syntax highlighting for the code but I don't get rendering for the markdown.

So I think the advantage of an 'official' way of saying you're using this arrangement would be communicating intent to more-or-less generic tools.

It might be nice if modern languages defined an official way to "flip" the interpretation of a source file, so that by default the content is treated as markdown and the code goes in fenced blocks (rather than defaulting to code and providing a way to mark comment blocks).

Then we might hope for support in most tooling to appear quite quickly.

I think one reason why literate programming is less attractive nowadays (compared to the days of Pascal) is that programming languages have got better at letting you arrange your code in whatever way you like. So maybe something like the above is enough to get 90% of the advantages of a full literate programming system.

Well, I'm baffled then. From where I'm sitting that point 8 is clearly talking about what happens after a bug is discovered, and not about discovering bugs.

The longer paragraph doesn't seem to contradict the notion either. My impression (based on the "How Many Eyeballs Tame Complexity" chapter) is that Raymond thought that "debugging" means "fixing bugs".

If I were criticising this part of essay, I'd say the main weakness is that the things Raymond thought of as "taming complexity" weren't really addressing the hard problem of reducing the number of bugs.

Again: the purported law says "shallow", not "soon discovered".

I don't think "bugs are shallow", or the "many eyeballs" section of this essay, are particularly talking about _discovering_ bugs.

The author seems to have had a worldview in which bugs don't really matter if people aren't coming across them, and in which the difficult part of dealing with a bug is either reproducing it or getting from a symptom to a cause.

If you were in a world where those two things are true then I think he's probably right that "many eyeballs" would help a great deal.

I think it's fine for the case where running the operation more than once at a time isn't incorrect, but potentially wastes resources.

This one? http://www.thecodelesscode.com/case/110