Would the image be very different for a rotating black hole?

Since they probably all rotate in nature.

Not much about token efficiency ("a bit shorter") or token/s.

Sublime is an editor I trust to leave open at all times, no matter what.

But, Helix lsp integration and shortcuts is really excellent, and much better than anything else IMO.

My guess is that iOS, iPadOS and macOS are converging on some points, and Siri gets included.

It would be interesting on macOS if it had amazing computer use and was able to control all aspects of all apps, and you’d be able to instantly do anything with voice only.

Siri Actions are one tiny step closer to that, but we’re pretty far away from this.

LSP helps with not having to develop the same tooling in each editor for each language.

This isn’t for Electron app only, but is also helpful for Emacs, vim or helix (especially when they lack said language plugins).

Now, some IDEs provide capabilities for a language far exceeding what can even be implemented in a LSP.

Perhaps something like what TigerBeetle does: deterministic simulation testing.

Very true.

Even full page screenshot doesn’t always capture the non visible part of the page (below the viewport).

> … to call them Select and Where.

While map is a great name, I always struggle to remember if ‘filter’ keeps elements that match the condition or removes them.

I mean, it’s like a colander: you filter noodles and water, but which one do you keep? The noodles, right? But, replace noodles with tea and now you want to keep the water part.

Naming is hard I guess.

There's always the Ruby strategy of just making all the names work. `select` and `filter` are buddies and you can use whichever you want or even go back and forth. Not a fan of `reduce`? That's fine, `inject` has got your back. Miss getting to type `collect` from Java or Rust? Don't worry, just use it instead of `map`, it's the same thing.

I believe Ruby uses names inspired by SmallTalk.

Yeah, Smalltalk has select, reject (inverted filter), collect (map) and inject.

Right, I'm just saying that it has a lot of aliases, which is fairly uncommon in most mainstream languages

Talking about un-guessable, misleading function names,

C++ std::remove.

I would never have guessed what it does exactly. (It moves elements that match the filter to the front, and moves the end-marker forward. Leaves all the elements in the collection. You need to erase them yourself. )

It returns the new end marker

Oh it's a bit like unordered-delete when using an arena. I guess I would have expected an ordered-delete instead

I've never run into a generic "filter" function which keeps only the non-matching elements.

Common Lisp's filter is remove-if which works this way.

