Page 5 of 6

Posted: Wed Sep 14, 2005 7:17 pm
by neophyte
I admit I'm no expert. But from a distance it would appear that there is no right or wrong answer to this question. It' a matter of preference.

But McGruff's method is appealing to say the least. I'd do almost anything to not have to spend time testing and testing my script through a browser and still not know if what I've written is solid or just "working". I hate writing and then testing through a browser and writing and testing and still not knowing if I missed something along the way. But then again what if the test your wrote was inadequate? :wink: :roll:

I for one wouldn't mind reading more productive discussions on this topic. Maybe two separate threads one for each topic.

Posted: Wed Sep 14, 2005 9:26 pm
by McGruff
neophyte wrote:But then again what if the test your wrote was inadequate?
That can happen. Different people give different estimates of how close to a 100% proof you can get. I'd say pretty close. The fact that you do have a formal, written document helps. You might not get everything first time around but you can always add new tests as new issues spring to mind.

It was interesting to hear the replies to the test/code dilemma.

Posted: Wed Sep 14, 2005 9:30 pm
by Roja
McGruff wrote:The only two of these I've dipped into are phpmyAdmin and phpBB. Sophisticated is not a word I often hear used to describe the code. They're both excellent examples of just how difficult maintenance can be with poor design.
I won't disagree on the maintenance point. Sophistication has a wide range of definitions, often including "complicated" as one of the terms. However, the quote had context, and the point was that people who want to work on a wide range of apps - including the top of the food chain - would do well to ignore procedural.

I think even you will acknowledge (despite their shortcomings) that the apps listed power the vast majority of sites today. They are not trivial apps.

But I do agree - maintainance on them is far from the best of the best.
McGruff wrote:Say I want to add a new bbcode tag in phpBB. It's a nightmare simply trying to identify the relevant chunk(s) of code. There are no tests to run after an edit so I don't know if the new feature works or if it broke something somewhere else - made all the more likely with global variables flying around. When I install it live, again there are no tests to run to check if everything's OK. It basically has to be tested by site visitors which isn't terribly professional.
Be careful in the use of professional there. It shows your bias, and reduces the value of your argument. Again, its one of the number one forums installed. What definition are you using for professional? To denigrate one of the top three forums on the web today makes your definition look unrealistic.

I'd argue that its not easily maintainable - I think that is a definition that is fair.
McGruff wrote:Compare that to a fully tested OOP design.
Please do cite a counter example that is widely installed, that fits that description. To my knowledge, the closest competitor that is actually mostly OOP is FudForum. I suspect many of the forum goers here have never heard of it, which should highlight the disparity.

That goes back to the original point, in the correct context: In the real world, you encounter significant amounts of procedural code. Not knowing procedural, or more accurately, seeking to rewrite it in OOP is both arrogant, and unrealistic.

Thats not to say that there isn't a value to OOP. Thats simply highlighting the value of knowing both.
McGruff wrote: Testing is a big deal (and there's much more to it than I've touched on here). I'd go as far as to say it's unprofessional not to test.
There's that word again, so lets define it. "Conforming to the standards of a profession" is a solid choice. Considering that the closest competitor is far behind in terms of longevity, features, user base, programmers, and more, I'd say that phpbb, despite its maintenance challenges *for you* has proven to be the more professionally accepted. Going a step further, I'd say you've given the perfect example of how an over-focus on OOP has limited your abilities.
McGruff wrote:In procedural apps like phpBB, I'm not sure how you would identify discrete units to test in the first place and I've never heard of a procedural analogue for test driven design.
You've said that multiple times, and I've answered it multiple times, and each time you pretend you didn't hear it. :)

You can test a function just like you can test a class. Each has discrete entry points and exit points, inputs and outputs, and definable ranges for responses. There is no difference in testing the output of $class->method("word") to testing the output of function("word"). Both have an input ("word"), both have an output, and that output has a discrete range of appropriate, measurable data.

Again, I think this becomes a fantastic example of why you need knowledge of both. The programmers working on phpbb have the knowledge of both. There are objects in use in phpbb, but they are used sparingly. The system works so well that thousands of sites have made add-ons, themes, mods, and run their sites on it.

