What does it matter when the compiler was released?
What a silly thing to say. Programming languages evolve, and always have. In the mid-90s, C was fairly stable (having been around for eons), C++ was beginning to mature but had no standard, Java was barely usable, Visual Basic was some funky new toy this company called Microsoft were playing with, most of the successful scripting languages we have today were barely a glint in their creators' eyes, functional languages hadn't worked out how to deal with that slight problem that real programs need side effects, and academics thought Pascal was a cool teaching language. (How many of these things are still true today is left as an exercise for the reader, but clearly it's not all of them.)
If you really expect to work in this industry and use tools from around a decade ago but still keep up with the current generation, you have a lot more to learn than how to do pass by reference in C.
Of course there is. You get pass by reference semantics by passing or returning pointers. It's not as clean as C++'s passing a reference, but that's just syntax, not semantics.
Nope, sorry, it's not. I use VC++.Net 2003 every day at work, and its standards compliance is quite impressive. Claiming that GCC is somehow way ahead in its standards support is (-1, Just Plain Wrong).
I believe that Comeau has historically had the most compliant C++ compilers. I'm not sure if they fully implement the standard, but if anybody does, it's them.
I suspected someone would say Microsoft's compiler produces better code. Now where's the evidence?
There are at least two easy answers to that question:
Look at the disassembly for any reasonably complex algorithm, and spot all the platform-specific optimisations that VC++ (and indeed most other commercial compilers on Windows) perform that GCC (due to its portability requirements) does not.
Use Google, and look for people who've compared the real world performance of non-trivial apps built with each compiler. (You might do better with Google Groups than the Google web search engine on this one.)
I think alpha-blending, if done properly, is a better way to unhide relavent information. Dual monitors, wide-screens, or really large screens with a lot of resolution are others.
I think the key is not so much how much information you can see at once, but how fast and intuitively you can get to what you've hidden. I don't know about you, but I can't concentrate on things going on in seventeen windows at once. I find the following useful in a typical 2D WIMP GUI today:
the maximize button
a quick way to switch between maximized windows
a good way to see the status of hidden applications ("Your download is 57% complete")
a good way to get simple notifications from hidden apps ("You have 1 new mail", "Your document has finished printing")
a good way to move information between apps.
The fact that all my notification examples relate to events I might have been waiting for, and thus times I might want to switch immediately to the generating application, is not a coincidence. I think one area where UIs have been developing over the past decade is the separation of a main "work area" and a separate area for notifications and status, and starting new work. I expect this trend to continue.
I also guess that another serious UI research area in the next few years will be why a simple copy-and-paste system is so useful, yet a "super-powerful" system like Microsoft's OLE is rarely used in practice. I think moving data between apps is going to be one of the next big things in usability, but I haven't seen anyone get it right yet. The basic copy-and-paste idea is good, and drag-and-drop is good. A few people have played with "multiple clipboards", but it's always broken down with efforts to date: the simplicity and therefore usability goes.
Now, getting back on topic, I'm not sure how a 3D interface will help much with these ideas, compared to simply having a really big display area. (Even then you'd have to be careful not to put notifications out of the user's main field of vision when they were working on something else.) The almost-sideways-on view of "minimized" windows in some of the 3D desktop demos has a certain appeal, since it might be a better representation of what data is hidden and how to get it back than existing task bars and such, but I think most of it is just the new-and-different factor, and I'm afraid usability will stamp on it real fast if that's all it's got to offer.
How far are we from being able to just wave our arms around as part of our ui?
I could tell you, but then I'd have to kill you. Except that those hand-wavy interfaces are so good that some smart-ass cop with one of them will see your murder coming, and a whole load of special forces geezers will descend upon my house from an aerodynamically implausible airborne transport and arrest me for a crime I'm about to commit...
It is just as useful to people with dial-up modems. There's nothing like only getting ~5kB/s at the best of times, and then doubling your download time because a transatlantic link was slow.
This approach has been tried, and is extremely annoying to those of us who do know what we are doing. Last time I checked, Fedora Core doesn't even install gcc if you go with the typical installation (yet of course the Games and Entertainment package was installed).
So Fedora has bad usability. If something intended for both power users and newbies has good usability, then the newbies won't be able to shoot themselves in the foot and the power users will be able to get things done efficiently.
But it's still the best all-around choice for cross-platform development, hence its popularity.
I'm not sure I agree with that. To give the most obvious example, I currently work on a project that ships on probably 15 different platforms myself, including several popular flavours of UNIX, a couple of flavours of MS Windows, a couple of flavours of Mac, and a few more esoteric extras. (The project is basically a library, BTW.)
We write in C++. Why? Because everyone can bind to C++ (or at least to the C interface we also provide), and because there's a C++ compiler available for all of those platforms. Neither is true of Java.
The fact that Java aims to be WORA doesn't mean that it is, nor does it invalidate the use of standardised languages with compilers on many platforms (of which there are quite a few) as alternatives for cross-platform development.
If anything this'll only convince people that the open source community is some kind of weird religious cult with communistic tendencies.
Careful -- that's the free software community you're talking about.
The open source idea does have some interesting possibilities, and while I'm not as fanatical about it as some, I'm certainly prepared to give it a shot if the opportunity arises.
The free software idea has pretty much no demonstrated benefits, other than those that come with open source anyway. It's a philosophical movement, with whose philosophy I happen to disagree. That's mainly because my employer makes money from selling good products, significantly ahead of the nearest competition due to investing in good staff who work hard. While that business model seems entirely ethical to me, it would be destroyed instantly by making everything free-as-in-FSF.
Article #1 (by the leader of JavaLobby) says "Oh, no, Sun (a commercial body) have given up and sold out our precious Java in the way we always knew they could!". And a world of C and C++ developers rose up and cried as one, "We told you so."
Article #2 (by RMS) says "See, commercial software development sucks, and everything in the world should be free." And a world of developers rose up and cried as one... oh, no, sorry, they just ignored yet another RMS rant, noting that as usual he failed to address issues like how to pay the rent with free software, how projects without strong leadership usually fail, and how no successful programming language in recent history has developed without someone controlling what goes in and attempting to keep all implementations compatible.
See all those Java jobs out there? I know a few months ago there were more of those than any other language. I doubt that has changed... or will change in the near future.
There were more Java jobs than any other language? Really? Or do you just mean there were more adverts mentioning the buzzword "Java" than any other buzzword? There's a world of difference.
As for changing, tell that to all the VB6 developers.
Sun could drop off into the Pacific tomorrow, and Java would keep on going because in a lot of places it's the best tool for the job.
So do you work for Sun PR, or are you someone who's built a career around developing in Java and is desperately willing what he says to come true? Blanket statements like the above are meaningless: there is no job for which, other things being equal, Java does not have at least one serious rival. Often the best tool is decided by who you happen to have on your development team, rather than an odd detail supported by Java but not by <alternative of choice>.
If Java rolled over and died tomorrow, some people/businesses who'd invested too much in it would get hurt, and then the software development world would move on, just as it always has.
Don't go chasing waterfalls...
on
UML Fever
·
· Score: 2, Insightful
On the other hand I have seen environments where the UML was adopted as sort of cornerstone of top-down approach: all the design is done first and captured in UML.
That sounds suspiciously like the waterfall model.
The problem is that disagrams become absolete very quickly and people stop referring to them which accelerates the decay even more.
And that sounds suspiciously like the big problem with the waterfall model...
Re: Everything, including tools, in moderation!
on
UML Fever
·
· Score: 2, Insightful
IMHO, s/use/rely on/
I take your point, but there's nothing to say that you haven't just found a new context in which an existing pattern can usefully be applied. (After all, by definition something is a pattern in the first place only if it's got multiple real world applications.)
I see where you're coming from, but there's a fine line between making a dramatic protest (which would happen if all free software stopped working for 24 hours and companies suffered as a result) and coming across as petty, second-rate children (which would happen if sites like Slashdot shut down completely for a day, and is exactly the image problem the FOSS community has been trying so hard to overcome).
There are certain conventions in the grown up world, and if you really want things to change, you need to follow them, or at least respect them when you don't. If you really care, write to your representatives, give your support to a politician who opposes the proposals, or do something to raise general awareness (which will have a knock-on effect on the other two). Radical protests by tiny minority groups (which is all the FOSS community is outside its own little world) are very self-righteous, but rarely achieve anything. FOSS is more important than the size of its supporters might suggest, but you need to direct the passion and collective wisdom of such a group the right way to make a difference.
It's OK, they're just evolving towards giving you both the hardware and the software for free, and making all their profit through service. It's just the "service" part they don't quite understand yet...
Ehm... so you are saying that the shell is obsolete, because you have Perl?
Not at all. I never said "the shell" was obsolete. I suggested that the advantages attributed to a command line (note subthread title) by the OP were actually the result of other things, basically the ability to use scripting to glue small tools together, and that these advantages were just as applicable to the GUI. It's the advocacy of a command line as something inherently more powerful than a GUI that I'm attacking; my example achieved the same effect without any command prompt, or other similarly interactive interface, in sight.
Not sure I really understand this -- is this a fictional GUI system which should allow for the same tasks to be performed? or can you actually do this?
Erm... It's pretty routine in any mainstream GUI for any mainstream OS.
Creating a temporary script file is usually only a couple of clicks and typing a file name, even if you haven't already got something simpler set up.
Between my colleagues and myself at work, we probably use three or four different scripting languages, and pretty much everyone will have at least Perl on their system, so producing the log file is as almost easy as with your command line shell of choice.
We also have probably three (maybe four) different graphical diff tools, all significantly more powerful than the command line toys mentioned by the original poster.
And this is running on Windows XP, not relying on ports of UNIX command line tools. None of this stuff is particularly unusual, you just have to understand that a GUI for an OS doesn't just mean a file manager showing lists in pretty windows. As I said, it's not the command line that gives you the power in this case, it's basically lots of useful little tools for processing text files, and a scripting language to glue them together with, and all of that is available with a GUI just as easily.
Of course there are a few minor pros and cons for each approach. The command line version, to an experienced user at least, is probably going to be slightly faster to do (though we're talking differences in seconds here). The proper temporary script version, which is basically what you're always going to do with a GUI, can be kept and used again or modified to create a new script in future. But at the end of the day, you can achieve the same goal in a similar amount of time and with at least as much flexibility in a GUI as you can with a command line. (And I write this as an avid user of both.)
One of the great crimes people commit against their fellow developers is to not give the bird's-eye view. If you want details, you can always go consult the source code. Getting the bird's eye view of the system, the unifying vision, the overall-architecture, that is much harder to extract from the raw code.
That alone was worth a (+5, Insightful). Separate documentation should deal with high level design, and rarely if ever the implementation details. That's what comments in code are for.
The other thing I'd say is: use the right visuals.
If you're documenting an OO system, throw in a class diagram showing the overall design of each module. Maybe highlight a few carefully chosen key functions/data members.
If you're documenting a database, give a clear list of the tables, and then for each table, give a clear indication of what it's for and any restrictions on it. Yes, this is bordering on "implementation details", but tends to work much better when you're documenting a database than when you're documenting oft-modified code.
In your case, looking at a CMS system, maybe a simple flow chart showing the various steps in each process you're supporting would be useful. Add a few notes about where to start exploring the code underlying each step, and you've already provided enough useful information for an average developer to start learning the system.
Don't throw in random graphics that don't serve a useful purpose, but keep in mind that it's much easier for most people to read a document with graphical aids than a densely written piece of prose, particularly if lots of technical details are involved.
That makes it almost certain that the NSA has has methods for decrypting common algorithms. Considering their mission it would be irresponcible of them to not reaserch it.
Sure, and considering their mission it would be irresponsible for NASA not to be researching faster-than-light travel. That doesn't mean their few elite engineers and astrophysicists have a secret space ship that can reach Jupiter tomorrow, which the numerous similarly elite engineers and physicists outside their organisation have no idea about, though...
The last big arms race took us to the moon, where's the next one going to take us?
In a world full of people who hate you so much they'll give their very lives just to hurt you, who have no care for diplomacy or negotiation, who fall outside the normal rules of engagement, who are hard to track with intelligence, and who have the sympathies of several countries likely to join in that arms race, I'm guessing it's going to take you straight to hell. Just don't take the rest of us with you when you leave, OK?
That seems a slightly over-dramatic statement. Sure, there are serious threats that are capable of doing serious damage to a surface vessel. There always have been, and sometimes ships get sunk. But a Hellfire isn't going to sink an aircraft carrier, and in 20 years time when all the unmanned drones have more firepower, there will be 20 years more technology supporting the sensors, defensive firepower and survivability of the ships, too. Just compare the effectiveness of tank armour today with what it was 20 years ago, and what it was back in WW2, and you can easily see the difference that amount of time can make.
I do wonder whether naval vessels will start to fall into two very distinct categories: armoured as hell, and light, fast and stealthy. I'd like to see what one of your Mach 4 missiles did against the armoured hull of a WW2 battleship. Not a whole lot, I'm guessing. If you can develop an armour with the same effectiveness but lighter and thus with less impact on a ship's speed of deployment etc. and then kit out all your "heavy" ships with that technology, then that UAV-with-a-bigger-missile doesn't sound so bad.
When you also factor in improvements in sensor technology and the inevitable development of better surface-to-air missiles to take the drone out while it's loitering, I don't think surface vessels are quite as dead as you make out just yet.
I think there's another world war brewing, and whether we're the good guys or not, I'm not interested in losing.
If there's another world war brewing, it's probably because of two things: religious extremists (and the nations whose governments support them) and the belligerence and meddling foreign policies of the United States of America (or, to be fairer and more precise, the current government of the United States of America). Neither of these things is going to be fixed by spending a military budget larger than the next several nations' combined on super-powerful weapons. Ships like this and tactical, small-scale warfare may be the way forward, but big spending on military hardware in general isn't. You're far enough ahead already to make it a formality, and all your attitude is going to do is provoke another arms race.
Slashdot Mirror
What a silly thing to say. Programming languages evolve, and always have. In the mid-90s, C was fairly stable (having been around for eons), C++ was beginning to mature but had no standard, Java was barely usable, Visual Basic was some funky new toy this company called Microsoft were playing with, most of the successful scripting languages we have today were barely a glint in their creators' eyes, functional languages hadn't worked out how to deal with that slight problem that real programs need side effects, and academics thought Pascal was a cool teaching language. (How many of these things are still true today is left as an exercise for the reader, but clearly it's not all of them.)
If you really expect to work in this industry and use tools from around a decade ago but still keep up with the current generation, you have a lot more to learn than how to do pass by reference in C.
Of course there is. You get pass by reference semantics by passing or returning pointers. It's not as clean as C++'s passing a reference, but that's just syntax, not semantics.
Nope, sorry, it's not. I use VC++.Net 2003 every day at work, and its standards compliance is quite impressive. Claiming that GCC is somehow way ahead in its standards support is (-1, Just Plain Wrong).
They do, including TC1.
There are at least two easy answers to that question:
I think the key is not so much how much information you can see at once, but how fast and intuitively you can get to what you've hidden. I don't know about you, but I can't concentrate on things going on in seventeen windows at once. I find the following useful in a typical 2D WIMP GUI today:
The fact that all my notification examples relate to events I might have been waiting for, and thus times I might want to switch immediately to the generating application, is not a coincidence. I think one area where UIs have been developing over the past decade is the separation of a main "work area" and a separate area for notifications and status, and starting new work. I expect this trend to continue.
I also guess that another serious UI research area in the next few years will be why a simple copy-and-paste system is so useful, yet a "super-powerful" system like Microsoft's OLE is rarely used in practice. I think moving data between apps is going to be one of the next big things in usability, but I haven't seen anyone get it right yet. The basic copy-and-paste idea is good, and drag-and-drop is good. A few people have played with "multiple clipboards", but it's always broken down with efforts to date: the simplicity and therefore usability goes.
Now, getting back on topic, I'm not sure how a 3D interface will help much with these ideas, compared to simply having a really big display area. (Even then you'd have to be careful not to put notifications out of the user's main field of vision when they were working on something else.) The almost-sideways-on view of "minimized" windows in some of the 3D desktop demos has a certain appeal, since it might be a better representation of what data is hidden and how to get it back than existing task bars and such, but I think most of it is just the new-and-different factor, and I'm afraid usability will stamp on it real fast if that's all it's got to offer.
I could tell you, but then I'd have to kill you. Except that those hand-wavy interfaces are so good that some smart-ass cop with one of them will see your murder coming, and a whole load of special forces geezers will descend upon my house from an aerodynamically implausible airborne transport and arrest me for a crime I'm about to commit...
It is just as useful to people with dial-up modems. There's nothing like only getting ~5kB/s at the best of times, and then doubling your download time because a transatlantic link was slow.
So Fedora has bad usability. If something intended for both power users and newbies has good usability, then the newbies won't be able to shoot themselves in the foot and the power users will be able to get things done efficiently.
I'm not sure I agree with that. To give the most obvious example, I currently work on a project that ships on probably 15 different platforms myself, including several popular flavours of UNIX, a couple of flavours of MS Windows, a couple of flavours of Mac, and a few more esoteric extras. (The project is basically a library, BTW.)
We write in C++. Why? Because everyone can bind to C++ (or at least to the C interface we also provide), and because there's a C++ compiler available for all of those platforms. Neither is true of Java.
The fact that Java aims to be WORA doesn't mean that it is, nor does it invalidate the use of standardised languages with compilers on many platforms (of which there are quite a few) as alternatives for cross-platform development.
Careful -- that's the free software community you're talking about.
The open source idea does have some interesting possibilities, and while I'm not as fanatical about it as some, I'm certainly prepared to give it a shot if the opportunity arises.
The free software idea has pretty much no demonstrated benefits, other than those that come with open source anyway. It's a philosophical movement, with whose philosophy I happen to disagree. That's mainly because my employer makes money from selling good products, significantly ahead of the nearest competition due to investing in good staff who work hard. While that business model seems entirely ethical to me, it would be destroyed instantly by making everything free-as-in-FSF.
So, here's the executive summary:
Article #1 (by the leader of JavaLobby) says "Oh, no, Sun (a commercial body) have given up and sold out our precious Java in the way we always knew they could!". And a world of C and C++ developers rose up and cried as one, "We told you so."
Article #2 (by RMS) says "See, commercial software development sucks, and everything in the world should be free." And a world of developers rose up and cried as one... oh, no, sorry, they just ignored yet another RMS rant, noting that as usual he failed to address issues like how to pay the rent with free software, how projects without strong leadership usually fail, and how no successful programming language in recent history has developed without someone controlling what goes in and attempting to keep all implementations compatible.
There were more Java jobs than any other language? Really? Or do you just mean there were more adverts mentioning the buzzword "Java" than any other buzzword? There's a world of difference.
As for changing, tell that to all the VB6 developers.
So do you work for Sun PR, or are you someone who's built a career around developing in Java and is desperately willing what he says to come true? Blanket statements like the above are meaningless: there is no job for which, other things being equal, Java does not have at least one serious rival. Often the best tool is decided by who you happen to have on your development team, rather than an odd detail supported by Java but not by <alternative of choice>.
If Java rolled over and died tomorrow, some people/businesses who'd invested too much in it would get hurt, and then the software development world would move on, just as it always has.
That sounds suspiciously like the waterfall model.
And that sounds suspiciously like the big problem with the waterfall model...
IMHO, s/use/rely on/
I take your point, but there's nothing to say that you haven't just found a new context in which an existing pattern can usefully be applied. (After all, by definition something is a pattern in the first place only if it's got multiple real world applications.)
I see where you're coming from, but there's a fine line between making a dramatic protest (which would happen if all free software stopped working for 24 hours and companies suffered as a result) and coming across as petty, second-rate children (which would happen if sites like Slashdot shut down completely for a day, and is exactly the image problem the FOSS community has been trying so hard to overcome).
There are certain conventions in the grown up world, and if you really want things to change, you need to follow them, or at least respect them when you don't. If you really care, write to your representatives, give your support to a politician who opposes the proposals, or do something to raise general awareness (which will have a knock-on effect on the other two). Radical protests by tiny minority groups (which is all the FOSS community is outside its own little world) are very self-righteous, but rarely achieve anything. FOSS is more important than the size of its supporters might suggest, but you need to direct the passion and collective wisdom of such a group the right way to make a difference.
It's OK, they're just evolving towards giving you both the hardware and the software for free, and making all their profit through service. It's just the "service" part they don't quite understand yet...
We told you so.
Not at all. I never said "the shell" was obsolete. I suggested that the advantages attributed to a command line (note subthread title) by the OP were actually the result of other things, basically the ability to use scripting to glue small tools together, and that these advantages were just as applicable to the GUI. It's the advocacy of a command line as something inherently more powerful than a GUI that I'm attacking; my example achieved the same effect without any command prompt, or other similarly interactive interface, in sight.
Erm... It's pretty routine in any mainstream GUI for any mainstream OS.
Creating a temporary script file is usually only a couple of clicks and typing a file name, even if you haven't already got something simpler set up.
Between my colleagues and myself at work, we probably use three or four different scripting languages, and pretty much everyone will have at least Perl on their system, so producing the log file is as almost easy as with your command line shell of choice.
We also have probably three (maybe four) different graphical diff tools, all significantly more powerful than the command line toys mentioned by the original poster.
And this is running on Windows XP, not relying on ports of UNIX command line tools. None of this stuff is particularly unusual, you just have to understand that a GUI for an OS doesn't just mean a file manager showing lists in pretty windows. As I said, it's not the command line that gives you the power in this case, it's basically lots of useful little tools for processing text files, and a scripting language to glue them together with, and all of that is available with a GUI just as easily.
Of course there are a few minor pros and cons for each approach. The command line version, to an experienced user at least, is probably going to be slightly faster to do (though we're talking differences in seconds here). The proper temporary script version, which is basically what you're always going to do with a GUI, can be kept and used again or modified to create a new script in future. But at the end of the day, you can achieve the same goal in a similar amount of time and with at least as much flexibility in a GUI as you can with a command line. (And I write this as an avid user of both.)
That alone was worth a (+5, Insightful). Separate documentation should deal with high level design, and rarely if ever the implementation details. That's what comments in code are for.
The other thing I'd say is: use the right visuals.
If you're documenting an OO system, throw in a class diagram showing the overall design of each module. Maybe highlight a few carefully chosen key functions/data members.
If you're documenting a database, give a clear list of the tables, and then for each table, give a clear indication of what it's for and any restrictions on it. Yes, this is bordering on "implementation details", but tends to work much better when you're documenting a database than when you're documenting oft-modified code.
In your case, looking at a CMS system, maybe a simple flow chart showing the various steps in each process you're supporting would be useful. Add a few notes about where to start exploring the code underlying each step, and you've already provided enough useful information for an average developer to start learning the system.
Don't throw in random graphics that don't serve a useful purpose, but keep in mind that it's much easier for most people to read a document with graphical aids than a densely written piece of prose, particularly if lots of technical details are involved.
Sure, and considering their mission it would be irresponsible for NASA not to be researching faster-than-light travel. That doesn't mean their few elite engineers and astrophysicists have a secret space ship that can reach Jupiter tomorrow, which the numerous similarly elite engineers and physicists outside their organisation have no idea about, though...
In a world full of people who hate you so much they'll give their very lives just to hurt you, who have no care for diplomacy or negotiation, who fall outside the normal rules of engagement, who are hard to track with intelligence, and who have the sympathies of several countries likely to join in that arms race, I'm guessing it's going to take you straight to hell. Just don't take the rest of us with you when you leave, OK?
That seems a slightly over-dramatic statement. Sure, there are serious threats that are capable of doing serious damage to a surface vessel. There always have been, and sometimes ships get sunk. But a Hellfire isn't going to sink an aircraft carrier, and in 20 years time when all the unmanned drones have more firepower, there will be 20 years more technology supporting the sensors, defensive firepower and survivability of the ships, too. Just compare the effectiveness of tank armour today with what it was 20 years ago, and what it was back in WW2, and you can easily see the difference that amount of time can make.
I do wonder whether naval vessels will start to fall into two very distinct categories: armoured as hell, and light, fast and stealthy. I'd like to see what one of your Mach 4 missiles did against the armoured hull of a WW2 battleship. Not a whole lot, I'm guessing. If you can develop an armour with the same effectiveness but lighter and thus with less impact on a ship's speed of deployment etc. and then kit out all your "heavy" ships with that technology, then that UAV-with-a-bigger-missile doesn't sound so bad.
When you also factor in improvements in sensor technology and the inevitable development of better surface-to-air missiles to take the drone out while it's loitering, I don't think surface vessels are quite as dead as you make out just yet.
If there's another world war brewing, it's probably because of two things: religious extremists (and the nations whose governments support them) and the belligerence and meddling foreign policies of the United States of America (or, to be fairer and more precise, the current government of the United States of America). Neither of these things is going to be fixed by spending a military budget larger than the next several nations' combined on super-powerful weapons. Ships like this and tactical, small-scale warfare may be the way forward, but big spending on military hardware in general isn't. You're far enough ahead already to make it a formality, and all your attitude is going to do is provoke another arms race.