While your argument is entirely reasonable, I'm not sure it's really the point of this particular discussion. From the point of view of quality control and programmer error, I'd say a bug is exactly a failure of the finished program to behave as the designers' spec indicates. If the designers' spec doesn't meet the requirements, that's a problem, but it's a different kind of problem that lives further up the chain.
My point wasn't so much about the sunbather, but rather the fact that the guy who decided to film her without permission while she was on her own property (this wasn't a public activity) was being treated like a victim by the legal system (as is made clear by comments from both prosecutor and judge), yet not held accountable in any way for what many of us would surely consider inappropriate behaviour.
The scary thing is this idea that anything you know or have access to is automatically suitable for public consumption, and you automatically have the right to share it. It's tantamount to saying that no-one has any moral right to privacy, even in their own home (or, in the case of businesses, in their own office and among their own staff). I personally don't want to live in a world where it's OK not to keep secrets you've been trusted with.
OK, I've heard the "information wants to be free" mantra a zillion times, and I've met my fair share of people who think their right to free speech (no matter what they're saying and what the consequences will be) trumps anything else.
I've seen an absurd story on the news today about a British woman who was prosecuted for indecent exposure, because she had the audacity to sunbathe nude in her own garden. (She was acquitted, but the comments by both the public prosecutor and the judge were profoundly inappropriate, and no-one seems to have taken any action against the "offended" neighbour who videoed the nude sunbather without her permission - something that probably is illegal under the recent Sexual Offences Act.)
You know the thing that really scared me today? A professor (in the UK sense, i.e., a very senior academic) talking about the "semantic web" and implying that in a few years, everyone will have a unique "Internet ID", and everything from their personal details to pictures of their wedding will be on-line for all to look up, instantly and reliably.
Choosing to share your personal information with the world is one thing, though I suspect a great many of the enthusiastic youngsters supporting trendy web sites today will regret it one day. Choosing to share others' personal information with the world is an entirely different thing, and I'm not sure I want to live in a world where everything about you is assumed to be public knowledge.
Maybe I'm just biased, since a bitter ex of mine did once post intimate and formerly private personal messages on her blog (but edited and with modified dates). It just seems to me that this sort of thing is happening ever more often: it's assumed that no-one you deal with has a private life, and if you know it, it's perfectly fine to share it with others. I guess the whole posting confidential company information thing is just another nail in the coffin: as the saying goes, privacy is dead, and we have killed it.
It's tragic, and it's even more tragic that most people don't even realise. Yet.
Somehow, I just had a vision of a car parking on a level crossing, the door locks automatically engaging, and then someone's phone ringing, as a guy in a sling stands outside the car looking mean in a suit.
I can't think where that came from, or why it's connected to your comment...
Tell that bold bit to Knuth. In fact, go find a bug in TeX; is he still offering a substantial financial reward to anyone who does?
As others have said, whether you fix a bug is a matter of return on investment, and whether you ship with bugs is a matter of acceptable risk/reward. However, claiming that software can't be made without bugs (or at least with far fewer bugs than most software today ships with, since we aren't all of the calibre of Knuth) is simply trying to defend shoddy work.
But the consumers speaking with their wallets doesn't really tell us very much in the software case. There are far more productive and reliable ways to develop software than those typically used in the mainstream. However, until the mainstream catches up and lots of developers are familiar with better techniques and using better tools, all the big name commercial offerings will be as bad as each other, so there's not much for the consumer to vote between.
Here's an example: I reported a way to crash Paint Shop Pro X to Corel via their web site not long ago. I was trialling it, and considering buying it, but click the wrong button on the toolbar and wham, segfault city. That betrays a pretty crappy underlying design somewhere. Do you know what they did? They closed the bug. Immediately. Without so much as a "thanks for letting us know".
Now, I work in software development. We make high performance maths libraries, that are used in things like CAD programs. If a customer of ours reports a crash bug in our code, the average time to sending them a patch release containing the fix is a few hours. Go figure.
The sad thing is, I did buy Paint Shop Pro X in the end (though through Amazon, who charge about half as much as Corel themselves). Other things I'd looked at and within my budget - the GIMP, for one - just couldn't do what I wanted to, or had similarly obscene bugs. So despite their pathetic attitude to fixing a very serious problem in their software, Corel have wound up with my money anyway. Of course, as soon as someone comes along with a similar "budget graphics" app that has a good range of features and better quality, I'll never be buying another upgrade to PSP. I won't hold my breath...
I'm not sure either of your legal premises hold up.
Firstly, as soon as the ambulance services comes under fire for using a version of WidgetWorx with known problems, they could line up a dozen expert witnesses to testify that pretty much all software has bugs, and it takes someone of the calibre of Don Knuth to produce a complex program that (probably) doesn't (any more). It is therefore unrealistic to expect that any software wouldn't have bugs, even if they weren't disclosed ahead of time.
Secondly, if the ambulance service purchased/licensed/whatever the WidgetWorx software when its faults were already known and disclosed, surely it would be a slam dunk for them not to be liable for anything? I can't sue my car manufacturer because I can't outrace a Ferrari, even though the spec sheet said top speed of 90mph, now can I? If anything, the liability should arise the other way around: if the software manufacturer knowingly shipped a product that was unfit for purpose because of bugs, then they'd have the moral low ground in any law suit.
Probably not good for Trolltech's users
on
Trolltech Going Public
·
· Score: 3, Insightful
Unfortunately, IPOs rarely prove to be advantageous to the customers of the company in question. If I were making decisions about a cross-platform toolkit to use for development, Qt would just have gone way down the list. It's all very well having the source, but it's still much better if the guys who really know it inside out are doing the maintenance, and some of that maintenance may not be in the future shareholders' interests.
Trouble is, these are the qualifications employers look for.
But what employers, for what jobs? If you're looking for someone to type up your documents and your workplace uses MS Office, then it's perfectly reasonable to look for an indication that a potential employee is competent to use MS Office. On the other hand, where I work (as a developer of cross-platform software) not one of the qualifications you mentioned would carry any weight at all.
XP also talks about design and and simplicity, please check your facts.
Sorry, but it's going to take a lot more than a cheesy Wikipedia citation to undo the damage here. The entire XP approach, and repeated comments by its high-profile advocates, revolve around the idea that unit tests are the primary means of ensuring program quality, and that the primary goal of writing or changing code should be to make sure that it passes, and continues to pass, those tests.
Perhaps more significantly, those few people I know who actually work in an XP-based environment (or, to be fairer, their managers who set their procedures based on XP) have bought into this philosophy hook, line and sinker. I have been told by some senior developers, quite categorically, that it's perfectly safe for them to hack around - RefactorWithFunnyPunctuation or whatever they call it this week - as long as the tests all still pass, because that guarantees that nothing can go wrong. Guess what? My current project has thousands of automated tests, too, but neither my training nor my experience on this project tell me that hacking around is safe as a consequence. There is simply no substitute for understanding what your code is supposed to do and why.
That's when you have to rewrite the code if there's nothing more important to do or your client is willing to pay for that (this isn't always an option in real world conditions and the norm is to hack around).
The norm for crappy coders is to hack around. Good coders know that the extra time taken in the short term to maintain a clean design pays for itself many times over in the long term. My employer learned the hard way, when they had to pay me a year's salary to get a feature they should have been able to have in six weeks, because the underlying model had become so flawed after a decade of hacking around that we'd reached breaking point, and there was simply no alternative but to spend the time going over it and ironing out all the wrinkles before we continued. (This is not a statement on my abilities as a designer or coder. When I explained to my team leader and project manager why I believed it was necessary to clean up the design before doing the project they'd asked me to do, and provided examples to illustrate the sort of thing that had slipped through the net, they agreed and allowed me the extra time.)
<sarcasm>Yes because the people who learn the theorical way with paper and pen don't cheat in exams and don't memorize whole textbooks only to improve their final results, no, they understand everything they read during that last week before their exams.<sarcasm> The trial and error learning process is not blind as you think, each particular failure gives you more experience and improves your general awareness.
Why so defensive? Your sarcastic comment is pointless: whether people make the effort to learn properly or just cheat is entirely irrelevant to the question at hand.
As I said before - you even quoted me - the trial and error process can be a good way to learn. But if you continue with that mindset when you're writing production code, rather than taking the time to work out what should be happening and why and then making sure that your code gets the right results for the right reasons, then you will always be a crappy coder.
What you don't seem to understand is that you won't have a second chance of crashing a plane... If software crashes you fix the bug and repeat the test, and this is where the analogy fails.
Not all bugs crash code. The kind of bug that creeps in with the trial-and-error approach that MarkusQ challenged is usually far more sinister: it may give you subtly incorrect results, and often go unnoticed for many years. Even if you use automated unit tests, they rarely give 100% coverage; they're an extra layer of security on top of writing clean code with a systematic design, not a substitute for it. (This is where the so-called extreme programming crowd often miss the point, IME.)
Here's a real-world example: not so long ago, I spent around a year reworking the core subsystem of a mathematical library, to bring it back to a coherent design that didn't suffer from ten years of small changes on top of other small changes that weren't fully thought through but had "worked at the time". That's your trial-and-error approach in action.
Now, all those changes hadn't caused regressions in our automated test results, and they did fix whatever bug they were supposed to fix. But alas, two wrongs do make a right, if both of them are multiplying by -1. You don't spot the bug until the time you get a positive number when it's normally negative, and then you realise that the code should actually have taken an absolute value instead of doing the second sign-flip.
It took a long time to rework that code, during which I fixed rather a lot of such bugs. Perhaps unsurprisingly, in the process I also fixed rather a lot of the outstanding minor bug reports that had been hanging around as low-priority things where no-one could immediately see what the problem was.
This is the benefit of understanding your code rather than playing try-it-and-see until you get something that looks right. It's not that the latter can't be a good way to learn, but it's no way to write production code.
So I'd say teach the students how to use a debugger from the beginning.
I'm sorry, but I couldn't disagree more. It's entirely possible to debug most programs without ever needing a debugger, just by using some basic instrumentation. If anything's going to be taught about defensive programming and debugging in an introductory course, it should be the simple idea that you can add diagnostic output to your code using the same tools you use for any other I/O, with a little thought about how this can tie in with other programming ideas (e.g., a good place to dump data is on the way into or out of a module). Perhaps the use of assertions could be mentioned in the same context.
These are simple ideas, directly related to what the student should be learning anyway, and they take little time to mention. Debuggers, profilers and the like are all valuable tools to a professional who knows how to use them, but they're well above the level of an intro-to-programming course, and in the real world instrumentation is usually more useful anyway.
On the other hand, you can at least thank [Microsoft] for not totally screwing up their IDE. Not like Internet Explorer, where the best version was probably version 2.0, or maybe 3.0, and it pretty much went downhill from there.
Actually, for those of us who use Visual C++, a lot of people will tell you that version 6 was the high point, and everything's gone to hell since all the.Net rubbish got tied into it. There are precious few changes since v6 that actually add value, while performance has plummeted and key features have been removed entirely, or removed and then reintroduced in a half-assed fashion. (Yeah, yeah, Visual C# has all the funky new toys. That's not much use to those of us who program C++ for a living.)
I work in an office where the devs have pretty much a free choice of tools. (We build on a dozen or so platforms anyway, so which one people prefer to develop with can be left to personal preference.) I don't think it's a coincidence that more people still use VC++6 than anything else, and that includes several people who installed one or more.Net incarnations and subsequently removed them again after a few days.
Now, VC++ 6 had an IDE that's probably about right for the kind of intro course we're talking about: it has basics like syntax highlighting and some source code navigation aids, it has a good, well-integrated debugger, and it provides a friendly front-end to the various compiler and linker options, but you still have a clear "compile", "link", "clean", etc. on the menus for when the instructor is explaining the build process.
"When men talk about defense, they always claim to be protecting women and children, but they never ask the women and children what they think." - Pat Schroeder
Why are you sending out your CV in Word format, instead of PDF?
Presumably the employers he's applying to asked for it in that format. That's not unusual around here, certainly.
Personally, I give immediate demerits to any employer who requires.doc and won't accept.pdf, but more because I work in a technical industry and such a requirement betrays either a lack of technical competence or an HR department that get in the way of doing useful things, neither of which is a good sign...
Not saying it's better, but it's been in use for a very long time (longer than Ax sizes, of course), and A4 is most definitely not the default here. Blame it on nostalgia;)
I'll blame it on whatever you want, just as soon as I've finished my pint.
Problem: There is no straightforward way to set keyboard shortcuts for assigning/removing styles, inserting specific special characters, etc. For non-trivial documents, this means repeated use of the mouse/toolbars/insert character dialog are required.
Workaround: Macros can be used, though this is slow and awkward.
Typographical weaknesses
Problem: Support for high-quality typography is poor.
In particular, support for professional-grade OpenType fonts is weak, with some of the best (the Zapfino Extra family is a clear example) not rendering properly at all on screen and even being substituted with completely different fonts in PDF output. No advantage is taken of features like ligatures, true small caps, different figure styles, stylistic and contextual alternates, and similar refinements. More generally, the layout algorithms (e.g., for H&J) are poor.
Workaround: There isn't really one: these are straight-up missing features or outright bugs. However, DTP packages already provide this sort of feature routinely, and more significantly, new versions of MS Office are likely to take advantage of the OpenType rendering support in Windows. OpenOffice's cross-platform nature may be a liability here.
Poor support for formal, structured documents
Problem: There is very limited support for things like structured headings and matching tables of contents (try generating two tables, one with only chapter titles+subtitles and one with chapter titles+all subheadings, or formatting a table of contents significantly differently from the default styles). There is no direct support for bibliographies. The UI for bullets, numbering and list styles is poor.
Workaround: Short of typing things in manually (or editing the auto-generated version every time) there's not much you can do. Cross-references can do a limited amount to support bibliographies within a single document.
Poor support for complex page layouts
Problem: Features like frames don't always work as expected. There seem to be several obscure bugs where multiple frames are concerned. Features like overlapping frames and transparency aren't supported.
Workaround: Usually patience or ingenuity, IME.
Start-up times are very long
Problem: It takes forever to load Writer the frst time.
Workaround: Get a faster machine?:-)
Mail merge support is very poor
Problem: Various. The UI is confusing. Output options are limited. (Can you merge to a single file in the latest version? You couldn't the last time I tried it.) The data source system is bug-ridden to the point that it's easier to start again and set up a new source if the slightest thing goes wrong.
Workaround: I've never found one for most of this, although some limitations can be overcome by merging-to-print and using a cheat printer driver that outputs to PostScript/PDF or similar.
1. the whole "genius" of client-side xslt is it makes the client do work that would otherwise drag the server.
The problem with that is that client-side xslt has suffered from some pretty serious bugs over the years, and still does on many platforms. I think basic numbering in Gecko browsers works these days, but for a long time it didn't. So much for those funky auto-generated footnotes/references/tables of contents...
As I mentioned elsewhere, we now use a server-side XSLT-based process to get our pages ready, and the lack of reliability of client-side rendering was a major reason for deciding on that approach.
FWIW, server-side XSLT isn't particularly complicated. I'm just shifting a medium-sized site (maybe 100 unique pages) for a club I belong to onto a new host, and I set up all the necessary processing within an hour or two. For the benefit of being able to see/control the actual XHTML that you're shipping to browsers, IMHO it's more than worth it.
We've been using this approach through three generations of the site now, and I find it strange that anyone still uses things like Frontpage or Dreamweaver. They seem like children's toys in comparison to what you can do with the XSLT - and let's face it, XSLT isn't exactly the world's best programming language!
Standards-based, accessible websites [...] tend to produce better search engine results, be faster to download, use less bandwidth, and improved usability.
Repeat after me, please: correlation does not imply causation.
I'm amazed that we haven't seen almost the same answer from every pro commenting in this thread: standards are a means to an end. If following W3C standards does gain you better search engine placement, or cut down your bandwidth, knock yourself out. And of course, if following W3C standards means your site renders better for people you care about (which isn't necessarily everyone with a web browser) then go for it. But don't follow W3C standards, or anyone else's, dogmatically. Always know why following a particular standard will help you.
Personally, I do try to keep the code for the site I run valid, but that's more because the benefits above do apply to me (for example, my server logs tell me around 1/3 of my visitors are using a Gecko-based browser) than anything else.
Slashdot Mirror
Not convinced. No digg!
While your argument is entirely reasonable, I'm not sure it's really the point of this particular discussion. From the point of view of quality control and programmer error, I'd say a bug is exactly a failure of the finished program to behave as the designers' spec indicates. If the designers' spec doesn't meet the requirements, that's a problem, but it's a different kind of problem that lives further up the chain.
My point wasn't so much about the sunbather, but rather the fact that the guy who decided to film her without permission while she was on her own property (this wasn't a public activity) was being treated like a victim by the legal system (as is made clear by comments from both prosecutor and judge), yet not held accountable in any way for what many of us would surely consider inappropriate behaviour.
The scary thing is this idea that anything you know or have access to is automatically suitable for public consumption, and you automatically have the right to share it. It's tantamount to saying that no-one has any moral right to privacy, even in their own home (or, in the case of businesses, in their own office and among their own staff). I personally don't want to live in a world where it's OK not to keep secrets you've been trusted with.
The problem is when somebody else puts it on-line for you...
OK, I've heard the "information wants to be free" mantra a zillion times, and I've met my fair share of people who think their right to free speech (no matter what they're saying and what the consequences will be) trumps anything else.
I've seen an absurd story on the news today about a British woman who was prosecuted for indecent exposure, because she had the audacity to sunbathe nude in her own garden. (She was acquitted, but the comments by both the public prosecutor and the judge were profoundly inappropriate, and no-one seems to have taken any action against the "offended" neighbour who videoed the nude sunbather without her permission - something that probably is illegal under the recent Sexual Offences Act.)
You know the thing that really scared me today? A professor (in the UK sense, i.e., a very senior academic) talking about the "semantic web" and implying that in a few years, everyone will have a unique "Internet ID", and everything from their personal details to pictures of their wedding will be on-line for all to look up, instantly and reliably.
Choosing to share your personal information with the world is one thing, though I suspect a great many of the enthusiastic youngsters supporting trendy web sites today will regret it one day. Choosing to share others' personal information with the world is an entirely different thing, and I'm not sure I want to live in a world where everything about you is assumed to be public knowledge.
Maybe I'm just biased, since a bitter ex of mine did once post intimate and formerly private personal messages on her blog (but edited and with modified dates). It just seems to me that this sort of thing is happening ever more often: it's assumed that no-one you deal with has a private life, and if you know it, it's perfectly fine to share it with others. I guess the whole posting confidential company information thing is just another nail in the coffin: as the saying goes, privacy is dead, and we have killed it.
It's tragic, and it's even more tragic that most people don't even realise. Yet.
Somehow, I just had a vision of a car parking on a level crossing, the door locks automatically engaging, and then someone's phone ringing, as a guy in a sling stands outside the car looking mean in a suit.
I can't think where that came from, or why it's connected to your comment...
Tell that bold bit to Knuth. In fact, go find a bug in TeX; is he still offering a substantial financial reward to anyone who does?
As others have said, whether you fix a bug is a matter of return on investment, and whether you ship with bugs is a matter of acceptable risk/reward. However, claiming that software can't be made without bugs (or at least with far fewer bugs than most software today ships with, since we aren't all of the calibre of Knuth) is simply trying to defend shoddy work.
But the consumers speaking with their wallets doesn't really tell us very much in the software case. There are far more productive and reliable ways to develop software than those typically used in the mainstream. However, until the mainstream catches up and lots of developers are familiar with better techniques and using better tools, all the big name commercial offerings will be as bad as each other, so there's not much for the consumer to vote between.
Here's an example: I reported a way to crash Paint Shop Pro X to Corel via their web site not long ago. I was trialling it, and considering buying it, but click the wrong button on the toolbar and wham, segfault city. That betrays a pretty crappy underlying design somewhere. Do you know what they did? They closed the bug. Immediately. Without so much as a "thanks for letting us know".
Now, I work in software development. We make high performance maths libraries, that are used in things like CAD programs. If a customer of ours reports a crash bug in our code, the average time to sending them a patch release containing the fix is a few hours. Go figure.
The sad thing is, I did buy Paint Shop Pro X in the end (though through Amazon, who charge about half as much as Corel themselves). Other things I'd looked at and within my budget - the GIMP, for one - just couldn't do what I wanted to, or had similarly obscene bugs. So despite their pathetic attitude to fixing a very serious problem in their software, Corel have wound up with my money anyway. Of course, as soon as someone comes along with a similar "budget graphics" app that has a good range of features and better quality, I'll never be buying another upgrade to PSP. I won't hold my breath...
I'm not sure either of your legal premises hold up.
Firstly, as soon as the ambulance services comes under fire for using a version of WidgetWorx with known problems, they could line up a dozen expert witnesses to testify that pretty much all software has bugs, and it takes someone of the calibre of Don Knuth to produce a complex program that (probably) doesn't (any more). It is therefore unrealistic to expect that any software wouldn't have bugs, even if they weren't disclosed ahead of time.
Secondly, if the ambulance service purchased/licensed/whatever the WidgetWorx software when its faults were already known and disclosed, surely it would be a slam dunk for them not to be liable for anything? I can't sue my car manufacturer because I can't outrace a Ferrari, even though the spec sheet said top speed of 90mph, now can I? If anything, the liability should arise the other way around: if the software manufacturer knowingly shipped a product that was unfit for purpose because of bugs, then they'd have the moral low ground in any law suit.
Unfortunately, IPOs rarely prove to be advantageous to the customers of the company in question. If I were making decisions about a cross-platform toolkit to use for development, Qt would just have gone way down the list. It's all very well having the source, but it's still much better if the guys who really know it inside out are doing the maintenance, and some of that maintenance may not be in the future shareholders' interests.
But what employers, for what jobs? If you're looking for someone to type up your documents and your workplace uses MS Office, then it's perfectly reasonable to look for an indication that a potential employee is competent to use MS Office. On the other hand, where I work (as a developer of cross-platform software) not one of the qualifications you mentioned would carry any weight at all.
What a terribly sad, black and white world you must live in.
Tell me, in your black and white world, what colour results when two people's inalienable and equally valuable freedoms come into conflict?
Sorry, but it's going to take a lot more than a cheesy Wikipedia citation to undo the damage here. The entire XP approach, and repeated comments by its high-profile advocates, revolve around the idea that unit tests are the primary means of ensuring program quality, and that the primary goal of writing or changing code should be to make sure that it passes, and continues to pass, those tests.
Perhaps more significantly, those few people I know who actually work in an XP-based environment (or, to be fairer, their managers who set their procedures based on XP) have bought into this philosophy hook, line and sinker. I have been told by some senior developers, quite categorically, that it's perfectly safe for them to hack around - RefactorWithFunnyPunctuation or whatever they call it this week - as long as the tests all still pass, because that guarantees that nothing can go wrong. Guess what? My current project has thousands of automated tests, too, but neither my training nor my experience on this project tell me that hacking around is safe as a consequence. There is simply no substitute for understanding what your code is supposed to do and why.
The norm for crappy coders is to hack around. Good coders know that the extra time taken in the short term to maintain a clean design pays for itself many times over in the long term. My employer learned the hard way, when they had to pay me a year's salary to get a feature they should have been able to have in six weeks, because the underlying model had become so flawed after a decade of hacking around that we'd reached breaking point, and there was simply no alternative but to spend the time going over it and ironing out all the wrinkles before we continued. (This is not a statement on my abilities as a designer or coder. When I explained to my team leader and project manager why I believed it was necessary to clean up the design before doing the project they'd asked me to do, and provided examples to illustrate the sort of thing that had slipped through the net, they agreed and allowed me the extra time.)
Why so defensive? Your sarcastic comment is pointless: whether people make the effort to learn properly or just cheat is entirely irrelevant to the question at hand.
As I said before - you even quoted me - the trial and error process can be a good way to learn. But if you continue with that mindset when you're writing production code, rather than taking the time to work out what should be happening and why and then making sure that your code gets the right results for the right reasons, then you will always be a crappy coder.
Not all bugs crash code. The kind of bug that creeps in with the trial-and-error approach that MarkusQ challenged is usually far more sinister: it may give you subtly incorrect results, and often go unnoticed for many years. Even if you use automated unit tests, they rarely give 100% coverage; they're an extra layer of security on top of writing clean code with a systematic design, not a substitute for it. (This is where the so-called extreme programming crowd often miss the point, IME.)
Here's a real-world example: not so long ago, I spent around a year reworking the core subsystem of a mathematical library, to bring it back to a coherent design that didn't suffer from ten years of small changes on top of other small changes that weren't fully thought through but had "worked at the time". That's your trial-and-error approach in action.
Now, all those changes hadn't caused regressions in our automated test results, and they did fix whatever bug they were supposed to fix. But alas, two wrongs do make a right, if both of them are multiplying by -1. You don't spot the bug until the time you get a positive number when it's normally negative, and then you realise that the code should actually have taken an absolute value instead of doing the second sign-flip.
It took a long time to rework that code, during which I fixed rather a lot of such bugs. Perhaps unsurprisingly, in the process I also fixed rather a lot of the outstanding minor bug reports that had been hanging around as low-priority things where no-one could immediately see what the problem was.
This is the benefit of understanding your code rather than playing try-it-and-see until you get something that looks right. It's not that the latter can't be a good way to learn, but it's no way to write production code.
I'm sorry, but I couldn't disagree more. It's entirely possible to debug most programs without ever needing a debugger, just by using some basic instrumentation. If anything's going to be taught about defensive programming and debugging in an introductory course, it should be the simple idea that you can add diagnostic output to your code using the same tools you use for any other I/O, with a little thought about how this can tie in with other programming ideas (e.g., a good place to dump data is on the way into or out of a module). Perhaps the use of assertions could be mentioned in the same context.
These are simple ideas, directly related to what the student should be learning anyway, and they take little time to mention. Debuggers, profilers and the like are all valuable tools to a professional who knows how to use them, but they're well above the level of an intro-to-programming course, and in the real world instrumentation is usually more useful anyway.
Actually, for those of us who use Visual C++, a lot of people will tell you that version 6 was the high point, and everything's gone to hell since all the .Net rubbish got tied into it. There are precious few changes since v6 that actually add value, while performance has plummeted and key features have been removed entirely, or removed and then reintroduced in a half-assed fashion. (Yeah, yeah, Visual C# has all the funky new toys. That's not much use to those of us who program C++ for a living.)
I work in an office where the devs have pretty much a free choice of tools. (We build on a dozen or so platforms anyway, so which one people prefer to develop with can be left to personal preference.) I don't think it's a coincidence that more people still use VC++6 than anything else, and that includes several people who installed one or more .Net incarnations and subsequently removed them again after a few days.
Now, VC++ 6 had an IDE that's probably about right for the kind of intro course we're talking about: it has basics like syntax highlighting and some source code navigation aids, it has a good, well-integrated debugger, and it provides a friendly front-end to the various compiler and linker options, but you still have a clear "compile", "link", "clean", etc. on the menus for when the instructor is explaining the build process.
Would you care to cite a source for that incredibly high number?
Think of the children, you say, sir?
Sorry, but as they say, if you have to ask, you can't afford it...
Blockquoth the AC:
Presumably the employers he's applying to asked for it in that format. That's not unusual around here, certainly.
Personally, I give immediate demerits to any employer who requires .doc and won't accept .pdf, but more because I work in a technical industry and such a requirement betrays either a lack of technical competence or an HR department that get in the way of doing useful things, neither of which is a good sign...
I'll blame it on whatever you want, just as soon as I've finished my pint.
Cheers, :-)
Your friendly local Brit
Keyboard usability
Problem: There is no straightforward way to set keyboard shortcuts for assigning/removing styles, inserting specific special characters, etc. For non-trivial documents, this means repeated use of the mouse/toolbars/insert character dialog are required.
Workaround: Macros can be used, though this is slow and awkward.
Typographical weaknesses
Problem: Support for high-quality typography is poor. In particular, support for professional-grade OpenType fonts is weak, with some of the best (the Zapfino Extra family is a clear example) not rendering properly at all on screen and even being substituted with completely different fonts in PDF output. No advantage is taken of features like ligatures, true small caps, different figure styles, stylistic and contextual alternates, and similar refinements. More generally, the layout algorithms (e.g., for H&J) are poor.
Workaround: There isn't really one: these are straight-up missing features or outright bugs. However, DTP packages already provide this sort of feature routinely, and more significantly, new versions of MS Office are likely to take advantage of the OpenType rendering support in Windows. OpenOffice's cross-platform nature may be a liability here.
Poor support for formal, structured documents
Problem: There is very limited support for things like structured headings and matching tables of contents (try generating two tables, one with only chapter titles+subtitles and one with chapter titles+all subheadings, or formatting a table of contents significantly differently from the default styles). There is no direct support for bibliographies. The UI for bullets, numbering and list styles is poor.
Workaround: Short of typing things in manually (or editing the auto-generated version every time) there's not much you can do. Cross-references can do a limited amount to support bibliographies within a single document.
Poor support for complex page layouts
Problem: Features like frames don't always work as expected. There seem to be several obscure bugs where multiple frames are concerned. Features like overlapping frames and transparency aren't supported.
Workaround: Usually patience or ingenuity, IME.
Start-up times are very long
Problem: It takes forever to load Writer the frst time.
Workaround: Get a faster machine? :-)
Mail merge support is very poor
Problem: Various. The UI is confusing. Output options are limited. (Can you merge to a single file in the latest version? You couldn't the last time I tried it.) The data source system is bug-ridden to the point that it's easier to start again and set up a new source if the slightest thing goes wrong.
Workaround: I've never found one for most of this, although some limitations can be overcome by merging-to-print and using a cheat printer driver that outputs to PostScript/PDF or similar.
The problem with that is that client-side xslt has suffered from some pretty serious bugs over the years, and still does on many platforms. I think basic numbering in Gecko browsers works these days, but for a long time it didn't. So much for those funky auto-generated footnotes/references/tables of contents...
As I mentioned elsewhere, we now use a server-side XSLT-based process to get our pages ready, and the lack of reliability of client-side rendering was a major reason for deciding on that approach.
FWIW, server-side XSLT isn't particularly complicated. I'm just shifting a medium-sized site (maybe 100 unique pages) for a club I belong to onto a new host, and I set up all the necessary processing within an hour or two. For the benefit of being able to see/control the actual XHTML that you're shipping to browsers, IMHO it's more than worth it.
We've been using this approach through three generations of the site now, and I find it strange that anyone still uses things like Frontpage or Dreamweaver. They seem like children's toys in comparison to what you can do with the XSLT - and let's face it, XSLT isn't exactly the world's best programming language!
Repeat after me, please: correlation does not imply causation.
I'm amazed that we haven't seen almost the same answer from every pro commenting in this thread: standards are a means to an end. If following W3C standards does gain you better search engine placement, or cut down your bandwidth, knock yourself out. And of course, if following W3C standards means your site renders better for people you care about (which isn't necessarily everyone with a web browser) then go for it. But don't follow W3C standards, or anyone else's, dogmatically. Always know why following a particular standard will help you.
Personally, I do try to keep the code for the site I run valid, but that's more because the benefits above do apply to me (for example, my server logs tell me around 1/3 of my visitors are using a Gecko-based browser) than anything else.