I believe that Grothendieck always insisted on spelling his first name "Alexander" rather than the French "Alexandre." If this is true, as I believe it is, let's make an effort to respect his wish.
I like the author's pragmatic approach to evaluating C++ as a programming tool. The question is not, as it is so often posed, "Is C++ too complicated?" (What does that even mean? Too complicated for what?) The question is, "Is C++ so complicated that it diverts too much of my attention and mental resources away from solving the problem at hand?" I personally agree that over the history of C++, the answer to that question has gone from "no" to "most likely so." More and more, C++ is becoming the hammer that forces you to take your eyes off the nail all the time. It seems to me that the areas in which the advantages gained from using C++ outweigh this disadvantage are shrinking fast.
I hope that this is just a reporter getting carried away with his subject, and not an indication of what our civilization has come to:
[...] When Despicable Me 2 came out in theaters last year, Facebook worked up a partnership that let users download Minion stickers. It’s easy to imagine a future strategy for making money off stickers.
As Paul Graham points out, it is absurd to think that he or anybody at his firm would be swayed by someone's physical resemblance to Mark Zuckerberg. However, I have the sinking feeling that in this respect, Mr. Graham and his partners are the exception rather than the rule. That may well be one of the reasons why they are so successful. Not that I have hard data, and I'm not sure if reliable data could be obtained, but I have personally witnessed a frighteningly large number of incidents in which people were obviously influenced by the physical appearance of those whom they were tasked to judge.
I think it was Dave Abrahams who first brought up the issue of destructors with side effects and their implications for move semantics. For example, a destructor may have the side effect of releasing a lock. If I remember correctly, Dave's advice was to write your move operations in such a way that they always perform at least those destructor actions that have side effects. I seem to remember that he discussed this on his cpp-next blog, but the site appears to be down. Does anybody know if those blog posts are available somewhere?
I liked Woody Allen's answer to the question why he was still working in his late seventies:
You know in a mental institution they sometimes give a person some clay or some basket weaving? It’s the therapy of moviemaking that has been good in my life. If you don’t work, it’s unhealthy—for me, particularly unhealthy. I could sit here suffering from morbid introspection, ruing my mortality, being anxious. But it’s very therapeutic to get up and think, Can I get this actor; does my third act work? All these solvable problems that are delightful puzzles, as opposed to the great puzzles of life that are unsolvable, or that have very bad solutions. So I get pleasure from doing this. It’s my version of basket weaving.
Thanks, I have updated the blog post accordingly. There is a conspicuous note at the top now saying the problem will be fixed in version 38. I think the blog post still makes sense, as it will be a while for the fix to become effective for everybody.
I live up in Tahoe, and I've always wondered why Reno doesn't attract more high tech enterprises. It has a good business climate, and it sits right there at the foot of the Sierra Nevada, with skiing minutes away and endless other outdoor possibilities. SF and Silicon Valley are a hop and a skip away. Granted, some of the casinos are eyesores, but who doesn't have eyesores. Right now, Reno is also practically free of traffic congestion and stuff like that. Not sure what I should be wishing for...
I honestly don't know if it's the mathematician in me, or if I'm just a cranky person, or if I actually have a valid point, but if I were given the FizzBuzz task the way it is worded here, I would reject it on the grounds that it is self-contradictory:
'for multiples of three print “Fizz” instead of the number [...]. For numbers which are multiples of both three and five print “FizzBuzz”'
So for the number 15, for example, I am being asked to print "Fizz" instead of the number, but I am also asked to print "FizzBuzz". That cannot be done. A valid way of formulating the problem would be:
Write a program that prints the numbers from 1 to 100. But for multiples of three that are not multiples of five print “Fizz” instead of the number, and for multiples of five that are not multiples of three print “Buzz” instead of the number. For numbers which are multiples of both three and five print “FizzBuzz” instead of the number.
An alternate way of saying it would be:
Write a program that prints the numbers from 1 to 100, except for numbers that are multiples of three or five. For multiples of three print “Fizz”. For multiples of five print “Buzz”.
(Edit: no, the above doesn't work, because it would allow you to print "BuzzFizz" for numbers like 15. You'd still have to add, 'For numbers which are multiples of both three and five, print “FizzBuzz”.' So it's really just the clause "instead of the number" in the original formulation that causes the contradiction.)
Wow. Extremely impressive all around. I can see how Standard Treasury's priorities are well-chosen, in every respect. Personally, however, I find it a bit regrettable that interacting with personal investors' brokerage accounts does not seem to be on that list of priorities. I'd just like to weigh in by saying that for me, for the project that I'm working on, and ultimately for every personal investor, it would be awesome to be able to interact programmatically with brokerage accounts, in a way that is not indirect, kludgy, and costly. The first and most important step would be to get daily balances and cash flows. Next would be getting information about trades. Ultimately, of course, one would be able to make trades. Again, like everything else, this is possible now. It just needs to become easy and not cost an arm and a leg.
It is perhaps worth drawing attention to this sentence in the article: "Though Bayes' theorem is where Bayesians get their name, it is not this law itself that is controversial, but the Bayesian interpretation of probability implied by the term P(F_true | D)." A widespread misunderstanding is that there is something fundamentally Bayesian about Bayes' theorem, or even that frequentists don't believe in it. It is rarely pointed out that this is not the case, and we should thank the authors for doing so.
In this context, it's interesting to look at the history of the label "Made in Germany." It was mandated by the British in 1887 to distinguish true British products from cheap imitations of inferior quality, the latter coming mostly from Germany. And now look what happened. Could it be that the Samwer brothers are the vanguard of a golden age of German software products?
I started a separate thread on that subject earlier. It didn't get a whole lot of attention, but FWIW: search for "thebear" on this page to find it. Specifically, you may like the employee vs. nuclear missile example that someone posted in that thread. That nicely illustrates our point.
Nice example with the nuclear missile. For those to whom this seems contrived, let me explain why the issue of type-safety and semantics is so important to me. I used to work in symbolic computation. In that world, it is very common for a large number of types to have the exact same operations, although they are semantically very different. Example: groups. If type-safety is a purely syntactical notion, then type is no longer a tool to enforce the distinction between different kinds of groups, such as abelian groups, torsion-free groups, etc.
Ok, I got you. If type-safety means, as you say, "you can only use operations on x that x's type supports", then all is well. I must admit that I was under the impression that type-safety meant more: if I assign to a variable x of type A an object of type B, then that is an error even if the type B will work syntactically (i.e. has all the operations needed by my variable x), because it may not work semantically.
Yes, that's correct. It is, in fact, the same kind of behavior you get with templated code: you can instantiate your template with any type you wish; compile errors will occur when the instantiation is used in ways that are forbidden by the type. This behavior has been recognized as less than ideal, and the issue will be addressed by concepts. My question is: if we have this behavior not only for templates, but for every variable, isn't that less type-safety? Isn't that less than 'strongly typed'? (Come to think of it, I think I'm really asking about the definition of 'strongly typed'.)
Thanks for this blog post; it will help me to make the best use of C++11/14 features in day-to-day programming. One thing I've been wondering about for a while is how the auto keyword relates to type-safety. The blog post lists the point "auto type deduction everywhere" under "type-safety". But consider the line
auto x = foo();
Suppose you refactor your code, and in the process, the return type of foo() changes. Without the use of auto, the compiler would produce an error message, alerting you that the above line of code may need your attention. As it is, with the use of auto, the above line will compile no matter what. In other words, that particular line now behaves as if C++ was an untyped language. Isn't that a step down as far as type-safety is concerned? Please note: I'm not asking here whether that's good or bad. I'm asking, "Assuming that we use the auto keyword throughout, can we still call C++ 'strongly typed'"?
- Second Mayor Josef Schmid (CSU, conservative): "Every department I talk to reports user complaints. Our employees are suffering. The original decision to switch to Linux was politically motivated. We feel that Linux is not cheaper for us, because it requires a lot of software development. We're missing a program to handle email, calendar, and contacts in one place. The city will get an opinion from an independent panel of experts."
- First Mayor Dieter Reiter (SPD, social democrat): "Linux software sometimes trails behind Windows software."
- Sabine Nallinger (Green Party): "Data exchange with government agencies outside of Munich does not work well."
Here's a bit of historical trivia that may or may not be relevant in connection with Iran as a potential new exciting market for VCs. I do believe it's something that every hacker should know. I quote from the Wikipedia article on the 9th century Persian Mathematician Muḥammad ibn Mūsā al-Khwārizmī:
Some words reflect the importance of al-Khwarizmi's contributions to mathematics. "Algebra" is derived from al-jabr, one of the two operations he used to solve quadratic equations. Algorism and algorithm stem from Algoritmi, the Latin form of his name. His name is also the origin of (Spanish) guarismo and of (Portuguese) algarismo, both meaning digit.
Given the facts that functional programming has been all the rage lately, and that advocates of functional programming tend to emphasize its mathematical roots, I would find it interesting to get Donald Knuth's take on the subject. Web search came up empty for me. Does anybody know of any statements he's made on functional programming?
OP here: very true. We're not done with performance measurement and benchmarking until we fully account for taxes, and for all fees as well. My grand vision is a system that does that effortlessly for every individual investor. But that's a tall order, considering the data that's needed. We'll get there. But it's probably a long way off. One step at a time.
Indeed, investing in just the S&P 500 would be an example of poor diversification: you'd limit yourself to US large cap stocks. By recommending the S&P 500, Warren Buffet is saying, implicitly, that he believes in US large caps to the extent that he does not even want to diversify.
Yay, my Erdos number is 2 and thus better than that of Richard Feynman. I have a paper with Erdos-1 mathematician Saharon Shelah. Unfortunately, my Bacon number is infinity. To look up your Erdos number, if any, go to
I guess they were right when they said that the cobbler's kids wear no shoes. It stumps me how one of the biggest, most powerful, and most resourceful software companies in the world would have a bunch of humans write a document on how to format source code, then have all their programmers read that document and memorize it to the point where they can abide by it every second of their work day. Formatting code is the kind of thing that a computer can do. Write a program that formats the code the way you want it to be formatted, and invoke it in the appropriate place. Preferably, make it invokable in people's IDEs, so that they can go conformant whenever they wish.
Another way to see the effect of the precession of the Earth's axis is in astrology. What's your sign? It's the constellation in which the sun stands on the day of your birthday. It's easy to see that: go up into the stratosphere in a balloon, and you'll see both the stars and the sun. Identify the constellation in which the sun stands, and there's your sign. So, my birthday is September 7, and my sign is Virgo. But every time I go up to the stratosphere on my birthday, what do I see? The sun is smack dab in the middle of Leo. Now I don't know anything about astrology, and trust me I don't want to, but a possible explanation would be this: the zodiac moves relative to the sun by about one constellation every 2150 years (25800 years for a full rotation), due to the precession of Earth's axis. So my best guess is that they made up the astrological signs about 2000 years ago and forgot all about precession.
I would be interested to know what the OP thinks about stepping through code as opposed to reading it. To me, reading code and stepping through it in a debugger are two complimentary ways of understanding it. I call those the static and the dynamic way of viewing code.
Perhaps the most important insight to be gained from this article is Abelson's statement that "a lot of times you crud up a program to make it finally work and do all of the things that you need it to do, so there’s a lot of extraneous stuff around there that isn’t the core idea." There is an old blog entry by Joel Spolski that elaborates on this phenomenon: