Programmer Personality Test

[ygolo]

It's always better when we finally understand each other (and we're writing in english, kindof).

I am much closer to agreeing with you now.

I think you are misunderstanding the point completely. I'll simply say .. Documentation isn't supposed to explain what the code does .. Documentation is supposed to explain the reasons why the programmer wrote what he did, when he did, and why he did .. Documentation should NEVER explain HOW he did, because the CODE is supposed to explain that part ..

I agree with that statement, mostly. "How" comments should be local to the code doing it (not outside the function or class), and only be used when the "how" is complicated or ambiguous in the code (in which case you may want to reconsider re-writing the code, also).

/*Add 3 to x*/ is a perfect example of bad documentation because it described exactly what the code does .. We both agree that anybody who is a programmer should be able to read the code, and figure that part out.

Documentation is supposed to explain to the next person reading the code, WHY the previous programmer did what he did .. "If all the attributes of the child node check out, then the child node hasn't changed"

Maybe I just needed more context. I undertand that part of the comment, now to be some form of invariant, not simply what the code is doing--A big difference in interpretation.

The Invariant, Pre-Condition, Post-Condition paradigm is incredibly powerful, and a standard they used to teach everyone. I'm not sure when they stopped. A Discipline of Programming

You know I won't get into people of different languages, because I did work on a project which was 100% commented in Japanese, but needless to say it didn't help that the "self-explanatory" variable names and such were also in Japanese. Yes it took a LOT of time reverse-engineering it and in those sort of cases its unavoidable. But that example is a worst case scenario in which case it really makes no difference whether or not you document at all.

But if you had a Japanese-English dictonary and could translate the words, Pre-Condition, Post-Condition, and Invariant, I'd bet you would have been helped out a lot. Since you could look for those standard markers, if the comments were done that way.

