Where do you think the real power in LISP comes from? Do you think someone in their first term of studying serious computing will appreciate that power and why it's important/useful? Will they learn anything from LISP, at that time, that they couldn't learn from the other functional programming languages I mentioned?
Ah, but the GP post didn't say "correct", it said "perfect". You can prove correctness against some specification, and perhaps even get it right on the scale we're talking about here. However, in the real world, that's only worth as much as the specification and as the implementation you're running against matches its own spec. You can be a smart LISP programmer and write an implemention in LISP in just a few lines, but at some point, someone wrote a bootstrapping implementation that was far more complex, and how do you know that works properly? Ultimately, even the computer and operating system you're running on are probably out of your control, yet your program will rely on them to do its job, too. In other words, there is a big reality gap between proving against a specification and proving that your program is perfect in any useful sense of the word.
I'm not sure "hate" is quite fair, at least in the majority of cases. Java is often criticised by those with broad experience because it is underpowered and overhyped relative to potential alternatives. The industrial result of this is that the knowledgeable critics are often the ones who clear up the mess when enthusiastic (indeed, sometimes evangelical) but naive Java developers come in and produce overengineered, inefficient rubbish that isn't fit to send to a customer and costs a fortune to maintain.
No doubt you can do all of that stuff in Scheme. Unfortunately, actually doing so produces a person who thinks only in terms of Scheme, which is as bad as a person who thinks only in terms of Java or C. It also leads to rose-tinted spectacles, as you kindly illustrated with the nonsense about proving your software is perfect. Whatever you were actually proving in your classes, I guarantee that wasn't it.
Well, I just looked up the Surrey Computing BSc brochure (warning: PDF) and to be brutally honest, I'm not that impressed.
Perhaps their presentation in the brochure is bad or their courses are unfortunately named, but when two of the five "core" modules in the first year are given as "web publishing" and "professional studies", while the first course in data structures and algorithms features in the second year alongside "usability engineering", alarm bells are ringing pretty loudly.
Where are the courses on different programming styles and languages? Operating systems? Applications like databases, graphics and image processing, natural language processing? Numerical analysis? Programming language design and compiler construction? There do seem to be some interesting courses among the optional modules, particularly by the final year, so perhaps these things really are covered and the advertising is poor.
I suggest you seek a more detailed syllabus, and compare it with alternatives offered at other universities, before committing to this course. Looking at a few other places (I tried Cambridge, Warwick, Brunel, Imperial) there is considerable variation in what's offered, and at first glance, I'd suggest the Imperial or Cambridge syllabuses as guidelines for the sort of things to look for.
For the record, I had a quite different experience at the University of Cambridge Computer Lab. I was there nearly a decade ago, but things don't seem to have changed too much. They do use Java for the basic intro to programming courses there, and to be honest the guy who taught them was pretty rubbish and most of us ignored them. However, there were also courses on functional programming, Prolog/AI, and so on, which introduced me to some concepts I hadn't previously encountered despite being an enthusiastic geek at heart. So not all UK universities have fallen into the cheap/vocational trap.
Maybe when more than half your undergrads can explain the difference between a spinlock and a semaphore we'll listen.
I did study some formal CS at university, but never heard the term "spinlock" before. I did, however, implement the ideas in the Wikipedia article cited in another reply at the end of last week, simply by looking at the available tools and guarantees provided by the programming environment I was using, and concluding that what you call a spinlock was the simplest and most efficient way to achieve the behaviour I needed.
I think this is the difference between the approach you seem to value and that valued by places like MIT: you do stuff by rote because a book told you to, while people who have learned to think analytically will simply create it if they need it.
Even though at first functional programming can seem counter intuitive to people raised on OOP it is kind of neat once you understand it ( Of course it has no application for 90 % of real world software).
That's a pretty bold statement. In what major areas do you think functional programming has no application?
You shouldn't be intensely worried, but reading around your subject is pretty much always a smart move if you're a serious student. I learned this lesson very late in my academic career, and now wish I'd understood what the phrase really meant a couple of years earlier.
In this business, knowing multiple programming languages (and in particular, knowing multiple programming styles -- OOP, procedural, functional, etc.) is a big asset. It helps you to think about problems in more varied ways, even if you will ultimately code the solution in whatever language is required by your particular professor or, in due course, employer.
There are two suggestions I've heard in the past that I appreciate more as time goes by: try to learn a new programming language and to read a new book about programming every year. In the former case, if you're learning Java, that's OK, it's a pragmatic tool that's widely used in industry and it will teach you one way of thinking about a problem. I suggest the following as complementary languages, to be explored as and when you have the opportunity:
C, or even some version of assembler, to understand what's going on under the hood and what a low-level programming language really is;
Haskell or a dialect of ML, to understand that not all programming languages are block-structured procedural languages, and what a high-level programming language really is;
Python or Perl, to understand the costs and benefits of requiring less formal structure, and the use of dynamic type systems, and to learn a few neat ideas like regular expressions;
when you're ready, LISP, to understand what the old sayings "code is data" and "data is code" really mean, and what concepts like macros and metaprogramming are really all about.
There are various other unique things you'll take away from each of the above, but if you spend perhaps a few months exploring each of them in some detail, it will make you a much more rounded programmer. I'd suggest either the above order, or swapping the first two around and going for a functional programming language and then something low-level. The requirements of your course or good advice from friends/teachers may guide you otherwise. Go with what works for you.
To make your learning practical, pick some simple projects, perhaps to practise whatever algorithms you happen to be studying lately in other courses, and write a few small but real programs in each language. For example, if you're learning about operating system basics, try rewriting a couple of simple OS utilities or networking tools in C or assembler. If you're learning about databases, try writing a simple web front-end for a database, and power it with a few CGI scripts written in Perl or Python that use SQL to look up and modify the data in your database. If you're learning about graphics and image processing, write a simple ray tracer in Haskell or ML.
Along the way, you'll develop potentially useful real world experience with things like OS APIs (and perhaps how they vary between platforms, and thus why standards are useful for these things), HTML/CSS and CGI for web development, SQL for database work, and so on.
As you go through this, consider buying a good textbook on major subjects (programming languages, databases design and SQL, graphics algorithms, etc.) or make sure you've identified some good reference and tutorial material on the web. The latter is a big advantage for the modern compsci student, though you have to be careful to check your sources are well-regarded and not just a pretty web site with an authoritative tone of voice written by someone very enthusiastic but regrettably ill-informed. Things like FAQs and newsgroups can be valuable sources of information, but sometimes, there's just no substitute for a well-written, well-edited, authoritative textbook.
Anyway, this post is now far too long, so I'll stop there. Please consider it "the approach I'd take if I could have my university days again" and take it for whatever it's worth to you. Good luck.:-)
That's why these proposed laws, like the one recently introduced in California, need to specify that the standard must have an open-source reference implementation.
So tell me, what does a reference implementation of a document format look like?
Even if these standards have no "teeth", it is still hugely useful that they exist.
Only if they are minimal, complete and unambiguous. In other words, only if everyone implementing the standard will follow the same conventions in practice. Since Microsoft's XML "standard" is neither complete nor unambiguous, it's worth about as much to anyone else as a patent dressed up in obscuring legalese, and any standards body worth its salt should reject it.
The sad thing is, I would have preferred the alcoholic over any of the likely leaders of the three big political parties in England going into the next general election. Cameron sounds increasingly like Blair Lite, and the other two don't really seem to be saying much at all. In Campbell's case, I think he just doesn't have a loud enough voice: his party blew the whole leg off when they dumped Kennedy, and will now pay the price for their lack of vision. In Brown's case, I think he is a very shrewd political operator who knows when to keep his mouth shut, which will win him nothing from people like me, but may see exactly the outcome he wants in about six years' time. (See if you can figure out how I think that will happen...)
You're right about the aptly named RIP Act heralding the beginning of the end, of course. I remember back then, thinking how draconian Jack Straw was as Home Secretary. Compared to his successors, he was practically Gandhi.
Thus, bending with new requirements is more important than being bug-free.
You write as if they are mutually exclusive. Why?
Many of the formal techniques assume a stable interface but a bubbling implementation. Often it is the other way around.
That makes no sense. The whole point of the interface/implementation separation is that you can change the implementation without changing the interface. If you change the interface, you will necessarily change the implementation at least enough to match.
I'm also curious about your repeated reference to "formal" techniques. What do you mean by this? Do you also consider unit tests a formal technique? Commenting code? Structured programming? Where do you draw the line between what is helpful and what is a burden?
By the way, please skip the IE tab. If you are using Firefox, it is in your best interest to abandon sites that only support Internet Explorer.
Unfortunately, as others have noted, that just isn't practical. For example, the following sites that I use regularly require IE to function properly:
the corporate intranet at work (uses custom stuff involving ActiveX, amongst other things)
some of the financial companies I use
Windows Update
None of those is expendable, and there is little chance of most of them supporting other browsers fully in the near future. (Unlike some people around here, I care more about the benefits of the financial services provided by my financial services companies than I do about have to use IE to access their web sites.)
Design by contract, like most formal method approaches, doesn't scale to interesting levels. If you are working on a 200KLOC project on a tight schedule, the last thing you can afford yourself is increasing time spent per line of code by equipping classes, loops and methods with pre & post conditions.
By a similar argument, we should all give up with unit and integration testing, because the additional effort required to write automated tests for individual modules and then for interactions between them is prohibitive. And yet, I suspect we would agree that automated unit and integration tests can be very useful and provide a good return on investment.
It's great if you can specify that a piece of code is a 100% correct implementation of a given specification but in real life the requirements are sketchy at best & keep changing during development. So, you are likely to end up with the wrong system if you don't adjust your interpretation of them to reality during development.
Hmm... Wouldn't it be great if we had a mechanism that could make sure our code always met current expectations, and which could automatically notify us if loopholes started to creep in as the requirements changed and bits of code here and there were modified to keep up?
Besides there are other, much more useful tools for improving code quality: unit testing, integration testing, static code checkers, compile time type checking, inspections & reviews are all part of the toolkit of an experienced software engineer and largely remove the need for more formal approaches.
You're quite right about using a variety of tools, of course, but some of them are much cheaper than others. For example, it costs less to find a bug using static code analysis that can be performed automatically every check-in than to find the same bug using human intervention during a formal code inspection.
In theory disaster could strike any second, in practice it is a rare event that it does and the consequences are quite manageable usually.
Is it really that rare? Or are you just so used to shoddy software that you've come to accept it without realising?
A huge proportion of the computers connected to the Internet are now part of botnets, mainly caused by basic security failings in the operating system and networking software installed on those machines. The net loss of quality of life and financial cost to business as a result of a relatively small number of bugs in that area is staggering.
We now have quite advanced software in many consumer goods. What is the cost in quality of life if a new PVR fails to record one programme for every consumer who buys it, or a new washing machine occasionally randomly sets the temperature to 90 when it should have been 40 and ruins a whole load of clothes?
It is an unfortunate reality that most businesses depend on a few very widely used pieces of software. What is the cost of a little UI bug in Word, if it wastes 30 seconds of time for 10 million users?
Not so long ago, someone at the UK HQ of our organisation sent out a mail that was supposed to have the latest phone list in it. Unfortunately, due to some gremlin somewhere, the data generated included a significant amount of other, supposedly confidential, information about every employee in the UK, which was sent to every other employee in the UK. I don't know whether that was human error, but it's the sort of thing that could easily enough be caused by a small mistake in whatever script was used to generate the report, and a huge amount of bad feeling was generated amongst the entire UK employee base as a result.
I could go on, but hopefully my point is made by now.
Perhaps it's just wishful thinking, but I can't help noticing an increasing number of comments among my friends and family recently about just wanting
Actually, in your example I'd prefer the following. (Apologies for losing the indentation; how do you get Slashdot not to do that?)
if(full()) { if(expandable()) expand(); else throw range_error("The array is full, but we can't expand it"); }
array[++lastElement] = newElement;
The comments in English add no value at all: they simply repeat, in a more verbose and less precise fashion, what the code already says.
I'm not really sure what you're trying to demonstrate with the assertions in this case. Your first condition is testing for something that sounds like it could legitimately go wrong at run-time, i.e., something that is not a logic error. That isn't really a very good use of pre/postconditions, which are (IMHO) best reserved for things that should never go wrong. The later tests are restating what you've already stated immediately above them, and again they add no real value.
In the real world they often want as many features as possible with the smallest staff possible.
I think what they usually want is the best return on investment, which isn't necessarily the same as what you wrote there.
In any case, I think your entire post is backwards, though I've heard the same argument many times before. If you want to get lots of features working quickly, the only way to achieve it is to do the development properly. Neglecting QA is a false economy, as is dropping other defensive programming and active testing approaches earlier in the development process, which if anything are more valuable, because they find problems sooner. This is why the whole "pick two of good, fast and cheap" thing is quite misleading: while the up-front costs for people who can do good and fast can be a lot higher than those of code monkeys, they'll give you a much better product that is likely to cost far less measured over its entire lifetime.
So tell us, oh wise one, what would you have us do? It's easy to snipe from the cheap seats, but offering constructive suggestions is the only thing worth a damn in this debate.
We know that there will be a general election at some stage within the next three years or so, at which point it is all but certain that Labour will lose power.
We know that the current political climate has stripped away most of the real power from Tony Blair's administration, and that it is unlikely that they will be able to pass much further heinous legislation.
We know that opposition parties are openly saying they will kill/repeal much of the nastiest stuff New Labour have legislated in recent years, and this is likely to be a major election issue.
We also know, as I explained in another post in this discussion, that Labour really don't care about any sort of peaceful protest at this point, because they have nothing to lose.
So what is the wisest course of action for the many of us who disagree with their current policies? Should we wait patiently, knowing that little further harm can be done as long as we maintain peaceful pressure on the government, and then use what's left of our democratic system to get rid of them decisively when our opportunity comes? Or should we do something else, and if so, what?
Slashdot Mirror
I'm not sure I agree with that.
Where do you think the real power in LISP comes from? Do you think someone in their first term of studying serious computing will appreciate that power and why it's important/useful? Will they learn anything from LISP, at that time, that they couldn't learn from the other functional programming languages I mentioned?
Ah, but the GP post didn't say "correct", it said "perfect". You can prove correctness against some specification, and perhaps even get it right on the scale we're talking about here. However, in the real world, that's only worth as much as the specification and as the implementation you're running against matches its own spec. You can be a smart LISP programmer and write an implemention in LISP in just a few lines, but at some point, someone wrote a bootstrapping implementation that was far more complex, and how do you know that works properly? Ultimately, even the computer and operating system you're running on are probably out of your control, yet your program will rely on them to do its job, too. In other words, there is a big reality gap between proving against a specification and proving that your program is perfect in any useful sense of the word.
I'm not sure "hate" is quite fair, at least in the majority of cases. Java is often criticised by those with broad experience because it is underpowered and overhyped relative to potential alternatives. The industrial result of this is that the knowledgeable critics are often the ones who clear up the mess when enthusiastic (indeed, sometimes evangelical) but naive Java developers come in and produce overengineered, inefficient rubbish that isn't fit to send to a customer and costs a fortune to maintain.
No doubt you can do all of that stuff in Scheme. Unfortunately, actually doing so produces a person who thinks only in terms of Scheme, which is as bad as a person who thinks only in terms of Java or C. It also leads to rose-tinted spectacles, as you kindly illustrated with the nonsense about proving your software is perfect. Whatever you were actually proving in your classes, I guarantee that wasn't it.
Well, I just looked up the Surrey Computing BSc brochure (warning: PDF) and to be brutally honest, I'm not that impressed.
Perhaps their presentation in the brochure is bad or their courses are unfortunately named, but when two of the five "core" modules in the first year are given as "web publishing" and "professional studies", while the first course in data structures and algorithms features in the second year alongside "usability engineering", alarm bells are ringing pretty loudly.
Where are the courses on different programming styles and languages? Operating systems? Applications like databases, graphics and image processing, natural language processing? Numerical analysis? Programming language design and compiler construction? There do seem to be some interesting courses among the optional modules, particularly by the final year, so perhaps these things really are covered and the advertising is poor.
I suggest you seek a more detailed syllabus, and compare it with alternatives offered at other universities, before committing to this course. Looking at a few other places (I tried Cambridge, Warwick, Brunel, Imperial) there is considerable variation in what's offered, and at first glance, I'd suggest the Imperial or Cambridge syllabuses as guidelines for the sort of things to look for.
For the record, I had a quite different experience at the University of Cambridge Computer Lab. I was there nearly a decade ago, but things don't seem to have changed too much. They do use Java for the basic intro to programming courses there, and to be honest the guy who taught them was pretty rubbish and most of us ignored them. However, there were also courses on functional programming, Prolog/AI, and so on, which introduced me to some concepts I hadn't previously encountered despite being an enthusiastic geek at heart. So not all UK universities have fallen into the cheap/vocational trap.
I did study some formal CS at university, but never heard the term "spinlock" before. I did, however, implement the ideas in the Wikipedia article cited in another reply at the end of last week, simply by looking at the available tools and guarantees provided by the programming environment I was using, and concluding that what you call a spinlock was the simplest and most efficient way to achieve the behaviour I needed.
I think this is the difference between the approach you seem to value and that valued by places like MIT: you do stuff by rote because a book told you to, while people who have learned to think analytically will simply create it if they need it.
That's a pretty bold statement. In what major areas do you think functional programming has no application?
What do you oppose: learning LISP, or waiting until you're ready before trying to learn it?
You shouldn't be intensely worried, but reading around your subject is pretty much always a smart move if you're a serious student. I learned this lesson very late in my academic career, and now wish I'd understood what the phrase really meant a couple of years earlier.
In this business, knowing multiple programming languages (and in particular, knowing multiple programming styles -- OOP, procedural, functional, etc.) is a big asset. It helps you to think about problems in more varied ways, even if you will ultimately code the solution in whatever language is required by your particular professor or, in due course, employer.
There are two suggestions I've heard in the past that I appreciate more as time goes by: try to learn a new programming language and to read a new book about programming every year. In the former case, if you're learning Java, that's OK, it's a pragmatic tool that's widely used in industry and it will teach you one way of thinking about a problem. I suggest the following as complementary languages, to be explored as and when you have the opportunity:
There are various other unique things you'll take away from each of the above, but if you spend perhaps a few months exploring each of them in some detail, it will make you a much more rounded programmer. I'd suggest either the above order, or swapping the first two around and going for a functional programming language and then something low-level. The requirements of your course or good advice from friends/teachers may guide you otherwise. Go with what works for you.
To make your learning practical, pick some simple projects, perhaps to practise whatever algorithms you happen to be studying lately in other courses, and write a few small but real programs in each language. For example, if you're learning about operating system basics, try rewriting a couple of simple OS utilities or networking tools in C or assembler. If you're learning about databases, try writing a simple web front-end for a database, and power it with a few CGI scripts written in Perl or Python that use SQL to look up and modify the data in your database. If you're learning about graphics and image processing, write a simple ray tracer in Haskell or ML.
Along the way, you'll develop potentially useful real world experience with things like OS APIs (and perhaps how they vary between platforms, and thus why standards are useful for these things), HTML/CSS and CGI for web development, SQL for database work, and so on.
As you go through this, consider buying a good textbook on major subjects (programming languages, databases design and SQL, graphics algorithms, etc.) or make sure you've identified some good reference and tutorial material on the web. The latter is a big advantage for the modern compsci student, though you have to be careful to check your sources are well-regarded and not just a pretty web site with an authoritative tone of voice written by someone very enthusiastic but regrettably ill-informed. Things like FAQs and newsgroups can be valuable sources of information, but sometimes, there's just no substitute for a well-written, well-edited, authoritative textbook.
Anyway, this post is now far too long, so I'll stop there. Please consider it "the approach I'd take if I could have my university days again" and take it for whatever it's worth to you. Good luck. :-)
So tell me, what does a reference implementation of a document format look like?
A blood-covered chair nailed to her front door?
Only if they are minimal, complete and unambiguous. In other words, only if everyone implementing the standard will follow the same conventions in practice. Since Microsoft's XML "standard" is neither complete nor unambiguous, it's worth about as much to anyone else as a patent dressed up in obscuring legalese, and any standards body worth its salt should reject it.
Great, thanks.
The sad thing is, I would have preferred the alcoholic over any of the likely leaders of the three big political parties in England going into the next general election. Cameron sounds increasingly like Blair Lite, and the other two don't really seem to be saying much at all. In Campbell's case, I think he just doesn't have a loud enough voice: his party blew the whole leg off when they dumped Kennedy, and will now pay the price for their lack of vision. In Brown's case, I think he is a very shrewd political operator who knows when to keep his mouth shut, which will win him nothing from people like me, but may see exactly the outcome he wants in about six years' time. (See if you can figure out how I think that will happen...)
You're right about the aptly named RIP Act heralding the beginning of the end, of course. I remember back then, thinking how draconian Jack Straw was as Home Secretary. Compared to his successors, he was practically Gandhi.
You write as if they are mutually exclusive. Why?
That makes no sense. The whole point of the interface/implementation separation is that you can change the implementation without changing the interface. If you change the interface, you will necessarily change the implementation at least enough to match.
I'm also curious about your repeated reference to "formal" techniques. What do you mean by this? Do you also consider unit tests a formal technique? Commenting code? Structured programming? Where do you draw the line between what is helpful and what is a burden?
Unfortunately, as others have noted, that just isn't practical. For example, the following sites that I use regularly require IE to function properly:
None of those is expendable, and there is little chance of most of them supporting other browsers fully in the near future. (Unlike some people around here, I care more about the benefits of the financial services provided by my financial services companies than I do about have to use IE to access their web sites.)
Well, just because you've got a contract, that doesn't mean it will do anything useful when you enforce it. ;-)
Most software projects also produce crap at the end. As with much in life, you get what you pay for.
By a similar argument, we should all give up with unit and integration testing, because the additional effort required to write automated tests for individual modules and then for interactions between them is prohibitive. And yet, I suspect we would agree that automated unit and integration tests can be very useful and provide a good return on investment.
Hmm... Wouldn't it be great if we had a mechanism that could make sure our code always met current expectations, and which could automatically notify us if loopholes started to creep in as the requirements changed and bits of code here and there were modified to keep up?
You're quite right about using a variety of tools, of course, but some of them are much cheaper than others. For example, it costs less to find a bug using static code analysis that can be performed automatically every check-in than to find the same bug using human intervention during a formal code inspection.
Is it really that rare? Or are you just so used to shoddy software that you've come to accept it without realising?
A huge proportion of the computers connected to the Internet are now part of botnets, mainly caused by basic security failings in the operating system and networking software installed on those machines. The net loss of quality of life and financial cost to business as a result of a relatively small number of bugs in that area is staggering.
We now have quite advanced software in many consumer goods. What is the cost in quality of life if a new PVR fails to record one programme for every consumer who buys it, or a new washing machine occasionally randomly sets the temperature to 90 when it should have been 40 and ruins a whole load of clothes?
It is an unfortunate reality that most businesses depend on a few very widely used pieces of software. What is the cost of a little UI bug in Word, if it wastes 30 seconds of time for 10 million users?
Not so long ago, someone at the UK HQ of our organisation sent out a mail that was supposed to have the latest phone list in it. Unfortunately, due to some gremlin somewhere, the data generated included a significant amount of other, supposedly confidential, information about every employee in the UK, which was sent to every other employee in the UK. I don't know whether that was human error, but it's the sort of thing that could easily enough be caused by a small mistake in whatever script was used to generate the report, and a huge amount of bad feeling was generated amongst the entire UK employee base as a result.
I could go on, but hopefully my point is made by now.
Perhaps it's just wishful thinking, but I can't help noticing an increasing number of comments among my friends and family recently about just wanting
Or, just use assert (n != UNINITIALISED_DATA) instead of magic numbers, and avoid the obscure idiom. :-)
Actually, in your example I'd prefer the following. (Apologies for losing the indentation; how do you get Slashdot not to do that?)
The comments in English add no value at all: they simply repeat, in a more verbose and less precise fashion, what the code already says.
I'm not really sure what you're trying to demonstrate with the assertions in this case. Your first condition is testing for something that sounds like it could legitimately go wrong at run-time, i.e., something that is not a logic error. That isn't really a very good use of pre/postconditions, which are (IMHO) best reserved for things that should never go wrong. The later tests are restating what you've already stated immediately above them, and again they add no real value.
I think Slashdot cut off part of your post there. You might like to repost what you originally intended.
I think what they usually want is the best return on investment, which isn't necessarily the same as what you wrote there.
In any case, I think your entire post is backwards, though I've heard the same argument many times before. If you want to get lots of features working quickly, the only way to achieve it is to do the development properly. Neglecting QA is a false economy, as is dropping other defensive programming and active testing approaches earlier in the development process, which if anything are more valuable, because they find problems sooner. This is why the whole "pick two of good, fast and cheap" thing is quite misleading: while the up-front costs for people who can do good and fast can be a lot higher than those of code monkeys, they'll give you a much better product that is likely to cost far less measured over its entire lifetime.
So tell us, oh wise one, what would you have us do? It's easy to snipe from the cheap seats, but offering constructive suggestions is the only thing worth a damn in this debate.
We know that there will be a general election at some stage within the next three years or so, at which point it is all but certain that Labour will lose power.
We know that the current political climate has stripped away most of the real power from Tony Blair's administration, and that it is unlikely that they will be able to pass much further heinous legislation.
We know that opposition parties are openly saying they will kill/repeal much of the nastiest stuff New Labour have legislated in recent years, and this is likely to be a major election issue.
We also know, as I explained in another post in this discussion, that Labour really don't care about any sort of peaceful protest at this point, because they have nothing to lose.
So what is the wisest course of action for the many of us who disagree with their current policies? Should we wait patiently, knowing that little further harm can be done as long as we maintain peaceful pressure on the government, and then use what's left of our democratic system to get rid of them decisively when our opportunity comes? Or should we do something else, and if so, what?