Expecto Sanitas

Implicit Cross Joins Considered Harmful

2008-08-03T22:49:00.000-07:00

This will be a somewhat shorter post than my previous rants, and hopefully set me down a path mixing relatively infrequent essay-ish posts with more frequent, but tighter focused post. These will generally be about something that has interested me or annoyed me enough to remark about it.

In this blog post, I'll be discussing SQL joins. Specifically, the habit of using a cross join and a where clause instead of an inner join and on clause, such as:

SELECT col1, col2 FROM table1, table2 WHERE table1.foo = table2.bar

instead of

SELECT col1, col2 FROM table1 JOIN table2 ON table1.foo = table2.bar

To make this more concrete, here's an example in the form of an online store.

Say we have two tables in our database, called users and transactions. The user table has a user's name, address, and a numerical id for that user; the transaction table has a numerical id for the transaction, the amount for the transaction, and the id of the user associated with the transaction. Let's say I want to get all the transaction ids associated with users in the zipcode 12345. I can write this query in at least two different ways:

SELECT transaction.id FROM transaction JOIN user ON transaction.user = user.id WHERE user.zipcode = 12345

SELECT transaction.id FROM transaction, user WHERE transaction.id = user.id AND user.zipcode = 12345

So far, so good. Both of these queries will return the same results, and within at least PostgreSQL 8.3.3 and MySQL 5.0.51, both have the exact same EXPLAIN plans.

Spacial Locality of Table References

Let's introduce two more tables: product, and product_transaction. The former table indicates products we have in stock; the latter table indicates which products were associated with a particular transaction. Now I want the number of each product a user in the zipcode mentioned above bought. Again, this can be done one of two different ways:

SELECT
user.id, product.sku, count(product.sku)
FROM user
JOIN transaction ON user.id = transaction.user
JOIN product_transaction ON transaction.id = product_transaction.transaction
JOIN product ON product.id = product_transaction.product
WHERE
user.zipcode = 12345
GROUP BY user.id, product.sku

SELECT
user.id, product.sku, count(product.sku)
FROM
user, transaction, product_transaction, product
WHERE
user.id = transaction.id AND
transaction.id = product_transaction.transaction AND
product_transaction.product = product.id AND
user.zipcode = 12345
GROUP BY user.id, product.sku

Both queries are still manageable, but there's a pathology that is starting to develop in latter query syntax; the conditions by which tables are joined are becoming more spatially segregated from the references to those tables. The associations are not made immediately obvious except by the names of the tables themselves. So lets remove the names:

SELECT
table1.id, table2.id, count(table2.id)
FROM
table1
JOIN table4 ON table1.id = table4.t1_id
JOIN table3 ON table4.id = table3.t3_id
JOIN table2 ON table3.t2_id = table2.id
WHERE
table1.zc = 12345

SELECT
table1.id, table2.id, count(table2.id)
FROM
table1, table2, table3, table4
WHERE
table1.id = table4.t1_id AND
table4.id = table3.t3_id AND
table3.t2_id = table2.id AND
table1.zc = 12345
GROUP BY user.id, product.sku

Which of these queries makes more immediately obvious the relationships between tables? If I were to ask you how table4 is related to table2, which query would you rather have to reference?

The former query specifies the join relationship as soon as each table is declared, allowing the user some indication on structure even if the tables are named poorly.

The latter separates the relationship out, sending the coder hunting through conditions in the WHERE clause to find the table name they are after. There is also no guarantee that the conditions in the WHERE clause will be in the same order as the table references in the FROM clause. This problem only becomes further exacerbated by additional table references and join conditions.

To slightly modify the words of Harold Abelson and Gerald Sussman, SQL queries must be written for people to read, and only incidentally for RBDMSs to execute. The latter set of queries break that philosophy by making the developer have to work hard to understand things, with no gain in query performance. The only benefit is less typing now, due to trading typing 'JOIN' and 'ON' for 'AND' and commas. Less typing is a weak reason and generally not accepted anywhere else as an excuse for making things cryptic, so it makes no more sense that it would acceptable here.

