Q: Why do programmers confuse Christmas and Halloween?
A: Because DEC 25 = OCT 31
914 karma · joined September 12, 2010
A: Because DEC 25 = OCT 31
Of course it's better for software to be free / open source, but it's nonsense to imply that only open source software has the potential to be seen by "many eyes".
My eyes are still red and sore from staring at the MFC source code before the turn of the century.
And your tax dollars are paying for all of that work. And you can be sure those elves have known about those bugs for years.
And those bugs have caused many unfortunate consequences. So it's just not wise to go around giving people a false sense of security in order to promote your brand.
A bunch of programmers were endlessly arguing back and forth about how to do such-and-such to emacs on the gnu-emacs mailing list.
RMS derailed the argument by pointing out that there were just a few people in the world who know the code well enough that they could actually just sit down and solve the problem themselves without discussing it with anyone else, and they were all very busy.
But all the bike shedding and social chatter about what to do, how to do it, what to call it, and what color to paint it, by the people who either can't or won't actually do it themselves, is just distracting and wasting the precious time of the few people who can just solve the problem themselves without any discussion.
"But there is still one thing that America has taught the world. You have taught us all that giving second chances is not just generosity, but the wisdom that even the best of us sometimes make stupid mistakes that it would be grossly unfair to believe were one's true nature." -Eric Naggum
"I learned a lot from talking to Erik on matters technical and non-technical. But one thing I learned, not from what he said, but from the meta-discussion which was always there about whether to tolerate him, is that I think we as people are not all the same. We make rules of manners and good ways to be that are for typical people. But the really exceptional people among us are not typical. Often the people who achieve things in fact do so because of some idiosyncracy of them, some failing they have turned to a strength." -Kent Pitmann
"The purpose of human existence is to learn and to understand as much as we can of what came before us, so we can further the sum total of human knowledge in our life." —Erik Naggum
http://open.salon.com/blog/kent_pitman/2009/06/24/erik_naggu...
I also have a tremendous amount of respect for RMS, and forgive his personality quirks, although I'd never want to work for him. Unfortunately, a lot of his personality quirks and ways of communicating are self defeating. But more importantly, his beliefs are totally logical and consistent and well thought out, and he sticks by them. It's his priorities and his way of communicating them that people have problems with.
He's also got a brilliant sense of humor, that a lot of people just don't get, and take offense at, when he was just trying to make them think. But at the same time, he's incredibly easy to wind up by mentioning Open Source Software. But I think he's in on the joke and it's just a theatrical performance, like Saint IGNUcius.
My Emacs Hacker Boss from UniPress Software and I ran into him at a scifi con, and my "Evil Software Hoarder" colleague asked him "I heard a terrible rumor about your house burning down. Is it true?" He fired back without missing a beat, "Yes, but where you work, you probably heard about it in advance." We all had a laugh and no offense was taken: he's got a sharp sense of humor and he's quick on his feet!
Here he is being a total dick, by chastising someone for posting a baby announcement (who is now 21 years old) to a mailing list about having dinner on the other side of the continent as he was on. But he's fucking brilliant and hilarious and makes some excellent points that are totally consistent with his beliefs, even through he wound everyone up and was repeatedly told to fuck off in various ways, which he took in stride.
http://www.art.net/~hopkins/Don/text/rms-vs-doctor.html
"You people just have no sense of humor. I thought the original message was pretty funny and made a few good points (if it didn't, nobody would have been offended). I guess it's a shock for smug self-righteous breeders to learn that not everybody in the world thinks babies are cute and special. -Wayne A. Christopher"
"Finally, someone read the message as it was intended to be read. -RMS"
"I'm somewhat surprised by the idea that a mere message from me could torpedo the happiness of parents. I'd think it wouldn't even come close to doing that. Not that I wanted to do that. The most I thought it could do was to discourage the posting birth announcements. -RMS"
RMS is like William Shatner, in that he's in on the joke, and can have a good laugh at himself, and at least he isn't the mean kind of narcissist. To extend that metaphor further than I should: RMS = Captain Kirk, Theo = Spock, ESR = Harvey Mudd, Microsoft = Klingons, and Free Open Source Software = Tribbles.
The same thing with misusing "this" in JavaScript closures: no matter how hard I try to consciously avoid doing it, it's always the first thing I check for when code doesn't work as intended, because I still make that same mistake all the time.
Another source of confusion in code that Ben Shneiderman pointed out, is that the meaning of "and" and "or" are opposite to programmers and normal human beings, so languages like SQL and logical expressions in most programming languages are fundamentally confusing to many people, and the inconsistency can be an un-obvious blind spot.
Normal humans mean to union when they say "this AND that AND those AND these", while programmers mean to intersect when they say "this AND that AND those AND these". So that's a terrible source of confusion.
In other words, programmers think adding "AND" clauses narrows down the selection like "((user.age >= 18) AND (user.gender = 'F'))", while humans think adding "AND" clauses augments the selection like "adults AND women".
I'm not advocating changing the meaning of "AND" and "OR", just pointing out that it's a source of confusion you should look out for, and be aware of when talking with non-programmers.
I saw Alvy Ray Smith give a talk about 3D graphics programming, and he confessed that he and his colleagues would just write some code and then flip the signs around until it did what they meant it to do. That made me feel a lot less embarrassed about doing that myself.
I feel much more confident using libraries whose source code I've already at least skimmed through. (Speed reading code and learning where to look for stuff later when you need it is a useful skill to develop.)
But reading static code isn't enough to trust it and be sure the comments and formatting aren't lying to you. Stepping through code in the debugger and looking at its runtime state and control flow is crucial to understanding what's really going on.
But the problem with reading code (especially code that you're not running in the debugger), is that you see what you think it's supposed to do, not what it's actually doing, especially when you're "skimming" over it as I like to do.
Occasionally I have the luxury of enough time to go into "study mode" and carefully read over code line by line (I've been reading the amazing npm packages in http://voxeljs.com recently, which is some amazing and beautiful JavaScript code that I recommend highly). But that is extremely tedious and exhausting, and uses so much energy and attention and blood sugar that I have to close my eyes and take little power naps to let my mind garbage collect.
And then I get these weird dreams where I'm thinking in terms of the new models and api's I've just learned, and sometimes wake up in a cold sweat screaming in the middle of the night. (I have sympathy for Theo and his neighbors he wakes up at night from nightmares about all the terrifying code he reads.) (So far no terrible nightmares about voxeljs, but a few claustrophobic underground minecraft flashbacks.)
Refactoring or rewriting or translating code to another language is a great way to force yourself to really understand some code. I've found some terrible bugs in my own code that way, that I totally overlooked before. And looking back, the reason the bugs were there was that I just saw what I intended to have written, instead of what I actually wrote.
And for those kinds of bugs, comments that describe the programmer's intent are actually very dangerous and misleading if they're not totally up to date and valid. Because the compiler does not check comments for errors!
I try to use lots of intermediate descriptive variable names (instead of complex nested expressions), lots of asserts and debug logs, and do things in small easy to understand and validate steps that you can single step through with the debugger. It's important to examine the runtime state of the program as well as the static source code. But that is hellishly hard to do with networking code in the kernel.
I also like to get away from the distractions of the keyboard and debugger, and slog my way through every line of the code, by printing it out on paper, going outside, sitting in the sun under a tree, and reading through every page one by one front to back, scribbling notes on the paper with a magic marker. That forces me to make my way all the way through the code before making any false assumptions, jumping around, and getting distracted. (ADHD Management Techniques 101!)
And I'd rather be an asshole with eyeballs than a mouth full of bullshit.
I believe that Eric the Flute was disrespectful to Linus by labeling ESR's "Many Eyes" theory "Linus's Law".
I believe that Eric the Flute was disrespectful to RMS by relabeling RMS's "Free Software" movement "Open Source".
I believe that Eric the Flute has made a career out of bogging down the FOSS world in internal doctrinal disputes, and that his "many eyes" argument gives people a false sense of security in open source software, and that kind of pap diverts attention and money away from supporting qualified eyeballs and assholes who do the incredibly difficult and tedious work of meticulously reviewing code and fixing bugs like Theo De Raadt does.
And I believe that Eric the Flute is being a narcissistic hypocrite when he writes stuff like this recent blog posting, with numbered instructions for where, when and how to drop and not drop his name. Specifically, number two, which gives me the right to drop his name in this context:
Namedropping "ESR" http://esr.ibiblio.org/?p=5266
2. Do drop my name if by doing so you can achieve some
mission objective of which I would approve. Examples
that have come up: encouraging people to design in
accordance with the Unix philosophy, or settling a
dispute about hacker slang, or explaining why it's
important for everyone's freedom for the hacker
community to hang together and not get bogged down in
internal doctrinal disputes.
My mission is to explain why it's important for people in the FOSS community not to base their careers on tearing other people down. Why can't we all just get along, huh?
I'd like to hear Eric the Flute explain how his goal of "not get bogged down in internal doctrinal disputes" squares with his decades-long ongoing feud with RMS about "free software" -vs- "open source software" on which he's based career?
And I'd like to ask him to please stop encouraging his followers to act as if there's some kind of war going on between Free Software and Open Source Software.
For example, Eric the Flute's friend and fellow right wing global warming denying libertarian gun nut internet celebrity "Tron Guy" Jay Maynard (who fawningly replied to that blog posting "FWIW, I apply my own fame in much the same way, and follow this set of rules both for myself and for my friendship with Eric. Like him, I didn’t set out to become famous.") has taken a stand on wikipedia and his Hercules emulator project about how there is a war going on, and he ideologically opposes Free Software but supports Open Source Software, and it's insulting to him for anyone to insinuate otherwise:
https://en.wikipedia.org/wiki/Talk:Hercules_(emulator)#So-ca... https://en.wikipedia.org/wiki/Talk:Jay_Maynard#Hercules_and_...
The Hercules development community generally objects
to the term "free software", and in several instances
contributes to Hercules specifically as a reaction to
the misuse of the term. As long as the portal and the
categories use this misleading term to apply to
software that is freely available and redistributable,
please do not add Hercules to them, since it implies
support for the "free software" side of the ongoing
political war that does not, in fact, exist. -- Jay
Maynard (talk) 08:57, 13 March 2009 (UTC)
Please do not ascribe to me a viewpoint I do not hold.
Hercules rejects the term "free software", and many of
its developers - including me - contribute to the
project on the explicit basis that it is not part of
that world. This has been hashed out at the
Talk:Hercules emulator page.
Calling it "free software" here ascribes to me a view
that I not only do not hold, but actively disagree
with. Please don't count me as a supporter of "free
software", the FSF, or Richard M. Stallman, and please
don't enlist me on your side of the "free
software"/open source war.
I believe calling it "free software" is argument by
redefinition, and fundamentally dishonest. It's also a
naked attempt to glorify a major restriction of
freedom for programmers by nevertheless calling it
"free", in the same vein as "War is peace". The
concept of freedom is far too valuable to demean it in
that manner.
As for "but it's free software anyway", the reverse
argument, that "free software" is all open source, is
just as valid - yet "free software" zealots reject it
out of hand and say "don't co-opt our work!" Well,
that sword cuts both ways.
I am not a member of the so-called "free software"
movement and never will be. Please don't insult me and
misrepresent my views by calling me one. -- Jay
Maynard (talk) 13:22, 16 August 2010 (UTC)
http://rationalwiki.org/wiki/Talk:Eric_S._Raymond
Like Lubos Motl, his crankery is a counterpoint to his
area of brilliance, not a negation of it. And I
disagree with just about every political opinion ESR
has. (And have actually argued them with his good
friend Jay Maynard.) - David Gerard (talk) 20:46, 29
July 2010 (UTC)
It saddens me that Jay "Tron Guy" Maynard is one of
ESR's fans. Turns out the guy who made cosplay
respectable for grownups is a right-wing asshole --
wonder if he's a brony? (Anyway, it seems he's given
up lead maintainership of the Hercules mainframe
emulator, so, um... yay?) EVDebs (talk) 23:42, 10 July
2013 (UTC)
struct code_reviewer *qualified_code_reviewer =
(struct code_reviewer *)malloc(
sizeof(struct code_reviewer));
assert(qualified_code_reviewer != NULL);https://en.wikipedia.org/wiki/Linus's_Law
Linus's Law as described by Raymond is a claim about software development, named in honor of Linus Torvalds and formulated by Raymond in his essay and book "The Cathedral and the Bazaar" (1999). The law states that "given enough eyeballs, all bugs are shallow"; or more formally: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone." Presenting the code to multiple developers with the purpose of reaching consensus about its acceptance is a simple form of software reviewing. Researchers and practitioners have repeatedly shown the effectiveness of various types of reviewing process in finding bugs and security issues, and also that reviews may be more efficient than testing.
In Facts and Fallacies about Software Engineering, Robert Glass refers to the law as a "mantra" of the open source movement, but calls it a fallacy due to the lack of supporting evidence and because research has indicated that the rate at which additional bugs are uncovered does not scale linearly with the number of reviewers; rather, there is a small maximum number of useful reviewers, between two and four, and additional reviewers above this number uncover bugs at a much lower rate. While closed-source practitioners also promote stringent, independent code analysis during a software project's development, they focus on in-depth review by a few and not primarily the number of "eyeballs".
That approach might work pretty well on Queen's Day in Amsterdam, too. (Well it's going to be known as King's Day from now on, now that the queen has abdicated.)
http://www.youtube.com/watch?v=826qq6pslJk
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=...
The Indigos were another story entirely: They couldn't touch the raw graphics performance of an Iris, since the rendering was all in software, but you could actually stuff one of them in the overhead compartment on an airplane!
And then there was the SGI Indy... They made up for being small on the outside, by being HUGE and BLOATED in the inside:
"Indy: an Indigo without the 'go'". -- Mark Hughes (?)
This legendary leaked memo has become required reading for operating system design courses:
http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassi...
Software Usability II October 5, 1993 Tom Davis
Last May, I published my first report on software usability, which Rocky Rhodes and I presented to at Tom Jermoluk's staff meeting (with Ed, but without Tom). Subsequently, I made it available to quite a few other people. This sequel is to satisfy all those people who have urged me to bring it up to date. I begin with a summary; details follow.
Please read at least the summary.
SUMMARY
Release 5.1 is a disappointment. Performance for common operations has dropped 40% from 4.0.5, we shipped with 500 priority 1 and 2 bugs, and a base Indy is much more sluggish than a Macintosh. Disk space requirements have increased dramatically.
The primary cause is that we attempted far too much in too little time. Management would not cut features early, so we were forced to make massive cuts in the final weeks of the release.
What shall we do now? Let's not look for scapegoats, but learn from our mistakes and do better next time.
A December release of 5.1.2 is too early to fix much -- we'll spend much more time on the release process than fixing things. Allow enough time for a solid release so we don't get: 5.1.2.1, 5.1.2.2, 5.1.2.3, ...
Let's decide ahead of time exactly what features are in 5.1.2. If we pick a reasonable set we'll avoid emergency feature cuts at the end.
Nobody knows what's wrong -- opinions are as common as senior engineers. The software environment is so convoluted that at times it seems to rival the US economy for complexity and unpredictability. I propose massive code walk-throughs and design reviews to analyze the software. We'll be forced to look closely at the code, and fresh reviewers can provide fresh insights.
For the long term, let's change the way we do things so that the contents and scheduling of releases are better planned and executed. Make sure marketing and engineering expectations are in agreement.
INTRODUCTION
We've addressed some of the problems presented in the original May report, but not enough. Most of the report's warnings and predictions have come true in 5.1. If we keep doing the exact same thing, we'll keep getting the exact same results. I'm preparing this report in ASCII to make it widely available. It's easy to distribute via news and mail, and everyone can read it.
An ASCII version of the May 12 report can be found in:
bedlam.asd:/usr/tmp/report.text
The included quotations are not verbatim. Although the wordings are inexact, I believe they capture the spirit of the originals.
BLOAT UPDATE
"Do you want to be a bloat detective? It's easy; just pick any executable. There! You found some!" -- Rolf van Widenfelt
[...] Read the rest at: http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassi...
Only when somebody pointed out that obvious fact to them, did they come up with a recursive retronym to paper over their initial stupidity: "YAML Ain't Markup Language". How clever by half.
I prefer to use formats that were designed by people who actually knew what they were doing and what it was called and how it was meant to be used.
And how does your answer "Probably because..." address my question "What is the name of the law...". I am asking you for an actual objective fact, the name of the law, not for you to take a wild guess about "Why" anybody is doing anything.
Are you even replying to the right posting, or just constructing a coatrack on which to hang your off-base raging accusations? Care to try again and cite the name of the law that I asked for?