Some of the decision-makers are aware of their discriminatory behavior, others are in denial. Often it is the nature of many engineers (who may find themselves in a leadership position) to also have a somewhat diminished sense of empathy, and this adds to the potential for all sorts of discrimination to occur.

Whatever its origin, this nasty environmental factor is not going to away without some serious social engineering. We can exploit it, or cope with it, depending on where we are in life. We can also try to kill it. And we should, because we are only getting older. If enough people change what they do, we can all collectively benefit.

Sort of like planting trees in our neighborhood.

Ridiculously, I first felt age-related discrimination when I was only 25. More recently, I watched one partner in a rapidly expanding tech company tell an unemployed 55 year old developer (who was asking about what kinds of people the company is looking for) that the company was looking to hire young grads from the university. While this was at an informal gathering of developers, the insensitivity of it was palpable.

But sensitivity does not help a tech company survive. The young programmer possesses a naivete and a drive to learn that is prized, and at a low price. The old programmer possesses an equally valuable experience level, but at a high price. The advantages and disadvantages of each are clear, but short-term answers to cost contraints rule over the long-term benefit of experience.

This is because experience can be learned, and naivete cannot. Usually.

If you are an aging programmer, get into the habit of unlearning. Stop being good at something old, and start being bad at something new. Take on what seems to be a stupid, newfangled technology that does not appear to be a better solution than the older solution (that you happen to know inside and out).

Let go of your advantages. And plant a tree or two.

By targeting common patterns in ML, we developed GraphLab, which improves upon abstractions like MapReduce by compactly expressing asynchronous iterative algorithms with sparse computational dependencies while ensuring data consistency and achieving a high degree of parallel performance.

Source: GraphLab Overview

Having cut his teeth in NYC finance tech, Mr. Schachter built del.icio.us in perl. I saw him speak at a Ycombinator startup school and this man is the quintessential Wall Street engineer: practical, tough, direct, and funny as hell. It is obviously too soon to tell whether he will use perl to build parts of his new venture, but he probably won't be using anything like Yahoo's php+c++ framework.

But WTF is this talk about beleaguered status? I've been through the java jungle and ruby rockstardom and I've never been so fired up about a technology as I am about perl right now.

It isn't correct to think of WordPress and a theme as separate entities. As far as the code is concerned, they form one functional unit. The theme code doesn't sit "on top of" WordPress. It is within it, in multiple different places, with multiple interdependencies. This forms a web of shared data structures and code all contained within a shared memory space.

Ah, yes, how wonderful, a web of sharing between you, your lawyer, and a lamprey with seventeen heads.

The WordPress community could use a good dose of TIMTOWTDI as embodied in MT's approach to contributions (and in perl in general).

Many who experienced the early web in its full glory have bad memories of table-less web sites that made heavy use of blink tags, under construction animated gifs, and cloudy, repeat-backgrounds made in photoshop. I treasure these bad memories. Any memorable era will have its own special gaudiness, perhaps because there are few physical and social rules in place to prevent silliness.

But how else would we get unbridled greatness?

Long live the blink tag!

• perl6 allows you to define new language constructs and modify current ones. Damian Conway walked us through some conversions of his current perl5 modules to perl6 that demonstrated this in full. I was completely tripping out for at least 30 minutes after the end of that session.
• You can use an apostrophe in a module name for effect because this is what :: used to be called. Hence, ACME::Don't.
• perl6 needs a CPAN, or whatever they are going to call it.
• Samy demonstrated how to build packet sniffers, ARP spoofers, and other useful utilities in perl... without depending on any c libraries. All who attended his talk bore gleeful looks of mischief as they walked out.
• George Lakoff pointed out that we should should be saying that "perl is alive" (instead of negating a frame). Mr. Lakoff makes a good point, but the lame "perl is dead" frame is so widely believed that it can be effectively countered with direct force.
• Perl needs marketing. Actually, CPAN needs marketing.

I went to a lot of talks and found out many interesting things. Here are some tidbits:

• Tatsuhiko Miyagawa's starman web server has lots of potential in the high-performance space.
• Installing your cpan modules in your home dir using local::lib is gaining acceptance. Why did we ever need to talk to the sysadmins to do perl dev?
• Doh, I should have built my mega API project using Catalyst::Controller::DBIC::API
• CPAN development is a lot easier now with Dist::Zilla. It uses a set of configurations and plugins to version, pack, and upload your module to CPAN.
• perl5 is brimming with new features, and so is cpan. A few of my favorites:


• defined-or operator: $age //= 100
• method signatures
• MOOSE and MOOSE roles, among the most perlish things to happen to perl, yet I first started using dependency injection in java and ruby
• perl6 rocks
• today's perl5 and cpan are a good way to learn perl6.
• Human processing: don't over-engineer something that can be done by an hour of repetitive work using the world's best computer.
• DBIx::Connector looks like a nice alternative Apache::DBI except that it does not require a mod_perl container. It does not cache the connection, just makes sure that it is available.

Ok, well, that was day one. I'll add more tomorrow...

This type of database has been begging for a name ever since BerkeleyDB reigned. It probably should refer to what it is (and not what it isn't). so out the window we should throw the term "nosql". Following that should be "structured storage", which does not fully differentiate it from a relational database. On our march to O'rielly conferences, blog posts, and constant twitterings we should guide the terminology for clarity and for posterity.

After all, we don't want another AJAX or Web 2.0 on our key-flattened fingertips.

So, what is a clear way to refer to a database that favors availability over integrity? I just read an account of a talk at Southeast Linux Fest in which Richard Hipp referred to them as "postmodern databases."

Which is a great way to put it. When I hear this in my mind, I laugh because I am reminded of Baudrillard's Simulacra and Simulation. According to Baudrillard's way of looking at things, we are so deep in simulation that we no longer even know what is original, or even what original is.

The postmodern database is the appropriate technology for our age of mutability and interconnectedness, a world in which our need to instantaneously connect to each other and to connect to our knowledge is more important than "properly" categorizing and extracting meaning.

We can always write processes later on to cull postmodern data and diligently pack it into something "tried and true".

Meanwhile, real people have seemingly figured everything out.

These subtle changes should put me in much better form for the upcoming YAPC 2010!