Connecting with your OUTER self

Seeing the results of our query above, the marketing department decides they're doing a great job, and decide to start packing up for an early departure to the local pub. Catching wind of this, you start feeling envious because you have a list of bugs to fix so long it causes your browser to start paging to disk. So, you decide to show them just how many people their advertising campaign isn't working on. If you're using the former query above, you're in good luck. The necessary changes are highlighted in bold:

SELECT
user.id product.sku, count(transaction.id)
FROM user LEFT OUTER JOIN transaction ON user.id = transaction.user
WHERE
user.zipcode = 12345
GROUP BY user.id
HAVING count(transaction.id) = 0

As for the latter, you have more work ahead of you:

SELECT
 user.id, transaction.id, count(transaction.id)
FROM
 user, transaction
 user LEFT OUTER JOIN transaction ON user.id = transaction.user

WHERE
 user.id = transaction.id AND
 user.zipcode = 12345
GROUP BY user.id
HAVING count(transaction.id) = 0

The use of an LEFT OUTER JOIN is necessary, as the use of a CROSS JOIN will not produce a table containing user rows with no associated transaction rows; a Cartesian product of anything against the empty set is the empty set. So you're stuck doing heavier surgery to the latter query, but at least you got to give your hands a break when you were first typing it. Those small victories can add up.

Performance Anxiety

The other question which came to mind while thinking about this was if doing the joins one way or the other affects performance in any way across most modern day databases. As I mentioned above, both MySQL and PostgreSQL will construct same query plan for either syntax, and I would be surprised if the parsing cost was of any significance either way. I dug into the documentation for both MSSQL and Oracle, and found that they, too, will construct exactly the same query plan either way. So from a performance perspective, the difference between these two is non-existent.

Conclusion

There is no difference between implicit WHERE-clause constrained cross joins, and their ON-clause constrained inner join cousins regarding performance. The only real trade-off is between greater readability and faster coding time, and as several authors far smarter and experienced that myself have stated, trading off readability for efficiency is almost always not worth the added pain later on. So, the next time you catch yourself joining tables with commas, and packing everything into your WHERE clause, I ask that you take a moment to consider readability and whether or not using explicit ON-clauses in an inner join is the better way to go.

A Siege on The Ivory Tower

2008-07-31T11:41:00.000-07:00

An ongoing debate with a former manager of mine -- not former because of this debate, btw -- regarding the design of object-oriented programming pondered into a blog sized post pondering one implication in particular. I will assume in this post you are somewhat familiar with the concept; if you aren't, it will seem like I am speaking in dead tongues through parts of this post. The basic ideas aren't hard, and wikipedia has an excellent treatment on them for the unfamiliar. Once you feel like you have a good handle, read on while keeping that page in a separate tab for when you reach an unfamiliar term. Now, on with the show.

The argument he presents can be distilled to a single quote: "objects respond to events, they do not pass data." There are several implications to this philosophy, which the similarly-minded Allen Holub goes into greater length about in a few posts. The basic idea I can gather from the conversation I had with him, along with these posts which seem to follow the same line of thinking, is that people are misunderstanding and misapplying encapsulation. This is blamed for a considerable amount of grief within the software development world, with the solution being a different, and supposedly better encapsulation. One that really cordones off your code from the evil demons that lurk within the core. Before I dig into the differing philosophies, there's something that must first be resolved.

Defining Encapsulation

As experience is quickly teaching me, a disproportionate number of technical arguments tend to boil down to disagreements on definition. Either the participants have distinct and incompatible definitions of the same term, or they have a disagreement about the meaning of a term in a definition they both agree on. So, let's start with a definition of encapsulation, in an attempt to diffuse the former.

As Wikipedia defines it, encapsulation "conceals the functional details of a class from objects that send messages to it."

Immediately, there is a problem of definition. What constitutes functional details, and what do we mean by concealment? It might sound like I am being overly pedantic, but this same sort of seemingly trivial confusion causes endless heated arguments on other topics. In this case, both are subjective terms. What details does one decide are worth concealing, and how concealed should each detail be? What qualifies as a functional detail, and what is sufficiently tangential to the functionality of the code to be ignored.