Using it as an example of the failure of procedural highlights the distance from reality for an experienced programmer when approaching OOP: Its a fine paradigm, but the majority of sophisticated code DOESNT use it.
McGruff wrote:If you're looking for sophisticated programming the modern agile movement is where to look - and it's all about OOP.
As I said above and previously, it all comes down to definitions. You presumably are using a different definition of sophisticated, so it would help if you define your term so we can understand it. Until you do, the reality on the ground is that the majority of the most widely deployed, developed, and supported apps are in fact using a mix of procedural and OOP - not purely OOP.

Also, describing agile as a modern or sophisticated programming methodology is inaccurate as well. In the first place, it was formalized roughly five years ago, and had its beginnings almost ten years ago. There are plenty of alternative methodologies that have been founded since then. Sophisticated of course brings up the need for a counter definition, but until one is given, the original definition stands, and agile suffers as a result.

Much criticism has been brought against agile programming for requiring far too much cultural change to accomplish. Or in a nutshell, you either have to drink the koolaid, or you don't get the benefits. Much like the koolaid, the people that drink it see no other alternative. Or put another way, until you convert all the screws into nails, the hammer just isn't that useful.

Which again highlights my recurring point: A knowledgable professional will have both in their arsenal to use as needed.

Posted: Wed Sep 14, 2005 9:38 pm
by Roja
McGruff wrote:Tests don't actually add anything to the code - although they can shape code in a beneficial way. The test cases are completely separate classes which exercise the class under test by setting up fixtures and making assertions about behaviour in different conditions.
This is an important point, and one that needs to be hammered on. You cannot magically have tests appear. Developing them DOES add something to your code: Development time and size.

