I only half agree with this. I agree that there is no one perfect language or stack and that there is a reason for there being so many alternatives. I also have worked with a fair share of languages and stacks by now and am not afraid of picking up any new technology when necessary.
But languages and stacks do have trade-offs. Sometimes the trade-offs can even be almost prohibitive (e.g. there are stacks I've worked on that were so immature they were a legitimate liability to the product and business, even if of course we would find some ways to mitigate them (but you can't mitigate something you're not even aware of)). In other situations, it depends a lot on the context: what languages/stacks does the team/company already know? What sorts of libraries are you going to use (there is no point in trying to use Ruby for an NLP project, for example)? Do you have special requirements in terms of performance, parallelism, etc. (that might exclude some languages)? And so on.
Agreed with the rest of your comment, and I want to add that "the ability to reason about a program in your head" is also why I tend to prefer functional programming with immutable values (even though, of course, that has its own set of trade-offs).
True, it's not that the stacks and whatever don't matter at all, just that they'll change, you will have to learn new ones, and so any kind of religious attachment to one is a sign of an amateur programmer (in the Gerald Weinberg sense).
I, too, really like functional programming for that very reason. :-) It just isn't the approach I grew up with, and the functional programming manner of dealing with imperative is still a bit hard to get my head around.
I only half agree with this. I agree that there is no one perfect language or stack and that there is a reason for there being so many alternatives. I also have worked with a fair share of languages and stacks by now and am not afraid of picking up any new technology when necessary.
But languages and stacks do have trade-offs. Sometimes the trade-offs can even be almost prohibitive (e.g. there are stacks I've worked on that were so immature they were a legitimate liability to the product and business, even if of course we would find some ways to mitigate them (but you can't mitigate something you're not even aware of)). In other situations, it depends a lot on the context: what languages/stacks does the team/company already know? What sorts of libraries are you going to use (there is no point in trying to use Ruby for an NLP project, for example)? Do you have special requirements in terms of performance, parallelism, etc. (that might exclude some languages)? And so on.
Agreed with the rest of your comment, and I want to add that "the ability to reason about a program in your head" is also why I tend to prefer functional programming with immutable values (even though, of course, that has its own set of trade-offs).