holmak
> Although it was not until well into 1970 that Brian Kernighan suggested the name ‘Unix,’ in a somewhat treacherous pun on ‘Multics,’ the operating system we know today was born.
I like this paper for its thorough description of the very earliest versions of the operating system.
Joking aside, they've snuck up on me more than once when I'm about to cross the street and they're trying to right-on-red. I'm surprised they don't have some artificial noise to improve awareness.
I did buy Stroustrup's post-C++11 book, "A Tour of C++", which is supposed to be the compact "how to do Modern C++". It provides tips, but as I mentioned above, I did not find it comprehensive enough. Terse recommendations like "Prefer returning by value" may be great small-scale recommendations, but they don't explain how the big picture is supposed to come together.
> In the presentation before the awarding of the Japan Prize today, you were quoted on the distinction between research and development. [The former, Thompson stated, was directionless, whereas development had a specific goal in mind.] So in that context, is Go experimental? > Yes. When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter] [1]
It looks like you were half-right about the early Go compiler being partly written in C++: There were two compilers, and "gccgo" had a C++ front-end, while their homemade compiler "gc" was written entirely in C. [2]
[1] http://www.drdobbs.com/open-source/interview-with-ken-thomps...
[2] https://golang.org/doc/faq#What_compiler_technology_is_used_...
I know all the copying and moving and whatnot is supposed to "just work", but as far as I can tell, there's no easy way to verify that your program is doing what you intend. There also aren't any compact guidelines -- "follow these N simple rules and the STL won't explode!". With most other languages, I can at least think through the program to figure out if it is going to do what you intend, but the way that the STL is implemented to support all the modern C++ behavior requires a brain the size of a planet to understand.
I'm sure Stroustrup and the committee can write Modern C++, but I sure can't. Not with any confidence, anyway.
Anyway, the bit about (comparatively) experienced programmers intimidating the other students in freshman classes is a real and terrible thing. I thoroughly support shoving all those students into a different class; it is disruptive to have them in an intro course.
From the Wikipedia page on moral hazard:
> [...] the term dates back to the 17th century [...] Dembe and Boden point out, however, that prominent mathematicians studying decision making in the 18th century used "moral" to mean "subjective", which may cloud the true ethical significance in the term.
From the Wikipedia page on rent seeking:
> The word "rent" does not refer here to payment on a lease but stems instead from Adam Smith's division of incomes into profit, wage, and rent. The origin of the term refers to gaining control of land or other natural resources.
> This paper tries to shed some light in the dark corners, and explores whether the language can be cleaned up so that good template documentation does not drag obscure language-lawyer details into the domain of the regular user.
It may be nowhere close to the popular ideal of democracy, but the reduced violence and destruction would probably make it a worthwhile innovation anyway.
One-bit Computing at 60 Hertz
The old-fashioned ("culture of honor/dignity"?) style of one-on-one negotiation is often futile when you are dealing with a company.
It is just strangely convenient!
TIS-100 Tessellated Intelligence System
You also mention that this limited ability to defer purchases in the face of deflation is what makes short bouts of deflation not catastrophic -- it is somewhat difficult to get the deflationary spiral going if you can't actually wait to purchase things.
Given all this, the interesting question to me is, how much deflation does it take to actually cause a deflationary spiral? The answer is likely complicated, given that it depends on the specific utility functions for each consumer of all the goods and services that they consume.
Empirically, we seem to be able to cope with a decent amount of deflation, at least when it is limited to certain goods, like video game consoles, computing power, other manufactured goods, etc. (In some cases, even over very long timespans.)
I know the the correct, rational answer to this question: "I won't buy it today, or ever, because it will always be cheaper the next day." (And then the deflationary spiral begins!)
But if this is really true, why has anyone bought a Playstation 4 or Xbox One? They will undoubtedly be cheaper in two or three or ten years. Well, consumers might be totally irrational; what about firms? Why has any company in history ever bought a computer when the price of computing power has been falling rapidly and (mostly) predictably for fifty years?
I don't think the question "Why buy today what can be bought tomorrow cheaper?" fully explains the behavior of people in the face of increasing purchasing power; there seems to be something else going on. Any thoughts?
> U.S. pharma company Pfeizer, total revenues of $59bn in 2012, U.S. was $27bn and international $36bn. Pfeizer invested $7.9bn in R&D (c. 13% of revenues).
Do you know what fraction of those revenue figures are profit? It is entirely possible that the companies could have different profit margins in different areas.
In the brief time that I used Clojure, I also thought that the contrast between immutability and dynamic typing was very strange. Ultimately, I think it makes more sense than having the entire language be highly dynamic (or highly static).
I think Clojure's choice is not inconsistency, but that there is a kind of budget for craziness in a language. In Clojure, you can go crazy with dynamic types on the foundation of immutability, transactions, etc. In Haskell, you can go crazy with really awesome static typing tricks that would be utterly unfathomable if the language wasn't very rigid in every other way -- immutable, referentially transparent, side-effect-tracking. These two pack all their craziness into one corner of the language.
On the other hand, other languages -- Python, Javascript, Ruby -- seem to spread the craziness (I am not sure I picked the best word for this!) around, instead of having one super dynamic feature and everything else very inflexible. These languages tend to lack the really big flashy features: macros, typeclasses, etc.
It seems that you have a lot of flexibility as a language designer on how you spend your craziness budget, as long as you don't go too high (and become incomprehensible) or too low (Java?).
The implied goal seems to be to help the poor, but as others have pointed out, other policies (EITC, guaranteed minimum income, negative income tax) are better suited to that goal. So, do proponents of the idea have a different (or additional) goal in mind? Do proponents believe that these other policies are not more effective solutions?
I would like to hear others' opinions on the answer to this question, especially if you support the raise.