(It also has remove-if-not but that's deprecated and if you use it your code smells.)

`remove-if-not` was deprecated before the Common Lisp standard was approved and yet it remained (and will never be removed because the standard will never be updated). That's not deprecated for any practical purpose. And it's more convenient than using `(remove-if (complement #'some-predicate) sequence)`

Scheme has `filter` and `filter-not` in the SRFI-1 list library. Both of which can easily be written using a fold to bring this vaguely on topic.

Nope! Common Lisp's filter is in fact remove-if-not, which is exactly the same thing as "keep if": keep all items which match the predicate (removing those that do not).

I suspect the reason the function was deprecated was its naming, nothing more; had it been called retain-if or keep-if, it would not have attracted deprecating attention.

The smell added to your code is just the double-negative name of that function, not what it's doing for you.

The name filter smells even more. Is that filtering for items that match? Or filtering out?

In physical filters, sometimes the filtrate is considered the payload output (that which passes through the filter) and sometimes the retentate (that which is caught in the filter).

keep-if is readable.

I agree that keep-if is a better name. But you reiterated my point: remove-if works in the counterintuitive way the original comment noted, i.e. not like the common connotation of 'filter.'

As for deprecation, IIRC the '-if-not' functions were deprecated because the committee felt the 'complement' function accomplished that task better.

Edit: My IIRC seems largely correct. More detail at

https://www.lispworks.com/documentation/HyperSpec/Issues/iss...

Nonetheless, they were fooled by that function, because it's just keep-if by a funny name that includes "not" suggesting that it contains a complement that might be factored out.

If you want keep-if, you don't want to use a different function, which forces you to complement your predicate. If you want (keep-if #'redp jellybean-list) to keep the red jelly beans, you don't want to write (remove-if (complement #'not-red-p) jellybean-list). If keep-if has a silly name remoe-if-not, you might nonetheless prefer (remove-if-not #'redp jelly-bean-list).

Shims like complements are ugly, and compilers won't optimize through them for arbitrary function definitions (whose source code is not even in scope), so it is good to have both keepers and removers. Heck, it's useful to have a function which does both in one pass returning two values: the filtrate and the retentate.

Smalltalk has #reject: which does that. You could, of course, just wrap a not around the test in the closure, but sometimes reject with a well-named predicate is easier to read.

bsnpApproved := tvShows reject: [ :eachShow | eachShow hasNaughtyContent ].

The filter keeps the tea... it's just that you then lift the filter out of the cup, carrying the tea with it. Flip your brain around to see it from that direction and it might help you with the mnemonics.

> While map is a great name, I always struggle to remember if ‘filter’ keeps elements that match the condition or removes them.

In Common Lisp both functions exist, under the names `remove-if` and `remove-if-not`.

In elixir we have Enum.filter (run a predicate over the enumerable keeping the things that match the predicate) and Enum.reject (run a predicate over the enumerable removing the thing that match the predicate)

I think since we have a pair of them and reject is so obvious it helps me remember which way filter works.

I think Enum.keep and Enum.reject might be a better pair, but I've used them enough to internalize it now

Maybe those two could be filter_for (the “where” case) and filter_out.

Kotlin has filter and filterNot (it also has separate "reduce" and "fold" functions, dependingon whether you want to specify an initial accumulator value or not)

If you're making tea with a colander something is very wrong ;)

I was thinking an apt analogy might be making stock -- you filter out all the solid food you don't want to keep in the liquid.

And it's a doubly-good analogy, because I have occasionally gotten that confused in real-life as well. Twice in the past ten years I've had a stock boil away for three hours, and then set a colander in the sink and poured it through, only to watch my beautiful stock swirl down the drain because motor-memory made me forget that I wasn't draining pasta but should have put the colander in a bowl...

This is painfully relatable.

depends on the size of the sieve, but sometimes one does cook a whole stewpot of tea at once (f.e. in canteen)

A colander would allow the tea leaves through to no purpose. A colander is a type of sieve but a sieve is not necessarily a colander.

  > I always struggle to remember if ‘filter’ keeps elements that match the condition or removes them

if you had parameter names maybe it might help?

`filter(where:)` like in swift...?

Doesn't seem to help the ambiguity to me.

maybe its the verb?

what about `exclude()` or `keep()`?

in those cases its less ambiguous (to me anyways) that returning true means 'yes' to 'keep' or 'exclude', whereas saying yes or no to filter is like 'filter to exclude or include?'

thats my take anyway

select/reject (Ruby)

To me, the public seems to prefer a design that integrates, or fit in, with the rest of the street/location it's in.

Modern buildings often are their own idiosyncratic isolate in the middle of the city.

When looking at movies, cities tend to have a uniform feel and look (like the elvish Rivendell), and I think people enjoy that.

Like Mont-Saint-Michel in France, or the Chuxi Tulou village in Fujian, China.

When we moved to the bay area in 2015 (south bay), I was absolutely stunned at the variety of residential architecture, having come from the mid-Atlantic where everything tended to be uniform based roughly on construction date/period. Since land is exorbitantly costly, homeowners tend to build what they like, no matter whether it fits the neighborhood aesthetic or not.

I'm pretty sure that some kind of hybrid can be found where the exterior could look nice and the interior would be very nice as well.

Now, not every modern building has to look like a glass and steel colorless brick.

For example, I really like the look of Oodi [0], Helsinki's new library: it reminds me of wood covered with snow, and the interior is exactly what you would expect from a modern building (built in 2018).

[0]: https://oodihelsinki.fi/en/

Oodi is very much modern architecture. Nordics are full of pretty modern architecture.

The article reads like the author picked a conclusion and made things fit his opinion.