nicops

That's all fine and dandy, but conceptually it's wrong to say the average of an array is 0, and can and will lead to wrong results in a variety of cases. I'm sure you can think of a lot of these cases yourself. I think in the history of computer science we programmers have found that there are a lot of convenience shortcuts that make sense in a lot of cases but bite our asses in other. Implicit is fast and fun, but it's nice to have your seatbelt on when the car crashes. Going back to the average case, if you want an average function that returns 0 on empty arrays, fine. But that's not the average function, and you shouldn't call it that way, and names matter, you should call it averageOrZero or something like that.

And it's not like any other language you can choose from for working in the browser is perfect.

But maybe bringing fruits up it's irrelevant in some context, depending on what we're talking about. This is one of these contexts. The very same phrase you quoted from the article clarifies it's not talking about "perfect" rationality.

In the history of psychology/sociology, Freud and Ariely don't make sense with each other.

The irrationality studied by Dan Ariely et al it's not comparable _at all_ with the freudian irrationality. The former brings to the forefront our fauly heuristics and biases. The later is about how culture and our psyche actively makes us ignorant of parts of ourselves that are inconvenient, and that can come out in bursts of irrational, unstable, "crazy" behavior.

Agree with the attention to details. Details are crucial.

But in my experience there is a kind of so-called "perfectionists" that won't work well in complex enviroments where:

1. they actually have to weight in the importance of details (and the cost of dealing with them)

2. Details aren't always obvious, and are easy to miss

So these kind of perfectionists might end up very focused on obvious details that don't matter that much and aren't useful to be taken care of in terms of cost-benefit relation, while ignoring not-so-obvious details that might actually matter more.

> If you need to a 'chill' with the original researcher to get critical details, that's not science anymore.

Certainly there is always the possibility that there was some details misunderstood, something that needs to be clarified, a print error, etc. Your "that's not science anymore" statement seems highly exaggerated. People are not supposed to communicate only via papers.

Agreed. I guess everything is subjective, but when I read the article state:

> While the [ctrl-r] method is more powerful, when doing some redundant task, it’s much easier to remember !22 than it is to muck with ctrl-r type searches or even the arrow keys.

how?!

Let me tell you a story. When I do frontend nowadays, I mostly develop with angular js. People like to complain about angular and having to know so many libraries, and frameworks, when the past was simple.

But what is simple, really? Let's look at some past experiences:

1. At a very first gig, when I was doing my very little first steps in this software thing, I had to build a website prototype. Pure static html pages inside a folder, that were linked to each other, didn't need to deploy, it was just a demo. It didn't use CSS. It didn't use a template engine. Really simple. But, every change was a PITA, because the website had a header, so every change, meant you had to open the file, and rewrite the whole header... in all files, manually!

2. In another moment of my past, I had to do some changes in an app was built with JQuery. JQuery is a library, but it's pretty simple. Select dom elements, and apply changes and hook events up. Simple.

Only, following and understanding the flow of the app was hard as hell. Each page had a lot of code and it wasn't obvious at all what was happening. Complex transformations of the dom were daunting. Small changes would break in intractable ways.

3. PL/SQL Stored procedures + tables. Pure SQL + structured programming is simpler than objects, and way simpler than using ORMS. Of course we had no tests, so less stuff to look at. I'm not even going to describe the downsides because you all people surely know that.

My point is, let's always look at the other side of things, and really weight at all the tradeoffs. I get what you mean but when I read a line like:

> I want to get back to focusing on building logical models that fit the domain, solving problems, and simulating things.

I feel that it's really a little _naive_. I mean, of course you focus on that kind of things. You need to work on backend, solving some kind of problems. But in some other problems, like for example, visual interfaces, you better be reusing shit.

Curious. What do you suggest?

I think that those are valid names in a good context. e.g. if you have a function like "substring", then you can name "str" as the parameter and "result" the variable where you accumulate the result. Any other more semantic name for "result" would be "substring", i.e. the name of the function itself.

Probably because the author doesn't use them and thus has no idea of what their problems are, so they seem "perfect" from a distance.

I would think that in 2016 this should be something everybody knows....

ok, but we were talking about alphaGo here, and what does it represent as an example of progress in AI.

It's progress, very neat progress, but it's not even progress in the sense that there are new kind of problems being solved. AI for Go and similar games has existed for a zillion times, but, given the huge space of the game of Go, it had never been that good at playing it as to beat a human.

Not to diminish that this isn't an achievement, but let's put it into context. To talk about being closer to AGI, a different kind of progress would need to be shown: AI solving different -new- kinds of problems.