rpier001

I didn't see it in the comments, but FWIW you can choose specific dependencies. You can use regular [dependency specifiers](https://packaging.python.org/en/latest/specifications/depend...), see [PEP 723](https://packaging.python.org/en/latest/specifications/inline...).

Re: b. This is a place where remote standard dev environments are a boon. I'm not going to give each dev a terabyte of RAM, but a terabyte to share with a reservation mechanism understanding that contention for the full resource is low? Yes, please.

I wonder if anybody has used PostgREST (https://docs.postgrest.org/en/v12/) and explored this could provide a comparison. They seem largely similar with PostgREST having some feature advantages associated with being built on Postgres. Where does Manifest have an advantage?

We need a to-do app following these principles... then another for product management.

R is the better EDA language by far. Python has caught up a lot. Notebook diffs are now readable in git with the right tooling, that's huge.

The drum about not fitting into data pipelines... if you're literally using a bash pipe its true most R programmers have no idea how to do that. Otherwise, that is where Docker and k8s shine.

On packaging. R's package authority runs tests and ensures that all packages work with the latest version of their peers. The dependency heck is much less deep as a result.

We use R at my employer still because we put statistical data science into production. Our experts come to us comfortable with R. Reimplementation would be absurd.

Out of context (and with limited knowledge) comment 3 seems terrifying.

Relax, don't do it. When you want this, you're turning the relations in postgres into a contract. No service gets to persist internal state. If you're _really_ committed to domain driven design it could work... but you'd be better off with a light (but real) event driven system.

Effect size g is in units relative to variation. It's a corrected version of Cohen's d for cases of unequal variance between groups.

Right on the linked page is commentary about how the title is misleading. https://www.nature.com/articles/s41598-020-62398-w

I expect the emails themselves are just formatted strings. You could use an email parser to get the structure back out. You or someone else mentioned Zapier webhooks, so https://parser.zapier.com/ might be extra relevant.

I wonder if import taxation that reflects externalities (pollution) and costs that we carry to reduce suffering (child labor, minimum wage) would make a difference.

When Google got into self driving cars that was a thought some people had in earnest. Self-driving means a lot more time your eyes can be on ads.

There is also the question of what constitutes 'racist'. In earlier times the threshold/definition included malicious intent. In 2020 more people, myself included, are prone to include cases of benign neglect/inattention.

Yeah. It kind of is. If we trained as much for black faces as white faces, the algorithms would be better. Moreover, the background contrast for white faces is frequently worse (against backgrounds of white walls).

People in other professions have similar issues. Some 'smart' folks feel as if they should be able to understand everything. It probably often works for them, after all, how did they become 'smart'? But, it's a fine line between genuine interest and distrust per se. Try to assume good intent, consider it interest and grow your ability to explain. At some point you might have to call it as a poor use of time and move on, but if you can use the time to grow on both sides of the discussion - bonus.

What technology in what language are you comparing them against?

Are you trolling right now? R's idioms for parallelism are pretty darn straightforward and easy to use. Effective too.

Effectively. These days you can use a Python kennel in notebooks and get syntax highlighting, but not much else. Python and SQL are supported but second class use cases.

One thing your rods (lower light receptor cells that are more dominant 1deg+ off the exact area of gaze) have peak sensitivity at the 'green' range of the spectrum. So, green will nuke your night vision whereas red (and to a lesser extent Amber) will leave your rods dark adapted.

In short, not entirely. Bayes' theorem helps when you have a correct model. People don't have access to truth or correct models. Generally people applying Bayesian methods are using cookie cutter formulas. These can't protect you from the many many ways one can muck up their data especially if you want your decisions and density intervals to be close to "right".

For what it is worth, priming isn't really K's work. System 1 and System 2 isn't even unique to him. See also, httpp://www.decisionsciencenews.com/2012/10/05/kahneman-on-the-storm-of-doubts-surrounding-social-priming-research/

It isn't because he is not. One line of research he endorsed, priming, has failed to stand up to rigorous attempts at replication. Nearly every other aspect of behavioral economics he brought to the forefront remains intact and important.

Except that the quote reflects a common misunderstanding. The problem of optimal stopping is mostly a function of decision making over multiple looks. A Bayesian approach that makes decisions over multiple looks has similar issues. This can be mitigated by strong priors, but typically to an unknown degree and at some cost to 'power'. How/why does this claim arise? It is because a 'true' Bayesian approach makes no decisions/inferences - it just describes the current state of knowledge. If describing the distribution of the posterior, then 'stop at any time and be valid' else 'you got your Neyman-Pearson in my Bayesian analysis'.

scale() for example uses attributes to hold on to the parameters used for scaling. Most packages that use attributes provide accessor functions so that the useR doesn't need to concern themselves with how the metadata are stored. I'll grant that people do tend to use lists because the access semantics are easier.

Sounds like you aren't running your scripts as scripts. If you source a script or run it via Rscript it will halt when it hits a failure (unless you've changed a default). Copying and pasting in to the REPL will hide errors like you describe.

The other part is that it sounds like you don't have a standardized R environment. I admit that R's tooling there isn't the best, but there are options, e.g. {packrat} & {lockbox}... or better yet a Docker image.

> It seems likely that R could have been designed to have the same strengths without having so many weird and arbitrary quirks.

Not really... at least not practically. R is a successor to S which was written in 1976 (fun talk on the history: http://blog.revolutionanalytics.com/2016/07/rick-becker-s-ta...).

Many of the arbitrary quirks started out for the sake of backward compatibility with S. All that being said, yeah, you could probably design a 'modern R' without the weird and arbitrary quirks.

I think what you're saying is mostly on point. I wanted to share a couple possible balms for your bugbears.

For attach metadata to an anything, why not use attributes()/attr() or the tidy equivs? Isn't that what it is for?

It might not make you feel much better, but data.frame is just a special list, c.f. is.list(data.frame()). So, if you don't want to use the connivence layers for data.frame you can just pretend it is a list and reduce the ways of accessing data structures by one.

You can paper over the distinction between data.frames and matrices if it comes up for you often enough. E.g.

`%matrix_mult%` <- function(x,y) { if("data.frame" %in% class(x)) { x <- as.matrix(x) stopifnot(all(is.numeric(x))) } if("data.frame" %in% class(y)) { y <- as.matrix(y) stopifnot(all(is.numeric(y))) } stopifnot(dim(x)[2] == dim(y)[1]) x %*% y }

d1 %matrix_mult% d2

... but I'll grant that isn't the language default.

Have you ever worked with other major statistical packages? Have you ever caught people doing data munging in Excel? R fails far less silently than the credible alternatives. Source: I've been around the academic block and seen many types of horrors.

It's unfortunate that you've gotten to a _terrible_ feeling about R without realizing that many of the 'silent' failures are easily configured away (some examples, https://github.com/hadley/strict). That R isn't noisy about things that CS majors might think it should be by default is, BTW, entirely appropriate. Many of what one might call 'silent' failure modes in R are for the express purposes of making exploratory data analysis easier... and that was one of the original purposes for R.