December 8, 2007
Dan Weinreb's CL implementation survey
Wow! I see that Dan Weinreb has posted a rather impressive Common Lisp implementation survey. It is quite interesting to read through the detailed description of the many choices available (well, slightly fewer if you are on Win32).
The other thing that is quite telling is how small all the commercial vendors are -- sure, this is far from a dead language but it is also not where you become rich being a language vendor... OK, in all fairness, I don't know that anybody has gotten rich as a language vendor in the last decade...
Update: Looking through the del.icio.us history for the survey URL and looking at some of the other users' histories did dig up somewhat of an equivalent link for Scheme: Brian Denheyer's "The Schemes I have seen" Scheme evaluation page.
Posted by cwirving at 3:34 PM
December 7, 2007
More generation matters: was it the Basic and Assember generation?
To add to my AI backlash theory, I think that another factor was that my contemporaries -- at least the hacker types -- were increasingly coming to university with plenty of exposure to the early consumer personal computers. There we were having spent years hacking away at our machines in some combination of Basic and assembler. The initial computer experience wasn't meeting university big iron and it wasn't the sophisticated PCs that came later. We were low-level programming junkies. We'd been poking around the bare metal of these interesting primitive machines and had established frame of reference that may not have been shared with students much earlier or later.
Although European-centric, I don't think that my exposure to computers was that unusual for the era: I started out with a Sinclair ZX80, moved on to a ZX81, sidetracked slightly with a Belgian-built DAI machine and finally got a Sinclair QL before entering the world of IBM PC clones. Oh, yeah, and there was an Epson HX-20 in there somewhere, too. Those were all machines programmed in Basic where you had to jump down into native assembler to really get the most out of them. The DAI was especially fertile for that because its video hardware was quite awesomely flexible for a machine of that era.
Even later, I still couldn't keep my hands off the bare metal -- I entertained myself on my freshman university summer designing and wire-wrapping a Motorola 68010-based computer that I never really found much time to actually program for...
So, anyway, going to university to learn computer science and being dumped in front of an IBM 3270 (we were lucky enough to avoid punch cards) was maybe not as impressive in comparison to the hacking we'd done up to then. Even the following succession of later time-shared machines (notably a PDP-10) we had access to didn't hold quite the wonder they should have. I think that we continued to do all our exploring at home with our personal machines -- and, thus, with the tools available on them. Had we come earlier, we would have been forced to work on university machines and, had we come in later years, the tools available on personal computers would have been higher-level[*].
So, there, maybe it was all those years of hacking in Basic and assembler that made us such low-level programmers? I certainly have many fond memories of that era, including disassembling my PC clone's Phoenix BIOS to patch an adapter card BIOS detection bug that prevented me from using something or other in the machine (an Adaptec SCSI card, I think). Writing EPROMs on some crappy ISA burner card that I'd rewritten the software for to allow me to write the larger chips the motherboard needed... Yeah, those were the days...
[*]: before you ask about how we'd have afforded any of these better tools, remember that this was the 80's in Europe: software piracy was rampant and I vividly remember friends driving around with the trunk of their car full of Amiga software, late night debugging sessions to remove copy-protection code from games and so forth. At that time, it really didn't matter how much software cost as long as somebody could lay their hands on the diskettes somewhere...
Posted by cwirving at 8:07 PM
Welcome to the AI Backlash generation
Everybody talks in terms of generations. Typically it is in terms of popular culture, pitting Baby Boomers against Generation X and so forth regarding their tastes in music, film, etc. Well, I think we can say the same with programmers: as I get older, I think that there are trends that appear pretty widely in the programming population. Some are the result of major changes in how computer science is taught (think Joel Spolski's rant on JavaSchools) while some are more environmental. At one level, the appearance of the mass-market personal computer (I'm not sure whether to include the early -- hardcore -- kits) transformed how we approach computers but I think that there were some of these environmental changes that transformed how we program...
One blog post by Dan Weinreb (Why did Symbolics Fail?) struck a chord in that respect: I have wondered why I -- and most of my contemporaries -- spurned the rich dynamic languages and environments of the eighties and spent the last twenty years hacking away in some child language of Algol (whether C-like or Pascal-like)? We're old enough that we were exposed to Lisp, Smalltalk, Prolog (OK, that's a stretch there) and so forth. We don't have JavaSchools to blame, yet there seems to be far fewer visible dynamic language practitioners in our generation than before or after (the modern excitement with Python, Ruby and their ilk is quite the reversal -- although at the cost of reinventing much of what the original language crowd had discovered over the last half century).
At the risk of going out on a limb, I'm tempted to say that we are the children of the AI Backlash: being an undergraduate computer science student just as the AI phenomenon was waning did probably help condemn everything associated with Artificial Intelligence to the jail of impractical ivory tower ideas. Even in their waning days, the AI researchers at the university I attended still were the chosen few, the only ones with access to the precious Symbolics worksations while everybody else got to make do with, well, environments that did nothing to make Lisp look like a practical language. Sure, I remember having a lot of fun writing Lisp programs on my PC, but the interpreter was limited and slow, had no interesting libraries and certainly no visual environment. I remember shelving that exercise as futile for any practical software I would want to write, switching instead to Turbo Pascal and Turbo C at the time. By the time the AI backlash kicked in, there wasn't many tears shed for the ivory tower residents and their elitist endeavors...
Obviously, this isn't the whole story -- the early exposure to primitive personal computers is also a huge factor, I think (more on that later) -- but I can't help that there was this window of time when sophisticated dynamic languages and environments were uniquely identified with the AI elite and the waning of research made them nearly invisible to those that came later. We weren't ignorant as much as vindictive, maybe?
Posted by cwirving at 7:20 PM
I (heart) DejaNews, I mean: Google Groups
Well, I've been adjusting the band on my new Seiko watch and was wondering how to remove links... A quick web search came up fruitless (it is a relatively cheap watch, so it is a pinless band) and Seiko's website seems to operate under the delusion that only jewelers are allowed to adjust watches. Most frustrating...
Of course, that's when I remembered that the Internet is a far bigger than just the web: time to search newsgroups. Sure enough, a top search result was right on the money. In five minutes, I had my watch band adjusted and was done.
So, kids: remember that newsgroups are for more than trading pirated files and pr0n -- there actually is wonderful information out there!
Posted by cwirving at 7:05 PM
December 5, 2007
The Operator Firefox extension or how microformats finally become user-visible
Following a plug in the New York Times Open blog, I installed the Operator Firefox extension to parse microformats out of web pages. Although there are very comparatively few pages out there that are microformat-enabled (the various NY Times blogs appear to be), the automatic microformat extraction is quite useful -- from calendar integration to address lookup or del.icio.us tag searching...
Now all I need to do is fix my blog templates to expose microformats for tags, etc. Hopefully, I'll get to that when I relocate it to a new server in the near future.
Posted by cwirving at 2:12 PM
November 21, 2007
More OOPSLA 2007 linkage
I just noticed that Dan Weinreb (formerly of Symbolics, ObjectStore and now ITA Software) has a report on OOPSLA 2007 that gives a different perspective on the conference.
Posted by cwirving at 3:07 PM
November 20, 2007
About that e-book thing...
So, Paula and I have been going back & forth most of the day about the Kindle... Sure, we both want one -- or, rather, we want the e-book experience it promises. However, apart from my e-book pricing concerns I expressed in the previous post, the other thing that we need to consider is how e-books actually look and how they read.
From what I can tell, e-book readers are basically specialized HTML browsers. Not only that, the HTML capabilities they implement are more akin to NCSA Mosaic than Mozilla Firefox: they have styles and formatting, but no tables (OK, I lied about the NCSA Mosaic thing: they actually have stylesheets -- something that Mosaic definitely didn't). So, PDF conversion is utterly futile since Acrobat does very little to preserve outlining and style information in PDF files -- most, if not all, non-trivial PDF files look like garbage when converted to e-book format (just look at the HTML version of searched PDFs in Google for an idea of what you get). Just like the difference between printing and generating a website, e-books differ radically from the printed page. I'm not sure that most people understand that small detail and, until people get to grope working e-book readers, the implications are not going to be clear at all.
At this point, I would be very curious to see how good a job e-books can do to for more illustration or layout-intensive books than novels. Even code-related technical books would be a good start -- a quick experiment with a chapter from Peter Seibel's Practical Common Lisp and MobiPocket's e-book creation software shows that it is borderline usable. I think that with some time invested in stylesheet tweaks, it could actually be pretty decent... Of course, the chapter I chose had no graphical illustrations or tables -- which is not representative of most textbooks.
Of course, a lot of the content available today is not available in this HTML form. As an example in the same domain, take Paul Graham's On Lisp -- which is only available in rendered form (presumably the TEX source exists somewhere, but not online). Given that kind of source material, it appears impossible to get usable results with the current generation of e-book formats and small screens: I could imagine pre-rendering the PDF to a bitmap for a screen that could cover the original page at high resolution (e-paper doesn't scroll nicely) but that is not ideal for searching and other interesting manipulation. So, yeah, we have a ways to go before e-book readers are general-purpose document readers.
That isn't to say that I root for paper: I would love to be rid of the piles and piles of dead trees that end up in my house and office but we've got some work to do in order to go electronic. Never mind the fact that the Word documents I print out to read offline are generally authored by people with no clue about outlining or style usage -- so they are not incredibly good candidates for good e-book source material, either.
Posted by cwirving at 11:34 PM
November 19, 2007
Yeah, Kindle... Whatever...
Everybody's talking about Amazon's new Kindle e-book reader. The world and their dog have something to say -- usually about the device itself (OK, it is kinda homely but even just a nicer paint job could do wonders to change that), or how it is going to get into a train wreck with Apple... But what bothers me is the e-book pricing model itself: although Amazon is apparently burning through a chunk of cash to make sure that bestsellers are priced sensibly ($10), as soon as you look at less mainstream titles (e.g., Fred Brooks' The Mythical Man-Month), we're back within a couple of dollars from the physical book price. That doesn't make sense!
I know, Amazon is working very hard to drag the publishing industry -- kicking and screaming -- into the twenty-first century, but explain this to me: why, when a physical book needs to be typeset, printed in a sweatshop somewhere in China, stuffed in a container, shipped around the globe, put on a truck, shipped to a warehouse for the publisher, shipped to a warehouse for the distributor, shipped to the consumer... does the publisher expect me to pay the same amount for an e-book that they just needed to upload to Amazon's server? The author isn't getting a magical big cut of the pie. The publisher hasn't put any effort into it. 'Splain me that?!
For all I think Amazon has made the e-book purchasing experience wonderfully streamlined, each e-book still comes with a virtual kick in the nuts: you pay nearly the same amount for a book that you can't lend, can't re-sell and, until the current generation of e-ink readers, couldn't read in most places a "real" book can! Yeah, I know, right about now is when somebody usually chimes in with the duo of "but you get more -- is is digital!" and "but, it is because of the rampant piracy we must do this!" Riiight... Just like twenty years ago, none of my classmates in college had figured out how to cut off the spine of a textbook and drop it into a photocopier? Sorry to break the illusion of physical book copyright wonderland, but my aforementioned classmates were pretty proficient at the photocopier thing and I'm sure that today's piracy groupies have heard of duplex scanners.
So, selling books is just like any other intellectual property: you pick a price that maximizes returns -- high enough that you make a profit, low enough that the majority of potential customers would prefer to do the right thing -- and you make buying the book easier than cheating. The Kindle and Amazon's store definitely do the latter. Now, if the publishers could do the former, somebody could get around to making some money... Especially when the incremental cost to the publisher of each e-book sold is practically zero, the math should be simple.
Update: Michael Mace has some pretty interesting comments on the royalty structure for self-publishing on Amazon's Digital Text Platform.
Posted by cwirving at 10:02 PM
November 16, 2007
Rethinking Software
While this "Rethinking Software" thread has been going on for a while in a lot of minds, I thought that there was an intriguing juxtaposition of posts in the newsfeeds I read today.
First, we have Bruce Schneier pointing to D. J. Bernstein's paper on security in QMail -- which covers more ground than the Schneier's excerpt hints at. There are interesting parallels with Mark S.Miller's object-capability talk at OOPSLA and, ultimately talks to the way we need to structure software systems to be robust and secure. Lots of other detours that are worth thinking about as well. It is definitely not a "least privilege sux" one-track paper...
Second, we have Joe Hummel reporting on a talk by Michael Wolfe on some of the way software is going to have to change to exploit modern computer architectures. No, it isn't the oft-quoted "need more parallelism" mantra but a rather more subtle one: yes, modern processors are much more parallel but they also are very bottlenecked on data: while we can write software that remains blissfully ignorant of the underlying hardware traits, the reality is that to go fast on a modern system, you have to be more aware of the many levels of hardware performance traits than ever...
Finally, we have Miguel de Icaza pointing out that Luke Hoban, whose prowess is demonstrated by his implementation of a ray tracer as a 60-line LINQ expression, is moving from the C# team to the nascent F# team in Redmond. I can't help but notice that Microsoft is making quite a decisive push to get new, different, programming paradigms into the hands of the programming masses (or, at least, everybody with an MSDN subscription).
While I think that we -- as a profession -- are still incredibly myopic when it comes to the things our predecessors learned, I am glad to see that there is real mainstream interest in moving the state of the art forward beyond simply "same crap, same idiot programmers, more threads" that is the rallying cry of too many people these days. Watching the goings on in Tim Bray's thread on his Wide Finder project is pretty discouraging. If anything, it does demonstrate the price we pay for ignoring either correct abstractions or actual physical hardware performance (or both) in current programming practices.
Posted by cwirving at 12:23 PM
November 1, 2007
OOPSLA 2007: One more thing... Podcasts
One very useful resource I should have mentioned earlier -- which may make more sense some of my session descriptions is the set of OOPSLA 2007 podcasts available on the conference website at:
http://www.oopsla.org/oopsla2007/index.php?page=podcasts/
Posted by cwirving at 11:13 AM
October 31, 2007
OOPSLA 2007 Day 4: John McCarthy
John McCarthy: Elephant 2000: A Programming Language Based on Speech Acts
It was basically this material plus an early history of Lisp that I have not found verbatim on the Stanford site, but that certainly lives somewhere in the documents of historical interest McCarthy has posted.
Nevertheless, seeing a living legend in person and hearing him talk about the early years of computer science as we know it was quite a treat.
From the conference website: Link to podcast MP3 / All OOPSLA 2007 podcasts
Posted by cwirving at 10:25 PM
OOPSLA 2007 Day 4: David Parnas
David Lorge Parnas: Precise Software Documentation: Making Object-Orientation Work Better
I'm not sure how I want to describe the documentation technique advocated by David Parnas. I suppose that the best online reference is in his slide sets (see the link below -- I think "Software Inspections We Can Trust" is probably quite faithful to the documentation-assisted inspections thread in this talk) but it is really hard to give a good feel for the table-based formal documentation scheme. On one hand, Parnas takes aim at Z and other formal methods (mainly pointing out their unreadability) while, on the other, he makes a big deal of how formal his approach is.
Whether or not I understand the finer points of his scheme, I think that the idea of tables being a low-cost way of achieving some level of formalism and partitioning of the system's behavior is well-taken. I especially liked the notion of using color as an additional hint to the reader. Where I have trouble is in the mapping of the requirements as they come in the real world for desktop business applications to the formalisms suitable for tabular representation. Hmm...
The description of this documentation technique goes hand-in-hand with how to perform good software inspections ad Parnas implies that the former is a prerequisite to the latter. Although the slides at OOPSLA were pretty light on how that would work, his slides online are quite clear, using the same nuclear power station example.
Anyway, a couple of points cited about the enduring need for quality documentation: Parnas cited statements to that effect in 1969, when he worked for Philips in the Netherlands and Microsoft's current (expensive) interoperability woes with the European Union.
See: David Parnas' Research Publications at the University of Limerick.
From the conference website: Link to podcast MP3 / All OOPSLA 2007 podcasts
Posted by cwirving at 9:12 PM
October 30, 2007
OOPSLA 2007 powerpointware links
A quick Google search for OOPSLA 2007 slides did dig up a few sessions I did not attend:
Mark Baker and Stuart Charlton: The Web: Distributed Objects Realized!
Chuck Allison: Python as a General-Purpose Object-Oriented Programming Language (Powerpoint link)
Pattern Writer's Workshop submissions at The Refactory
Martin Odersky: The Scala Experience (PDF link)
Posted by cwirving at 6:57 PM
OOPSLA 2007: "No Silver Bullet" Reloaded panel
Panel: "No Silver Bullet" Reloaded
Steven Fraser, Frederick P. Brooks, David Lorge Parnas, Linda Northrop, Aki Namioka, Ricardo Lopez, Martin Fowler.
Once again, my notes are disjoint and incomplete compared to Michael Stal but I think that this gives a flavour of the session.
Everybody, including Fred Brooks, was willing to entertain the idea that object orientation may actually be the technique that has come closest to the order-of-magnitude productivity enhancement set out as a challenge in the book. However, everybody also agreed that we aren't there.
David Parnas (PDF link) kicked off his opening statements with a rather insightful comment about the very nature of the "silver bullets" the software industry yearns for: silver bullets are things that require no skill to use. Hidden below all the words of crisis and mounting challenges faced by the industry, there is this undying hope by some that this will someday become, if not child's play, an activity that doesn't require the education and skill it does today.
Dave Thomas continued that thought by offering the pithy observation that "colleges certify people instead of making them competent" and saying that some of the attempts to solve the problem, such as OO frameworks have been messes compounding their lack of talent or experience in the subject domain with leaky abstractions that are imposed on their users -- who are, by design, made powerless to fix them. Closing with: "OO Middleware is a gratuitous disaster" that we have inflicted on ourselves.
Martin Fowler made the entertaining choice of actually sitting on the panel in the role of the werewolf (after some entertaining shtick during the opening statements where he rolled around on the podium and donned the wolf mask). As the werewolf, he got to utter some rather pithy one-liners that point to the heart of the problem: "Object-orientation is is all very nice but nobody does it!" "The use of pre-built libraries is a great theory... When the libraries are any good." "We love the illusion of control -- hence the waterfall model." "Peopleware is a dangerous book. Fortunately it is hard work to manage a team. It is more than Microsoft Project."
Brian Foote, in the audience, asked whether we shouldn't simply admit that the world runs on bad code -- that, fundamentally, we have been successful despite the bad code and simply learn how to let more people write (bad) code? Ricardo Lopez' retort was that the world relies on code. We have become far more vulnerable to code and that as we become more dependent, we are more and more likely to suffer when errors happen. [I interpreted this as a call for resiliency, failing softly and an observation that we'll soon be at a point where we can't afford catastrophic failures.]
Books mentioned:
Thomas F. Gilbert: Human Competence: Engineering Worthy Performance
Dean Smith et al.: The Carolina Way: Leadership Lessons from a Life in Coaching
Tom DeMarco and Timothy Lister: Peopleware: Productive Projects and Teams
Posted by cwirving at 6:13 PM
OOPSLA 2007 Day 4: Bloat!
Nick Mitchell and Gary Sevitsky: The causes of bloat, the limits of health
Although rather simple in concept, this presentation was delightfully well-executed from a visual perspective: they had taken heap snapshots of many running JVMs and had analyzed the actual contents, breaking them down by category to try and understand what these zillions of objects were. Their initial findings, breaking down the heap contents by class, could be paraphrased as Heap-O-Crap! (I'm going to have to trademark that. It is nearly as good as "craptastic." :-)
At this first level, it is clear that there are huge numbers of unexpected, janitorial even, objects taking up a large percentage of each heap's contents. Things like internal nodes from lists, hash maps, etc. But is this actually the true data-to-bloat ratio? Actually, no: a deeper analysis of the data structures (by looking at the Java standard library sources) showed that even within the data structure containers themselves, there are various ways memory is used. Just for example, it could be the data itself, it could be headers, pointers, space kept in reserve for something, etc. So, their neat visual approach was to build a 4x4 table of potential memory uses, apply a value judgment to the table cells and "paint" the heap with the resulting judgment (e.g., data/waste/spare)... The outcomes were pretty shocking: the number of studied systems where the "bloat" category far exceeded the "data" category was far staggering.
If you look at small, easy to understand examples, you can see how this happens, though: Imagine inserting three short strings into a hash map ("L", "XL", "XXL") -- the hash map overhead would drown the strings (only 16% of the total are the strings, actually). The way systems are written these days appears to have a lot in common with this scenario: structures are chosen for their abstraction at all sizes but they are optimized for one end of the size spectrum, not both... "One size fits all" ends up fitting none.
They also went into lots of detail trying to find the efficiency limits of common Java containers but I didn't pay too much attention given that I actually don't program in Java. I'll simply assume that it is a different mess in .NET and elsewhere. :-)
Posted by cwirving at 4:08 PM
OOPSLA 2007 Day 4: Fred Brooks Jr.
OK, so Day 4 of OOPSLA 2007 has been nicknamed the "Day of the Giants" and that is definitely true: with keynotes by Fred Brooks, John McCarthy and David Parnas, a panel commemorating the "No Silver Bullet" paper, you couldn't ask for much more software engineering history in one day!
Frederick P. Brooks Jr: Collaboration and Telecollaboration in Design The initial observation of the talk is quite simple: over the last century, design has changed in many ways but none more so than in the number of people involved. Design at the turn of the century (from the 19th to the 20th, that is) was an individual affair. Today, it is teamwork -- often shared amongst many. In comparison, artists have historically -- and still do -- work alone or, at most, in pairs... Why the difference? Why did design go from a lonely profession to the group activity it is today?
One answer: "There are no naïve technologies in the West." Brooks gives the example of visiting Procter & Gamble and discovering that they use computational fluid dynamics to design the mixing apparatus for shampoo (it is a three-layer emulsion and they want to mix without shearing). CFD for shampoo?!
But, seriously, the answer lies in two areas: sophistication and time to market. We want widgets that are massively more complicated than in the past and we want them faster.
So, how do successful teams maintain conceptual integrity under such circumstances? Brooks offers the following guidelines:
- One architect for the overall project -- if only one person understands the system as a whole, the architect is that person. If nobody understands the system as a whole, mediocrity is the best one can hope for.
- One user interface designer -- again this is the guardian of conceptual integrity in the user experience
- Where there are assumptions, document them! It is better to be wrong than to be vague.
- Projects should have a "style sheet" -- documented decisions and rationale, standards (including standard libraries for code) that is understood by all on the team
Cool. Teams can be made to work... So, when does collaboration help?
Collaboration:
- Helps to determine needs from users
- Helps in conceptual exploration
- Does not help in conceptual or detailed design -- this is still an individual activity
- Helps in the form of pair programming -- not through any direct cost savings (it is expensive) but, rather, through a near tenfold reduction of defects
There are some notable caveats, though:
- Collaboration is more complex than one thinks
- Change control for the design becomes essential
- Collaboration is no substitute for thought -- people still need to take their activities offline to think
One example of recent large-scale collaboration is the Airbus design team for the A380. On top of the usual telecollaboration tools, they added two key things: Ambassadors -- Each team had representatives co-located with their counterparts. They were able to defend their position at any time and provided trusted communication channels. A daily shuttle between sites -- Even with all the telecollaboration tools, face time is still crucial.
Because telecollaboration is currently "technology-driven" rather than "application-pulled," the focus often is on high-tech solutions that may not be all that valuable. In fact, in a steep decreasing order, the most effective things to share are: documents, voice and video. The technological fixation on the latter does seem at odds with what actually works.
Finally, just like in factory shift-work, keeping the handoff between collaborating teams to a well-defined, minimalist even, interface often is a very effective technique. [I assume that he alludes to a form of signal-to-noise ratio, where loading extraneous communications and ritual into the channel effectively drowns the important information].
From the conference website: Link to podcast MP3 / All OOPSLA 2007 podcasts
Posted by cwirving at 3:24 PM
OOPSLA 2007 day 3: Second Life
Jim Purbrick and Mark Lentczner: Second Life: The World's Biggest Programming Environmnent
Everybody seems to cover this talk, pick up the mind-boggling statistics (15% of Second Life users have written scripts, over 40% of the users are women -- Tim Bray -- an outspoken proponent of women in programming[*] -- would be so proud...). The delicious irony that one can be incredibly successful with a totally craptastic scripting language, tight arbitrary limits and an even more awful technical implementation behind the scenes gets everybody atwitter... Apparently, we have an infinite ability to be surprised by the success stories of people that did something awesomely compelling despite getting some details completely wrong.
Fine... I personally remain somewhat unconvinced by Second Life but I think that they deserve a tremendous amount of credit for the compelling experience that gets them the 30,000+ concurrent users they mention. Doing something different is hard. Doing something different that people actually use is monumentally difficult. Anyway, the meat of their talk was about how they use Second Life as a virtual Agile team hangout, meeting and pair programming online -- it is interesting and I do hope that it does work as well as they say it does, but I think that we're only going to know once somebody other than the actual owners of the environments get to do it.
[*]: Don't get me wrong, I think that women are terribly under-represented in our profession -- I just don't think that men getting all worked up about it in public comes across as particularly authentic.
From the conference website: Link to podcast MP3 / All OOPSLA 2007 podcasts
Posted by cwirving at 11:51 AM