I think you may be overestimating the importance of the programming language over the whole programming environment. I think it is the programming environment that is the most important tool – not just the language. There are often many requirements that might lead you to choose a possibly inferior language because it lives in an altogether superior environment for your needs.
I have been writing large, server side software for many years. These are long-running applications that require superb performance as well as first-class monitoring tools. So, for me, one requirement for a language is that it runs on the JVM. The JVM gives you superb performance as well as unparalleled monitoring tools (made even better by the inclusion of the flight-recorder and Java Mission Control in the latest version of the JVM); you also get a vast ecosystem with a huge selection of very high quality libraries (and some other important features like dynamic linking) – all that before you even choose a particular language. You can also buy commercial support for every single component you're using if you need it.
On the other hand, if you're writing a command-line tool that needs a very fast startup time, or if your RAM is very constrained, then the JVM might be a bad choice for you, which would rule out the JVM languages no matter how good they are.
My point is that there are more important issues to consider than the mere merits of the language itself.
Also, you're putting a lot of emphasis on expressivity, while downplaying the importance of a short learning curve. I think the two are of similar importance. It's been my experience that programs written in some of the more expressive languages are actually harder to maintain than code written in the easy-to-learn ones. The reason seems to be that programmers use the expressivity of the former (which seems to be of a particular nature or natures: functional construct, higher-order types, meta-programming) to model their own thought-process, which may be hard to replicate for someone else maintaining the code. The easier-to-learn languages usually work at a lower level of abstraction, which can sometimes be easier for others to follow because its a well-understood common denominator.
Now, I'm not saying that worse is better, or that more "primitive" languages are better, or even that one should pick them over more expressive ones. I'm just saying that, especially when working in a large team or writing code that would need to be maintained for a long time, there are other issues to consider.
Programming will always be a matter of modeling your own thought process. That's what domain knowledge is: a model of the problem domain so precise that a machine can follow it.
The important part is how easy that model is to communicate to the other programmers on your team, because that's what source code is. And that's going to depend upon their backgrounds. Hire a bunch of hackers that are all familiar with idiomatic Python, and Python is a great tool for communicating. Hire folks who like things spelled out in more detail, and Java is a great tool for communicating. Hire people who all think at the level of the machine and C is a great tool for communicating.
I do think that one of the major benefits of choosing a language is that you pick the people who will be willing to work with you. If you pick Haskell you will end up with a lot of folks with mathematical backgrounds and an interest in programming languages for programming languages' sake, which may or may not be a good thing depending upon problem domain. If you pick Python you will end up with a lot of folks that have command of large toolbox of scripting functions, although that toolbox may not perform great when adapted outside its original domain. If you pick Java you will end up with a lot of folks that don't want to think too hard about their language.
>The reason seems to be that programmers use the expressivity of the former (which seems to be of a particular nature or natures: functional construct, higher-order types, meta-programming) to model their own thought-process, which may be hard to replicate for someone else maintaining the code.
I agree with that. Working on code in a large and ever changing team is very difficult, and it seems to benefit from less abstraction, even if it leads to more verbose code. That's the whole secret of Java. I've been implementing a small part of my current project in Go and it has similar benefits.
That said, when working alone or with one or two others, I feel kind of dumb repeating some things over and over at the same level of abstraction. There are lots of things like this little piece of C++ code that I tried to translate into reasonably efficient Go:
As an aside, Go is also "a Java" in the same sense that Clojure is a lisp (similar syntax and concepts, same level of abstraction, same philosophy). In fact, Google seems to be turning out many of these "Javas" lately (Android, Go, Dart).
While Java and its variants' appeal at most large organizations is considered by some a sign of their conservatism, Google is anything but when it comes to picking the best tools. Google's fondness of Java is evidence of the merits of the Java philosophy when it comes to maintaining large codebases by large teams.
Creating a language that follows this philosophy while still boosting productivity (and maybe providing other benefits as well) is an interesting challenge. I think Go falls short. Kotlin looks interesting.
I always thought the Java love at Google came from needing speed more than a startup -- they automatically will get factors of ten more users directly for most everything they do. (Edit: Point is, "Java-like" is Google's optimum for other reasons than being conservative.)
Sure, performance is a big requirement for them, but there are other languages with good performance and better expressivity (like Haskell and Scala), yet they are not used at Google, and Google's new languages did not adopt their philosophies.
Google uses Java because they were able to pick up a lot of really skilled Java developers during the 2001-2004 recession, and those devs built many of the products that were introduced in 2004-2007. Once a product's been built and adopted by the marketplace it's very difficult to change the implementation language.
Most of the devs who were hired at Google from 1999 - 2002 still prefer C++, and products built in that era (Search and much of the infrastructure) are still in C++. In general rewrites from C++ -> Java have not gone well; I know at least one such frontend that was rewritten back in C++ a year later.
I'm not sure I get your point. Are you saying that Google's new programming languages adopt the Java philosophy because of developers they hired over ten years ago? Also, I'm not sure I understood what you were trying to say about C++ at Google.
I think his point is that the choice of language at google isn't exactly a managerial or strategic decision. They just happen to have a lot of java devs (probably at senior positions now, since they were hired a long time ago).Even if they have gone out, if most of your stuff is made in a language, it would be really difficult for new comers to shift that paradigm to some other language.
The part about C++ was to describe a similar scene. When they had mostly C++ devs, their language of choice was C++. and now they have mostly java devs, so java it is!
Wouldn't it be better to avoid calling the V() default constructor every time the function is called? You never know, it might have some long-winded side effect...
template<typename V, typename R>
R defaulted(const V& val, const R& default_val) {
const static V v0;
return val == v0 ? default_val : val;
}
With GCC, at least, you can guarantee that it's thread-safe. (Of course, in some pathological cases you can get then get deadlocks during global static initialisation. C++ is such a lovely language!)
Also, I don't think Google's style guide is the be-all-and-end-all of good C++ style. Virtually non of Boost's code would comply with it. "We do not use C++ exceptions" indeed!
Google's styleguide makes it clear that the reason they don't use exceptions is because all code that calls a function that may throw an exception needs to be exception-safe, and Google has a large body of code that was written before exceptions were reliably supported by many compilers and so isn't exception-safe. It's a historical accident, in other words. The styleguide is also clear that if they were designing the it in the present without having to deal with a large body of legacy code, they might make a very different choice.
You're starting from a false premise, which is that Boost is good. In reality, Boost is stuff that either couldn't make the cut to get into the C++ standard library, or is so new that nobody knows whether it's any good or not.
Boost is stuff that everyone wants to use but can't because they're forced to use an old or broken compiler that isn't capable of building real C++0x/C++2011 code. It's a staging ground. How else are you going to use std::bind or std::thread et. al. with visual c++ 2005?
Also, there are plenty of nice modules in boost that just don't belong in the standard library. ASIO is quite nice, but it has io_service implementations that are platform dependent. Statechart is pretty good, but it isn't the only state machine implementation in Boost and neither is clearly better than the other. Spirit has it's uses, but does it belong in the standard library?
You would never catch me saying that Boost is good. Heaven forfend! Some of it is good, and other bits are awful. The Boost "style" is, however, quite popular in commercial C++ projects.
Agreed. For example, if your environment is Google App Engine, your choices are more limited, and Go suddenly becomes a very attractive performance option.
I have been writing large, server side software for many years. These are long-running applications that require superb performance as well as first-class monitoring tools. So, for me, one requirement for a language is that it runs on the JVM. The JVM gives you superb performance as well as unparalleled monitoring tools (made even better by the inclusion of the flight-recorder and Java Mission Control in the latest version of the JVM); you also get a vast ecosystem with a huge selection of very high quality libraries (and some other important features like dynamic linking) – all that before you even choose a particular language. You can also buy commercial support for every single component you're using if you need it.
On the other hand, if you're writing a command-line tool that needs a very fast startup time, or if your RAM is very constrained, then the JVM might be a bad choice for you, which would rule out the JVM languages no matter how good they are.
My point is that there are more important issues to consider than the mere merits of the language itself.
Also, you're putting a lot of emphasis on expressivity, while downplaying the importance of a short learning curve. I think the two are of similar importance. It's been my experience that programs written in some of the more expressive languages are actually harder to maintain than code written in the easy-to-learn ones. The reason seems to be that programmers use the expressivity of the former (which seems to be of a particular nature or natures: functional construct, higher-order types, meta-programming) to model their own thought-process, which may be hard to replicate for someone else maintaining the code. The easier-to-learn languages usually work at a lower level of abstraction, which can sometimes be easier for others to follow because its a well-understood common denominator.
Now, I'm not saying that worse is better, or that more "primitive" languages are better, or even that one should pick them over more expressive ones. I'm just saying that, especially when working in a large team or writing code that would need to be maintained for a long time, there are other issues to consider.