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).

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.

Go on Google Maps and look at a city like Montreal and you'll see that the streets are very rectangular.

Look at a city like Paris and you'll see a spiderweb instead of rectangles.

It throws me much more than it should.

So yeah, I wonder if depending on the context, the classification of languages and dialects differs.

I think academics shy away from attempting to make the distinction except when extremely obvious, and instead talk directly about quantitative measurements and feature overlaps (isogloss is a search term that may be useful here). Dialect/language lines will often have completely different shapes when you look at different distinctions in lexicon, phonetics, syntax, etc. If I had to generalize though, in a particular language "chain", linguists seem to identify an order of magnitude more separable languages than non-academics do. (Consider the cases of huge macrolanguages like "Chinese" & "Arabic", or even "Italian", whose singular labels by laypeople are pretty universally rejected.)

It doesn't help that people are generally unaware of the incredible political pressure most nations put on presenting a singular linguistic front, when the truth is much much more muddled. As a result, the common parlance distinction between dialect & language often verges on meaningless.

My family is from Aveyron/Tarn (near Albi). We can understand texts from Frederic Mistral, written in Provençal (near Marseille) even though it sounds weird. My uncle says he had some success speaking Occitan in the Italian Piedmomd. However neither my parents nor my uncle understand any of the Catalan spoken in Barcelona. (I do, but I'm fluent in Spanish and not in Occitan...)

I think my parents (born in the 1950s) are the last generation fluent in Occitan. In France, even though it's now being taught as a second language, it's essentially gone. My mom told me she used to be punished for using Occitan at school whether in the classroom or during recess. I remember when I was a child, the farmers used to speak it among themselves (or more likely to their elders). The same people today only really speak French, even among themselves.

My father remembers that they could tell the town of origin of somebody by little variations of accent and vocabulary, over distances of less than 10 km in a well populated and well connected area centered around Milan.

Uela, you have to consider that Milanese dialects basically overlapped modern Italian already - as standardized on the works of Alessandro Manzoni, a writer from Milan. The accents still survive though, and even a few words.

It's incredibly funny to observe language in motion. At one point in the '90s, a few rappers living in the city I come from (Bologna) popularized a bunch of local slang in their songs. Nowadays, youngsters from Milan use that slang as native and strongly believe it originated there.

And by the way, "bagaglio" always surprises people here.

For the non Italians, among the other things the Milan accent basically swaps the open and closed e sounds. I have to change the way I say spaghetti when I'm outside region :-)

I have seen this in Ireland where upon meeting someone new, one Irish person would guess the other person as coming from a small village (of a few hundred people).

The Irish language itself is interesting. Before standardisation, I'm told the Irish of the north of the island was more similar to Scots Gaelic than that of the south. Many of the regional dialects have disappeared now though.

Interestingly, in this small, flat, homogenous country, linguistic faultlines can still be persistent and razor sharp, clearly reflecting population boundaries from way, way back - the viking age and earlier. Travel some thirty kilometers between some neighbouring major towns, and hear the tone of spoken language change abruptly about midway.

Norway was ruled from Denmark, so the danish ruling class in Norway probably spoke a similar dialect to yours. (See bokmål, basically danish style Norwegian.)

Norway has dialects VERY different from each other - these were used as stock for an attempt at standardization of non-danish-inspired language, which they call "nynorsk". Which is confusing, because it's basically a mix of OLDER norse dialects. :) https://en.wikipedia.org/wiki/Ivar_Aasen

In Norway, the very distinct local dialects makes sense, because people were separated by high mountain ridges. (The same story goes for Greek dialects, but I digress.)

So it IS indeed interesting that Denmark, which is very flat, still has these sharp boundaries. :)

Rhythm and intonation of spoken Danish shifts markedly down towards the southern islands. No difficulty of compehension whatsoever, but it's clearly a dialectal belt with a history quite different from neighbouring parts of Sjælland (or "Zealand"). I'd love to see a genetic mapping of the local communities. I'm almost certain that lots of corresponding patterns would turn up.

The article alludes to this at the end:

"Romance linguistics teaches that by walking across the former Roman Empire from Sicily to Normandy, every pair of neighboring villages can understand each other."

"Language" vs. "dialect" is also very tricky because politics often come into play to demarcate the two. The classic saying is that a language has an army and a navy whereas dialects do not (i.e.: languages are associated with nation states).

