According to the Wikipedia definition of ORM, it's primarly about the mapping of types:
Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in relational databases and object-oriented programming languages.
Yes, a mismatch exists and can lead to compromises as you try to use the object paradigm to glue the two layers together. But the benefits are also undeniable, primarily that of productivity gained during development by not having to concern yourself with the job of mapping types between the two layers.
Maybe they didn't compare tough problems to Vietnam but my point was that good teachers often have a knack for translating difficult-to-grasp abstract concepts into the familiar and the concrete. Some people look down on such teachers and accuse them of dumbing things down. I would say on the contrary that the job of a teacher is exactly to dumb things down.
Most client drivers/libs for RDBs have basic type conversions for each language. You don't always need an ORM for this. If you have a ruby or python Time object, the low level db lib generally will convert it to/from the RDB format.
Didn't know that. If that's correct, then the low-level db lib is an ORM in Python. In which case SQLObject/SQLAlchemy probably just harnesses those features and adds some additional cream on top.
You mentioned a "common approach". Is this the approach that you use or have you found a better way? The reason I ask is I don't quite understand how your description above correlates to an ORM type-mapping system. Customer.find() returns a customer which contains your dict. I don't know python but I assume a dict is a type-less hashmap. So if your customer has a field called 'updated_at', wouldn't you need to write a function to convert that type appropriately for the application since the application doesn't know whether it's a Date, Datetime or Timestamp?
If anyone could be accused of linkbaiting it would be Neward since he wrote the original article titled "The Vietnam of Computer Science". But I think it's less useful to think of the war analogy as linkbait than as a didactic tool to bring attention to aspects of ORM use that Neward wished to highlight. Creating effective analogies is the same strategy used by good teachers the world over.
I think the comparison to Vietnam makes sense as an analogy.
The basic argument seems to be that each ORM imposes limitations specific to that implementation which may result in the developer's choices being limited later on in the development process - just as early strategic decisions in a war can predetermine the outcome and potentially result in 'quagmire'.
It's an argument that seems to echo Joel's idea of "leaky abstractions", i.e. the ORM is just a big leaky abstraction and you have to deal with the leaks sooner or later.
How do you map the types if the rows are returned as dicts? Doesn't that become an application responsibility? By using an ORM you would not need to build that functionality, i.e. reinvent the wheel.
Did you consider using SQLObject or SQLAlchemy? If so, I'd be curious to know why you decided against using them?
Excellent points and very well said. Recently I have been starting to feel down about myself and I noticed that it had to do with reading Hacker News and estimating my value through the lens of this startup value system. Despite the obvious talent and intelligence in this community, as you pointed out, if you are constantly face to face with a value system that is at odds with yours you will either (a) decide that it is not for you and walk away or (b) if you are of a more impressionable mindset, you may start to wonder why you don't match up. In my case, I have been finding the latter, at the expense of my self-esteem. So perhaps, as you suggested, I should take a break from HN for a while, as seductive as it is both in terms of content as well as the quality of the discussions.
I appreciate that you say that because I do find it troubling that some people here seem to suggest that unless you are willing to take the kinds of risks involved in doing a startup, you are not really living or actualizing your potential.
It's the attitude that if you work in a company you are just a wage slave and a drone.
It's an attitude that expresses a value system which places a premium on achievement and 'Success' and is not so different from the value system of certain people inside the corporate world who are desperately clawing their way up the ladder to prove something to their peers, their neighbors or themselves.
I don't begrudge someone their ambition to do that if they want to but what I do resent is when someone tries to make me feel that my choices are somehow less if I'm not willing to 'step up'. It all comes down to what you value more.
One thing I disagree with in the article is the premise that people get real jobs because "it's the default thing to do". While that may be true, it's also true that a regular job is simply the most likely way that you are going to make a secure living over the long run since most startups fail.
If your job "fails", you can always get another one and make close to what you were making before. And especially if you work in tech, nothing about what has happened in the economy recently has really changed this reality.
But if your startup fails your next startup is also likely to fail - less likely than the first time perhaps, but still more likely than not.
What kind of storage costs would they be paying for all that binary data? I'm guessing they're using Amazon Simple Storage, which is not expensive, but in that kind of volume I'm sure it adds up. Great idea, though. Thumbs up and best of luck.
Except for a couple of typos ('are' instead of 'our'), this is an extremely articulate and informative statement which will no doubt help them justify this decision to future funders or employers. Very impressive.
This competition is open to anyone with a Twitter account who is at least 16 years of age ... You agree to allow InciteBot to share your personal details with affiliated companies. Basically, you agree to let us submit your application to the employer.
This is a great idea. I've often wished that pg's original ideas article was updated more regularly but your suggestion would be a nice alternative to giving pg more work to do, especially given how poorly we pay him.