data_hope's comments

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.

I don't even...

> he wants mathematics to be about textual rules

that is a princial problem with his blog post.

In a way he is also kind of right - although I don't agree with his conclusion. E[X^2] is not the most precise notation. I have occasionally seen notations like E_X[X^2] to avoid confusion and clearly state "the expected value for X^2 with respect to the distribution of X" or something like that. I remember multiple times were imprecise notation has kept me from understanding statistical methods, while I would say that I am reasonably familiar with the field.

Another problem: Different "schools" use different notations, which are then mixed arbitrarily. This is a major problem for example on Wikipedia, where articles use different notation and sometimes switch notations within the article.

https://github.com/dropbox/pyston seems to be option 3

This can be good advice for some. It might not be choice for someone with depression. Deeper problems are not solved by a vacation.

Another issue: In my experience, in north america, navigation is more focused on compass points (take Road XYZ north, southwest, etc) whereas in Europe it is more focused on semantic directions (turn right on highway towards Groningen). The european way allows for easier verification if the road is actually the road you want to take (as in: do I really want to drive to Hobbington? The street sign says I should take the second exit, so I go with that.

from my experience, gramatical gender is always more difficult than no gener, even when you have a native tongue that employs a grammatical gender. In romance langauges, the moon is feminine ("la lune"), in german it is masculine ("der mond"), so for both french and german speakers learning english ("a moon") should be easier, because it does not require learning an additional bit or two of information.

I would argue that dictionary size does not matter for basic language skills, but becomes more important the closer you get to native proficiency.

and the realities of the job economy is exactly why "not PC"?

of course physical labor does not pay as much, as long as the pool of workers is significantly larger. Doesn't mean that some folks would choose another career path if other fields would pay as much as software engineering does.

not everything has to be binary. In fact outside of math and deterministic CS, we hardly have the comfort of being clearly wrong or right. https://www.cs.rit.edu/~rlaz/prec20092/slides/BayesianDecisi...

uh, this is a very pessimistic view on history rewriting.

Much more common probably is the fact that one tries to persist very gradually local changes, and once the dust has settled, submit a much coarser commit. Because most of the time all these "fixup this", "add missing imports" commits are really of nobodies interest any more.

If you hold on to a git hash, you are can identify history changes very easily.

Original author of the blog post here. I find it interesting that your takeaway from my blog post is that I am writing unfavorable over smalltalk. I quite liked it. I think I mentioned that I was checking out Smalltalk, didn't claim to summarize longer experience with it.

Moose looks interesting indeed.

In my experience, people in science who are not statisticians have not completely understood the p value. Typically people are clueless on p-Values and the statistical power and how they relate.