mjw1007

For readability, I'd quite like to see a design that looks a bit more like K&R-era C, where the function signature just has the parameter names, and each parameter's type annotation gets a line of its own somewhere further down.

I found this a little difficult to follow, because you show a table and say that it contains a typo, but you don't directly say which part of the text needs to be changed.

I think the words "V is visible only if TE is not T" are intended to replace the entire text in the bottom-right cell of Table 2; is that right?

It seems unnecessarily heavy-handed to me.

Back in the day the Ada people had a reputation for being very "controlling", but they didn't stop the Gnat people naming their company "Ada Core Technologies", and they didn't stop the adahome.com people using that domain name or writing "Ada Home: The Web Site for Ada" in big letters on top of their webpage.

I don't think that caused any serious problems.

I don't think the "this is power-tripping" model of what's going on is very likely.

The "this is what you get if you ask lawyers for a trademark policy and don't pay enough attention to what you get back" model seems closer.

This post by a former nodejs decision-maker provides some evidence for that:

https://old.reddit.com/r/rust/comments/12lb0am/can_someone_e...

I think you keep writing "Python" when you intended to write "PHP".

The central thesis of the Selfish Gene has nothing to do with "junk DNA", and when the book does talk about the subject it doesn't assume that it has no purpose.

(What it does say is "Biologists are racking their brains trying to think what useful task this apparently surplus DNA is doing" and "The simplest way to explain the surplus DNA is to suppose that it is a parasite, or at best a harmless but useless passenger".)

Learning about an unfamiliar and underdocumented codebase.

I think a "Omnicient"/"Time-travel" debugger with strong tracing support would be interesting.

I'd like to be able to take a recorded run and add tracepoints after the fact, and be able to toggle them on and off, or add or modify conditions on the output, watching the trace change as I do it.

When I looked at the Pernosco demo it looked like it had the capabilities to do this sort of thing, but only a rather primitive user interface.

I don't think this is really an example of Hyrum's law. Hyrum's law claims that even if you carefully document your contract, someone will rely on the observable behaviour rather than the documentation anyway.

But this is an example of a much weaker proposition: if you don't document your contract, then people will guess what the contract is and some of them will guess wrong.

(In fact in this case it seems it's more like "if you don't document your contract and your support staff sometimes say the behaviour is A, people will rely on the behaviour being A".)

I found a recentish (2021) survey at [1] which suggests that in 2021 ML was some way behind web development, sysadmin stuff, and data analysis among Python users (and didn't seem to be on the way up the list).

[1] https://lp.jetbrains.com/python-developers-survey-2021/#Gene...

I've come across this notion that nowadays machine learning provides (in some sense) the biggest group of Python users a few times recently.

What reason is there to suppose this is true? It seems surprising to me.

Thirty years ago you might have read a similarly-anonymised account of the incident in the risks digest.

I don't think the reporting being 'live' makes it much better or worse, though it probably wastes more of the readers' time.

Yes, this sort of consistency is very valuable.

It's far too common that the interface an IDE gives you for something like adding a watchpoint is "type an expression into this small area in a dialog box, using a restricted subset of my text-editing features".

I sometimes think the main attraction of print-style debugging is that it doesn't do that to you.

http://smallcultfollowing.com/babysteps/atom.xml looks like it works

I have no strong opinion on what the policy should be, but I think there's no excuse for allowing the stated policy to get so far out of sync with the actual policy.

That is, I think the stable-release maintainers should update Documentation/process/stable-kernel-rules.rst so that it tells the truth.

(I think this is about normal stable kernels, not 'longterm' ones. I don't think 6.0 was expected to become the next LTS release.)

Allegedly this was the patch introducing the bug: https://lore.kernel.org/stable/20221228144337.512799851@linu...

It seems to me that for a long time now stable releases haven't been trying very hard to follow the stated policy [1], in particular the parts that say

> It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).

and

> It must fix a problem that causes a build error ([...]), an oops, a hang, data corruption, a real security issue, or some "oh, that’s not good" issue. In short, something critical.

[1]: https://docs.kernel.org/process/stable-kernel-rules.html

In a sense: because all it does is move money from one place to another.

That's very different to wasting money in a way that actually uses up physical resources or people's time.

I think some programmers need to hear the advice "don't assume that newer is necessarily better", and others need to hear "don't dismiss new things as being created by a cascade of attention-deficit teenagers".

Maybe the author of this article is meeting more of the first kind, but it's dangerous to issue advice that amounts to "wherever you are on this balance, move further East".

I think Brexit can also be seen as an argument for more direct democracy: if there had been a referendum in the UK on one or more of the major changes in the EU treaties in the previous 25 years, I think it's likely that Brexit wouldn't have happened, or else that it would have happened much earlier with less damage as a result.

It can also happen if you have two copies of 'stock' Firefox running (with different profiles) and one of them runs the update.

I agree.

It looks to me like the only place they're really wasting space is the hefty margin above the body text.

I'm no fan of the Telegraph, but all those links show is that it's willing to give comment space to people with different points of view.

(Or, to put it another way, the fact that they're willing to print a column by Fraser Nelson isn't a reason to suppose their home affairs editor isn't still in favour of the bill.)

The other part of an installer's job is to provide a reliable way to uninstall the program, without leaving any mess behind.

I think that's the main reason I'm reluctant to run curl|bash-ware. I might trust the authors not to be malicious, but I generally wouldn't trust them to be competent at cleaning up after themselves.

I see plenty of advice on technical writing, which typically concentrates on how to structure things on a large scale, and how to make the words clear on a small scale.

But when (as very often happens) I'm reading documentation and I find it's less than satisfactory, the main problem is rarely the structure or the wording.

The main problem is nearly always that the information I need just isn't there.

So please, if you're training people to write, tell them to always keep these in mind as priorities: "Are the terms I used here defined elsewhere in the document, or else ones that I can assume all readers already know?", and "Have I actually said what this thing does?".

The 8086 didn't have a separate stack for interrupts.

So, as I understand it, the problem isn't that code running in the interrupt handler might push data to a bad place; the problem is that the the processor itself would do so when pushing the return address before branching to the interrupt handler.

I think this is the most interesting part:

> [Github's Terms of Service] specifically identifies “GitHub” to include all of its affiliates (like Microsoft) and users of GitHub grant GitHub the right to use their content to perform and improve the “Service.” Diligent product counsel will not be surprised to learn that “Service” is defined as any services provided by “GitHub,” i.e. including all of GitHub’s affiliates.

There's a traditional semi-standard utility called `rpl` for making this easy.

Unfortunately the current maintainer of the active fork decided to remove the `-R` option because they think piping find(1) output into it is better.

There's some discussion at https://github.com/rrthomas/rpl/issues/9 .

As I understand it, the position under the heading "My own take" is the one that the post's author is espousing, and the other positions they bring up are being talked _about_.

If a project with half a dozen developers put political messages from those developers in their release notes, I'd think that was fine.

But I disapprove of the people writing the release notes for a Rust release putting messages of their choice in there, because they don't have a mandate to speak on behalf of the people whose work they're showcasing.

Note that this is the British Indian Ocean Territory, perhaps best known in these parts for having the .io cctld.