tdestan

I think what they're arguing is that since most engineers don't use the algorithmic knowledge on a day-to-day basis (and are thus likely to be rusty), the time they'd need to spend reviewing/prepping to pass a whiteboard coding interview is greater than the time it would take to do the work sample.

I think the target use case is an existing JS library that you want to use from an OCaml/Reason program but don't want to port... OK maybe this is a very narrow use case.

Depends.

Based on my hazy memory of C#, if id is a struct/value type it is copied, but if it is a class type, there's nothing preventing the method call from mutating it.

Which is unfortunate, I agree.

Did you read far enough to see the tuple return value syntax?

  var (first, middle, last) = LookupName(id1);

Seems like what you're suggesting, no?

> Stroustrup is right, there are languages that people complain about, and languages that no-one uses.

This quote has always struck me as an intellectually lazy cop out to avoid engaging with criticism. It's an indirect appeal to the fallacy of false equivalence: "If people actually used language $Foo, surely they would complain about it just as much, because all programming languages are basically the same."

> Either way, people are out there using it, making systems from it, and generally getting on with it.

See, this argument could be used to dismiss any criticism of just about anything.

>If what you are doing is old news and part of an active "enterprise-y" code process, then it does reduce friction. Otherwise, it can be a source of friction unto itself.

I don't understand this statement. What does having an "enterprise-y" code process have to do with anything?

In principle, I don't see why they should have to be. Given an extensible editor and sufficient blood and sweat, you ought to be able to build anything. But in practice, the best refactoring tools I've used have been bundled into IDEs (Jetbrains products, mostly).

I'd be interested in an existence proof here: Is anyone aware of refactoring tools that are not bundled with an IDE, yet still compare favorably with something like Resharper?

This is like attempting to counter a proposed rule/guideline of program design by saying, "You should always use the best tool for the job." While technically true, it doesn't say anything about what makes a tool suitable for a job. Similarly here, maybe there are common patterns/rules followed by libraries that "do their job well and don't get in the way of using other tools." But dismissing any proposed rule just cuts off the conversation without giving a reason. The details really do matter.

I think what bothers me most about this way of thinking (which seems common here and elsewhere in the industry) is that it provides a veneer of credibility to bad developers who don't want to think about design and would prefer to just wing it.

>... and I'm even including Visual Studio itself in this mix, since an IDE that needs extra investments into ReSharper is not that good in my opinion.

That's a fair point, but even so, I've yet to find an IDE/editor/whatever that compares favorably to the combination of Visual Studio + Resharper + NCrunch.

In SVN there really is no technical difference between a tag and a branch IIRC, although their intended usages are different, as you say.

If it supports any form of semantic completion (i.e. Intellisense) , that would be a reason. I'm still not sure from reading the article if that's the case, though.