I never suggested that documentation is an alternative for proper coding .. However I'm not going to expect the next person who touches my code to expect to read my mind .. I don't document the programming language (C# in this case) .. I document my logic .. Why I wrote what I did ..

They are expected not to read your mind, but read the problem to be solved. I am fairly confident I could go back to code I wrote 9 years ago, refresh my memory of the problem to be solved, and understand what I was doing. The same is true when I read the code of other experience programmers (who also followed the "Discipline"). Again, the pre-condition, post-condition, invariant paradigm allows a programmer to map the problem to be solved (which usually forces invariants across the whole system) to the particular software artifacts you created (which individually will have invariants, if functioning properly).

I think expecting to be "verbally taught" by a former developer of the project is quite naive, since the case is more often than not that the former developer has quit the project. It tends to flow that way.

But that doesn't keep you from "verbally teaching" others about your code.

My audience is composed of fellow or future programmers, and myself, who are incapable of reading my mind and figuring out the logic I used to write the code by simple telepathy, or in my case, am subject gaps in my own memory due to not caring enough about a project to remember why I wrote what I did ..

Again, not mind reading, but problem reading. Experienced programmers use similar Design Patterns to solve similar problems over and over again. These can be fairly easily recognized if implemented in the clasical design patterns in an OO sytem. Design patterns have been around for longer than that term had been coined. There are slight variations, but there is a good reason that design memory is one of the few skills needed by all engineering disciplines. Learn to recognize and use the standard design patterns (at various levels) and you will make your work-life, and the work-lives of those that come after you much easier.

What can I say .. I'm expected to program in the real world whether i like it or not .. And in the real world documentation is required to be in english since more often than not, the paycheck comes from somebody who signs it in english.

Don't use "I work in the real world" as an excuse not to make that world a better place. More documentation does not equal better documentation. Reference the design patterns you used, the invariants of your system, the pre-conditions and post-contitions where appropriate in your "English" documentation. This is not "nerd" speak. These are common words and idioms used by practicing software engineers and programmers, and is handy in whatever language(natural and programming) you are required to use.

By the way, I did google this subject since I was curious what the thought on this topic was and needless to say its a hot debate that isn't solved elsewhere ..

Linux.com :: How to document your code

However thanks to our discussion and my following "research" I found an amazing documenting resource called Doxygen which automatically generates external HTML documentation for your code. It will give summaries and such as well provided they were documented in the first place in the code. I think you should check it out cuz I found it pretty amazing.

Doxygen

I knew about Doxygen. Just following their format is better than "plain english". Because, then I can strip your comments if I find out they are not of much use.

 

[Ghost of the dead horse]

I have programmed since about 5 or 6 years old.

Your programmer personality type is: DHSC

You're a Doer.
You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.

You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.

You work best in a Solo situation.
The best way to program is by yourself. There's no communication problems, you know every part of the code allowing you to write the best programs possible.

You are a Conservative programmer.
The less code you write, the less chance there is of it containing a bug. You write short and to the point code that gets the job done efficiently.


I was absolutely shocked at seeing the last code example with comments more than code. I am trying to get over it.

 

[Falcarius]

DHSB

 

[Bushranger]

I was absolutely shocked at seeing the last code example with comments more than code. I am trying to get over it.

What was silly was defining a function to perform standard addition.



ygolo:

Liberal coding technique is not only about the comments, but also how you space the code, how you group statements together, how you name identifiers and how you make conventions (e.g. design patterns) recognizable.

With modern programmer's editors, long variable and class names do not cost any extra effort, storage space is cheap, programmer time is not.

The best place to be is somewhere between the test's concept of liberal and conservative. Be concise and well structured, make use of common idioms of the language you are using. Be Pragmatic, bit twiddling requires a different approach than application development.

 

[Ghost of the dead horse]

On documentation: I also try to think my "target audience" and place the code so as to facilitate easy reading. I dont always have the time to properly align every space and tab, especially if I write something with notepad and not with an auto-intendating editor.

I find it required to explain advanced mathematics if I sometimes use such in an unexpected place.

 

[Bushranger]

Society as a whole is not where it could be with the aid of computers.
The computer tech. (software and hardware) is not where it could be.
Programmer productivity is not where it could be.
The productivity of you average office worker is not where it could be.

In 20-30 years they will look back at how we used computers and wonder how we ever confused it with productivity.

The best thing that has happened so far in this regard is the introduction of the modern mobile phone. It is not that they are great examples of information technology (the software in particular, stinks), but that they are starting to make people understand that a computer can be more than a box that sits on their desk.

 

[Bushranger]

especially if I write something with notepad and not with an auto-intendating editor.

My sympathies.

 

[ygolo]

What was silly was defining a function to perform standard addition.



ygolo:

Liberal coding technique is not only about the comments, but also how you space the code, how you group statements together, how you name identifiers and how you make conventions (e.g. design patterns) recognizable.

With modern programmer's editors, long variable and class names do not cost any extra effort, storage space is cheap, programmer time is not.

The best place to be is somewhere between the test's concept of liberal and conservative. Be concise and well structured, make use of common idioms of the language you are using. Be Pragmatic, bit twiddling requires a different approach than application development.

Regarding whitespace -- Tabs are evil. Not a big deal in general since I had scripts that reformatted the way I liked or the way coding convention dictated.

Regarding variable names--descriptive, but as concise as possible, and or follows pre-supposed project wide coding standards. Single letters for some loop indexes are fine (unless you are looping over some iterator of special significance). For classic, Floyd's algorithm, for example, i,j, and k are perfectly acceptable. For other math-related algorithms, using conventional, usually single letter variables is also OK.

I wrote programs so that they could be easily read and modified easily. That usually means as short as possible. I made exceptions only when clarity dictated I write longer code, or add extra comments. Peer-review is excellent feedback on what is appropriate (experienced reviewers I knew showed preference for shorter).

 

[ygolo]

In 20-30 years they will look back at how we used computers and wonder how we ever confused it with productivity.

The best thing that has happened so far in this regard is the introduction of the modern mobile phone. It is not that they are great examples of information technology (the software in particular, stinks), but that they are starting to make people understand that a computer can be more than a box that sits on their desk.

Says the man who wants to use an abacus, wants to do all scientific modeling by hand, wants to run expensive real-life experiments whenever possible, will pick his brokerage firm to be the one who enters his trades by hand and goes purely by opinion, wants to fly in only klunky, noisy old planes, drive only cars without curves, wants no part in the knowledge gained in the human-genome project, wants his flight luggage handled like in a third world country, Wants to go back to the old days of standing in line at every gov't office, wants all his financial information in paper form, ......

No, computing isn't about productivity, No. :rolli:

 

[Hoth]

Doer, high level, solo, conservative.

I saw this once:
/*hack put in to fix issues*/

That's a comment I've written many times. Sometimes a quick fix is necessary, and it's best to keep track of where so it can be improved later. Doing a major rewrite creates bugs which you may not want to introduce to a stable release, the hack is safer.

My comments are only notes to myself though, being self-employed. The inability of others to understand it just works as intellectual property protection.

 

[Ghost of the dead horse]

What was silly was defining a function to perform standard addition.

I took it as an example asking for a little suspension of disbelief.

especially if I write something with notepad and not with an auto-intendating editor.

My sympathies.

Part bad workhabits, part that I work so well on the low level, part that I started a new project in new language to me, requiring to open many files in parallel. I didn't like that starting a new instance of the editor took 5 seconds on my machine, so I rather use that. Moreover, I couldn't fix all the annoying features on the editor in 1 minute that I had the patience to browse the options for: opening language function dialogues when putting mouse over a variable, etc..

Only thing that I used the language editor was to find the matching parenthesis in a code that I had not written myself.

The auto-indentendation features in many programming editors dont follow my trail of thought at all, so I much prefer doing my own intendation.

I do think that I would increase my efficiency if I searched for a good editor, used a powerful computer and had the trouble to find the most appropriate settings.

 

[Bushranger]

A simple guide for variable names is to make their length inversely proportional to how often they are used.

 

[ygolo]

Doer, high level, solo, conservative.



That's a comment I've written many times. Sometimes a quick fix is necessary, and it's best to keep track of where so it can be improved later. Doing a major rewrite creates bugs which you may not want to introduce to a stable release, the hack is safer.

My comments are only notes to myself though, being self-employed. The inability of others to understand it just works as intellectual property protection.

I hope you have a good revision control system.

Systems that have very many small bugs that constantly need patching is also a way to ensure job security I guess.

Web code, I suppose, doesn't need to be very robust (or even correct) unless you are dealing with peoples financial data (If your attitude is like that for financial transactions also, I hope you get you a** sued). Despite the strong language, no offense is intended .

 

[ygolo]

What types of software were/are you good/bad at?

A sub-topic to flesh out the test taking.

I tested PHTC.

Good at:Creating "Virtual Machines", distributed systems, higher-level programming interfaces for other programmers.

I liked having to plan stuff out, to create little software machines, that enhance/upgrade the "magic" of computing.


Bad at:GUIs.

They were time-traps for me. I spent forever trying to make things look and feel right, and would often spend a lot of time trying to implement features that I would later decide didn't look right, and re-do it. I think GUIs are better left to Industrial Designers or Artists. I'd rather write a toolkit for IDs with a bit of coding experience to use. Perhaps one of them could then design a GUI to interface with my toolkit, at which point all IDs could then use it.

 

[Bushranger]

Says the man who wants to use an abacus,

Pocket calculator.

wants to do all scientific modeling by hand,

Scientific calculator, or specialist software. May need some programming and math ability.
Interface: Terminal.

wants to run expensive real-life experiments whenever possible,

Proper simulation requires specialist software and hardware. Not to mention specialist knowledge.
Interface: Terminal.

will pick his brokerage firm to be the one who enters his trades by hand and goes purely by opinion,

Talk to your modern brokerage firm through the telephone or access their systems through a Terminal.

wants to fly in only klunky, noisy old planes,

Avionics are all nicely hidden away. [1]

drive only cars without curves,

The designers may actually need the speed of a desktop for this task.

wants no part in the knowledge gained in the human-genome project,

Specialist gene sequencers. [1]

wants his flight luggage handled like in a third world country,

Industrial electronics [1]

Wants to go back to the old days of standing in line at every gov't office,

Staff use terminals, hard lifting done elsewhere.

wants all his financial information in paper form, ......

That may not be such a bad idea.

No, computing isn't about productivity, No. :rolli:

The most productive scenarios above, (marked [1]) have all had the need of an invasive interface eliminated. In the general office environment a computer is almost as big a time sink as it is a help. The word processor for example. It has eliminated the typing pool, but also requires the user to spend a lot of time acting like a typesetter.

Ideally, the computer would be almost non present. The white board would double as a display, so would the poster on the wall. Your mail and address book would be available on any electronic surface at hand. When doing code review, you could pass code and design documentation around by pointing and tapping on surfaces, annotate it and pass it back, all without paper.

Yes, things are better now than they used to be, but we still have a long way to go.

 

[ygolo]

Pocket calculator.

Do you do your taxes with a pocket calculator? I can go through mortgage info., stock and options trades, renting out rooms, school loans, charities, everything by importing data from the appropriate parties into TurboTax and be done in under an hour for less money that for paying a person (who lets face it, will be doing the same thing)

Scientific calculator, or specialist software. May need some programming and math ability.
Interface: Terminal.

So? We live in a modern economy. Everyone is a specialist. Some specialists are called scientists and engineers. Any idiot can program if he/she is patient enough. The use of the computer is the normal part of training. I don't see your point. Still a big productivity improvement.

Proper simulation requires specialist software and hardware. Not to mention specialist knowledge.
Interface: Terminal.

Again, everyone is a specialist. Creating simulations is now part of the regular training (instead of doing paper complicated paper calcs.)

Talk to your modern brokerage firm through the telephone or access their systems through a Terminal.

What is your point about a terminal? My brokerage only has limited phone service. They are a lot cheaper than full-service firms, and they are just as good.

If you think speed of entry of your trade is irrelevant in a modern market you are sorely mistaken.

Avionics are all nicely hidden away. [1]

The designers may actually need the speed of a desktop for this task.

Specialist gene sequencers. [1]

Industrial electronics [1]

All these things are still computers. There are already a lot more of them than there or "Desktops". What's your point?

Staff use terminals, hard lifting done elsewhere.

The heavy-lifting machines are also computers. Computing never has been, and never will be confined to your desktop. I don't see your point.

That may not be such a bad idea.

Again, how long do you take to do your taxes. If you have Quicken, you can import all that data directly into TurboTax, other financial info. can also be imported into TurboTax.

The most productive scenarios above, (marked [1]) have all had the need of an invasive interface eliminated. In the general office environment a computer is almost as big a time sink as it is a help. The word processor for example. It has eliminated the typing pool, but also requires the user to spend a lot of time acting like a typesetter.

Are you seriously saying that a users time typesetting is less productive than having a whole typing pool?

Ideally, the computer would be almost non present. The white board would double as a display, so would the poster on the wall. Your mail and address book would be available on any electronic surface at hand. When doing code review, you could pass code and design documentation around by pointing and tapping on surfaces, annotate it and pass it back, all without paper.

Yes, things are better now than they used to be, but we still have a long way to go.

I actually agree with your ideal. That's what I was saying originally. Productivity is not nearly as good as it could be.

I am not a lick closer to thinking that computing have nothing to do with productivity.

 

[Hoth]

I hope you have a good revision control system.

Systems that have very many small bugs that constantly need patching is also a way to ensure job security I guess.

Web code, I suppose, doesn't need to be very robust (or even correct) unless you are dealing with peoples financial data (If your attitude is like that for financial transactions also, I hope you get you a** sued). Despite the strong language, no offense is intended .

Revenue security comes from giving customers what they want, which for mine at least is for the problem they've just reported to be fixed immediately so they can get on with what they're doing. That's what a quick hack will do. A revision control system seems overkill for a one-person project, no need (GNU diff is always at hand if needed). I do usually have a stable and experimental series in progress concurrently though, so I may do the more elegant fix in experimental but the safer one in stable.

Just because one would do things one way writing a banking application doesn't mean one should do them that way for everything. Likewise what one does as part of a team will differ from what one does solo. There's no one right way... though there is a way I prefer, which draws me to sell the sort of products (PHP forum/directory/kb/gallery) which suit my preference.

 

[ygolo]

Revenue security comes from giving customers what they want, which for mine at least is for the problem they've just reported to be fixed immediately so they can get on with what they're doing. That's what a quick hack will do. A revision control system seems overkill for a one-person project, no need (GNU diff is always at hand if needed). I do usually have a stable and experimental series in progress concurrently though, so I may do the more elegant fix in experimental but the safer one in stable.

Just because one would do things one way writing a banking application doesn't mean one should do them that way for everything. Likewise what one does as part of a team will differ from what one does solo. There's no one right way... though there is a way I prefer, which draws me to sell the sort of products (PHP forum/directory/kb/gallery) which suit my preference.

Yes. I've had to put in quick hacks like that to produce a quick fix fix wehen dealing with poorly a design architecture we inherited (I hated doing it but there weren't many options given the time constraints). Needless to say that things became obsolete rather quickly in that system.