The answer I'd expect, and have gotten a number of times, from the proverbial object-oriented purist is to conceal as many details as possible, and conceal them as much as possible, regardless of the benefit each quanta of concealment provides. Allow the programmer the most minimalistic interface possible, not in the sense that it is simple, but in the sense that very little can be done with the interface exposed. The class should allow just enough access so that the user can actually do *something* at some point. Any more access than this, and class developer is providing rope than he should lest the developer interfacing with that class hang himself. The class developer walks a thin line between having something completely cordoned off and useless, or having something that someone could use *irresponsibly* and outside of its original rigidly specified use-cases. It becomes a choice between providing functionality, but being defensive about the way it the interface coded, or being defensive by *not* providing that functionality at all. The cause of this obsession is one of extreme distrust, and a belief that anyone who uses their code is either an idiot or malevolent. The definition of malevolent here is relatively broad, it pretty much envelopes anyone who might use or extend the class contrary to or in absense of requirements in the adjoining specification.

Extreme Encapsulation

The logical extreme of this philosophy is that one provides a minimalistic interface available only wrapped around another interface defined elsewhere. The only thing better than encapsulation is encapsulated encapsulation, ad infinitum. When someone describes a system that responds to events, they are almost inevitably talking about a system based on messaging. In the world of Java, this almost invariably means using something that relies on an implementation of JSR 914, colloquialy known as Java Messaging Service, or JMS. This is the ultimate of limited interface: one method, one way to deliver data to it, and one way to get data from it. Messaging systems are a good thing when their usage makes sense and adds functionality to the system, but this seems to do the opposite. The end result is the same, except now there are more steps involved, and the result of those new steps is static; it just adds more layers. A certain optimization opportunity if it weren't purporting a higher goal.

Building An Ivory Tower

It this feeling of distrust is apparently common amongst object-oriented designers and architects, at least in my experience. This distrust causes them to build their architecture in the form of an ivory tower, where those that dwell within are as secluded as possible from those without. If you must build a collosal system to make sure the entrance to it is as small as possible, then that is what you do. Metaphorically, it is like the lord who builds an collosal wall around his castle, and makes the only entrance to it a long winding hallway with a series of locked doors and guards. It almost makes one wonder if it is worth what is on the inside.

But the ivory tower architecture isn't to protect what is on the inside. The collosal castle wall and armed guards are not to protect the lord from the peasantry, it is to protect the builder of the wall from the lord. And it was built that way by specification, which the architect advocated for through the whole design process. Any explanation other than saying the architect was just covering his ass is wrong. It grants him license to handwave any criticisms away. Any inconsistency or misbehavior in the system is the fault of either the specification or the incompetent developer implementing it. The difficulty in accomodating the inevitable spec change will be blamed on the ineptitude of the specification authors. The design will also include components that are unnecessary, but further the apparent necessity of the architect. If a developer questions the component's existence, those concerns are dismissed by accusing the developer of not having context.

It is a pathology deserving of a name. If what I read most days is true, it is a pathology running rampant, and it seems to infect a disproportionate number of Java architects. Allen Holub even succumbs to it when he declares that flexibility is only a requirement of frameworks that can't make assumptions about how they will be used before-hand. How is he so certain the software he develops won't collapse under the tenuous requirements he swears are carved in stone? And how many frameworks that are now in widespread use throughout multiple corporations were ever built up with widespread use and praise as their eventual goal? I suspect the percentage is rather small. No one who authors a simple program ever thinks of "will be used worldwide as one of the canonical solutions to the larger problem it is solving a part of" as a use-case at the start. It just happens, and the design needs to be there from the start to accomodate that. Relying on restricting what the user can do to prevent errors can only scale so far, and then adding new functionality becomes a nightmare. The internal design has to change, but is hard to change because it was so rigid to begin with. Just because your restrictions and encapulations keep your users from having to care about the design of your software doesn't mean you don't have to. Design your software to be robust, fault-toleratant, and flexible, even if the specification implies you don't have to care. Eventually, you always will.

