Readit NewsWhen I go to Reader mode, the CPU goes down to less than 20%, scrolling works great, and the fan goes off.
Did they implement scrolling using JavaScript?
What appears is an unholy amalgamation of a launcher, a workspace strip, a window overview, workspace peeking, and a dock.
Worse yet is that every time you go in or out of this overview, an animation plays, making things fly and animate everywhere constantly, whenever you want to take any action.
Whenever someone points out to Gnome developers that most people only want to open a launcher to type "52*93" or find a contact, that they just want to mouse over a dock to have a lightweight way to see if an application is open (and to switch to it), they get irate and tell you their vision is vastly superior.
Gnome could be pretty great if the developers their attitude to their users wants and the feedback on their issue tracker wasn't extreme snark and "actually we are right". Even if clear UI defects are pointed out, no, in fact they are right.
The Gnome peoples also frustrate any attempt at improving Wayland at a more rapid clip.
There is a reason why Valve went with KDE. KDE has its own set of problems, but at least they are receptive, cooperative and friendly. I genuinely hope Valve puts enough money into KDE that Gnome with its high and mighty attitude gets completely railroaded.
Along comes a Luddite and puts icons on it, totally ruining its beauty. For fsck's sake! Just No.
Thankfully, along comes GNOME and it just says No.
I agree.
Please just give virtual desktops first class support and lets forget about the Activities experiment. Most users hate it.
The attitude regarding it is about as bad as Gnome forcing Overview on everyone, refusing to provide a first party dock or lightweight launcher. Despite almost every distro and 95% of Gnome users immediately installing Dash to Dock.
You didn't mention heap sort. A simple implementation, which doesn't do any method calls just like shell sort (also next to the merge sort above) is about twice as complex than shell sort.
I think I ignored Heap sort because it uses O(N) extra RAM, which is precious on a resource-constrained microcontroller.
I don't believe that insertion/selection sort is easier to grasp. Can you type it from memory, without looking it up? Here's bubble sort:
var swapped = true
while swapped:
swapped = false
for i in 0 .. list.len-2:
if list[i] > list[i+1]:
swap(list[i], list[i+1])
swapped = trueSelection sort was the first sorting algorithm that I ever created: Find the smallest element for slot #1. Find the next smallest for slot #2. And so on. I've recreated it from scratch many times. The double for-loop means that it is guaranteed to finish, and it is obviously O(N^2).
I did not learn about Bubble sort until my university class, where I thought, this is a terrible algorithm: It's not completely obvious that it will finish, and it's not obvious what the runtime complexity is. For example, if the inner loop used ">=" instead of ">", it would work for test data sets with unique elements, then hang forever with a real data set that contained duplicates.
Bubble sort doesn't click for me easily. I think it's because the terminating condition seems uglier than Selection sort or Insertion sort. I always have a little voice in the back of my mind, "Is this outer loop guaranteed to terminate?"
Both Insertion sort and Bubble sort are O(N^2). Both are stable sorts. Insertion sort consumes only about 10-20 bytes more flash memory than Bubble sort. It's hard to think of situations where Bubble sort would be preferred over Insertion sort.
Shell sort is vastly superior if you can afford an extra 40-100 bytes of flash memory. (It's not too much more complicated than Insertion sort, but sometimes, we don't have 100 extra bytes.) It is O(N^k), where k ≈ 1.3 to 1.5. As soon as N ⪆ 30, Shell sort will start clobbering Insertion sort. For N ≈ 1000, Shell sort is 10X faster than Insertion sort, which in turn is 6X faster than Bubble sort. Unfortunately Shell sort is not stable.
Comb sort has a similar O(N^k) runtime complexity as Shell sort. But it seems slower than Shell sort by a constant factor. Comb sort is also not stable. I cannot think of any reason to use Comb sort over Shell sort.
Quick sort is not much faster than Shell until about N ≈ 300. Above that, the O(N*log(N) of Quick sort wins over the O(N^k) of Shell sort. But Quick sort is not stable.
Merge sort is stable and runs in O(N*log(N)), but it consumes an extra O(N) of RAM, which may be impossible on a microcontroller. You may be forced back to Insertion sort for a stable sort.
1. How to do sets in Go?
2. What changed between Go 1.24 and 1.25?
3. Trusting an LLM?
4. Self-hosted compilers?
It is not clear at all. Also there are no conclusions, it's purely a waste of time, basically the story of a guy figuring out for no reason that the way maps are implemented has changed in Go.
And the title is about self-hosted compilers, whose "advantage" turned out to be just that the guy was able to read the code? How is that an advantage? I guess it is an advantage for him.
The TypeScript compiler is also written in Go instead of in TypeScript. So this shouldn't be an advantage? But this guy likes to read Go, so it would also be an advantage to him.
This is an article written by a real human person, who's going to meander a bit. I prefer that over an LLM article which is 100% focused, 100% confident, and 100% wrong. Let's give the human person a little bit of slack.