I second that. Crpgaddict's work ethic is beyond legendary, at times bordering on insanity. Honestly, I find Chet's blog to be one of the best and most valuable places on the internet these days (and I mean this literally). A modern day's monk, really.
We developed technology in order to help investigators access archives of documents of the time.
Once of the most interesting things you discover when you read the archives is that lost of things we consider obvious today, was not at the time.
One of those is the usefulness of airplanes at the start of WWI, proven at the end, and the usefulness of tanks at the start of WWII.
The fact tanks were bad weapons at fist, bulky, difficult to operate, slow,low range(compared with big cannons) easy targets, and no ability to cross difficult terrain.
This was improved in an incredible way, for example tank suspension improvements rendered the Maginot Line obsolete when finished.
Lots of people in the army were against change. Making tanks were very expensive, they needed fuel, and they genuinely considered money was better spent on other things.
I am not referring to cavalry charge against tanks myth here, that actually happened at the end as an act of desperation, like Spanish wood ships sacrificing themselves against US iron ones.
I am talking about power imbalance that made Poland completely obliterated by Germany and URSS within four weeks.
That Poland was "eaten or breakfast" because it was not prepared was a fact. Poland had not the industry to face Germany in a different type of war.
> Further, it shocks me at how bad the graphics are at some of these games after looking at them again after decades.
I played MI 1 and 2 in the early 1990s and after revisiting them after 15 years or so, my impression was exactly the opposite: "Look how well the graphics has aged!". Yes, pixels are there, but the aesthetic value of locations, landscapes etc. is relatively unaffected, it's still pleasing to watch (esp. in MI2). I think this says something about the quality of graphic design in those games.
Just a side note - you're probably conflating Perimeter Institute (www.perimeterinstitute.ca) and Institute for Quantum Computing (http://iqc.uwaterloo.ca/). Both are in Waterloo, but it's the latter that is involved in developing quantum computing implementations.
>I would refuse to work anywhere that I was expected to stand aside and ignore fraud, or where I was punished for doing what everyone would agree is the right thing (...)
You don't always have that much choice, do you?
>I would rail against it every day and try to change the system by doing the right thing and calling out other faculty for not doing so, publicly.
Yeah.
You will not simply fail, you'll get screwed by the system at the first opportunity. If you really want to "buck the system", cool down and watch some episodes of "The Wire". This series portays exactly and reallisticaly the inner workings of corrupt institutions and what happens to "lone wolves" trying to beat or change the system (spoiler - they get screwed by superiors and peers alike and achieve absolutely nothing).
I'm not saying it's impossible to transform the system from within. But trying to do it single-handedly is fighting a losing battle that is doomed to alienate your coworkers.
I don't think I'd be 'screwed by the system', and no I don't think I'll be taking my lessons from some TV cops and robbers show. Do you have any clue how hilariously bad this advice you are giving is?
"The Wire" is not "some TV cops and robbers show", but a complex narrative that depicts exactly the kind of situtations we're talking about (yes, it's styled as police drama, but it's much more than that).
The thing that has always puzzled me is if one's opinion on "talent vs hard work" is actually correlated to one's amount of talent. You can often hear very gifted people say things like "it's hard work that actually matters". At the same time, underperformers' claims that it's the talent that does the thing maybe treated as rationalizations ("I'm lazy, so, yeah, let's blame that on lack of talent, not work"). I don't see any easy way of studying this, though looking for such correlations might prove interesting.
The thing that has always puzzled me is if one's opinion on "talent vs hard work" is actually correlated to one's amount of talent.
There has been some research on this. Maybe I can open a thread sometime with some link to a good article on this issue. Meanwhile, I am reminded of pg's statement in his essay "What You'll Wish You'd Known"
"I'm not saying there's no such thing as genius. But if you're trying to choose between two theories and one gives you an excuse for being lazy, the other one is probably right."
"After this, they decided to pass me, though they said that my harmonic analysis was far from satisfactory. :("
especially when compared to the Fields Medal citation, where Tao is awarded the medal "for his contributions to partial differential equations, combinatorics, harmonic analysis and additive number theory".
Seems he did learn a bit of harmonic analysis in the meantime.
There is an important factor discouraging publishing source code - fear that there indeed are bugs and they will be exposed. This is blatantly "security through obscurity", but I fear it's a common attitude. If there are bugs and code is secret, even if someone else later points out that the results contradict their own findings, it's (presumably) not difficult to sweep the thing under the rug and cool it down. On the other hand, if the paper is published, code is public and someone spot serious bugs, it's instantly a big shame... (code review as a part of peer review would help, but it's very unrealistic - already, reviewing is very time consuming).
In addition, there are really no structural/institutional incentives to produce and share good quality scientific code. Maintaining good code costs much effort and, currently, gives few short-term benefits. It's often easier to produce crappy code, get the results, publish and move ahead.
Typically a review paper describing the software is what is actually cited, but yes!
For instance, in my department there is a guy who maintains an astrophysical software package called Cloudy. The faq[1] describes how to cite it. (Unlike a lot of the software mentioned here, that project actually is open source, uses version control, and was migrated from the original Fortran to C++.)
