| > If I were to launch a startup, should I go with the "cool shiny powerful" language, or should I stay with the boring verbose language that I know well? I think the danger with this decision is that we tend to get a "grass is always greener across the street" mentality. I have yet to find a programming language that has no serious warts. Certainly different languages have different warts, and thus suit different jobs better. However, just because we haven't used a language enough to appreciate its warts, that does not mean we will not discover them to our cost at exactly the wrong moment in our new project. Moreover, with newer or more recently popularised languages, there is sometimes a tendency for the community to bury its head in the sand. Some defenders might claim that we "just don't understand" if we identify a serious shortcoming. Sometimes the individual or group that defines/specifies a language will have a blind spot and make seemingly arbitrary decisions that we don't agree with. In contrast, with longer-established languages, the shortcomings tend to be well-known and acknowledged, and the emphasis in the community is often on sharing the most effective workarounds or alternative techniques. Obviously these generalisations aren't necessarily universal. We find helpful people in otherwise intransigent communities and awkward people in otherwise helpful communities. Still, I have seen the pattern repeat over the years for many different languages as they evolve from the Newer And Better Thing to a mainstream tool and ultimately to an older tool that is superceded by the next newer and better thing. When I'm choosing the tools for a project, I usually favour the middle of that spectrum over either extreme. Out-of-date and underpowered is bad, but tried-and-tested is good. YMMV. |
In contrast, with longer-established languages, the shortcomings tend to be well-known and acknowledged, and the emphasis in the community is often on sharing the most effective workarounds or alternative techniques.
Exactly. A good example of this is dependency injection. In Java, it was hard to mock dependencies, like you would do in a dynamic language. This forced the Java community to look into dependency injection / interface programming, to make the code testable. Dependency injection then lead to better componentization / modularity (some could say that one shouldn't have to use dependency injection if one were using a "better" language, though ;) ).
I also like established languages, because there are also established best practices. You don't have to reinvent the wheel.
Certainly different languages have different warts, and thus suit different jobs better. However, just because we haven't used a language enough to appreciate its warts, that does not mean we will not discover them to our cost at exactly the wrong moment in our new project.
That's the reason why I'm leaning on using a JVM language. I know the platform and the tools, and I can always "fall back" to Java if needed (for performance critical code or whatever).
Maturity is important, but I don't want to miss out on the power and expressiveness of higher level languages ( http://www.paulgraham.com/avg.html ). Using powerful languages is also useful when hiring good hackers ( http://www.paulgraham.com/pypar.html ).