I find I use Niri in a similar way to other tiling WMs, but instead of having one application per workspace, it lets me keep accessory applications clustered with the main ones. For example, my password manager lives in the same workspace (usually off-screen) as my browser. Whenever I need to generate a password or something, it's right there. Same with whatever accessory terminals I need in addition to my text editor.

Not really answering your question, but in my neighborhood (not in the UK), residents push back against developers asking them to install more brick facades on new homes. In my old house, a previous owner had installed brick veneer on one of the interior walls. So that's sort of the opposite of brutalism, or maybe it's some kind of imitated brutalism.

This is how I think of brutalism, and it makes it very hard to talk about with others. I think the word conjures dystopian images for a lot of people, which is really unfortunate. Maybe it should be abandoned in favor of a more positive-sounding term.

There's a truth though in this idea of honesty about materials that transcends a particular architectural fad, and I think brutalism ought to be an element that any design considers: can a structure be inherently beautiful without additional adornment?

I wish for more examples I could point to as brutalism that aren't just exposed concrete. The only one that springs to mind is this[0] redesign of some post-war brutalist (of the exposed concrete variety) playground equipment. It isn't a big step forward, but it's something. I also think that things allowing like good cable management to be seen is a form of brutalism. Actually, given this post's theme of "eco-brutalism", I think something like the earthship[1] might be a better example of brutalism.

[0]: https://www.assemblestudio.co.uk/projects/the-brutalist-play... [1]: https://en.wikipedia.org/wiki/Earthship

Yes, I often see people putting things into mutually-exclusive categories when I rather think they should be thinking with more of a tag system.

So many people (at least in the USA, but likely everyone) are so bound to an identity that includes X but explicitly excludes Y.

Worse yet those identities changed in their root definition, so that if you were some identity 20y ago, that now means something different.

For example, if you were a 2nd wave feminist, you're likely assumed to hate transgender people.

Haskell is a language standard, and GHC is an implementation of that standard. It may be the only one (not sure the status of Hugs, another implementation), but that's the difference, I believe.

I could text and drive without ever taking my eyes off the road. Probably still not the safest, but I constantly see people staring down into their lap while driving now.

The artist was already the consumer. Whatever the medium, the artist has to ultimately select particular things as "works of [their] art". If I paint my bathroom and then go on to paint a masterful painting, probably only one of those things is going to end up in a gallery, and that relies on there being a consumer.

A linear time algorithm ('.includes') is a constant time algorithm when its input is constant. Of course, the other input to '.includes' (the char) can vary in value, but to know if that affects running time we'd have to look at the implementation of '.includes'.

I'm not sure what you mean, how can it be constant? You have to check each element in the array and there are n elements in the array.

If you define `n` as "the number of vowels in the input language", making it dynamic, then yes.

However, the list of vowels in the function is static. So the execution time doe snot grow as the input size grows (there is only a single char as input).

O(5) = O(1) = constant.

.includes() is O(n), though.

Sounds like you might need a refresher (it's easy to get fuzzy over the years, happens to the best of us).

But you may want to update the blog post as not to confuse others more, I think people have exams coming up ;)

Yeah, I have learned a few things from the comments here and my understanding isn't perfect. Previously I thought of `n` as arbitrary; that it can be whatever you define it to be. I see now that you're right that technically it has a more precise definition: it refers to the input size.

However, I also think that in _practice_, as Znafon [says](https://news.ycombinator.com/item?id=24661411), the meaning of `n` is clear and it makes sense to stretch the technical definition a bit. In my experience, people often do. Imagine if there were one trillion vowels. It wouldn't be practical to describe it as an O(1) algorithm, despite what the answers to exam questions might say.

That said, I think that it is worth understanding the distinction between what `n` means in theory vs practice, so I was going to add a note to the blog post in order to avoid confusing readers, like you recommend. However, as I tried to do so, things got too side-tracked. Too many tangents, especially ones that aren't the easiest to understand, makes the post harder to follow. So I decided on linking to this thread parenthetically. That seems to my eye to strike the right balance.