Modeling The World of Office Politics

So what motivates this sort of design? A lot of the design that goes into software is in the form of metaphors, so what metaphors are these architects relying on to construct their software architectures? They seem to mirror a common architecture of a different kind: the organization structure of the corporation. If two teams are building two software systems that interface with one another, the corporate structure and dynamic between those two teams will come out in the code they write. If they tend to collaborate a lot, and the corporate culture is one where openness and trust are cultivated, the interface between the two systems will likely be relatively thin, maybe involving something like a remote procedure call from one directly into the other. However, if the two teams are defensive and territorial, and the corporate culture is likewise, the interface between the two systems will be mired in the same sort of bureaucracy and layering as real-life communication in the company. If each department acts like an ivory tower in real-life, it is inevitable that their software will be constructed likewise. It is the corrolary to Conway's Law.

But, knowing this, can we then start making better designs by actively fighting against this sort of organizational inertia. The stakeholder will all resoundingly answer "No.", but not for the reason you might suspect. They probably seeless crufty designs as a worthy ideal, but to suggest improvements assuming that is the goal entirely misses the point. The goal of these designs is not efficiency; the goal is protection of power and the status quo. The goal is to simulaneously protect the interests of the department writing the software against the meddling of other departments, and to protect the architect against seeming less valuable because the system he wrote wasn't sufficiently complex to justify his employment. It is the sign of an organization functioning off of assumptions that have been proven false time and time again: that more complex software is harder to write, that the only sure way to protect one's job and department is to engage in petty turf wars, that the status quo is always desireable to change.

The chasm between the designs of an architect who's primary motivation is to create something that solves a business problem efficiently and effectively, and the architect who's primary motivation is remaining an architect as long as possible, is as wide as an ocean. It will be blindingly obvious which problem an architect is solving for first, and it will be obvious from that what sort of culture the company is cultivating. I think you can learn a lot about a corporation just based on their software systems, and that the design appears busted suggests to me that the company is also busted.

The Good Sort of Encapsulation

I've spent probably a half hour of your life railing against one of the principles of object-oriented programming. Let me assure you I have no problem with the OO design philosophy, including encapsulation, and think there are several domains where it creates nice metaphors. My issue is with the designers who take the philosophy to what they believe is the logical conclusion, and use it as justification to build walled gardens - a means of usurping power, where any resulting useful software is just a happy accident. They don't encapsulate to abstract, but where they encapsulate to cover their butts.

I do believe that encapsulation is a worthwhile concept however, but not for the same purpose. I see it as being useful in the same way as namespaces and lexical scopes, as a means of abstracting functionality and data so the developer doesn't have to care about how something is done; the same reason why structured programming was such a win. Declaring data and internal methods private that should be private is not what I am against; I am not against information hiding and functionality on which the user should not be depending. It is the hiding and encapsulating of the interface that troubles me; the interface that tries to be as elusive as possible as providing any sort of functionality, including that which the user *should* be taking advantage of. By doing so, it introduces accidental complexity elsewhere, where things have to bend in order to work correctly. What if the other classes are designed the same way?

You may not handle all the capabilities in your initial design, and you should build your software with the assumption that things might change, which invariably means keeping things as simple as possible. Holub deviates from this, by saying that that although maintainability is paramount, complexity is to be embraced as inevitable. Perhaps I'm just an edge case, but I have observed a tautology between complexity and lack of maintainability. Claiming that the system can be constructed such that a particular bit of functionality is confined is fine, but I can't help but wonder what work is involved in locating that functionality when maintenance is necessary, especially if layered under proxy objects. For that matter, what happens when the method signatures of those proxy objects change? I wonder about the claim that such compositional gymnastics will eliminate forever the need to change more than one class at a time. Or is this yet another difficulty we sweep under the rug by assuming a priori a perfect high-level design? I think it's worth taking one of the tips out of Pragmatic Programmer, and design the system for potential changes from the start. It seems like the route for less potential headaches, and is less likely to devolve into a squabble over who is responsible for the pain of dealing with the inevitable changes that must occur.

