Isn't it because programmers are bad with all types of relationships?

Today's action items:

- Give me a list of good (lifetime sales > $10,000) customers on the west coast (CA, OR, WA) who bought any product on the defective list during busy season (10/06, 11/06, 12/06) and haven't placed an order since our last email blast. We'll find out why.

- Give me a list of phone numbers (using our Caller ID) of people who called in the last 4 days, whose call wasn't answered and had never called us before. We'll call them back.

- Give me a list of our slowest moving (10%) products that haven't been ordered in the last 4 months that are sitting in prime space (Location beginning with 1,2, or 3) in the warehouse. We'll move them to pallets to make room for new stuff.

- Give me a list of all products returned from Territory 7 in the last 3 months with a Problem Code related to fit or size. We want to make sure their description is correct on the website.

I could go on (and on and on)...

Do any of these with your "big hash table" in less than 1 second and earn a seat at the table with the big boys.

Just because something is old doesn't mean it's obsolete. Maybe because it works so well.

And just because someone understands this doesn't mean they "drank kool-aid".

Nothing wrong with a little debate. But please come up with more creative methaphors.

Funny you noticed that. There is one, but it's unpublished. I give copies to individual YC startups when the time comes.

You can specialize in engineering long before college. I was writing programs for our home computer at age 12. I'd bet that more than half the people reading this started out the same way.

In the specific case of computer hacking, this works - because even professional-level computer work doesn't require any equipment that a twelve-year-old cannot get. People in other fields aren't so lucky: You really can't learn much about the reality of practicing law, or medicine, or manufacturing from books or websites. You kind of have to learn these things on the job.

Why are so many tech companies founded by people in their twenties? Because software is one of the few fields where a twenty-two year old can have more than ten years of experience.

Of course, even young hackers face problems. They're still treated like children. Back when I was young, teens were rarely exposed to real mentors, taught real computer science, given real tasks, or paid real money. The web has helped to change a lot of this - on the internet nobody knows you're a teenager - which explains why young people are the web's most enthusiastic users.

"If I get to pick the programming language for a particular program, my "go to" language is Ada."

Your "go to" is considered harmful.

Thank you for exposing this Steve Yegge fellow for what he really is. I have to confess he had me fooled into thinking he was some kind of "programming guru" just because he ported Rails to JavaScript/Rhino. I hadn't noticed the blogspot template. Thanks for setting me straight.

Now this is just stupid.

I've built a career moving data out of flat files into RDBMS in order to get systems working properly (and quickly). I couldn't believe the hoops people jumped through just because of their dislike (or ignorance) of relational databases.

This data base model is perfect for many applications, and can easily be mixed with other data storage technologies (if you know what you're doing.)

Don't like the capabilities of your RDMBS? Then add what you need to you app. Indexing, transactions, stored procedures, audit, security, whatever. The code doesn't care where it's at. It still runs.

Not pretty enough for you? Then become a mathematician or fashion designer. Otherwise, shut up and code.

I don't understand the resistance to using multiple languages in one project. Every time you use an API, you're effectively using a new language. The syntax may be familiar, but the vocabulary is completely different. That's the point - through libraries and DSLs, we extend the capabilities of the base language so it's more suitable to the problem domain.

Take a look at the following SQLAlchemy code:

  select([users.c.first_name + ' ' + users.c.last_name,
          users.c.email, games.c.title], 
       from_obj=[users.join(games, 
                 users.c.user_id == games.c.creator_id],
       and_(games.c.creation_date == datetime.datetime.now() - datetime.timedelta(3),
            or_(users.c.email.like('%@aol.com'),
                users.c.email.like('%@hotmail.com'))))

Can you really say that's easier to read than this?

  SELECT users.first_name + ' ' + users.last_name,
         users.email, games.title
  FROM users
  INNER JOIN games ON (users.user_id = games.game_id)
  WHERE games.creation_date >= DATE_SUB(NOW(), INTERVAL 3 DAY)
  AND (users.email LIKE '%@aol.com' OR users.email LIKE '%@hotmail.com')

SQLAlchemy is a really cool library - it basically lets you write all your SQL queries in 100% Pure Python. But I doubt I'd use it on my own projects, because I've learned to be suspicious of libraries whose only purpose is to make some other tool look like a language I already know. Invariably there are reasons why the original language looked the way it did, and the reimplementation as a library becomes incredibly clunky as things get more complicated. I find I'm better off learning the original language instead.

Article summary:

Math is hard, buy Mathematica, buy Mathematica, here's a picture of Excel, buy Mathematica, buy Mathematica, math is hard unless you buy Mathematica, buy Mathematica, BUY MATHEMATICA, BUY MATHEMATICA, ... I SAID BUY MATHEMATICA OR MATH WILL BE HARD!!! BUY IT!!! BUY IT NOW!!!

Note that the salesmanship in the summary is a bit more subtle than the actual article.

Paul could you please publish it or if it's not suitable could you send via email. We're a startup from India, there's no ecosystem for startup's here unlike the valley.We've been looking for guidance mostly on the web and you're writings have been extremely helpful to us.In fact your writings have been one of the most important factors of inspiration for our belief that "it can be done !"

If he wants to see resumes with fewer buzzwords, then he should take ownership of the screening function.

At too many big companies, HR is used to screen, and all they know how to do is match buzzwords.

And that's just for starters (there's more to say on the topic of why job search is broken).

Employers need to realize the system is broken largely because of what they demand from candidates.

I didn't. SQLAlchemy did. ;-) (http://www.sqlalchemy.org/)

You mean simply using normal CS data structures and keeping application data in memory? That approach certainly works - PG uses it for this site, and I believe it's used for Mailinator and Bloglines.

But you should think of the services that a database gives you and consider whether you're going to use them. That includes:

1.) Indexing by arbitrary column

2.) Subranges & slices, again by arbitrary column

3.) Joins

4.) Sorting

5.) Quick summarizing, over any combination of columns

6.) Transactions

7.) Persistence

8.) Concurrency control

9.) Access from multiple languages

10.) Distribution

If you aren't going to use any of these, then by all means Keep It Simple. If you're only going to use one or two - say you need persistence, indexing, and slicing - you can probably roll something up with your language's normal libraries. But if it looks like you'll need a good chunk of them, you'll drive yourself nuts trying to implement them yourself. Even maintaining multiple indexes via your hashtable approach can get very complicated when you have multiple requests inserting, deleting, and changing rows.