corank

If you want automatic tiling, there are Kwin scripts for that eg https://github.com/anametologin/krohnkite/

Essentially turning kwin into a tiling WM

As I understand it this is precisely why in Haskell and OCaml standard libraries we get lots of things like

  map : (a -> b) -> a list -> b list

instead of

  map : a list -> (a -> b) -> b list

The main argument (data to be operated on) is positioned last, after the others which are more like parameters that tune the function. It's to allow chaining these things up left to right like Unix pipes:

  map f l |> filter g |> ...

I see.

My understanding is that Rust doesn't have _automatic_ reference counting as in Swift only because it has an alternative (move), which requires the programmer to specify their intent. The principle is nevertheless the same: ensure every time a reference is copied the ref count is incremented, free only when ref count is zero, and we get temporal memory safety.

I was actually talking about automatic reference counting. I think both Rc and Arc count as automatic reference counting? It's just that the term (which was apparently coined by Apple?) is not commonly used outside Apple's languages.

I'm not familiar with Swift though so my understanding could be incorrect.

The point about Rust is to avoid any extra runtime cost by statically enforcing a set of rules (borrow checking) on reference use that are sufficient to guarantee memory safety. It also has ARC but it's reserved only for cases where those rules are too restrictive.

I think I saw them sharing it on Reddit earlier

I'd love to learn more about how AMT works. How would a doubly linked list work in this language for example?

Does the conversion happen during run-time? Isn't that going to be super expensive?

There are different types of harmonicas. For 10-hole/blues harmonicas bending is a fairly common technique. It's less common or easy to do on other types of harmonicas, eg chromatic harmonicas. Maybe you tried one of those as a kid.

What are some safety guarantees for CSS?

> It forces functions to be memory pure (pure with respect to memory), even if they aren't.

What if the unsafe code is not supposed to be pure but mutates some memory? For example, does this allow implementing a doubly-linked list?

I own a Kindle Oasis 2. Amazon stopped software updates for it so I just jailbroke it and loaded KOReader. It's way better than the official software, probably the most feature-rich and customisable document viewer I've ever seen. I regret not installing it earlier.

I wouldn't call it an entirely new distro. It's just an Fedora image bundled with the necessary changes to create the UX. It doesn't provide its own software repositories. It's more like an unofficial Fedora Spin.

It seems to me that the part about unsafe operations is pretty much still unspecified. It's currently just a short paragraph saying it may cause undefined behaviour and a list of high-level descriptions of those unsafe operations. But what's the exact semantics of those operations? When is it undefined?

> if a process were to expose a mechanism for other processes to essentially proxy keychain queries through it, that can undermine the security of the whole system.

This looks like a case of confused deputy problem: https://en.wikipedia.org/wiki/Confused_deputy_problem

A capability-based design should be able to systematically prevent this kind of problems.

Perhaps these 1. Stress relief 2. Makes boring work a bit more interesting 3. Rubber duck debugging 4. A small amount of distraction might actually boost productivity by allowing us to jump out of a local optimum?

I think as long as the code sticks to the discipline of never actually doing I/O but only manipulating functions that perform them it would basically be doing the same thing as IO monads in Haskell.

So print(s) returns a function that when called prints s. Then there needs to be function that joins those functions, so print(a); print(b) evaluates to a function that once called prints out a and then b.

What makes Haskell special in my opinion is 1) it generalises this way of achieving "stateful" functions, 2) enforces such discipline for you and makes sure calling functions never produces side effects, and 3) some syntactic sugar (do, <-, etc) to make it easier to write this kind of code.

Also note that the above example only does output which would be the easier case. When it comes to code with input, there will suddenly be values which are unavailable until some side effects have been made, so the returned functions will also need to encode how those values are to be obtained and used, which complicates things further.

Is there evidence showing that such things do boost productivity? Or any research on how they affect the way people work?

It likely doesn't have performance that's good enough for production use. Doesn't look like there's JIT so it's all instruction by instruction interpreting.

Have you tried using Google in China? Or post anything that the government/party doesn't like online?

Pretty confident that it's not covered at all.

I think an important difference between how I use vim and how I use a web browser is that in vim I need to type frequently. Though I may spend most time in normal mode in vim, I still need to switch to insert mode to make edits very frequently. With my normal web browsing it's not the case, so I'm more comfortable with a mouse for that. But I realise that this depends largely on the specific use case for web browsing. Reading blog posts is quite different from reading some documentation where one needs to search and backtrack frequently, for example, although both are done on a web browser. The latter involves the keyboard more frequently so would benefit from a keyboard-centric interface more.

That's indeed a nice use case. In general keeping to the keyboard can be helpful in the context of typing, but if I'm just reading news or blog posts or watching videos I'd go with a mouse.

For text editors or IDEs, basically contexts where we expect a lot of typing, I get why sticking to the keyboard is desirable. I don't get how it's better to browse the web without using the mouse. Most of the time on the web I just read, not type.

An interesting idea! Sending signals to all processes sounds expensive as hell though. All that work just to make a system call again to flush a buffer. Maybe a mechanism can be added to make the kernel aware of the user space buffer so it can directly fetch stuff from there when it's idle? Is it kind of like io_uring https://man7.org/linux/man-pages/man3/io_uring_register_buff...

My hypothesis is that the PDF format bears much blame here. The results might be very different if the material is in a reflowable format like an epub or a web page. If you think about it, the notion of a page exists only because of the physical limitations of the paper medium, and PDF is page-centric only because it was designed to represent printable materials. There's no reason to stick to pages anymore if the material is to be consumed on a screen, and PDF is therefore also the wrong choice for this.