Thanks for reading. Feel free to leave any thoughts that you might have.

How to misunderstand an INTP

2008-01-30T03:02:00.000-08:00

According to a number of personality tests I've taken over the last several months, I fit into the relatively rare classification of INTP. A complete understanding of such a personality can be found at several sites on the other side of a Google search. The basic idea is that an INTP is much more analytical and logically driven than their counterparts in the other classifications. This leads them to be analytical of people as well, and can have some unintended and unhappy side-effects. This blog post is meant to provide at least a little bit of what one INTP is thinking, in hopes of diffusing future unhappy feelings. Before I dig into this too deeply, though, I should first provide a reasonable justification for why I think the Myers-Briggs Type Indicator (MBTI) is more fact than fluff.

Why MBTI has merit?

When I bring up the topic of the MBTI, or classification of people in general, the most common objection I hear is that I am unfairly putting people into predefined groups. The idea that people can be classified into sixteen, or any arbitrary number of basic personality types, seems to go directly counter to the assertion that every person is unique. I have two reasons to believe this argument doesn't hold: firstly, a macro level classification system still allows for a considerable amount of variation within; secondly, I think people give themselves too much credit for uniqueness.

In my experience, the people who would argue most passionately against such classification are the ones who have been taught since a more impressionable age that they are unique, and should never let anyone tell them otherwise. But personality profiling does not require that there only be so many variations in people as there are axes on the profile results. It also does not insist that there only be two values along each of the axes; the distributions are continuous, but can generally express a tendency one way or the other.

MBTI testing, along with other classification systems, purport a measurable indicator of a few behavioral and cognitive preferences, without making any claims to the traits it doesn't measure. And the traits it does measure are quite specific. To borrow my own profile for a moment, I stated before I am an Introverted Intuitive Thinking Perceiving type. These are very specific adjectives, each of them suggesting a narrow scope in describing who I am. And by knowing my classification, it can provide insight into how I might develop going forward, and how I may react in an unfamiliar situation.

For example, take the noun intuition. In the MBTI, Intuition is contrasted with Sensing, as one trait becomes dominant the other recedes. From Wikipedia:

Intuition are the information-gathering (perceiving) functions. They describe how new information is understood and interpreted. Individuals with a preference for sensing prefer to trust information that is in the present, tangible and concrete: that is, information that can be understood by the five senses. They tend to distrust hunches that seem to come out of nowhere. They prefer to look for detail and facts. For them, the meaning is in the data. On the other hand, those with a preference for intuition tend to trust information that is more abstract or theoretical, that can be associated with other information (either remembered or discovered by seeking a wider context or pattern). They may be more interested in future possibilities. They tend to trust those flashes of insight that seem to bubble up from the unconscious mind. The meaning is in how the data relates to the pattern or theory.

I might have picked a slightly different word than Sensing, perhaps Abstract contrasted with Concrete. But the idea is there, and my experiences suggest that people will show a tendency toward one or the other for gaining knowledge. And showing preference for one indicates, by definition, a preference against the other. And so the classification at least seems sound, even if the validity is questionable.

But then I am comfortable with the idea of classification in general, whereas many people tend to feel discomfort. The idea of classification tends to rest in peoples' minds near the idea of premature judgment and bigotry. Each piece of data that exists about you provides them with yet another opportunity for them to exclude or marginalize you in some way. We already have classification systems for intellectual ability, creditworthiness, academic achievement, athletic achievement, driving ability, and several others. We are being classified every day and lumped into aggregate groups. The only difference objections tend to be the loudest against those classifications we can least control. But the ability to work at changing one's classification is orthogonal to the validity of the classification. The classification we have the least control over is that of us being Homo sapiens, but I don't know of anyone who would argue against that classification's validity.