If tests consist of one-third the total codesize of an app (which isn't unusual), thats 1/3rd more work the developers have to do.

Arguably, the non-testers are also spending time and development work that is harder to measure discretely: The output is reabsorbed in the main code.

However, tests don't come out of thin air, and the original point was that testing easily bloats the development of a one-page function into many MANY pages more. You didn't answer that point: You avoided it by waving your hands and saying "Its not part of the main package". At best, you can argue that it doesn't grow the memory footprint, but from a development point of view and from a distribution point of view, those tests DO add something to the code: Development time, and code footprint.

Of course, I happen to firmly agree with McGruff that tests are in the overall picture *far* better than the alternative, especially once you get beyond a small application. Regardless, I chose the example of an email function for a reason. To gain the advantages that McGruff argues for, you have to have the development time to create all the tests, you have to have the footprint, which includes all the tests, when you could embrace the more intelligent solution, and use a definitive regex, make a simple function, and be not only just are well tested - but do it in less code, and with less work.

Thats why I chose it as an example. It highlights the intellectual arrogance of recoding for the sake of purity, instead of using the best tool for the job.

Posted: Wed Sep 14, 2005 10:18 pm
by McGruff
I really don't think it's fair to make statements about testing in OOP unless you've had some experience using it - please correct me if I'm wrong. Do you have a favourite testing tool? What are your strategies for regression testing? Continuous integration? Refactoring? Have you tried test driven design?

Buddha443556 mentioned that you can test data structures. I can't quite see how this is really giving you the same grip on the app. Without encapsulation, data and behaviour isn't bundled together in neat little parcels.

In OOP, you can conveniently stub out whole swathes of code in a test. Can I do that in procedural php? Objects give you all kinds of handles to pull on, parcels to pick up which just don't exist procedurally. Maybe I'm simply showing my own lack of knowledge. I must admit it's not something I've looked at seriously.

If you're testing data structures, that's a state-based test. Test driven design is an interaction style. Do you know of a procedural equivalent of mock objects? I don't.

TDD - using tests as a design tool - is a really nice way to work; testing is about much more than just quality control.

Posted: Wed Sep 14, 2005 10:53 pm
by McGruff
Roja wrote:If tests consist of one-third the total codesize of an app (which isn't unusual), thats 1/3rd more work the developers have to do.
...
those tests DO add something to the code: Development time, and code footprint.
This is getting silly. Or maybe I didn't explain it very well. I'll try again.

This is a very common attitude you come across in newcomers to testing. Why do all that extra work? You'd really have to experience it to find out and I wish I could persuade you to stop bickering and give it a go. That's really all I'm trying to achieve here: help people to learn, as others have helped me.

Test-infected programmers don't really write code: they write tests and the code just emerges from the tests. Well that's the way I look at it. It's a sea-change in perspective. They'll often see the tests as more important than the code itself - see that test/code dilemma link above. The reason for that, or rather one reason of many, is because it's easier to work this way. It saves time.

It saves time debugging (most test-infected prgrammers don't use debugging tools: they don't need them). There's nothing worse than those bang-your-head-on-the-table moments when you're faced with a bug and you don't even know what question to ask never mind a possible solution. With fine grained tests, you (hopefully) will have a helpful test message telling you exactly what went wrong and where.

The method of write a little test then write a little code to pass the test means that you're always taking little steps. It's much easier to work out what went wrong if you've only made small edits since the last time the app was in a working state, and much easier to change it back. Bugs never get a chance to disappear over the horizon. If you can run tests easily at the click of a button, they do get run regularly.

Tests can save you time by telling you when to stop. Coding to strict requirements helps to keep you focussed. They even allow you to try out wild guesses: every now and then, rather than take half an hour to think it through properly, I'll just splat something down and bang it works. Great. Time to move on to the next test. More often, it will just go splat, admittedly.

Offset against the time saved debugging, is of course the time spent writing the tests. My feeling is that you actually save time overall but let's be generous and say they cancel each other out. Or, if you like, let's say that it takes twice as long to create a working app.

Now what? Maintenance, of course. If I've got tests to back me up, maintenance is a breeze. I can go back to a program six months later, wondering what on earth it's supposed to do, and I've got the tests there as a source of documentation (which unlike written docs, never gets out of sync with the app). That's particulalrly important if you're working in a group.

When I make an edit, I can run the tests to check everything still works, and so on and so on. I've already gone through that. This is where you really get paid back in terms of time saved and that's why I wouldn't take a job where they weren't testing: it's just too hard. There are more interesting things to spend your time on (refactoring, probably).

But testing didn't just save me time. It probably also gave me a better app. You'll deliberately write code which is easier to test and that has a beneficial effect on the design. With a full suite of tests, run constantly throughout the lifecycle, it's also going to be more reliable.

EDIT: actually it won't save you time to begin with because you'll have to go through a learning process while you figure out how to use the new tools. Still, it's worth it in the long run.

Posted: Thu Sep 15, 2005 1:34 am
by Roja
McGruff wrote:I really don't think it's fair to make statements about testing in OOP unless you've had some experience using it - please correct me if I'm wrong.
You are extremely wrong. Here's my background info. I've coded in OOP for about 7 years. I started my work in OOP with C++, and when I came to PHP, I found similar references several years ago.
McGruff wrote:Do you have a favourite testing tool? What are your strategies for regression testing? Continuous integration? Refactoring? Have you tried test driven design?
Most of my day-job php programming is done using OOP and unit testing. I use SimpleTest for most of my tests, as I find it to be rather good at getting out of my way and letting me get to work (grin).

Regression testing I personally do at development milestones. I'll target an improvement, work towards it, test it, and then when I've reached it, I generally run a test suite against affected portions. If its unclear what portions might have been affected (rare), I'll do a full suite run.

Because I'm lucky enough to have discrete and well-defined project goals (since I generally set them), I don't rely as much on continuous integration. After reaching a stable build, I focus on changes from there, and avoid massive rewrites and refactoring.

I actually find refactoring to be a bit of a buzzword/fad. I do reviews of my code regularly, and by many definitions, you could call much of what I do refactoring, but honestly, its just overhyped as a development goal.

I think the important thing to mention here is that you are focusing on my knowledge, and my history, and avoiding the discussion of the issue. Thats called a straw man argument, and its a bad habit in online discussions. As you can see, I'm fully qualified in every sense of the word to comment on both sides of the debate.

Personally, I don't care about the background of the people here. Even a longtime master can learn from the fresh perspective of a beginner, so I welcome the discussion without worrying about the person.
McGruff wrote:Buddha443556 mentioned that you can test data structures. I can't quite see how this is really giving you the same grip on the app. Without encapsulation, data and behaviour isn't bundled together in neat little parcels.
Thats exactly right: Data and behavior isn't bundled together tightly. That doesn't neccesarily result in less control. OOP and procedural approach application development from opposite directions. OOP looks at the program in terms of objects and behaviors. Starting with broad categories and working down to discrete patterns of code.

Procedural looks at applications in terms of data (a concept that is different from objects), and functional goals. Some describe OOP as top-down, and Procedural as bottom-up, but I think both oversimplify things. At its heart, I think the best comparison I can make is that procedural is more focused on what the program DOES, and OOP is more focused on HOW.
McGruff wrote:In OOP, you can conveniently stub out whole swathes of code in a test. Can I do that in procedural php?
Thats a fair difference. I could give more than a few ways that you could hack up an equivalent, but I think thats a fair difference to site.
McGruff wrote:Objects give you all kinds of handles to pull on, parcels to pick up which just don't exist procedurally.
I think its more a matter of approach, but again, I think thats a fair difference. I'd say that classes are designed in a way that lends themselves to testing, but that you could duplicate most of it for procedural code.

The difference there is in importance and ease. The OOP world has a much better toolkit for testing, while procedural, you are essentially rolling your own (at least to my knowledge).
McGruff wrote:TDD - using tests as a design tool - is a really nice way to work; testing is about much more than just quality control.
I think thats the perfect statement, because it describes tests correctly: with a subjective preference ("nice"), it makes clear that some people won't prefer it.
McGruff wrote:This is a very common attitude you come across in newcomers to testing. Why do all that extra work? You'd really have to experience it to find out and I wish I could persuade you to stop bickering and give it a go. That's really all I'm trying to achieve here: help people to learn, as others have helped me.
I'm not a newcomer. I'm not inexperienced, and you continue to make assumptions about posters simply based on your own background. Its neither accurate nor fair.

Thats why lesson #1 in debate is to focus on the argument - the issue - and not the person.
McGruff wrote:Test-infected programmers don't really write code: they write tests and the code just emerges from the tests.. The reason for that, or rather one reason of many, is because it's easier to work this way. It saves time.
(I trimmed the comment a little, my apologies if I lost some context). The phrase "easier" is again a great choice: Its subjective, personal, and isn't absolute. However, following it with "it saves time" is a bit dishonest. For some it will save time. By example, it saves you substantial time. For someone that doesn't use tests regularly, it will considerably slow their development - you've mentioned the learning curve numerous times yourself. Thats not to say its a waste of time. Like you say in the end, its worth it in the long run.

My point was purely that there are situations where its not the ideal, and where it IS fair to say that it would be "less better", if you include development time as one of the criteria.

We're circling around the key issues, and its mostly due to delving into detail. The only question is "Is OOP always better than Procedural?".

We've discussed several situations where you've agreed that its not: From hello world, to shell scripts, from inexperienced testers who need to get up to speed with new methodologies, to projects that specifically define "better" to include development time.

Since you've agreed that there are *any* situations where OOP isn't better, we have to agree that OOP is NOT always better. I think everyone in the thread is in agreement that OOP is powerful, useful, and something to encourage. The difference from day one, that has always set MY hair on fire was your statements that implied that Procedural was inferior to OOP in every sense, or that people that prefered procedural were unwilling to learn.

Thats simply provably false.

OOP or procedural is absolutely a matter of preference. But going further, if you are a horrible programmer, NEITHER will solve that. Which puts more focus on the meta-issue: People should always look to improve themselves. That doesn't mean picking one and only one methodology! That means embracing the right tool for the job, and if you are more comfortable in Procedural, that may be the right tool until you get familiar with OOP.

Posted: Thu Sep 15, 2005 9:09 am
by Buddha443556
McGruff wrote:This is a very common attitude you come across in newcomers to testing. Why do all that extra work? You'd really have to experience it to find out and I wish I could persuade you to stop bickering and give it a go.
Been programming 28 years and the first time I used testing was on procedural code (assembly) about two decades ago. Last time I used testing was in Java, it was complex multithreaded program however that was 5 years ago. What test suite? Had to code that too. I really underestimated that project all the way around but the final working application was only possible because of TDD. I couldn't have done that project without the tests. Personally, I've never had "the code just emerges from the tests" I've always been there typing it. I have to agree with Roja that there is a cost to TDD in time and code.

Personally, I use TDD like any other tool - when I need it. I haven't needed OOP or TDD with PHP. I'm only working with pages that do one thing and are pretty much independent. Too small and too simple to need either OOP or TDD. It would just be over kill IMHO. Keep it super simple, I can't afford complexity as a freelancer. Learned that the hard way.
McGruff wrote:That's really all I'm trying to achieve here: help people to learn, as others have helped me.
I appreciate that. I also appreciate your high standards. I encourage everyone to learn as much as they can about OOP and TDD. They are very powerful tools, worth the time learn to use. (Haven't I said that before?) Of course, I also don't discourage anyone from learning to use other methods and techniques too. We may differ in that respect.

Posted: Thu Sep 15, 2005 9:35 am
by CoderGoblin
Like others I have been programming in a lot of different languages over approx 20 years. Having worked in a multitude of environments I can see the advantages of Test Driven development. For small projects maybe it isn't necessary but I have lost track of the amount of times something small has grown as multiple people work on the same thing. Changes to a piece of code written 4 years can have unexpected results due to a side effect. Full Regression testing is essential even in a point release.

At the end of the day it comes down to how many people properly document their code lifecycle. Design (yeah ok most people do this even if it's on a scrap piece of paper), build (a lot of people do at least comment the code a bit) and test (very few people have a test document). Most customers are not interested in documentation they just want the code. But these same people complain when things go wrong and you do not have that documentation. Not having the documentation means often the only person who knows the code is the person who originally wrote it and then even they forget a lot of it when the next project comes along. Even with documentation it is often very difficult to sift out the information you actually need to figure out how things work. In a test driven development environment when you have a problem you figure out the test and work from there.

We then come to the issue of cost for corrections over time. If things have to be corrected after being built the cost for the correction is far higher as often you not only have to work out the specific error but also correct any additional side effects (if you can find them). This is a proven fact.

Posted: Thu Sep 15, 2005 10:38 pm
by McGruff
Roja wrote:I think the important thing to mention here is that you are focusing on my knowledge, and my history, and avoiding the discussion of the issue. Thats called a straw man argument, and its a bad habit in online discussions. As you can see, I'm fully qualified in every sense of the word to comment on both sides of the debate.
OK but making statements that writing 1/3 more code (the tests) results in 1/3 more work sounds simplistic. And, I have to say, simply isn't correct. Tests can save you a huge amount of work over the lifetime of an app.

Debate is all about questioning ideas. We have to trust each other enough not to take that personally.

Incidentally, I'm in the middle of transferring a site to a new server. The php part is an old app I wrote years ago in procedural code and has only partially been refactored into OOP backed up with tests. Once the files have been copied over, I don't have a full set of tests to check everything's working fine. There are several thousand pages: I can't possibly check them all by clicking around. If I tried, simple fatigue could easily lead me to miss something. In practice, all I can do is cross my fingers and let visitors do the testing, assuming they do actually report any problems.

I will test a bit, of course, but it will take me longer to do much, much less. With tests, I could have clicked a button and got home a lot earlier, with the prospect of a sounder night's sleep.
Roja wrote:We're circling around the key issues, and its mostly due to delving into detail. The only question is "Is OOP always better than Procedural?".
I think this is one of the key issues. It's the combination of OOP and testing which is particularly powerful. We seem to have agreed that the limitations of procedural code can have an impact on testing. We don't seem to have found a way to do test driven design at all. That's one of the most important tools of all, IMO.

Posted: Thu Sep 15, 2005 10:57 pm
by McGruff
Buddha443556 wrote:Last time I used testing was in Java, it was complex multithreaded program however that was 5 years ago. What test suite? Had to code that too. I really underestimated that project all the way around but the final working application was only possible because of TDD. I couldn't have done that project without the tests.
I've felt that myself at times: I think testing does help you to tackle more complex projects. It's a force multiplier. Can't say I've done anything as complex as a multi-threaded java app though...
Buddha443556 wrote:Personally, I've never had "the code just emerges from the tests" I've always been there typing it.

:)

There's still that dang code to write. And debug too, if the tests are failing. It's just a lot easier to do when you're focussed tightly on an individual assertion. Sometimes it does feel like the app is writing itself. Most of my mental effort seems to go into the other side, thinking about the requirements and how to test them. Every now and then I'll be typing away and suddenly the tests are running green. How did I do that? Who cares, time to move on quick before I ruin it by adding that next line I was thinking about...

Posted: Fri Sep 16, 2005 1:35 am
by Buddha443556
McGruff wrote:I've felt that myself at times: I think testing does help you to tackle more complex projects. It's a force multiplier. Can't say I've done anything as complex as a multi-threaded java app though...
OOP also seem to have the same force multiplier effect.
Roja wrote:We're circling around the key issues, and its mostly due to delving into detail. The only question is "Is OOP always better than Procedural?".
OOP was based on lessons learned from procedure and structural programming. OOP is the evolution of procedural and structural programming. Somewhere in OOP those ideas of past survive. It's not a question better or worse but a question of how much? How much force do you need to apply to the problem? The bigger the problem the more tools you'll use. The more critial success the more tools you'll use. The more important your job is to you the more tools you'll be using to CYA.

I have no idea where I was going with this post. Just glade to have some problems.

It's 2AM ... I'm going to bed. Good Night All.

Posted: Fri Sep 16, 2005 8:47 am
by Maugrim_The_Reaper
Just to note a few points...
Roja wrote:Procedural looks at applications in terms of data (a concept that is different from objects), and functional goals. Some describe OOP as top-down, and Procedural as bottom-up, but I think both oversimplify things. At its heart, I think the best comparison I can make is that procedural is more focused on what the program DOES, and OOP is more focused on HOW.
It does oversimplify - for example I would generally take an overview of design goals, examine my data souces, look again at functional requirements, and see where the intervening links lead. It seems to work fine whether OOP or procedural - though OOP is a little more abstract, and takes more out of the box thinking. Now I'm probably over-simplifying myself - but I'd generally look at each in isolation before before coming to any grand conclusions. A case of spot the hobbyist maybe? :). I've always thought OOP and Procedural could work both ways.
Buddha443556 wrote:OOP was based on lessons learned from procedure and structural programming. OOP is the evolution of procedural and structural programming. Somewhere in OOP those ideas of past survive. It's not a question better or worse but a question of how much? How much force do you need to apply to the problem?
Evolution is a nice way of putting it. Evolution does not necessarily invalidate what came before - but is a response to environmental factors - or even competitive pressures. OOP has evolved, but its hardly a static process. I also agree that whether OOP or procedural is used depends largely on context, design goals, maintenance, complexity and other such sometimes nebulous concepts. Simply dismissing procedural as history is a little arrogant. Might as well be an Intelligent Design fanatic dismissing Darwin as nonsense...
CoderGoblin wrote:Like others I have been programming in a lot of different languages over approx 20 years. Having worked in a multitude of environments I can see the advantages of Test Driven development. For small projects maybe it isn't necessary but I have lost track of the amount of times something small has grown as multiple people work on the same thing. Changes to a piece of code written 4 years can have unexpected results due to a side effect. Full Regression testing is essential even in a point release.
Personally I've only rarely used TDD (mainly to leap that learning curve ;)). From a design perspective however I really like its objective and aim on using it more - it makes a lot of sense. Again I'm not sure its so useful in all circumstances - on paper yes, but in all real life do or die situations with the IT Manager screaming to get it finished? From my ignorant viewpoint not all projects will have either the time or resources to persue TDD right from the start. Then again maybe TDD simply needs more airtime to convince we underinformed masses of our poor judgement.

On whether OOP or procedural should be used - I'd have to side with Roja. I love OOP, but I don't worship it. Like Roja I spend a fair portion of my time creating PHP open source games, and come across a lot of procedural code which is surprisingly spry, modular and maintainable. Procedural is certainly alive and kicking "out there". I have used OOP (nearly exclusively) in my own game projects - but I completely fail to see any functional reason why procedural should be considered obsolete or defunct. I've seen procedural alone, procedural with OOP, and OOP alone. All three can get the job done, and even procedural if designed well isn't a distant misted over historic relic.

Posted: Fri Sep 16, 2005 8:50 am
by Roja
McGruff wrote:OK but making statements that writing 1/3 more code (the tests) results in 1/3 more work sounds simplistic. And, I have to say, simply isn't correct. Tests can save you a huge amount of work over the lifetime of an app.
It was simplistic. Because it was specific to the example given, that of validating an email to the degree that the definitive regex has already done. There are literally *hundreds* of combinations of "semi-legal" emails that by RFC have to be allowed, even though many mail servers wont accept them. Like I said, I chose the example for a reason: Its a horrible challenge for test-driven design, and its a (perfectly) finished problem in procedural code. It would *easily* take more than 1/3rd more code to develop all the tests to get to the same level. And remember, thats to get code in oop that replicates an already completed task!

I don't at all disagree that tests save time in the long run generally: I said that exactly. You are arguing that there is *no* time when OOP is inferior, and you've asked numerous times for a code-off, and I've given you the perfect example. Validating email is a completed task in procedural that would take FAR more code, time, and effort to duplicate in OOP.

In other words, it is the example that disproves the statement "OOP is always better". What you continue to argue is that I don't accept that OOP is better for the general case, which I have never said. I like OOP. Its powerful. I use it. I simply know that there are places that it *isnt* the best choice.
McGruff wrote:Debate is all about questioning ideas. We have to trust each other enough not to take that personally.
I agree, but my trust stops when people make sweeping generalizations about people holding a viewpoint instead of arguing the point itself. Thats the difference between an on-topic discussion and making it personal.

Don't get me wrong, once drawn into the fray, I've returned fire, and I should know better. I think in the course of this thread the quality of the argument has raised from flamebait to nearly reference material. :)
McGruff wrote:
Roja wrote:We're circling around the key issues, and its mostly due to delving into detail. The only question is "Is OOP always better than Procedural?".
I think this is one of the key issues. It's the combination of OOP and testing which is particularly powerful. We seem to have agreed that the limitations of procedural code can have an impact on testing. We don't seem to have found a way to do test driven design at all. That's one of the most important tools of all, IMO.
But see, your arguments again simply support the global aspect of OOP & testing being useful. We've already agreed on that point. What you need to do is defend the much more difficult statement that OOP (& testing if you wish) is *always* superior.

I've given a counter example. Even you mentioned shell scripts as a counter example. The only thing left is for you to either disprove both examples (and any others that people bring up), or agree that there are definitely places where OOP isn't the superior choice.

[UPDATE: Now that I have my 1000 posts, I can go away! Just kidding.. WoohOo! 1,000 posts!]

Posted: Fri Sep 16, 2005 12:08 pm
by sweatje
Roja wrote: I've given a counter example. Even you mentioned shell scripts as a counter example. The only thing left is for you to either disprove both examples (and any others that people bring up), or agree that there are definitely places where OOP isn't the superior choice.
FWIW: I am currently in the process of replacing a set of batch job shell scripts we have been using at work for many years. By adopting PHP as the shell scripting base langauge (as opposed to the existing korn shell scripts) and providing several pre-built (and unit tested) objects in the environment the script runs in, I reduced the average size of the typical script from several hundred lines to typically less than 20 lines.