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.

Actually that makes a lot of sense now that you mention it---given the huge number of JS libraries, and the fact that unlike other languages with massive library ecosystems (cough cough Python) JS libraries are all written in JS, that does seem like a nice cheap way to expand the set of libraries available to a nice language...

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?

Better. But the id1 argument can still be mutated by LookupName in this scope, no?

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.

> here's nothing preventing the method call from mutating it.

There is, the class could be immutable.

    public class Vector
    {
        public readonly int X;
        public readonly int Y;

        public Vector(int x, int y) 
        {
            X = x;
            Y = y;
        }

        public Vector With(int? X = null, int? Y = null) =>
            new Vector(X ?? this.X, Y ?? this.Y);
    }

I believe record-types are proposed for the next release of C#.

Mutable class with immutable struct wrapper would be better on allocations; then pass in the struct wrapper.

This is correct. One of the things I miss coming from C++ is the ability to pass const references. Then you have the advantage of passing a reference instead of copying an object, and the compiler enforces immutability in the function using the reference.

On a similar note, I also really miss the ability to define const class methods (i.e. instance methods which do not modify the instance on which they are invoked). Although, perhaps get-only accessors fill part of that niche in C#.

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

To me that quote says that there's no such thing as a perfect language.

Different tools for different jobs. If you wander too far from the main domain of the language, you'll find quirks and it's maybe better to use something else.

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

I wrote a programming language. Nobody uses it. Therefore, it has no IDE support, and trying to use it in an IDE will be a frustrating waste of your time.

Someone else wrote a language. It powers 100 trillion dollars of business. Lots of people use it. Therefore, it will have ten IDEs all competing with each other to be the best, fastest, most popular, and least buggy.

In which environment are you going to use an IDE?

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?

> Given an extensible editor and sufficient blood and sweat, you ought to be able to build anything.

Yeah, personally I prefer to do my integration in the shell, and then have thin hooks into my editor where applicable.

> Is anyone aware of refactoring tools that are not bundled with an IDE, yet still compare favorably with something like Resharper?

I'd also be very interested in this. I do most of my refactoring semi-manually (leaning heavily on my editor and compiler).

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.

Be pragmatic.. use the best tool at your disposal that suits your larger environment. If the company you work for is all .Net, they bringing in a small utility app that uses Python is a pretty big risk. The same can be said for most things in a given environment.

That said, I gave node a beachhead into a number of projects, because they were web applications and it made sense to do so. Even if not running on node, having the client-side bits using node tools made sense.

It really just depends. All in all, there are at least a dozen options for any given problem, and 4 out of 5 times the closest thing to what you are already doing is likely the right answer.

Yes, the point is—depends on what? That's the useful conversation to have.

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

To the point where it's almost easiest to say SVN doesn't have branches or tags - it just has directories and conventions.

Git doesn't really have a technical difference between a tag and a branch either. They are both files containing a hash for some commit. Tags are just more cumbersome to move (branches are moved on new commits), and they can be signed cryptologically(is that a word?).

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.