And the classic example is that of Norwegian, Danish, Swedish which due to high mutual intelligibility are often linguistically thought of as dialects of one language. However, each one belongs to a nation state whose inhabitants would likely often disagree that they speak "a mere dialect".

Edit: Stepped away from the computer for a long while before actually posting, hence the similarity to the answer below.

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.

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.

Ocaml does tend to be more verbose than Haskell - it's just the nature of the language syntax. E.g., in Ocaml, one says (fun x -> x+1) vs (\x -> x+1). Similarly, ocaml is cursed by the excessive "in"'s that accompany let bindings. "Let .. in let .. in let ...". That can get annoying.

Interestingly, I had the opposite experience with a commercial compiler project. Haskell's syntactic cleverness (monadic syntax, combinator libraries, etc..) eventually got in the way - it became very difficult to understand what a single line of code actually meant since one had to mentally unpack layers of type abstractions. Migrating to ocaml, the verbosity eventually was more tolerable than the opacity of the equivalent Haskell code once the compiler got sufficiently complex.

My experience may vary from yours. I've been doing Haskell/Ocaml in production for many years, so the pain points I've adapted to are likely different than one working on toy compilers or weekend projects. And no, category theory exposure is not and never has been necessary for understanding Haskell or FP unless one is a PL researcher (and even then, only a subset of PL researchers are concerned with those areas). And one can be quite productive and prolific in Haskell without a deep understanding of monads and monad transformers - the blogosphere has given you the wrong impression if you believe otherwise.

In our case, we dealt with it by keeping relatively bare, boring code. We avoided point-free style, crazy combinators like lenses, and complex monad transformer stacks except in the 'plumbing' part of the application that didn't need to change very much.

This paid off in spades as we had a lot of engineers who only ever had to work in the 'porcelain' parts of the application. They got a lot of great work done using abstractions that matched their intuition exactly.

As an example consider looking at the Angstrom[1] parser combinator library and my Pure[2] functional base library.

[1] https://github.com/inhabitedtype/angstrom

[2] https://github.com/rizo/pure

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.

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.

http://lkml.iu.edu/hypermail/linux/kernel/1702.2/03492.html

I've found that for smaller commits, if you have something long you want to explain in the commit message body... you should probably put it in a code comment!

If you don't think it merits a code comment, it's probably not important enough for people to look up the commit message body either (if only because the commit message body is less likely to be seen).

https://github.com/ribasushi/dbix-class/commit/1cf609901

Something like that I take it? :)

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.

Has it really become so common with git? I don't see such trend around me.

I'm replying to you but this is directed at everybody who advocates squash merge and discourages small commits.

IMO this is a tooling problem, plain and simple. When I am committing to Git, I am using the "write" components of Git which are incredibly powerful. I can commit in as small a chunk as I want and preserve the richest history of all the small changes I've made, knowing full well that the state of the code at HEAD will not be degraded for doing so. If I make two small independent changes, I can feel free to branch them separately and then merge them together to show that they could have been performed in any order.

When you read my history, you are using the "read" components of Git. Unfortunately these are not as powerful. You can do some nice things, like if you want to treat history as a straight line you can use `git log --first-parent` and you'll see only the merge commits (as if all merges had been squash-rebases).

It would be much better if you were able to collapse or expand any sequence of linear commits to gloss over the lower level details. But as far as I'm concerned, this is a problem with the "read" components of Git, not the "write" components, and so I will continue to use the "write" components to their full power. And the best part is that if I do it this way, we can improve the "read" components and allow the reader to collapse my verbose history, but we will never be able to expand pre-collapsed history.

But note the comment above mentioned a commit for variable change. Or a commit for adding some comment sentence. Nano commits they are.

Sure, tasks should be small, easy to get, easy to review. But there must be a balance. Going to extreme, both ways, doesn't do any good.

I find the PR mechanism works great for the view of the whole, whereas the individual commits are great for the pieces. So in my commit history, you can read the timeline, and then if you want to see the commits squashed down, you click on the individual PR. On the PR screen (assuming you're using GitHub), it has a nice list of the subject lines of each of the individual commits.

E.g. https://github.com/ibgib/ibgib/pull/180

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.

This was often the source of merge hell. Half of what makes git merges easier is the smaller commits that it encourages.

http://www.stvo.de/info/faq/165-ampel-bleibt-rot (German)