>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.
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:
I came away scratching my head a little, probably because I'm a Go newbie.