Outside of personality testing, the classification that tends to draw the most scrutiny is that of intellectual ability. The arguments tend to be largely the same as that of personality classification; the ultimate uniqueness of each person makes the test invalid for anything but detecting the most extreme cases of cognitive dysfunction. I tend to believe that the current methods we use to measure intelligence do provide useful information, though they may not correlate perfectly to every person's mental ability; what data I've seen on such tests suggests that there is noticeable correlation. The issue with gathering this sort of a metric is that any individual person only has so much control over their cognitive abilities. If they are measured at an IQ of 105, for instance, there may not be much they can do to modify that score. The issue comes when someone they know is measured by the same test to have an IQ of 130. Neither of them really had an substantial amount of control over the eventual outcome of the test, and so to feel anything but indifference is unfair. But human emotions care little about fairness, and a situation like this is bound to breed envy and spite. This seems to be the biggest argument against attempting to gauge intelligence in the general population, and it has absolutely nothing to do with the validity of the tests involved.

But personality profiles do not intrinsically carry the concept of ordering. A person with personality profile A is not immediately determined as "better" than a person with personality profile B. The implications of which is the "better" personality comes from societal pressures. These pressures would exist whether or not such a concrete measure existed. All that profiling allows for is people to explicitly state what they already knew intuitively. But it provides something substantive for detractors to point out, specifically the profile result. Outside of accuracy, which I spent some time arguing about earlier, this is the other big argument against profiling. But it lacks in even the most basic common sense. It is like insisting that if we ban racial profiling, racism will go away. People will continue to judge each other, the only difference will be the lack of tangible evidence that they are doing so.

So those are the two big arguments I see against personality profiling: that they unfairly lump people into presized boxes, and that they can be used as a means of selectively excluding people. As I've demonstrated above, I don't think we can hold profiling guilty of either of these, and definitely not to the point that it's usefulness is overshadowed.

The Portrait of the INTP

So, what traits make someone an INTP. Joe Butt provides an excellent summary of what drives an INTP, and what you can expect in dealing with one. Another good summary is provided by Paul James. The executive summary is as follows: INTPs are much more interested in logical arguments than emotional appeals. We enjoy playing with and creating complex systems, and will tend to get bored with simple drudgery. We try as best we can to develop models based on what we see around us, to attempt to discover the underlying mechanisms which drive the world around us. We tend be very non-social (which is different from anti-social), and spend large amounts of time alone with our thoughts. The products of those thoughts can be discovered in things like the objects we build, the conversations we have, and the essays we write. So now that I've hopefully made clear how I'm approaching this topic, what follows is the product of my thoughts.

How People Misinterpret an INTP

Why am I going on about classifications and personality types. Because of a misunderstanding of motivations I seem to keep encountering. Specifically, misunderstanding when communicating with other people. So, what follows are a few misinterpretations I seem to keep encountering, and my responses:

The first misinterpretation I encounter is when I express my disagreement with another person's claim, and they counter with the assertion that I am arrogant. Please do not confuse my disagreement and solicitation of a debate with you as arrogance. Please understand that I do not come to the table assuming without any doubt that I am right and you are wrong. By presenting arguments and assertions to support my side, I am soliciting two things: arguments and assertions to support your side, or arguments and assertions to refute my side. Keep in mind, these may not be the same, and I'd like to hear both.

To solicit a debate isn't arrogance, anyway. Arrogance would be asserting that you are wrong, and then refusing to listen to your defense. Continuing to disagree is not the same thing as ignorance. Instead I assume that both you and I have good reasons for holding our stance, and that we may have something to learn from one another. We may end the debate with one of us realizing they are in the wrong. We may each solidify our stances further, and realize there isn't a prayer of reconciliation. We may realize we misunderstood one another, and agree once we achieved common understanding. In any case, it's highly probable we both have a more informed position. The problem comes when I refute something, and am told to stop being arrogant and respect the opinions of other people. If you assert something and then assert that I am arrogant for refuting it and offering to debate it, I am not the one being arrogant. I'm not the one defending his pride by refusing to defend his beliefs.

