alex-robbins

If you can't tell the difference between computer science and software engineering, then at least one of those worlds contains none of your feet.

It seems like "serving advertisements" and "serving intelligence" are antithetical goals. Presumably, the market will recognize that in the long term.

Of course, I make no claims about how far in the long one will need to look to see that play out.

No, that's an example of robots/AI not working out. Yes, this means that "making robots/AI work out" is a political and economic problem, not just a technical one.

Care to name them? I use Mullvad, and I love them, but their exit nodes are routinely blocked by Reddit and streaming services.

You think that the farther in the future you go, the less likely it is that any existing population will know how to fix what breaks? That strikes me as oddly pessimistic, and frankly unlikely.

It strikes me as too bad that this API is so imperative. You can see a pattern over and over in the README where they have `do` blocks, in which they clear some global state (`initialize-prolog`), then add some assertions back into that global state (via side-effectful API calls), and finally run a query (which is implicitly a query on the state that's been built up). Why not represent the knowledge base as a normal Clojure data structure, rather than as the effect of a sequence of API calls? Then it can be passed in by the caller alongside the query, instead of being stored as mutable state.

This isn't just a style thing, either; there are consequences. REPL-driven development loses a lot of its slickness when some expressions can only be eval'd in a special context.

Also, what am I supposed to do if two different parts of my program want to use Clolog? If I'm using Clolog, and one of my dependencies is using it too, will we end up trashing each other's global state? (The case of external dependencies is just an example. Let's say I have an application that sets up the Clolog state and runs a query. Part of the setup involves calls to other parts of my application. At the time the code was written, those other parts didn't use Clolog, but now they do, and there's a bug, because those other parts are trashing the Clolog state that their caller had set up, before it runs its query.) Of course, you could get around this by adding something like a dynamically bound variable that points to the instance of state to use, but at that point you're jumping through hoops to support a subpar (stateful) paradigm that Clojure developers expect to be free of.

I don't see it in the Android app either, and I find the original claim very hard to believe in the first place, since that would be a weird piece of information for Signal to reveal about a user.

A superellipse is only a squircle if a and b are 1. As with squares and rectangles, all squircles are superellipses but not all superellipses are squircles.

Well, if you remove the choice, that can actually sacrifice the ergonomics GP described, because of one of the important differences between stacked and tabbed: directionality.

Tabs are oriented along a horizontal axis; as with hsplits, you move through them by moving the focus left and right. Stacks are oriented along a vertical axis; as with vsplits, you move through them by moving the focus up and down. The reason you want the ability to choose between the two options is (to continue parent's quote of GP) "to allow you to flip back and forth between [relevant pairs of] windows with just a couple keys". To reuse (and better explain) the example from GP:

    [ _ _      Tabbed Browsers      _ _ ]
    -------------------------------------
    |     emacs      |   Tabbed Terms   |
    |                |                  |
    |                |                  |
    |                |                  |
    |                |                  |

This is a root container whose two children are "Tabbed Browsers" and "hsplit of 'emacs' and 'a tabbed container with terminals'". (This root container is a stacking container, and the browsers' part only takes up about one title-bar-height on the screen because something in the hsplit has focus, so the hsplit gets all of the space and the actual content of the browser windows are not currently visible.) The reason it's stacking, and not tabbed, is because this way I can flip back and forth between any browser and any of the other windows with just one key per direction ("focus up" to get to whichever of the browsers was last focused, "focus down" to get back to whichever of the windows in the hsplit was last focused). Additionally, I can get back and forth between emacs and a specific tabbed term (the left-most one) with one key per direction ("focus right" and "focus left", of course), and I can get back and forth between emacs and any of the terms with 1+2=3 keys round-trip ("focus right" to get from emacs to whichever of the tabbed terms last had focus, "focus parent-wards then left" to get back to emacs). Critically, if you were to change any single one of the stacked containers in this layout to tabbed, or any of the tabbed containers to stacked, then you would be sacrificing at least one of these three properties.

So, the choice between stacking and tabbed matters. I'm not saying you can't have this choice in a scrolling tiling window manager. (Does Niri have stacking and tabbed containers? I hope so.) I'm also not saying that you or anyone else has to want to make that choice (it's okay to prefer a "simpler model" where you scroll around to get to all of your windows). What I am saying is that the author of TFA thinks that with traditional tiling window managers like sway, you can't have "very many windows open" without "constantly swapping between fullscreen and non-fullscreen views and running out of workspaces", and this is simply not true. (Perhaps worse, in the next sentence, they dismiss the solution out of hand by saying "don't get me started" on nested tabbed/stacking containers, because they're "the least ergonomic Band-Aid™ for the space issue I've ever seen", but it seems to me that declining to give a full treatment to that subject may actually be why the author's never seen it done ergonomically. But now I'm speculating.)

------

BTW, since anyone still reading is probably a completist: at the top, I said that directionality was "one of the" important differences between tabbed and stacking containers. The other one is how much space their title-bar areas take up vs. how many children they have. Stacking containers are O(n) in the number of children; tabbed containers are O(1). Interestingly, combining this with the directionality property yields an interesting result: in sway, there is a sort of asymmetry between the horizontal and vertical dimensions.

Does anyone else find it suspicious that the author was using so many workspaces on sway? I have to wonder if they're not making good use of sway's tabbed and stacked containers ...

> If you don't find yourself constantly swapping between fullscreen and non-fullscreen views and running out of workspaces, you don't have very many windows open. Don't even get me started on tabbed/stacked layouts with nested containers, the least ergonomic Band-Aid™ for the space issue I've ever seen.

On the contrary: I think this author really ought to get started on tabbed/stacking layouts! Constantly swapping between fullscreen and non-fullscreen views, like running out of workspaces, definitely sounds like an antipattern to me. I don't believe that the number of windows is the problem here.

If I'm deep into something, I might have 10 or more windows open, all on one workspace, on a 13" 1080p laptop panel. Of course, not all of the windows are visible at once. A common pattern for me is to have most of my screen taken up by a container split "horizontally" (meaning into a left side and a right side), where each side can be a tabbed container containing several windows. For example, I often have Emacs on the left, and several tabbed terminals (including man pages) on the right. Maybe some of those terminal tabs on the right are split "vertically" into a top and a bottom terminal (e.g. for a shell prompt on top and man page on bottom). Outside of this big left-right split container, which fills almost the whole screen when it's visible, I'll usually have some browser windows open. If it's just one browser window, I'll put it and the big-left-right-split (BLRS) in a stacking container. This way, you can think of the browser as being "above" the BLRS, and you can get there and back by moving the focus up and down again. It's like each stacked item (the browser and the BLRS) gets its own workspace, in that they each take up nearly the full screen when visible, but actually they're both on the same workspace, and the only cost is the loss of one title-bar's height of screen space. Then, if I want more browser windows, I can split the existing one into its own tabbed container. (I use both WM tabs and browser tabs, just like I used to use multiple browser windows on one workspace with Gnome.)

Basically, as my number of windows grows, things become (slightly!) more nested, rather than being ejected into surrounding workspaces. The trick to making this ergonomic is to choose what to stack vs tab so as to allow you to flip back and forth between (at least) any two windows with just a couple keys. (I also have two keybindings to split a container and immediately make it stacking or tabbed, and also two keybindings to focus parent-wards/child-wards. Then, you can easily jump from a window in the middle of a tabbed container on the right of the screen to the window on the left half of the screen---you just focus parent-wards then left (two keys). To get back, just focus right (one key).)

I should also add that I haven't really seen any problems with apps behaving badly when being resized, including Firefox. Maybe that's because my workflow mostly looks and feels like "slots" of a few different sizes (roughly full screen, half screen, quarter screen), and adding new windows to, or moving windows between, these slots is never going to change the size of the slots or the windows displayed in them. In fact, with traditional floating window managers, when has resizing a Firefox window ever caused me to lose my place in the page? Only when I make it super unusably narrow, or short, or both, and then expand it again. This is what would happen if you open a bunch of windows all in horizontal and/or vertical splits, with no stacking or tabbed containers! But why would you do that?