925 karma · joined September 26, 2010
I wish I'd had your foresight and set this up earlier, but now I'm glad I didn't let that prevent me from doing it anyway; it's always fun to play scientist. :)
As to how - cron job on my server querying GMail via IMAP. Source below. Manually copy and paste the resulting text file to a GDoc spreadsheet; use the Time Series widget to generate the chart.
require 'net/imap'
require 'date'
imap = Net::IMAP.new('imap.gmail.com',993,true)
imap.login('yourlogin','yourpwd')
msgs = imap.status("[Gmail]/Spam",["MESSAGES"])["MESSAGES"]
puts Date.today.to_s + "\t" + msgs.to_s(This is a time series graph of the count of my GMail spam folder since 2009, updated daily.)
Interestingly there are articles out there which suggest that one distribution (of competence, rather than productivity, but intuitively you'd expect the two to be related) is actually bimodal rather than normal, "the camel has two humps":
http://www.codinghorror.com/blog/2006/07/separating-programm...
"Citation" is the topic being discussed. It's a technical term that refers to how scientific papers refer to other scientific papers.
"Modality" is the concept I've been introducing for three paragraphs. You're supposed to know what it means by then, or I've not been clear enough.
"Present as" is an intransitive verb phrase. I could say the same thing, perhaps more simply, by saying "you can think of a citation as a modality". Perhaps it's this phrase that has thrown you?
[EDIT: I've changed the article to try and make the sentence clearer. Thanks for your feedback.]
It seems to me that "degree of confidence" is clear enough, and that it's clear enough that a modality can have a degree of confidence associated with it.
So the article introduces two technical terms you're perhaps not familiar with, but I'd suppose someone who can read a CS paper or write a program can cope with that much.
Doing that might involve getting clear on the terms. "Productivity" is too abstract and ambiguous to be used as-is, so we first need to say "here is what we are going to measure".
> If you're going to refute McConnell or even Peopleware, you've got to do a study.
What McConnell has published isn't empirical, or scientific; argument suffices to refute it.
That goes for DeMarco and Lister, too - Peopleware was a popular book, not an empirical study aiming at establishing scientific fact.
http://www.uselesspickles.com/triangles/
(That page was published in something like 2006... "Nothing new under the sun" indeed.)
Industry is made up of people who have by necessity cultivated a patience with excessive complexity.
In particular, I suspect that many unnecessarily complex or counterintuitive language features arise in imitation of what the designers have learned to live with in other languages, even as their focus is on "improving" some aspect that they think is important for industry.
If you did design a language which favored learnability at every opportunity you might not end up with something that flattered everyone's preconceived notions of what is suitable for industry, either.
I hesitate to name examples here, as there is a significant risk of trolling...
I can't muster much enthusiasm for the initiative myself. My gut reaction is "oh no, as if we needed one more", and I winced at the blog post which said "the most important thing in a new language is that you can println 'Hello world'". I can't find any evidence of design thinking that strives to achieve the lofty objectives set out in the PDF paper.
But I'm looking forward to the discussion :)
Ouch. Nothing hurts your credibility quite like an egregious spelling mistake just as your rant is taxiing onto the runway.
There's one point that I starkly disagree with:
> “Hero developers” make most of the big differences made in software development.
Wait, did I say I disagree? Hero developers make a big difference all right - for the worse. Nothing breeds bad management like the one guy who pulls through when the team can't. Managers come to rely on them, and therefore on sheer blind luck, when the name of the game is to engineer success, by putting together a solid team.
There's a saying, "Go is life". Learning the game will tell you an incredible amount about yourself, about determinism and chance and skill, about depth and limits and building knowledge and passing on knowledge.
For a software person there is a lot to learn about complexity and patterns. There are deep lessons about not fooling yourself, about the idea that a strategy for success emerges in surprising ways from ridiculously simple rules and facts of the underlying material.
There isn't much of a gap between Go's simple rules (alternating play, capture, ko) and software's fundamental elements (sequence, iteration, choice) in terms of simplicity, and likewise these simple rules combine to yield complexities that challenge the best human minds.
Always remember: "It's easier to ask for forgiveness than for permission."
If you want to do better than the cultural norm demands, nothing's keeping you. What's the worst that can happen?