In well designed systems quick fix in code ought not be necessary, just a fix in config. files or data.

I have come to believe there is very little difference these days form those who call themselves programmers, and users of programs. A person who opens word and creates a document is "programming" their term paper for instance. Or a student using a spreadsheet to do calcs. is "programming" the spreadsheet. I think a lot of web-programming comes close to that. These things are really better left to artists and industrial designers with a little bit of coding ability, I think (this is not to be-little them, the skill set is not something I posses). Serious coding paradigms applied to these types of things would be overkill, I agree.

 

[Hoth]

Yeah right, find an artist with a firm grasp of object oriented methodology, recursion and abstraction... the basic skills of computer science are far from basic to artists. Find an artist capable of building an extensible architecture which allows the same source code to run five seemingly different sorts of scripts. Ask an artist to write 50,000 lines of code and evolve a system over 5 years in a rapidly changing environment without it succumbing to obsolescence, adding thousands of features.

Your artist-who-dabbles-in-code may be able to throw together something that looks vaguely like the requirements, sure, but it'll end up being inflexible and impractical to maintain. There's a big difference between a quick and dirty web app (which does have a niche, such as when limited to a particular site with reason to believe there won't be changes needed) and one which can stand the test of time.

It's quite true that web apps don't need the same sort of education -- years spent learning assembly language, C and the like are wasted. But they certainly do need to be intelligently designed -- which doesn't mean designed the same way as a desktop app, that's part of being intelligent. By sticking to your one true way in a non-applicable context you'd end up with an unintelligent design dooming the app to failure. Since it's such easy stuff which you spit on, what are you doing slaving away for a company when you have the skills to dominate the entire web raking in untold cash?

In the real world, things are complicated. You can make your design as perfectly beautiful as you want, that's not going to make any difference when someone installs the software on a server configuration which you're unaware of. Your approach of refusing to fix the problem until you find out the source will leave the customer quite frustrated, it's simply irresponsible sometimes to not eliminate the symptom before the long process of tracking down the disease. Perhaps you have control of the hardware/software environment your code needs to run in, but most of us don't.

Which brings up a famous example -- the linux kernel is filled with apparently inelegant hacks, but these are necessary for obscure configurations (even hardware which may not follow standards or specs properly), and people who submit patches to simplify it are usually breaking something in ways that are very difficult to track down. If you feel the kernel is ghastly pile of amaturish artist goo, let's see you take your own kernel to the market.

I've long been aware that there are programmers who aren't actually interested in solutions to problems, but are instead self-absorbed with their ideas of intrinsic source beauty to an unhealthy extent. This sort will spend a year cleansing and purifying inconsquential code, and will refuse to admit that the user has errors because they don't show up in a perfect environment. While these people have some limited areas of usefulness, they're usually a productivity drain.

 

[ygolo]

Yeah right, find an artist with a firm grasp of object oriented methodology, recursion and abstraction... the basic skills of computer science are far from basic to artists. Find an artist capable of building an extensible architecture which allows the same source code to run five seemingly different sorts of scripts. Ask an artist to write 50,000 lines of code and evolve a system over 5 years in a rapidly changing environment without it succumbing to obsolescence, adding thousands of features.

Your artist-who-dabbles-in-code may be able to throw together something that looks vaguely like the requirements, sure, but it'll end up being inflexible and impractical to maintain. There's a big difference between a quick and dirty web app (which does have a niche, such as when limited to a particular site with reason to believe there won't be changes needed) and one which can stand the test of time.

It's quite true that web apps don't need the same sort of education -- years spent learning assembly language, C and the like are wasted. But they certainly do need to be intelligently designed -- which doesn't mean designed the same way as a desktop app, that's part of being intelligent. By thickheadedly sticking to your one true way in a non-applicable context you'd end up with an unintelligent design dooming the app to failure. Since it's such easy stuff which you spit on, what are you doing slaving away for a company when you have the skills to dominate the entire web raking in untold cash?

Wow I seem to have offended without intending to again. I believe we are in "violent agreement". I am certainly aware that time constraints require us to make quick fixes to satisfy customers. I am also aware that web-applications need to be intelligently designed. If you can make a mere 50K lines of code last for 5 years for all the problems you faced, I am certainly impressed. I was simply stating that what I knew as "programming" is quite different from what a lot of different situations now that are called programming.

Still, I think you are vastly underestimating "the artist-who-dabbles-in-code". I know someone who didn't graduate high-school (got GED though) who (though not officially an artist) really fits the artist style of personality(judging from his demeanor and his friends, who are artists). He spends his days using php (learning Ruby), and works for an automobile website. Form what I understand, he does a good job, and is the sole coder. This type of person is what I meant by artist/industrial designer with some coding skills. I hope you don't take offense to this. If you do, let me know why, because it is hard for me to fathom. OO, recursion, and abstraction are really simple concepts. That is the reason they are used --to allow our feeble human minds to deal with giant logical structures in simpler ways. There is no reason an artist would not be able to understand these concepts.

As far as me "spitting-on" something, or the "dominating the web, raking in untold cash", I assume it to be simply hyperbole based your assumption that I think I am better than you in some way (I don't. Rest assured). I was simply trying to be convincing in previous posts, not belittling.

In the real world, things are complicated. You can make your design as perfectly beautiful as you want, that's not going to make any difference when someone installs the software on a server configuration which you're unaware of. Your approach of refusing to fix the problem until you find out the source will leave the customer quite frustrated, it's simply irresponsible sometimes to not eliminate the symptom before the long process of tracking down the disease. Perhaps you have control of the hardware/software environment your code needs to run in, but most of us don't.

Please don't assume that I don't work in the "Real World" or that somehow you have more complicated situations to work with than I do (You may have. But it is an assumption, none-the-less). I don't have complete control over the hardware/software environments I work on (most of them don't even have OS's) and the embedded systems could have had all sorts of properties I was unaware of (I am a hardware guy now, so I speak in past tense).

I do not rigidly refuse to fix customer problems. In fact, I am (still) usually the one called on to do some of these quick fix, type hacks for drivers, embedded-code etc. Sometimes (much more often than people assume) tracking down the root contradiction is the simplest and quickest way to solve the customer problem (with the added benefit, that it keeps new similar/related problems from coming up).

Also, don't under-estimate the power of aesthetics in logical situations, it does wonders for solving problems you haven't thought of. It is a means of problem avoidance. As the saying goes, "an ounce of prevention, is worth a pound of cure." Beauty in logic comes from the appropriateness in theory (everyone has a theory, whether they are aware of it or not) to the situation as well as internal coherence. Both appropriateness and coherence lead to problem avoidance.

Which brings up a famous example -- the linux kernel is filled with apparently inelegant hacks, but these are necessary for obscure configurations (even hardware which may not follow standards or specs properly), and people who submit patches to simplify it are usually breaking something in ways that are very difficult to track down. If you feel the kernel is ghastly pile of amaturish artist goo, let's see you take your own kernel to the market.

Have thousands of people work on something for free. Give it away for free, and see if does not have any sort of disruptive effect on a market where competitive products are expensive. Although Torvalds is well of, Gates is much better off.

Linux's hacks were not necessary, and some of the decisions made are not rightly called hacks. You can search for the discussion/"flame war" Torvalds and Taunenbaum (creator of MINIX which Linux is based off of) had about design choices. The discussion is interesting.

I've long been aware that there are programmers who aren't actually interested in solutions to problems, but are instead self-absorbed with their ideas of intrinsic source beauty to an unhealthy extent. This sort will spend a year cleansing and purifying inconsquential code, and will refuse to admit that the user has errors because they don't show up in a perfect environment and the beautiful code cannot be tarnished. While these people have some limited areas of usefulness, they're usually a productivity drain or an outright danger to the project.

I think you may be unfairly characterizing some of the programmers motives. Time constraints are always an issue, but I suspect those you accuse of being "self-absorbed" may simply be tired of solving the same problem over and over again, simply because the "fixes" were poor. This quite frankly, is a drain on project resources also.

Adamantly sticking to Ideals when not possible is certainly an issue, but so is not having Ideals with the excuse of having to deal with the "real world". There is no such thing as the real world. Just a lie you've got to rise above (No. I'm not a Hootie fan).

I hope we can continue this discussion without resorting to personal put-downs.