mmyrte

No, but you do need to keep them secure. The argument goes towards computers as appliances, which I wholly support.

I am sure that this exists for other ecosystems as well - rustdoc, Documenter.jl and Sphinx seem to support this - but my experience lies in R: three of the Diátaxis categories map quite nicely onto R package constructs:

- Tutorials are implemented as "vignettes", executed on package validation - How-Tos are attached in roxygen documentation chunks, likewise executable by default - execution disabled when expensive or to avoid side effects. - Reference is implemented in a TeX or Markdown format, commonly parsed by roxygen

The only thing that's missing is a canonical way of documenting implementation rationale. Having the documentation outside the repo worked before LLMs, but there was always that weak point of code drifting away from the documentation...

Forgive my ignorance, but it seems that there is more information in the "explicitly inclusive" form than the "implicitly inclusive" one. Doesn't the existence of the inclusive form allow you to explicitly use a non-inclusive form? So in this case

Lehrer being explicitly male and Lehrer:innen being explicitly inclusive?

I appreciate that this seems to be an emotional topic, but if people choose to use language in a new way, would it not be best to not withhold that information from you as a reader? Someone else wrote that it's like using an ad-blocker, but if I were to read an article, I would want to read it in the exact form someone wrote it, no? It's a bit like Americans auto-replacing "fucking" with "f***g" in their browsers to avoid an annoyance, but they lose information in the process.

It seems like you would lose meaning by automatically replacing words, no? Why would you want to censor your internet experience, just because you find someone else's use of language awkward?

I read it not as a self-diagnosis but as "I have tested positively, and moreover I believe in the veracity/adequacy of the test".

TL;DR: In climatology, I know people are using zarr. However, I think columnar storage as in parquet also merits consideration.

My thinking goes as follows: I'm trying to read chunks from n-dimensional data with a minimum of skips/random reads. For user-facing analytics and drilling down into the data, these chunks tend to be relatively few, and I'd like to have them close to one another. For high-level statistics however, I only care that the data for each chunk of work be contiguous, since I'm going to read all chunks eventually anyways.

You can reach these goals with a partitioning strategy either in HDF or zarr or parquet, but you could also reach it with blob fields in a more traditional DB, be it relational or document based or whatever. Since any storage and memory is linear, I don't care whether a row-major or column-major array is populated from a 1d vector from columnar storage with dimensionality metadata or an explicitly array based storage format; I just trust that a table with good columnar compression doesn't waste too much storage on what is implicit in (dense) array storage.

Often, I've found that even climatological data _as it pertains to a specific analytic scenario_ is actually a sparse subset of an originally dense nd-array, e.g. only looking at data over land. This has led me to advocate for more tabular approaches, but this is very domain specific.

"Orion" is developed by the people at Kagi, free, and blocks a lot. As soon as I'm earning a salary again, I'll be supporting them financially; super valuable.

Have you thought of marketing at cities or public sector consultancies for modelling urban heat islands? Might be handy to prioritize climate adaptation measures.

Are you sure you mean topological data science? I know that there are topological methods for classifying high-dimensional data structures, but this discussion is mostly geographical/topographical. Yes, it does describe a surface, but there's a fundamental assumption that all objects are either on a plane or a sphere.

edit: If you mean GIS (geographical information systems/science), there are plenty of undergraduate courses strewn over github. IMO, the R geospatial ecosystem is more mature than its Python counterpart, but both are very usable.