The effect in the data (unless it isn't random fluctuation. At the moment I'd go with the assumtion that it is a genuine correlation, as the effect is present over all subgroups), might (1) not be monocausal, i.e. a combination of contributing factors like development experience, age of IDEs/tooling, etc. might play a role as well as other aspects. (2) a cause might not be "explained away" because the control variable was considered. Let me elaborate
The years of experience variable might be taken to explain away the effect of experience, and then conclude that tabs vs. spaces must be due to another effect than years of experience. But chances are, that "years of experience" and "tabs vs. spaces" are just correlated to a common, causal property (like "programming proficiency" or however you want to call it). Both "years of experience" and "tabs vs. spaces" are then just incomplete reflections of the underlying cause, both rendering the effect of the underlying cause incompletely.
What I am trying to say is: Its complicated, probably you won't be able to find the one true cause for the effect in the data. If this were physics, one could come up with a predictive theory to put this to the test. In social studies, we just cannot control the parameters well enough.
If you are interested in reading more on this, "Causality" by Judea Pearl is a good (but exhausting read).
as a european, in canada and the US I was constantly confused by directions. america uses street names and cardinal directions (turn north on I-??? then west on ...). europeans think in terms of sequences of towns (to get to munich I must drive on the autobahn via Stuttgart, Ulm, Augsburg).
I once travelled from toronto to chicago by car and decided to write down my own directions from google maps because I felt the ones provided were useless. Boy, was I lost when I didnt see a roadsign for windsor/detroit.
I wonder how different / similar these romance languages are, compared to the reference frame I have: German dialects. German dialects can be mutually unintelligible, young germans typically know standard german and thus have a "common ground" for communication, also they usually speak a form of the dialect that is already considerably closer to the standard "high" language of newspapers and televisions, than what their grandparents or their great grandparents speak / spoke. Sometimes (typically in documentaries), they even subtitle dialect speakers.
So yeah, I wonder if depending on the context, the classification of languages and dialects differs.
> The name "Ukraine" (Ukrainian: Україна Ukrayina
> [ukrɑˈjinɑ]) derives from the Slavic words "u", meaning
> "within", and "kraj", meaning "land" or "border".
> Together, "u+kraij" means "within the borders" or more aptly in
> English, "the heartland".
To quote wikipedia. I.e. from what I read on Wikipedia, it is the other way round: Ukraine is the heartland, Moscow would be at the outskirt.
I started to write a toy compiler in OCaml. I had some previous experience with Haskell, but in no way an expert. I.e. no category theory background, only shallow exposure to monads.
My "problems" with OCaml started, when I wanted to "map" over a data structure I defined. I ended up having to define custom mapping functions for all container-like data structures I wrote and call them in a non-polymorphic fashion (where I would have just used fmap in Haskell).
Sure, in OCAML I needed to use a parser generator where I would have used megaparsec in haskell, but it was also a tolerable inconvenience.
Trouble started when I needed to track state in the compilation process. I.e. I was generating variable names for temporary results and values, and I needed to track a number that increased. In the end I used a mutable state for it, and it turned out nightmarish in my unit tests.
After a while, I just ported the code base to Haskell and never looked back. The State monad was an easy fix for my mutable state issues. Parser combinators made the parser much more elegant. And many code paths improved, became much more concise. It is hard to describe, but in direct comparison, OCaml felt much more procedural and Haskell much more declarative (and actually easier to read).
The only advantage of OCaml to me is the strict evaluation. I don't think lazy evaluation by default ins Haskell is a great idea.
But kind of it was also the tooling. Most svn projects I worked on were trunk-based and thus integrated much tighter than git feature-branch based code. However, the times I merged subversion branches, I kind of was sure that subversion lost some changes.
especially with very small commits, I find small commits to be tedious and error prone (sometimes the software doesn't even build because the developer distributed two not-so-independent changes over two commits because the connection wasn't so obvious. Then you have a failed build and you don't really know if `git bisect` just beamed you into the middle of a refactoring, or whether there is an actual issue.
indeed, if the commits are individually reviewable it is nicer. To the contrary however often these small commits can be a bit messy. Sometimes you'll find commits that are reverted later on, or fixed up later on. I.e. for commit-level review to work well, it's great if the history was polished.
Changing public history is bad, because it makes collaboration and two devs working on one branch harder.
But I do not see a problem with rewriting history on a branch, if (and only if) you kind of know that no one else is pulling the changes. Or, when merging a PR, a rewrite is okay too, if the next feature will be branched off of the trunk, too.
Also, mercurial's tooling seems to help https://www.mercurial-scm.org/wiki/ChangesetEvolution with rewritten history by making it easier to track history rewrites. Basically I think this is a path in version control systems worth exploring.
> I'd wager BDFL prefers the CPython implementation because it's probably simpler. Also, it supports tons of targets and is super simple to build.
At a EuroPython Keynote, the BDFL mentioned that he hasn't had a closer look at PyPy (he mentioned downloading it and playing with it for a few minutes). I.e. there is a certain disinterest. Also, remember that the "Zen of Python" (https://www.python.org/dev/peps/pep-0020/#id3) was written about the design principles of the Python interpreter, and PyPy is not exactly the Zen of python.
Personally, I'd love to see Python 4 to be based entirely on PyPy.
I think you can do that in a merge commit, sort of.
The more I think about it, the stranger a strong aversion to rewriting commit history for clarity is. In university if I did some math / physics calculation, I would often start, and once I got somewhere, make a clean copy of the successful work to have a concise and revised version.
My personal, subjective impression: Commits are getting smaller and smaller nowadays. As in: In the subversion days, many people commited only few times a day, sometimes not for several days. SVN commits of course involved a sync with the server (a "push" in git lingo), and thus usually represented a much larger increment with a substantial change to the code base [X]
With git, it became very common to structure changes to a code base in many, very small commits. Rename a variable? Commit. Write some docs? Commit. Of course, the overall changes when developing a feature did not become smaller, they are now just distributed over many more commits. So I'd argue that a SVN commit was often conceptionally closer to what we now have with a git pull-request.
Why does this matter? Because It is kind of hard and not helping anyone if you describe your renaming of a local variable with an extensive docstring.
What I do miss however, is a good description of the overall change. I.e. now often the description in the merge commit is just the autogenerated message, but this is where I would like people to really take the time and describe the change extensively. This is why I like `--squash` merges, because they let people focus on the relevant parts in their description. I know, rewriting history is bad, but overall, I favour reading a history book than 18th century newspapers.
[X] not saying that there weren't small one-line-change commits, but overall they were rarer.
Funnily enough, there is precedent, that a red light can be ignored if it doesn't change for 5 minutes. And I really doubt that there isn't a way to regulate the crossing without a permanent red light.
The years of experience variable might be taken to explain away the effect of experience, and then conclude that tabs vs. spaces must be due to another effect than years of experience. But chances are, that "years of experience" and "tabs vs. spaces" are just correlated to a common, causal property (like "programming proficiency" or however you want to call it). Both "years of experience" and "tabs vs. spaces" are then just incomplete reflections of the underlying cause, both rendering the effect of the underlying cause incompletely.
What I am trying to say is: Its complicated, probably you won't be able to find the one true cause for the effect in the data. If this were physics, one could come up with a predictive theory to put this to the test. In social studies, we just cannot control the parameters well enough.
If you are interested in reading more on this, "Causality" by Judea Pearl is a good (but exhausting read).