data_hope

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

The best discussions are usually marked off topic or 'no good fit" or "not of use for future readers"

I can tell apart from whick village around my home village comes from just by hearing them say the word "eier" (eggs).

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.

line spacing of the gutenberg-latex-typeset version is terribly enlarged. It's a disease... Who can read that?

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

Not if the merge commits just say `merged branch ....`.

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.

neat

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.

excellent

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

ah you are right, probably there is a blue right-turn only sign (I just thought about the Grünpfeil depicted in the illustration image).

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.

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

I'd like to add, that with IKEA you know what you can expect in terms of quality, sturdiness and usability. You know it's not the best, but you also know that it'll survive a few years and maybe moving once.

With other brands, your expectation has a broader variance.

* the discount furniture competitor also uses cheap material, but you cannot be sure that you can even assemble the furniture (lousy packaging and screws are missing or you aren't able to grasp the manual, etc). * the quality brand thing might be amazing, or it might just be an expensive, good-looking piece of bad furniture. Anyone use USM Haller?

I admit: I buy all my furniture at IKEA. And helping friends move their furniture from place to place, I have learned, that IKEA is the choice if you don't want to become a furniture expert. They are sturdier than their reputation, their design doesn't quickly fall out of fashion (like other furniture often does) and overall a rational choice.

Also this seems to be reflected by the their resale value. I had lived a 1 h drive away from an IKEA last time I moved, and was able to sell off a lot of ikea furniture for prices I never dreamed reachable for used furniture. People knew what to expect, what the stuff cost new (because: catalog), didn't want to do the 1 hour drive and then felt like a high price was still reasonable.

Does it support virtual environments that are within a vagrant machine? That is a use case that I hardly find integrated in IDE's (other than pycharm) and so I usually quickly go back to vim and terminal again.

http://majutsushi.github.io/tagbar/ ?

Uh, I think every TDD "expert" makes it pretty clear, that there are cases where tests-first might not be the best option.

interesting, reading your comment, I would never guess that we are speaking about the same book. I found it to be more of a guidebook to precise communication with colleagues and management.

- don't only worry about code or getting features shipped, but about the process, how to deliver quality.

- behind any given reason, there is a complex network of real reasons. You don't need to second-guess any decision/order/suggestion, but it helps understanding.

- most user stories / user requests are raw diamonds waiting to be polished. ("What do they really want me to solve")

Essential reading list:

- Clean Coder and Clean Code https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma... https://www.amazon.com/Clean-Coder-Conduct-Professional-Prog...

- Test Driven Development by Kent Beck https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...

having a more-modern language for scripting? I remember that tikz (a library for vector graphics) had to emulate some floating point math because it just wasn't supported by TeX (which meant when I wrote my thesis, my macbooks fans were going through the roof).

Doesn't Fortran feature variable indices for quite a while now?

I think the varying indices are a great feature for porting old code over from other programming languages.

There are basically not many conclusive and reliable studies out there that would show empirical evidence for or against dynamic or static languages (software engineering is not even a social science in this respect, i.e. psychology and sociology are more empiric than us).

From my personal and anecdotal evidence, I would say that dynamical languages are on average a good choice in terms of productivity. More or less, Smalltalk and Lisp have explored that design space and we have a fairly solid understanding of what a good dynamic language looks like (basically, most of them really look all the same if you look beyond the syntax). There are established practices and resources. I would even go so far and say that with dynamical languages - even though they are highly flexible - we have a pretty homogeneous situation. The most important differences between let's say Ruby, Python, Javascript and Clojure is in the ecosystem (libraries, etc). So I say: So dynamic languages are this robust and reliable family van.

With statically typed languages the situation is not so homogeneous. The selling point of statically-typed languages is that they can give you compile-time guarantees. Yet we have expressive and non expressive type systems. Languages that only allow for simpler types (golang), for complex types (ML/Haskell, and Rust which is simpler in terms of polymorphism yet more complex because it has these lifetimes). What I am trying to say is that already when speaking about expressivity, there are differences in statiically typed languages that are pretty huge. Yet they don't map 1:1 to productivity. I don't think there is a language better suited for compiler-writing than Haskell, yet it will be an unproductive language when I use it as a replacement for shell-scripts (or Python scripts that do shell script tasks). And I frankly don't know if Golang would be the right tool for this (if I had the choice between Golang and Python for writing a compiler ,I would probably choose Python).

When it comes to a CRUD application, it probably is not so much a question of which language you pick for implementing it, but for how well you understand the patterns (MVC, etc) established for CRUD applications, how nice the ecosystem supports you (libraries, frameworks, etc) and how well you write your tests.