And even then I don't believe you've ever shipped code with no bugs.
Very intersting reply, and probably very good points for those who are used to a mor traditional form of programming... But this is the key right here, in your last sentence. Most people just don't believe it's possible to ship without bugs whereas I and the other developers where I work wonder how it's possible to ship a product WITH bugs. I have tried to explain too often to others in my profession, and I always get this same response in the end... but the fact remains that we've been developing for years, we introduce features on time, and we don't ship bugs. In fact, bugs in non-production code base are almost unheard of. You don't check in code unless it's fully tested, period. All without any formal design and without any documentation.
Basically, all we do is test everything, assume that the current code-base is always production-ready. We check in code every 5-10 minutes, taking baby steps. We refactor everything, constantly, almost to a fault. We write the tests before we write code, and we run the tests before we check in. And the end result is... it works. Simple as that.
I wish others would give it a try, but nobody wants to chance it. You know, it's been three years since I used a debugger? I think I used a printout (for testing putposes) for the first time in three months last week.
Good context for modular and reusable code include things like the the purpose for class. Is the class a custom GUI control, a data object, a control/worker object? What does the data represent? What does the worker object do? What does your control allow users to do?
Of course, that's modular-level, but the same must be done on the method level and lower. What does this method do? Does it animate a portion of the control in some way? Does it maniplate the data to a new state? What do the arguments represent? Is x in screen coordinates, container/control coordinates, 3d coordinates?
None of this information can be readily obtained from source code or test cases without careful analysis, and even then a deep understanding of the underlying APIs is necessary, which of course requires, you guessed it, the same context.
What seems to not make it across is that anything that cannot be expressed in code cannot be expressed in documentation either.
"Is x in screen coordinates, container/control coordinates, 3d coordinates?" can be addressed "in code" as simply as:
int xOnScreen = 5; int xFromContainer = 7;
But neither of which will be any more "true" in documentation or code form unless you have a test showing you take X out of the graphics plane, or out of the container, etc, and using that X in the method. Once you have that, then what good is the documentation except sucking time away from programmers?
Good tests should indeed show the code-context in which it is intended to be used. Good functional tests will include tests from the user-perspective as well, showing how a user will interact with the system, providing you all the context you need to mantain and use the code.
As long as you can show how the user will use the system, and show that the answers that he gets are the ones you expect, for every feature that the system is designed for, what more do you need?
In 21 years of coding, I have yet to see a project so simple that comments were not required. If you don't know how to write a comment, you have no business coding. If you cannot take the time to comment, you have no business coding. If you think comments are stupid, you have no business coding.
In your 21 years have you ever seen a project built and run for several years, adding new features every week, never slip a single deadline, all without a single bug of any kind making it into production? I've two such projects, and both of them were using XP methedologies with less than four or five well-placed comments in the entire code-base.
No, thats ABSOLUTELY what documentation tells you. It tells you what a function is for, and what the expected output is.
Does your function exist for a single purpose? Is it ever going to be reused? The problem with saying what a function is FOR (what you see in documentation) as opposed to what it DOES (which you see in code and tests) is that it assumes many thing that may or may not be correct. It also will breed duplication, as you may implement one method fome one "purpose" and another method for another "purpose" where actually they are exactly the same code, just with different names.
Your test cases should be documented as well, wether they be automatic or not- why was this test case chosen (corner case? random pick? check some bug we just fixed and want to watch out for in the future?). If your documentation is NOT telling you this, you and your team fail.
Easily solved with Good Names... testDoFooCornerCase(), testDoFooRandomlyChosenVariables(), testDoFooFailsWhenValueIsNineBug()
Assumptions change, reasoning changes, algorithms are refined, thrown out, and completely rewritten from scratch every day. And when this happens, the FIRST thing you do is change the documentation to reflect that. If you don't, you aren't doing your job.
Well, the first thing I wonder is what kind of state is your documentation in when you've just changed it to reflect your new assumptions but haven't gotten around to fixing the code yet? Which do you believe, the documentation, or the code, both of which are out of sync?
But most importantly, are you expecting every developer to a) memorize all documentation, Chapeter and Verse or B) go through every page of the documentation before implementing new assumptions? Because if you plan to change the documentation when you change your reasoning, you'll have to go through every piece of documentation to see if it has any relation to the change you are goign to implement. With a full suite of automated tests, you can make those changes where you assume they should go, and run the tests and see what other part break... With human-readable documentation you'll have to check it all manually, and carefully, because who knows what dependancies are there that you never suspected?
If you just trust the documentation you will be in a FAR more dangerous position that someone who is forced, by agile methods, to go back, constantly, to the source of the information and get the real, up-to-the minute details.
If you work someplace that is so sloppy you get into the positions you claim, maybe. But if your workplace is that sloppy, agile methods will be even worse-if you have devs who are so incompetent that they can't update plain text, I shudder to think of what their code looks like.
As I mentioned above, it has nothing to do with being sloppy... Sure, you can update the bits of documentation that you know about, but you can't know all the constantly changing documentation that is there, without a huge non-productive time-sink... And if you think you work somewhere that does this well, I suggest you take a closer look at your code base. There are guaranteed to be out-of-date comments in whatever code-base you are currently working on, it's unavoidable, it's pure entropy you're battling against.
Unit tests are not design. They are not documentation. They can help a well designed and documented program by finding bugs early, and thus are a good thing. But if you make me pick one to drop, it'd be the unit tests in an instant.
Unit tests (and funtional/integration tests, which are really just larger scoped "unit" tests) are absolutly design, if you want them to be. They are the BEST design, in fact, because they are design that can't be incompatible with the code-base, and a design that can prove all of your assumptions. They are proof of quality, or proof of the lack thereof. Writing testable code even forces you to use good encapsulation and proper obje
of course, all of this only really applies to junior developers. If you stick with the rule "simpler, shorter is better" you can almost never go wrong. Once you find out where you can go wrong, you may not need that rule any more.
He didn't believe in submitting the tests with the program itself or sharing them with other developers, so no one could ever understand what he was doing.
Come on, there is no way any sort of documentation could have helped this kind of problem... If he isn't willing to submit his tests, what chance is there he'll submit his documentation?
And here is one of the reasons the agile method people get so much wrong. Automatic tests are not documentation, by any means. They do not prove that code is correct, or bug free. A test proves that for some input, a certain output was generated. Thats it. It doesn't explain why that output was generated, why that case was important, what other cases might be important, how those test cases were chosen, or explain the logic used to generate that output. For that you need documentation- either in code or out of code. Automatic tests have their place, but they are not equal to design or documentation. Any place that uses them as such is producing shitty software which will bite them on the ass when the original devs leave.
It sounds like the agile developrs you have run into aren't doing thier jobs particularly well, or perhaps not understanding thier systems very well... Automated tests tell you exactly what is there, nothing more. It tells you, as you said, for inputs X, Y and Z you get outputs A, B, and C. However, if they are doing thier tests correctly, then they are basing those tests directly off of user/customer requirements, so what more do you need? If a custormer needs somethng that produces X, then proving that the method/class/system produces X, then it doesn't matter how it arrived at that position. The test doesn't tell you "why", but what use is this information?
All the documentation in the world can do is tell you, at a particular place in time, what somebody wishes would exist, or thinks does exist. Documentation can absolutly NOT tell you "why that output was generated, why that case was important, what other cases might be important, how those test cases were chosen, or explain the logic used to generate that output". It can tell you what somone assumes or knows at the point that it is written, but who knows about NOW? Assumptions change, reasoning changes, algorithms are refined, thrown out, and completely rewritten from scratch every day. In order to learn the "truth" of the matter that you have to go back into the code itself, to the developers, to the customers.
If you just trust the documentation you will be in a FAR more dangerous position that someone who is forced, by agile methods, to go back, constantly, to the source of the information and get the real, up-to-the minute details.
The problem, I guess, is trying to describe agile methods to a culture that simply is not prepared to change enough to accept them. Agile development is a complete restucturing of information flow, it's systemic, not just another guidebooks for the programmers to follow. If it's not being reflected in the entire organization from the coders themselves, to the sales department, to the marketroids, to the top brass, then it will quickly be "proven" a house of cards and you'll be very unimpressed with the results. It's a great system, but not one to implement half-heartedly.
For example, I've sometimes found myself refactoring code from a bunch of sort, tightly-coupled routines into one single one to create better encapsultion.
Good job! Excellent first step. But are you finished? I'm sure you could find a way to reduce that complexity even further if you spent more time one in.
In my experience, code is very fluid. It can grow and shrink over time, and almost exclusivly, the smaller it becomes, the more readable it becomes... And the more REUSABLE it becomes! The more you reuse code, the fewer overall bugs you will have, the easier it is to continue coding, and the better your code gets.
Even if you're the best normalizer/refactorer (is "refactorer" a word?) in the world, you had better explain what a function or method or class or aspect or (etc..) does, how it's used, and what the expected results are, or you have made code that is a nightmare to maintain.
That is what your automated tests are for! No comment in the world is better than a test showing exactly how a method works, what expected inputs and outputs are, and *proving* that what you think it should do is what it actually does. The great thing about proper automated tests, they can NEVER go out of date and still pass.
For significantly complicated projects, those programmers don't exist. If you think commenting your code is an unreasonable job requirement, I will fire you.
I have yet to see a project, in 11 years of coding, that is so complex that comments are a REQUIREMENT. If you don't know how to refactor, and how to reduce your bloated thousand-line long methods into a series of simple to understand 10-line long methods, you still have much to learn about good code.
Basically, treat comments like you should credit card debt. Use it rarely, only when you really have to, and try to get rid of it as soon as possible. If you can write the code in a clearer way, one that does not need comments, then do so, ASAP.
In a perfect world, the ONLY thing that you want to have comments are APIs into closed code (some outward-facing API that you aren't willing to give the source to). Everything else should only have comments when the code is too complex to be understood by reading it... and that code should be first in line for refactoring.
And never NEVER write comments like "the doFoo(Stringx, String y) does foo by taking string x and string y as parameters". This is useless, clutters up everything, and makes the important comments less visible.
I don't see how... Basically autocomplete isn't going to work when the program logic can be changed at runtime.
def missing_method(name, *args)
if (random_boolean())
do_a(args[0], args[1]);
else
do_b();
end end
Now when I call "string".foo(), it will eiteh rhave just enough parameters, or not enough, depending on, at runtime, if random_boolean returns true or false;
The only serious prank I ever did ended up as a one-liner in Time magazine. I has set up an elaborate system of personalities on all the "What it IT?" type websites (people trying to figure out what the segway was before it was revealed). It was full of secret insiders posting information, other "real" insiders negating what was said and posting the slightly more believable "truth", fake PR people from Dean Kamen's companies playing down the hype, invisible agents from major industrialists and venture capitalists offering bribes for more information, with cryptic responses, janitors who happened to "see something", bitter recriminations flying back and forth between both sides of my "regulars" and "hoaxers"... Man, it was great fun. In the end I had thousands, if not more, convinced it was a kind of flying surfboard looking thing that used very little power and would alter EVERYTHING.
Even in the wee hours of the morning, after Time and Newsweek had published thier international copy on the web, people were still convinced that it was all part of a HUGE elaborate conspiracy to keep the true nature of IT concealed until the very last second.
I am a big ruby fan, and I know it's so dynamic that, other than syntax hilighting, you can't really be sure, except at runtime, what a particular method is going to do, or it will even exist. If python is as dynamic as ruby, I suspect the best you can find will be something that KINDA works, not not in the way that a static language IDE will work.
Camille Paglia, in her book Sexual Personae, maintains that at the core, women represent nature, and man strives to control nature, thus he strives to control woman. "The primary image [of women in media] is the femme fatal, the woman fatal to man," she explains. "Woman's beauty is a compromise with her dangerous archetypal nature. It gives the eye the comforting illusion of the intellectual control over nature" (13-17). With this assertion, it is apparent that men's domination of female body image is intertwined with his need to control the feminine.
No.... That is called reading WAY THE FUCK too much into it. Let me spell it out for you: Men like boobies. Men design games. Thus all female characters in all games have boobs nearly as big as my wife's. That is all the logic there is to it.
Every ad next to yours reduces the impact of your ad geometrically. One ad is effective. One ad in a sea of thousands no so...
SO, the TRUE turning point in advertizing will be when ad companies start paying for BLANK space on all the billboards near thier ads. Imaging just a single ad on the road between here and Nantuckett, instead of 300... Imagine two minutes of black screen followed by a single ad, followed by two more minutes of black... THAT ad will have serious impact!
I'd much rathar have a product that is unfinished, and gets slowly finished in a way that the featured that get implemented are those that users actually need and want than a "finished" product that has features that a marketing department decides that I need.
Not necessarily; profit is one of those microeconomics things that is a curve. If you're on the top half of the curve for a specific product, lowering the price of a product will increase profits because volume goes up faster than unit-profit goes down.
You seem to imply that the recording industry has the slightest grasp of economics...
Slashdot Mirror
And even then I don't believe you've ever shipped code with no bugs.
Very intersting reply, and probably very good points for those who are used to a mor traditional form of programming... But this is the key right here, in your last sentence. Most people just don't believe it's possible to ship without bugs whereas I and the other developers where I work wonder how it's possible to ship a product WITH bugs. I have tried to explain too often to others in my profession, and I always get this same response in the end... but the fact remains that we've been developing for years, we introduce features on time, and we don't ship bugs. In fact, bugs in non-production code base are almost unheard of. You don't check in code unless it's fully tested, period. All without any formal design and without any documentation.
Basically, all we do is test everything, assume that the current code-base is always production-ready. We check in code every 5-10 minutes, taking baby steps. We refactor everything, constantly, almost to a fault. We write the tests before we write code, and we run the tests before we check in. And the end result is... it works. Simple as that.
I wish others would give it a try, but nobody wants to chance it. You know, it's been three years since I used a debugger? I think I used a printout (for testing putposes) for the first time in three months last week.
It's just a different level of coding.
Good context for modular and reusable code include things like the the purpose for class. Is the class a custom GUI control, a data object, a control/worker object? What does the data represent? What does the worker object do? What does your control allow users to do?
Of course, that's modular-level, but the same must be done on the method level and lower. What does this method do? Does it animate a portion of the control in some way? Does it maniplate the data to a new state? What do the arguments represent? Is x in screen coordinates, container/control coordinates, 3d coordinates?
None of this information can be readily obtained from source code or test cases without careful analysis, and even then a deep understanding of the underlying APIs is necessary, which of course requires, you guessed it, the same context.
What seems to not make it across is that anything that cannot be expressed in code cannot be expressed in documentation either.
"Is x in screen coordinates, container/control coordinates, 3d coordinates?" can be addressed "in code" as simply as:
int xOnScreen = 5;
int xFromContainer = 7;
But neither of which will be any more "true" in documentation or code form unless you have a test showing you take X out of the graphics plane, or out of the container, etc, and using that X in the method. Once you have that, then what good is the documentation except sucking time away from programmers?
Good tests should indeed show the code-context in which it is intended to be used. Good functional tests will include tests from the user-perspective as well, showing how a user will interact with the system, providing you all the context you need to mantain and use the code.
As long as you can show how the user will use the system, and show that the answers that he gets are the ones you expect, for every feature that the system is designed for, what more do you need?
In 21 years of coding, I have yet to see a project so simple that comments were not required. If you don't know how to write a comment, you have no business coding. If you cannot take the time to comment, you have no business coding. If you think comments are stupid, you have no business coding.
In your 21 years have you ever seen a project built and run for several years, adding new features every week, never slip a single deadline, all without a single bug of any kind making it into production? I've two such projects, and both of them were using XP methedologies with less than four or five well-placed comments in the entire code-base.
No, thats ABSOLUTELY what documentation tells you. It tells you what a function is for, and what the expected output is.
Does your function exist for a single purpose? Is it ever going to be reused? The problem with saying what a function is FOR (what you see in documentation) as opposed to what it DOES (which you see in code and tests) is that it assumes many thing that may or may not be correct. It also will breed duplication, as you may implement one method fome one "purpose" and another method for another "purpose" where actually they are exactly the same code, just with different names.
Your test cases should be documented as well, wether they be automatic or not- why was this test case chosen (corner case? random pick? check some bug we just fixed and want to watch out for in the future?). If your documentation is NOT telling you this, you and your team fail.
Easily solved with Good Names... testDoFooCornerCase(), testDoFooRandomlyChosenVariables(), testDoFooFailsWhenValueIsNineBug()
Assumptions change, reasoning changes, algorithms are refined, thrown out, and completely rewritten from scratch every day.
And when this happens, the FIRST thing you do is change the documentation to reflect that. If you don't, you aren't doing your job.
Well, the first thing I wonder is what kind of state is your documentation in when you've just changed it to reflect your new assumptions but haven't gotten around to fixing the code yet? Which do you believe, the documentation, or the code, both of which are out of sync?
But most importantly, are you expecting every developer to a) memorize all documentation, Chapeter and Verse or B) go through every page of the documentation before implementing new assumptions? Because if you plan to change the documentation when you change your reasoning, you'll have to go through every piece of documentation to see if it has any relation to the change you are goign to implement. With a full suite of automated tests, you can make those changes where you assume they should go, and run the tests and see what other part break... With human-readable documentation you'll have to check it all manually, and carefully, because who knows what dependancies are there that you never suspected?
If you just trust the documentation you will be in a FAR more dangerous position that someone who is forced, by agile methods, to go back, constantly, to the source of the information and get the real, up-to-the minute details.
If you work someplace that is so sloppy you get into the positions you claim, maybe. But if your workplace is that sloppy, agile methods will be even worse-if you have devs who are so incompetent that they can't update plain text, I shudder to think of what their code looks like.
As I mentioned above, it has nothing to do with being sloppy... Sure, you can update the bits of documentation that you know about, but you can't know all the constantly changing documentation that is there, without a huge non-productive time-sink... And if you think you work somewhere that does this well, I suggest you take a closer look at your code base. There are guaranteed to be out-of-date comments in whatever code-base you are currently working on, it's unavoidable, it's pure entropy you're battling against.
Unit tests are not design. They are not documentation. They can help a well designed and documented program by finding bugs early, and thus are a good thing. But if you make me pick one to drop, it'd be the unit tests in an instant.
Unit tests (and funtional/integration tests, which are really just larger scoped "unit" tests) are absolutly design, if you want them to be. They are the BEST design, in fact, because they are design that can't be incompatible with the code-base, and a design that can prove all of your assumptions. They are proof of quality, or proof of the lack thereof. Writing testable code even forces you to use good encapsulation and proper obje
of course, all of this only really applies to junior developers. If you stick with the rule "simpler, shorter is better" you can almost never go wrong. Once you find out where you can go wrong, you may not need that rule any more.
Automated tests do not grant context. Only non-structured narrative documentation can fully explain the purpose and use of a block of code.
Do you want your code to me modular and reusable? If so, what good is context?
He didn't believe in submitting the tests with the program itself or sharing them with other developers, so no one could ever understand what he was doing.
Come on, there is no way any sort of documentation could have helped this kind of problem... If he isn't willing to submit his tests, what chance is there he'll submit his documentation?
And here is one of the reasons the agile method people get so much wrong. Automatic tests are not documentation, by any means. They do not prove that code is correct, or bug free. A test proves that for some input, a certain output was generated. Thats it. It doesn't explain why that output was generated, why that case was important, what other cases might be important, how those test cases were chosen, or explain the logic used to generate that output. For that you need documentation- either in code or out of code. Automatic tests have their place, but they are not equal to design or documentation. Any place that uses them as such is producing shitty software which will bite them on the ass when the original devs leave.
It sounds like the agile developrs you have run into aren't doing thier jobs particularly well, or perhaps not understanding thier systems very well... Automated tests tell you exactly what is there, nothing more. It tells you, as you said, for inputs X, Y and Z you get outputs A, B, and C. However, if they are doing thier tests correctly, then they are basing those tests directly off of user/customer requirements, so what more do you need? If a custormer needs somethng that produces X, then proving that the method/class/system produces X, then it doesn't matter how it arrived at that position. The test doesn't tell you "why", but what use is this information?
All the documentation in the world can do is tell you, at a particular place in time, what somebody wishes would exist, or thinks does exist. Documentation can absolutly NOT tell you "why that output was generated, why that case was important, what other cases might be important, how those test cases were chosen, or explain the logic used to generate that output". It can tell you what somone assumes or knows at the point that it is written, but who knows about NOW? Assumptions change, reasoning changes, algorithms are refined, thrown out, and completely rewritten from scratch every day. In order to learn the "truth" of the matter that you have to go back into the code itself, to the developers, to the customers.
If you just trust the documentation you will be in a FAR more dangerous position that someone who is forced, by agile methods, to go back, constantly, to the source of the information and get the real, up-to-the minute details.
The problem, I guess, is trying to describe agile methods to a culture that simply is not prepared to change enough to accept them. Agile development is a complete restucturing of information flow, it's systemic, not just another guidebooks for the programmers to follow. If it's not being reflected in the entire organization from the coders themselves, to the sales department, to the marketroids, to the top brass, then it will quickly be "proven" a house of cards and you'll be very unimpressed with the results. It's a great system, but not one to implement half-heartedly.
For example, I've sometimes found myself refactoring code from a bunch of sort, tightly-coupled routines into one single one to create better encapsultion.
Good job! Excellent first step. But are you finished? I'm sure you could find a way to reduce that complexity even further if you spent more time one in.
In my experience, code is very fluid. It can grow and shrink over time, and almost exclusivly, the smaller it becomes, the more readable it becomes... And the more REUSABLE it becomes! The more you reuse code, the fewer overall bugs you will have, the easier it is to continue coding, and the better your code gets.
Of course they will, if they want to use it properly. Why assume somone will read comments but not read the tests?
Even if you're the best normalizer/refactorer (is "refactorer" a word?) in the world, you had better explain what a function or method or class or aspect or (etc..) does, how it's used, and what the expected results are, or you have made code that is a nightmare to maintain.
That is what your automated tests are for! No comment in the world is better than a test showing exactly how a method works, what expected inputs and outputs are, and *proving* that what you think it should do is what it actually does. The great thing about proper automated tests, they can NEVER go out of date and still pass.
For significantly complicated projects, those programmers don't exist. If you think commenting your code is an unreasonable job requirement, I will fire you.
I have yet to see a project, in 11 years of coding, that is so complex that comments are a REQUIREMENT. If you don't know how to refactor, and how to reduce your bloated thousand-line long methods into a series of simple to understand 10-line long methods, you still have much to learn about good code.
Basically, treat comments like you should credit card debt. Use it rarely, only when you really have to, and try to get rid of it as soon as possible. If you can write the code in a clearer way, one that does not need comments, then do so, ASAP.
In a perfect world, the ONLY thing that you want to have comments are APIs into closed code (some outward-facing API that you aren't willing to give the source to). Everything else should only have comments when the code is too complex to be understood by reading it... and that code should be first in line for refactoring.
And never NEVER write comments like "the doFoo(Stringx, String y) does foo by taking string x and string y as parameters". This is useless, clutters up everything, and makes the important comments less visible.
I guess you don't know what science fiction is then.
I'll take that over not understanding the concept of humor...
A stable of science fiction travel is the barn where you keep your faster than light-speed horses.
That the stable of FANTASY travel. The stable of SCIENCE FICTION travel is where you keep your light-speed Spline.
I thought it was interesting given the type of jokes that I would often laugh at but my wife would have no clue what was funny about them...
My favorite were the ones we would BOTH laugh at.... but for completely different reasons.
The solution to that problem is simply more introspection. See http://common-lisp.net/project/slime/ for an example.
I don't see how... Basically autocomplete isn't going to work when the program logic can be changed at runtime.
def missing_method(name, *args)
if (random_boolean())
do_a(args[0], args[1]);
else
do_b();
end
end
Now when I call "string".foo(), it will eiteh rhave just enough parameters, or not enough, depending on, at runtime, if random_boolean returns true or false;
Could this suggest that there is actually a difference in the genders?
Could be, could be... Or, perhaps, the difference sets of gonads may lead to a clue.
The only serious prank I ever did ended up as a one-liner in Time magazine. I has set up an elaborate system of personalities on all the "What it IT?" type websites (people trying to figure out what the segway was before it was revealed). It was full of secret insiders posting information, other "real" insiders negating what was said and posting the slightly more believable "truth", fake PR people from Dean Kamen's companies playing down the hype, invisible agents from major industrialists and venture capitalists offering bribes for more information, with cryptic responses, janitors who happened to "see something", bitter recriminations flying back and forth between both sides of my "regulars" and "hoaxers"... Man, it was great fun. In the end I had thousands, if not more, convinced it was a kind of flying surfboard looking thing that used very little power and would alter EVERYTHING.
Even in the wee hours of the morning, after Time and Newsweek had published thier international copy on the web, people were still convinced that it was all part of a HUGE elaborate conspiracy to keep the true nature of IT concealed until the very last second.
Sigh, good times.
I am a big ruby fan, and I know it's so dynamic that, other than syntax hilighting, you can't really be sure, except at runtime, what a particular method is going to do, or it will even exist. If python is as dynamic as ruby, I suspect the best you can find will be something that KINDA works, not not in the way that a static language IDE will work.
First you get the sugar, then you get the power, then you get the women...
Camille Paglia, in her book Sexual Personae, maintains that at the core, women represent nature, and man strives to control nature, thus he strives to control woman. "The primary image [of women in media] is the femme fatal, the woman fatal to man," she explains. "Woman's beauty is a compromise with her dangerous archetypal nature. It gives the eye the comforting illusion of the intellectual control over nature" (13-17). With this assertion, it is apparent that men's domination of female body image is intertwined with his need to control the feminine.
No.... That is called reading WAY THE FUCK too much into it. Let me spell it out for you: Men like boobies. Men design games. Thus all female characters in all games have boobs nearly as big as my wife's. That is all the logic there is to it.
Every ad next to yours reduces the impact of your ad geometrically. One ad is effective. One ad in a sea of thousands no so...
SO, the TRUE turning point in advertizing will be when ad companies start paying for BLANK space on all the billboards near thier ads. Imaging just a single ad on the road between here and Nantuckett, instead of 300... Imagine two minutes of black screen followed by a single ad, followed by two more minutes of black... THAT ad will have serious impact!
I'd much rathar have a product that is unfinished, and gets slowly finished in a way that the featured that get implemented are those that users actually need and want than a "finished" product that has features that a marketing department decides that I need.
Not necessarily; profit is one of those microeconomics things that is a curve. If you're on the top half of the curve for a specific product, lowering the price of a product will increase profits because volume goes up faster than unit-profit goes down.
You seem to imply that the recording industry has the slightest grasp of economics...