The second misinterpretation is that I do not care about your emotions because I don't seem to be taking them into consideration. Please do not confuse my rejection of your emotional arguments as a sign that I don't not acknowledge your emotions. My goal in arguing with people is not to ignore or inflame emotions or instigate a fight. However, emotions are subtle and do not spring up from a conscious train of thought. They can cause people to form conclusions that don't make sense when considered without the anger, fear, greed, pity, joy, or sorrow that drove them. They may form part of the human condition, but they cause us to do or believe things that are ultimately destructive to ourselves, our friends, and our society, while providing little or no benefit to anyone. And people will defend these emotional claims irrationally, either by refusing to offer them up for inspection, or by attacking the person who might disagree. There may be an underlying reason for the emotion, but while the reason appears unapparent, emotion can only defend itself by further emotion. Logical argument does not suffer from this vague, impulsive compulsion to protect any particular claim from needing a defense. The argument must stand on its own, and if it fails to do so, it must be dismissed.

To quote Sam Harris, who I think sums my thoughts up rather well on this, "No society in human history has ever suffered because it has become too reasonable." The implication of this quote, due to there existing suffering, is that it increases due to a reduction or lack of reason; from what empirical evident I can witness, I wholeheartedly agree.

Thirdly, please do not confuse who you are with what you believe. The smartest people in history have been wrong on more than one occasion. From Wikipedia, Isaac Newton once made the mistake of believing all prisms will produce spectra of the same length. There was Einstein's assumption of the need for a cosmological constant, discussed more in this article. I won't go into further detail, but even those people we might deify were not perfect in their life -- even Jesus , Yahweh, and Muhammad was arguably not without error, and yes, I can hear the flame train departing. I'm not debating people's beliefs because I want to prove them in error; my goals are not so nefarious. As I've stated above, my main goal in debating is learning. If it turns out I am mistaken about something, I can leave the debate with a better, more accurate understanding of things. Thus, I am less likely to commit an error later based on an incorrect belief, and means I can approach problems relating to what I learned with a greater confidence. If you attach your feeling of self-worth to believing what you know is correct, you leave yourself vulnerable to committing avoidable blunders later in life, and you give yourself even more rationale to defend what you believe from any sort of scrutiny.

I'd like to highlight this distinction between defending a belief, and guarding a belief; I think it's vital to the differences in thinking I describe in this post. In the former case, you debate the accuracy of the belief; in the latter case, you assert the belief is not open to debate. I think the latter case is severely detrimental, as it indicates either pride or vulnerability based on one's belief. It indicates that you've attached emotional value to the belief, and so you will have a negative emotional reaction if you are proven wrong. I think it is far better to attach value not to the beliefs you hold, but to the means by which you arrive at those beliefs and your openness to learning and better understanding. Don't be proud that you hold a particular political, religious, or work ethic, be proud of how you arrived at that ethic. If you can feel assured about the methods you use to develop the ideals you follow in life, I think you are well on your way. But, if you worry that your methods would not stand under scrutiny, take the time to introspect, and discover what seems lacking.

I hope the above paragraphs provide a slightly better understanding of where I, and likely other INTPs are coming from when communicating. It is not our goal to make you feel inferior or defensive. When we seem not to understand why you are feeling hurt or attacked, it is because we had no intention of doing so. What we saw as an opportunity for collective thinking and reasoning becomes, without our expecting it, an argument about why we believe the other participants are deficient in some way. This is not our goal, but we also will not accept the argument that soliciting such a reaction makes us inferior. It is a product of a misunderstanding, and a misunderstanding implies both people share responsibility for it. My goal in this essay was to describe how at least one INTP perceives this misunderstanding, in hope that others will understand me better, and that they will reciprocate in kind so I can understand them better. It is possible that philosophical debates will arise out of this, but realize it is all part of the greater process of understanding and learning from one another. And, as if anyone needs to be told, we could use a lot more of both of those.

-mstackrealign and -m32 under MacOS 10.4.x

2007-11-30T16:27:00.000-08:00

