Kind of you to engage! Ahh, ok, I misunderstood. Very cool! I think maybe it would have helped me if you had given a one-or-two-sentence description of the "representative change" in the main text, to make it a bit more concrete up-front? But possibly just a 'me' issue...
This is interesting, but I think it would be even more interesting to see a comparison of the token cost of adding a new feature, in the original codebase vs the refactored one. You'd think/hope that the cost of adding the new feature would be lower when starting from the refactored codebase, indicating that refactoring makes economic sense in the long run by lowering the cost of adding new features.
Andreas Kling has said that one of his inspirations for SerenityOS was the Windows 2000 UI (https://corecursive.com/serenity-os-with-andreas-kling/). I found his general goal for SerenityOS ("Roughly speaking, the goal is a marriage between the aesthetic of late-1990s productivity software and the power-user accessibility of late-2000s *nix.") to be strangely validating ('Wait... So it's not just me?!'). And so of course I decided to try out the KDE desktop, which I had always kinda dismissed as being a bit too much of a niche within a niche. And it's great. It really is wonderful to use an OS that is designed from the ground up for serious technical users. And the ubiquity of web apps nowadays makes Linux a far more practical choice than it was back in the day.
But I can't agree with the claim that "nan is almost always a mistake". Certainly if you're doing floating-point computation on large arrays, the last thing you want is e.g. for an error to be thrown in a elementwise division just because two corresponding elements both happen to be zero.
It's true that nan!=nan is one of the more 'controversial' parts of the standard, that possibly would have been decided the other way in a perfect world. But it was also a reasonable pragmatic decision at the time the standard was developed. See here: https://stackoverflow.com/a/1573715/1013442
This is only somewhat related, but: Has there ever been a language that adopted IEEE-754-like semantics for integer types? (Yes, I know this would be slow without hardware support.) By this I mean adding valid values for (signed) ints to represent positive infinity, negative infinity, and not-a-number; then use these values as the results of overflow, underflow, and division by zero in the natural way. It just seems like if these sort of values are useful in floating-point arithmetic, they might well be useful for integer arithmetic as well, for many of the same reasons.
The whole thing of calling controls "chrome" is basically a metaphor gone horribly awry. The term was coined in the 1990s because (at least on Windows) the "content" usually had a white background, and the controls usually had a gray background. But of course the use of the word "chrome" inevitably implies that this stuff (the controls) are like the chrome on a car: nonfunctional, inessential visual frippery. And so UI chrome must be bad, and something to eliminate. But of course this is nutty: The UI controls are what you use to manipulate the content! It's like calling the steering wheel and the pedals in a car "chrome" and deciding you need to deemphasize them so that the driver can 'focus on the road' or something. The controls are important! They are how you drive the car!
Middle-click paste is faster than Ctrl-C-then-Ctrl-V. And if you are a developer, you often find yourself copying long strings from one place to another. And it has been a standard behavior on Linux since the 1990s. This just seems to me like more of GNOME's "simplicity at all costs" run amok. I'm a power user. I want poser user features. So I use KDE, a project run by people who care about power users and their needs. I'm happy for you if GNOME meets your needs.
I'm not surprised that GNOME would contemplate this: it seems like a very GNOME-y thing to do. (And maybe this is a good thing for GNOME users. But this kind of thing is also why I use KDE.) But why would Firefox feel the need to touch this? Surely this is a DE-level setting, and Firefox should simply go along with the DE behavior so that its behavior is consistent with the rest of the apps running in the desktop session.
Shouldn't the first sentence on that website describe what GNU Unifont actually is? I guess it's a single copyleft font designed to have coverage of all (or nearly all?) unicode code points?
So, first off, it seems like Jonathan Riddell not working on KDE anymore is a huge loss for the KDE community.
But I'm not sure I really understand what happened. AFAICT, Valve had a contract with Blue Systems, specifically a subunit of Blue Systems that does KDE development. Blue Systems decided to sell that subunit to Techpaladin, Nate Graham's company. Riddell was unhappy about this, and proposed that... I guess that Blue Systems not sell to Techpaladin? Or that Techpaladin reorganize itself into a worker-owned company? And then when Graham declined to do this, stuff happened, and eventually Riddell got fired from Techpaladin, or not hired by Techpaladin, and now Riddell is not getting paid to work on KDE. So Riddell has (not unreasonably) decided to stop working on KDE. And the other people who once worked for Blue Systems and now work for Techpaladin have decided to keep working for Techpaladin.
My PhD research was actually studying the leech nervous system. They're still an important 'model' organism in neurobiology. Probably not as important in the field at large as they were in, say, the 1970s, but still. They're also a good system for neurophysiology education, because they are cheap and easy to obtain, have large-ish neurons that are identifiable from animal to animal, and their nervous system has a relatively simple organization.
Strongly endorse. That paper is really wonderful. It seems to me that MVS is the solution to the version selection problem, and now we just have to wait for awareness of this to fully percolate through the developer community.
The post title implies that all French villages have no more drinking water, which is not the case. Sounds like it's 16 villages, all near each other. Still a big deal, but not nearly as bad as if it was all of France.
Basically, he argues that application distribution outside of the distro (a la flatpak, snap, appimage) is just a bad model. The right model is the one distros have been using for years: You get software through the distro's package manager, and that software is packaged by people working on behalf of the distro. As he says: "Software distributions are often volunteer-run and represent the interests of the users; in a sense they are a kind of union of users."
The other issue, of course, is that in practice flatpaks/snaps/appimages never seem to 100% work as well as distro packages do.
There are certainly some aspects of it that are inelegant, in the interests of backwards compatibility, but otherwise I don't know what you are talking about. Matlab supports >2d arrays just fine, and has for at least 20 years.
I'm excited to see KDE promoted to being an "edition", but does anyone know what is behind this decision? It surprises me that Red Hat would take this step, since they are (seemingly) a big GNOME proponent, and I thought many of the GNOME developers work for Red Hat.
The statement I take issue with is that Sutton "is not to be celebrated or trusted". Which I can only interpret to mean that the speaker does not think that Sutton should be celebrated or trusted. (And they've chosen to state it in a kind of pompous way.) Which I think is too strong on both counts. I (and apparently the ACM) think that Sutton should be celebrated for his technical accomplishments. Also, I think he probably can be trusted on a lot of technical matters. Should he be trusted on matters of whether there need to be safeguards on AI research imposed by the state? Maybe not, but those are only a subset of all the matters.
This is not quite correct, at least not in most commonly-used languages. The difference comes when a "superclass" method calls self.whatever(), and the whatever() is implemented in both the "superclass" and the "subclass". In the implementation-inheritance-based version, self.whatever() will call the subclass method. In the composition-based version, self.whatever() will call the superclass method. The implementation-inheritance-based version is sometimes called "open recursion". This is why you need implementation inheritance for the GoF Template pattern. See for instance this paper:
I have a Sonos system at home, have for years. (I currently have to use the "Sonos S1" app because I have one older device that is not supported by the new app.) It sounds good (to me) when everything is working, but honestly the reliability has never been that great. After first buying it, I eventually learned that you really want to buy one of their 'hubs' (the one I have is the Sonos Boost) and have that plugged into your wired ethernet network. Otherwise, at least in my hands, things just don't work very reliably. (You can also, I am told, plug a single speaker into your wired network and achieve much the same effect, but for reasons it was easier for me to buy the Boost.) But even now when you select a new song/album/playlist, it seems to take a weirdly long time for it to start playing and have the album art show up on the phone, and sometimes it just fails and you have to try again (the 2nd time almost always works, FWIW). But it is really nice to have decent-sounding on-demand music throughout your home at the touch of a (few) button(s). I hear that bluOS and HEOS are decent alternatives, but they don't seem to be as popular as Sonos, and I've never seen a convincing demonstration that they would work better for me. And of cource there's the lock-in factor: Replacing all my Sonos equipment would be pricey at this point. I used to get really mad about lack of cross-manufacturer interop when I was younger and poorer, but nowadays I'm willing to stomach it if it means that stuff just works. But it's continually irksome that equipment at these prices isn't 100% glitch-free.
I feel like it's almost criminal of textbook writers not to mention this when introducing the characteristic function... At least as an aside or a footnote, for readers already familiar with Fourier transforms.
I am just reading about this whole Automattic vs WP Engine fight today, and I'm a little surprised that most people seem to think Automattic is the unambiguous bad guy. Automattic has still given away a huge amount of open-source software away over the years. WP Engine seems like it is entirely a mercenary operation. (Which there's nothing wrong with, per se. But it doesn't exactly warm the cockles of my heart.)
And paying people to leave if they don't agree with what the company is doing seems like a win-win.