Oh, quite true, and it may not be the most natural behavior for many of us.
Still, I think most people would understand it if you politely explained that time is limited and you're trying to meet as many new people as possible, and here's my contact info so we can continue this discussion later.
If folks are waiting in line to talk to you it's fine to say "do you mind if I give you a call or drop you an e-mail to do a follow up" and indicate (politely) that you would like to talk to folks who are waiting. Individuals will sometimes come up after a talk and want to have a 15 minute conversation--or try and have an argument of some sort--when three other people are waiting. It's not being rude to spend 30 seconds to a minute to understand the gist of what they want, make a note of it on their card, and follow up later.
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.
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.
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.
The first thing wrong with this title is the article is about "software engineering", not "computer science". The second thing wrong is engineering is a discipline that teaches you about trade-offs, costs, and finding balance in your solutions.
I had excellent engineering teachers. Never once did they compare the tough problems we were solving to Vietnam.
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.
The Vietnam analogy is bad in many respects but I can see where they're coming from. ORM was a battlefield, many faught hard (including myself) and ended up walking way disgusted and defeated at the same time.
I didn't mean to say that it was less meaningful. My battlefield was meant to be a Vietnam battlefield, not some alternative or better analogy. I'm defending Neward's analogy up to a point. Any war analogy of course misses the humanitarian horror that is a war. That's why it's always a problematic analogy as well.
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?
There are lots of ways to do this. A most common approach is to have each of those dicts be a first class object in python/blub, and therefore you know the class of the object. Customer.find() returns a customer which contains your dict. No magic going on here. You are not reinventing too much by deciding to use lightweight wrappers and eschew automated SQL generation or ORMS and related DSLs.
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?
Yes, dict is a hash map. A python dict is not "typeless", it contains whatever python objects you put in it.
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.
I've used both simple and complex mapping methods. At the moment, I'm using mongodb with very simple first class object wrappers around the hash/dict. This is appropriate for this new app.
For an app I already have in production, I use postgresql and ruby's datamapper. This limits me to knowing that adding some features requires more work so those features keep getting pushed off the plate. The reason I use postgres for this app is because my users expect RDB ACID properties. For the new app I'm working on, not so much.
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.
Most all low level rdb libs provide basic type conversion from allowed types in the db to type fitting the language you are using. From these libs you send SQL (any SQL you care to send) and you get returns of a "row" or a cursor usually.
An ORM adds stuff on top of the driver. General these frameworks provide relationship management, connection pooling, caching, and config management.
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.
Thats a pretty decent definition. I think their phrase "incompatible type systems" is meant for you to stress the word systems. The word type is not needed. Not to be confused with "type of an object, i.e. its class".
If you really want to know what's in various lower level drivers, as opposed to ORM frameworks (which vary quite a bit themselves), just go crack open some code and look at the APIs for yourself. You can go pretty far back to MS ODBC libs or even vendor dependent Oracle libs from mid to late 80s and see they were used quite effectively on their own for many years. JDBC was fairly straightforward derived from these predecessors.
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 found myself going through faces of obsessive determination and complete apathy last year. I think part of that's probably just life: Everybody runs into dilemmas. In cases like this, where partly it's a matter of being online talking to a focuses set of people, taking a few months off works wonders. Turn on noprocrast, set your away time to 65536, and figure out what else you can do. I just got access again a few weeks ago, and I don't feel the pull of this community anymore, so I don't feel as committed and frequently hopeless. With luck something like that could help you out as well.
(My other, snarkier advice is to go to Metafilter and look at every thread regarding a Paul Graham essay, because Metafilter's a bright community that loathes Paul Graham. My opinions are somewhere in between there or here, but reading those threads in June was rejuvenating in some ways.)
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.
Robustness, and potential of evolution, of a society relies on its diversity, I think. Tech start-ups stand on the huge body of relatively risk-free infrastructure provided by traditional structured organizations. Although such structure may change from the current way big corporations run, there will always be more people needed to work for such stable infrastructure than trying new things on top of it.
And people are different from each other. Some can draw their potential by taking risks and trying new things. Some can draw theirs by maintaining and gradually improving the existing organization. Some even want to produce things that don't pay their bills (e.g. most artists) so the need day jobs, but they are roots and trunk of rich culture.
PG doesn't say explicitly, but I think his essays aim at very specific type of people, especially those who aren't risk-averse type but are afraid of taking risks because they're educated so.
If you're bothered by those who look down you, you can just remind yourself that their success actually relies on you.
Preface to the following: I don't have enough time to frame my arguments in a more objective view-point, so, for those that read this post please do not take them personally! I respect individual free will greatly and never expound my philosophies unless someone asks :)
I would agree, in the end it is ultimately about happiness and joy. However, if you are inherently seeking personal evolution (which is what joy IS), 9 to 5 will do a lot to suppress that.
Unless you happen to be paid for research or bleeding edge development on some cool project, building webapps for other people day in and day out; or doing maintenance work day in and day out isn't a terribly creative expression IMHO. (Creativity IS spirit, it is an aspect of the intellect - there is regurgitation and then there is creativity)
I resigned from my 9 to 5 (as a systems engineer and web application developer) to pursue my self-education and a startup idea. While I almost did not hand in that letter of resignation, I did, and I am loving my life.
Mind you, I am 22, have 0 debts, 0 dependents, and am willing to live out of a tent and work from the library till my projects begin to generate an income (yes I am a lone wolf).
If you feel fear, that is an excellent indicator that you are staring right at your 'edge'. Edge being that boundary in which you, as a man (I'm assuming you're a man), find your present state of consciousness expanding into; pushing that edge pops the bubble and you begin expanding into that new boundary. The phallus is an excellent symbol, as men (speaking for myself and many that I know, I apologize for the sweeping generalization) we feel purposeless and mediocre when we are not constantly PUSHING, SPEARING, HUNTING, PENETRATING.
Find your edge and lean into it (don't jump off the edge), push push push. Use the masculine aspect of your psyche (intellect, hunter, etc...) to challenge yourself and your edge; you can even do this within the context of a 9 to 5 job, however, you will find at some point the typical 9 to 5 structure of serving your time to someone else is far less appealing than serving it to the greater self that is your life.
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.
Exactly - in fact, when I was evaluating starting my startup, I figured the startup experience - and received advice agreeing with this - would prove more valuable than the equivalent time spent a "normal" job.
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.