-mstackrealign combined with -m32 can bring great amounts of sadness under MacOS 10.4.x if you are building 32-bit code.

Generally, the program will crash with a SIGILL result code. From a small snippet of code from SoyLatte, I got this dump from GDB:

(gdb) run -q -T ../generated/adfiles/bsd_i486.ad -c../generated/adfiles/mktmp14425/ad_i486.cpp -h../generated/adfiles/mktmp14425/ad_i486.hpp -a../generated/adfiles/mktmp14425/dfa_i486.cpp -v../generated/adfiles/mktmp14425/adGlobals_i486.hpp
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /Users/edcarrel/Desktop/jdk6_devpreview_r1/control/build/bsd-i586-debug/hotspot/outputdir/bsd_i486_compiler2/generated/adfiles/adlc -q -T ../generated/adfiles/bsd_i486.ad -c../generated/adfiles/mktmp14425/ad_i486.cpp -h../generated/adfiles/mktmp14425/ad_i486.hpp -a../generated/adfiles/mktmp14425/dfa_i486.cpp -v../generated/adfiles/mktmp14425/adGlobals_i486.hpp

Breakpoint 1, main (argc=751405, argv=0x90b8f092) at /Users/edcarrel/Desktop/jdk6_devpreview_r1/hotspot/src/share/vm/adlc/main.cpp:26
26 if( argc == 1 ) usage(AD); // No arguments? Then print usage
(gdb) bt

(gdb) run -q -T ../generated/adfiles/bsd_i486.ad -c../generated/adfiles/mktmp14425/ad_i486.cpp -h../generated/adfiles/mktmp14425/ad_i486.hpp -a../generated/adfiles/mktmp14425/dfa_i486.cpp -v../generated/adfiles/mktmp14425/adGlobals_i486.hpp
Starting program: /Users/edcarrel/Desktop/jdk6_devpreview_r1/control/build/bsd-i586-debug/hotspot/outputdir/bsd_i486_compiler2/generated/adfiles/adlc -q -T ../generated/adfiles/bsd_i486.ad -c../generated/adfiles/mktmp14425/ad_i486.cpp -h../generated/adfiles/mktmp14425/ad_i486.hpp -a../generated/adfiles/mktmp14425/dfa_i486.cpp -v../generated/adfiles/mktmp14425/adGlobals_i486.hpp

Breakpoint 2, main (argc=7874, argv=0x8) at /Users/edcarrel/Desktop/jdk6_devpreview_r1/hotspot/src/share/vm/adlc/main.cpp:19
19 int main(int argc, char *argv[])
(gdb) The program is running. Exit anyway? (y or n) y

I ran into this recently under MacOS 10.4 while working on SoyLatte.

Here's the command used to build this program:

g++ -m32 -march=i586 -mstackrealign -m32 -march=i586 -mstackrealign -g -o ../generated/adfiles/adlc ../generated/adfiles/adlparse.o ../generated/adfiles/archDesc.o ../generated/adfiles/arena.o ../generated/adfiles/dfa.o ../generated/adfiles/dict2.o ../generated/adfiles/filebuff.o ../generated/adfiles/forms.o ../generated/adfiles/formsopt.o ../generated/adfiles/formssel.o ../generated/adfiles/main.o ../generated/adfiles/adlc-opcodes.o ../generated/adfiles/output_c.o ../generated/adfiles/output_h.o -lm

Notice that argc in both cases is off in no man's land, and argv has a mysteriously small pointer address for pointing to heap storage.

Turning off -mstackrealign will allow adlc to run crash free, but code elsewhere in SoyLatte -- specifically within JNI -- depends on this flag. Nevertheless, setting a flag that causes a stack realignment should preserve the values of the variables stored on the stack. At least in the case above, this invariant is violated. There appears to be a bug already filed with Apple by Ladd Van Tol for a similar problem. Landon Fuller, the lead developer of SoyLatte, mentioned that this is a known bug, so perhaps there are bug reports into Apple that don't have an associated mailing list submission.