Looks cool. I always wondered why navies never seemed to use multi-hulled ships, given their speed and handling characteristics. I guess in the days when all that mattered was the size of your gun and the thickness of your armour, it was a bit irrelevent.
If the rules are changing and speed/tactical operations are the New Way, I wonder whether high manoeuvrability "tanks" will be back on the agenda as well, then? They were never much good in the old days, when the accuracy of your opponent's gun was so bad that even if you dodged you might take an unlucky hit anyway (when armour would still protect you, of course) but if we're all about agile units able to get in and out quickly and stealthily now...?
Incidentally, am I the only one who spotted loads of cool things about the ship in the original article... except for any offensive capability (other than via aircraft)? If it's a multi-role vessel, you'd have thought it would carry some sort of firepower, even if only for self-defence!
Oh well. The military knows what they are doing, right?
Isn't this the same military that wants the OICW? (Well, the senior officers seem to, anyway. The guys who are actually going to trust their lives to it don't seem so sure.)
Given that I can see several hundred files on one screen, that doesn't seem such a terrible assumption. And it's Ctrl-Click, or Shift-Click for a range, on just about every PC-based GUI there is, and if that's your best shot (you, the guy who can remember complex regular expressions from the command line, can't remember which modifier key goes with a routine GUI operation?) then I'm afraid you don't have much of an argument, even before your absurd claim that you can wildcard in 50 random filenames before I can click and drag a few times.
I would take your 50 filenames, paste them into vi, replace all the ^ with "mv " and all the $ with "/tmp_cd". Execute the script.
Exactly none of which, other than possibly the final sentence, will use the command line, presumably.
Please see also my reply to the other repondent here: the point of the example is that you won't necessarily have the list of files in a convenient electronic format anyway, in which case it will be far faster and easier to shift them with a mouse than it will be to type everything into a data file or directly into a script.
Gosh, that was a lot easier than you made it sound...
That's because you didn't address the real point, which was that you might not have a convenient list of those files in electronic format. In that case selecting them all via a command line is much more tedious than just a few clicks/drags with a mouse.
Choose any command line shell. Change to a directory/folder. Copy the following list of 50 files with completely unrelated names to the/temp_cd folder ready to burn a backup CD. Stop when you get tired.
Insert list of 50 randomly generated filenames here.
Now open any GUI. Go to the same directory. Copy that list of files. If the last step took more than a handful of clicks and drags, stop reading Slashdot.
This is meant to demonstrate a few things:
The command line is not more powerful than a GUI for everything.
Geeks sometimes have too much faith in their pet tool(s).
Keep an open mind, and use the right tool for the job.
Incidentally, bizarrely enough, I think Windows 3 actually did have simple commands to do wildcard manipulations. Why they removed them in later versions I'll never know.
I completely take your point, but your post (like most others in this subthread) isn't really demonstrating the power of a command line interface. It's demonstrating the power of:
a basic toolkit of do-one-thing-well tools
scripting
regular expressions for processing text files.
The power of this approach is undeniable, and your argument in its favour is strong, but none of it has much to do with a command line interface per se. Working on my GUI system, I could just as easily
create a new text file
type a couple of short lines of $SCRIPTING_LANGUAGE in $TEXT_EDITOR to produce the required output log file and invoke $GRAPHICAL_DIFF_TOOL
run the script this produces.
Obviously some things (probably including your own example) are slightly faster from the command line. Others are slightly faster from a decent GUI (e.g., select a completely arbitrary set of files from a directory and send them all to a script as inputs). But ultimately, it's the ability to connect simple tools via some sort of script that gives the real power here.
What certain OSS advocates don't understand, and Microsoft does, is that it's more useful to have a usable product that works 98% of the time than it is to have a "perfect" back-end which isn't usable at all. You never reach the perfection stage anyway -- Linux and other OSS tools have plenty of security flaws of their own, for example -- and if you wait forever to get there, you never finish anything.
Wow, so many points to miss, all in one subthread!:-)
If 15 is too many, then the top choices are Red Hat, Mandrake, and SuSE. Each one seems to have a particular strength. So where is the chaos?
No offence, but did you actually read the subthread you were replying to? In it, there is a prime example of what happens all the time: you have one distro, you need to do something with it, and lots of L337 Hax0rs tell you you're using the wrong one and should just switch. That's chaos.
About terrible UI design, can you elaborate? The top 3 distros look really great!
They may look great, but there's more to UI design than looks: it has to work great, as well. That's the main point of this whole article/thread: achieving good usability is hard, and involves a lot more than pretty coloured widgets. The failure of most of the OSS world to grok this, or even realise that there is a problem, is why so many OSS applications are still several years behind commercial CSS equivalents in the real world, in spite of all the apparent advantages of the development model.
I'm sure many of the other distros also look great. All are being polished more with each revision. About applications, many of the most popular applications have nice UI design as well and look polished (ie. the OpenOffice suite, Gimp 2.0).
Thanks. You just cited two perfect examples of leading OSS projects where the usability completely sucks according to almost any of the mainstream commercial CSS alternatives.
You'd have done better going after something like Mozilla, which actually has some major steps forward on the most popular CSS alternative in the usability area: clean interfaces for tabbed browsing, good spam filtering, etc.
I think that the problem is that to have strong, consistent leadership and a single design focus, which is difficult when the you have a very large body of contributors who contribute voluntarily, sporadically and whom come and go frequently.
This is so true, in anything where you have volunteer help.
I am currently the president of a large club, with an organising committee of around 30, including about a dozen people with specific responsibilities. All of these people (me included) are volunteers, and we all work and/or study full-time.
Trying to co-ordinate this -- in particular, trying to balance the views of the "leadership" (who often spend a lot of time considering a question and shortlisting viable options before even consulting the full group) with the views of the main group (who collectively have far more experience, but often have laudable but unrealistic goals) -- is very challenging. What can I do if someone doesn't do their job properly?
All I can do is have a quiet word and ask them to change how they do something. If that doesn't work, my only real options are to put up with it, or to seek to have them removed. The latter is hardly a nice thing to do amongst a group of friends, and relies on finding another willing volunteer to take on the job. I don't have the options a business has of formal disciplinary procedures, nor the motivation of offering increased rewards for a good performance, and I couldn't rely on getting a good replacement if I had to get rid of someone, because unlike a business I can't just advertise a good remuneration package and wait for the phone calls.
And this is just with a group of 30 or so people, all in the same place, and often knowing each other well outside the organisation. Compare that to what the project leads on a large OSS project have to do, and it's easy to see why setting a clear direction (and, equally imporant, making sure people go that way afterwards) is so hard.
Buttons lead no where, help didn't work or was unhelpful.. now making your buttons work as advertised and having at least some help when you press the help button (since someone had to put the help button there in the first place), isn't hard or too much to expect in my opinion
No offence, but you're missing the point exactly the same way Raymond did, for exactly the same reasons this article describes.
You can put as many buttons and help screens on as you like, and obviously they should do something if they're there. But the point is that making a program with good usability requires more than this. You have to have the right buttons and have helpful help text.
That is hard, and for now it seems it really is too much to expect, at least from open source projects. I use several of them every day, and have great respect for the development teams, but that doesn't change the fact that the help text in them usually doesn't (or, in some cases, isn't) and the old-fashioned, commercial, closed-source alternatives are years ahead in usability terms.
It seems that what most music downloaders do is perfectly legal here in Canada. The only limitation is that the download must be for the user's own use.
But isn't there a tax on recordable media in Canada that provides an alternative means of compensation to the recording industries (whether the stuff recorded on that media is actually copyright of someone in those industries or not, obviously)?
That's a significantly different situation to many other countries, the US and UK for example, where Internet distribution results in mass ripping with no compensation at all for the copyright holders.
Design should be done primarily using English (or your local language) text, supplimented with diagrams.
Didn't anyone ever tell you that a picture is worth a thousand words?
(Of course, it has to be a good picture to be worth a thousand good words.)
Software is a linguistic construction;
Is it? We usually choose to represent it in a linguistic way, and attempts to use more graphical means have generally turned out pretty badly. However, it's debatable whether that failure was because software design is inherently more linguistic, or whether it just happened that the current linguistic notation was more concise and thus more efficient in use.
Languages are inherently linear. Structured programming (in the sequence, repetition and conditional sense) is a non-linear process: it has forks and loops. Simple functional decomposition is non-linear: it represents a tree of function calls. The relationships between modules in systems are more complex still, with class dependencies in an OO system a prime example.
Today, we happen to project these concepts onto a linear series of grammatical constructions in most languages, but that's only because you can't support anything more than a one-dimensional representation of the underlying structure in a text file. There are other ways, including plenty of research into alternatives to old school plain text representations, and the IDEs and diagramming tools used by many developers today are the current industrial results.
In today's business environment most of the development we do involves databases and complex relationships.
In your business environment, and many others, no doubt that is true. However, "enterprise applications" (or databases, as we used to call them) represent only a significant fraction of development work, not by any means all of it. A lot of real programs still use real algorithms that do more than construct a SQL query and whizz it off to some server via the latest and greatest RPC trick, y'know.:-)
In programs that do non-trivial processing of data, it's definitely useful to represent the algorithm itself in some concise and scannable form as well. Personally, I prefer pseudocode for this, but I could understand using flow charts, particularly if the algorithm is being developed by a group sitting around a whiteboard.
Please don't confuse OO with UML. None of the things you mention is necessary for OO (although some variation on things like class diagrams usually arises sooner or later) and some of them are equally applicable to other design methodologies.
For those who find napkins hard to draw on, use small sheets of paper instead. Just don't reach for that drawing tool! You'll end up spending all of your time figuring out how to make that font bigger and how to keep the lines from crossing inappropriately rather than just getting on with it and drawing the model.
While I have a lot of sympathy for the view that pencil and paper are an under-rated combination these days, I think that's going a bit far.
I've recently spent a fair amount of time drawing reasonably complex class diagrams to document the major design features of one of our systems. To give an idea of scale, these probably have 10-20 classes per page, and can usefully indicate a few key methods and data members on some of the classes.
I found having a good diagramming tool (in this case, the Pacestar UML Diagrammer I mentioned elsewhere in this thread) to be a great timesaver. It has the key advantage that you can adjust things after you've sketched most of the diagram. That might mean moving classes up a bit so you can fit another layer of a hierarchy in at the bottom, or extending one of the boxes to highlight where a couple of methods are over-ridden, for example. If I start using pencil and paper, I frequently find myself drawing the same diagram twice, once where I expected it to fit, and then a second, better laid out copy when I've seen which parts didn't fit the first time.
A good diagramming tool also produces better looking output, and in a more convenient form which can easily be included with design documentation if you like. That beats a cramped diagram with illegible handwriting scanned into a fixed graphic any day.
Of course, it's taken me several years to find a decent UML diagramming tool. Most of the freebies are bug-ridden and hard to use, and produce horrible output. Actually, some of the expensive ones (Rational Rose being a prime example) are among the worst. Certainly pen and paper is better than these...
Does it need to be prettier than a scanned napkin? Ask why. Those who want it prettied up are usually those who wouldn't know what to do with it in any format.
If it's going to be in serious documentation, then yes, it should be smarter than a scanned napkin. Good visual layout that reflects the logical structure is half the value of something like a class or state diagram. Without that, you might just as well write it in words or a big table.
I downloaded the month-long free trial version of Pacestar UML Diagrammer at work recently. I only used it for class diagrams, although it obviously does many other types as well, but it produced nice output and was very ease to use. I'd certainly recommend giving it a try.
Yep: if you want publicity, send an article on a brand new language that isn't finished yet to Slashdot and wait.:-)
At least we're improving, though. The last one was "pre-alpha" (or vapourware, as it's technically known). This one is "beta" (or get-everyone-else-to-test-it-for-you, as it's technically known). One of these days, someone will write an article about a genuinely innovative language that really exists in usable form, and the eds will reject it because we've all got bored.:-)
I don't assume that OOP is the better way to go. I know it is from experience.
Let's not over-generalise, eh? There are plenty of things that don't fit neatly into a purely OO form as commonly supported by major OO languages, and I'm not just talking about functional programming techniques. Not everything is an object (in the OO sense), simple as that.
IMHO inheritance is an overrated feature of OOP, I primarily like it because it forces people to work in a black box model, which makes the whole problem of updates and bug fixes 100x easier for the person who has to deal with your otherwise crappy code.
It's certainly true that many people don't understand the rationale behind inheritance and polymorphism, both of which are key components of object oriented programming. It's also true that these features are heavily over-used in some systems as a result of that lack of understanding, leading to "clever" designs that are actually harder to maintain than a completely non-inheritance-based system would have been.
The key advantage of inheritance/polymorphism in an OO design is really just a well-defined structure for implicit type conversions. If you're not using polymorphism, there's usually not much point in inheritance either. (You could achieve code reuse using aggregation instead, without all the overheads of having a whole class hierarchy.)
However, without inheritance and polymorphism, you're not talking about OO. You're advocating modular design and/or the use of abstract data types (OK, those aren't independent concepts). I've often heard a data-centric approach without inheritance and polymorphism called "object based" programming, which strikes me as quite a good term for it.
Try writing an operating system in all zeros, and then maybe I'll take you seriously.
You and your new-fangled concepts. People managed quite happily without zero for millions of years! Then along came your Babylonian friends, and look what happened...
...is why Microsoft don't state the genuine advantages they have over OpenOffice, such as:
much, much better on-line help
much, much slicker UI
much better graphing features in the spreadsheet
rather than relying on random manager-ese waffle.
Oh, wait, hang on... I do know. It's because Office 2003 got rid of the useful indices into help and forced you to use Clippy for everything, got rid of the useful styles configuration tools and stuck irritating sidebars all over the place, and generally regressed several steps from the previous version. But if Microsoft wanted to produce an improvement on Office 2003, at least they only have to look to Office XP to do it.:-)
OO.o doesn't have an overbar (opposite of underline) font attribute for text. Really a problem for doing technical documentation, but to date nobody has wanted to bother with it.
I long ago gave up using word processors to do technical documentation. They're hopelessly underpowered for the job. Use a serious DTP package, or a typesetting package like (La)TeX, and leave the word processors for typing letters and basic booklet work, which is about all they're good for.
Inheritance is really only a convenience when implementing systems. It shouldn't be used to decide what objects can respond to what messages, but in C++ you don't have any other tool. Java has interfaces, which allows that. In C++ you'd have to use multiple inheritance, but you can only get away with that pattern if objects subclass from parent classes using the virtual keyword.
That doesn't really make sense. Everything you can do with interfaces in Java you can also do with abstract base classes in C++. Moreover, C++ does allow generic programming via templates, where the interface methods are all that matters, regardless of base classes.
Types then aren't what's best for defining what an object does. In non-type based languages you'd simply query if your target object responds to a message if you need to (easy in Python or Objective-C).
It's a different approach, and each has pros and cons. For example, in your typeless world, if you're going to depend on multiple methods to achieve your goal, you have to check for all of them being present and you have to assume that they interact in the ways you expect. If I'm using a type that guarantees (enforced by the language) to support a particular interface, I need only write my code to work with that interface. Some strongly OO based languages even provide explicit support for preconditions, postconditions and class invariants, providing an extra guarantee about the relationship between various methods on an object. That removes a whole potential class of errors in strongly typed systems.
The confusion comes when you don't understand how to design a system in a non-type oriented environment. I mean really, if you've only used strong typing systems you can't really comment.
May I respectfully suggest that you make fewer assumptions about who you're talking to? You've consistently played the "You just don't understand" card in this thread, to me and others, and that isn't a very convincing argument to those of us who've been familiar with the tools or techniques in question since forever.
The only way you can correctly make an object do something that its type doesn't define is to typecast it to another type that does define it, which means using dynamic_cast.
And the problem with that is...?
Even in a typeless system, you can't just apply any old algorithm to any old data and expect an meaningful result. You have to know what an algorithm does, and what the rules are for how it manipulates data. In C++, you can use dynamic_cast to test whether an object supports a certain interface at run time, but even then you already know something about the object because of the static type system.
If it looks like a duck, sounds like a duck, walks like a duck, it's a duck. It's actually not a duck, but you don't care.
What if it looks like a duck, sounds like a duck, walks like a duck, but is poisonous when cooked crispy aromatic style and served with pancakes?
I haven't seen a C++ system that made programming any better than a C system.
I have. In fact, I've worked on a fairly large (MLOC) project in C++ that was essentially a reimplementation of a previous project that was written in C. (It was being rewritten as a Windows application, compared to the DOS-based predecessor.) This offers a fairly direct comparison, except that the C++ version was so much easier to work with that there really was no comparison possible, and a lot of that was due to a decent overall design using a lot of OO, exception-handling and generic features that simply aren't available in C.
Actually, I'm not going to risk discussing your take on exceptions too much. It seems so far out of my own experience with them -- indeed, almost diametrically opposed in places -- that I'm
Slashdot Mirror
Looks cool. I always wondered why navies never seemed to use multi-hulled ships, given their speed and handling characteristics. I guess in the days when all that mattered was the size of your gun and the thickness of your armour, it was a bit irrelevent.
If the rules are changing and speed/tactical operations are the New Way, I wonder whether high manoeuvrability "tanks" will be back on the agenda as well, then? They were never much good in the old days, when the accuracy of your opponent's gun was so bad that even if you dodged you might take an unlucky hit anyway (when armour would still protect you, of course) but if we're all about agile units able to get in and out quickly and stealthily now...?
Incidentally, am I the only one who spotted loads of cool things about the ship in the original article... except for any offensive capability (other than via aircraft)? If it's a multi-role vessel, you'd have thought it would carry some sort of firepower, even if only for self-defence!
If you'd have to kill me, don't tell me. :o)
Isn't this the same military that wants the OICW? (Well, the senior officers seem to, anyway. The guys who are actually going to trust their lives to it don't seem so sure.)
How about a nice game of chess?
(Sorry, someone had to... ;-))
Given that I can see several hundred files on one screen, that doesn't seem such a terrible assumption. And it's Ctrl-Click, or Shift-Click for a range, on just about every PC-based GUI there is, and if that's your best shot (you, the guy who can remember complex regular expressions from the command line, can't remember which modifier key goes with a routine GUI operation?) then I'm afraid you don't have much of an argument, even before your absurd claim that you can wildcard in 50 random filenames before I can click and drag a few times.
Exactly none of which, other than possibly the final sentence, will use the command line, presumably.
Please see also my reply to the other repondent here: the point of the example is that you won't necessarily have the list of files in a convenient electronic format anyway, in which case it will be far faster and easier to shift them with a mouse than it will be to type everything into a data file or directly into a script.
That's because you didn't address the real point, which was that you might not have a convenient list of those files in electronic format. In that case selecting them all via a command line is much more tedious than just a few clicks/drags with a mouse.
Choose any command line shell. Change to a directory/folder. Copy the following list of 50 files with completely unrelated names to the /temp_cd folder ready to burn a backup CD. Stop when you get tired.
Insert list of 50 randomly generated filenames here.
Now open any GUI. Go to the same directory. Copy that list of files. If the last step took more than a handful of clicks and drags, stop reading Slashdot.
This is meant to demonstrate a few things:
Incidentally, bizarrely enough, I think Windows 3 actually did have simple commands to do wildcard manipulations. Why they removed them in later versions I'll never know.
I completely take your point, but your post (like most others in this subthread) isn't really demonstrating the power of a command line interface. It's demonstrating the power of:
The power of this approach is undeniable, and your argument in its favour is strong, but none of it has much to do with a command line interface per se. Working on my GUI system, I could just as easily
Obviously some things (probably including your own example) are slightly faster from the command line. Others are slightly faster from a decent GUI (e.g., select a completely arbitrary set of files from a directory and send them all to a script as inputs). But ultimately, it's the ability to connect simple tools via some sort of script that gives the real power here.
What certain OSS advocates don't understand, and Microsoft does, is that it's more useful to have a usable product that works 98% of the time than it is to have a "perfect" back-end which isn't usable at all. You never reach the perfection stage anyway -- Linux and other OSS tools have plenty of security flaws of their own, for example -- and if you wait forever to get there, you never finish anything.
Wow, so many points to miss, all in one subthread! :-)
No offence, but did you actually read the subthread you were replying to? In it, there is a prime example of what happens all the time: you have one distro, you need to do something with it, and lots of L337 Hax0rs tell you you're using the wrong one and should just switch. That's chaos.
They may look great, but there's more to UI design than looks: it has to work great, as well. That's the main point of this whole article/thread: achieving good usability is hard, and involves a lot more than pretty coloured widgets. The failure of most of the OSS world to grok this, or even realise that there is a problem, is why so many OSS applications are still several years behind commercial CSS equivalents in the real world, in spite of all the apparent advantages of the development model.
Thanks. You just cited two perfect examples of leading OSS projects where the usability completely sucks according to almost any of the mainstream commercial CSS alternatives.
You'd have done better going after something like Mozilla, which actually has some major steps forward on the most popular CSS alternative in the usability area: clean interfaces for tabbed browsing, good spam filtering, etc.
I'm pretty sure all the chicks I know would rather tan their racks in the sun, and then do different things in bed. I guess maybe I'm just unlucky.
This is so true, in anything where you have volunteer help.
I am currently the president of a large club, with an organising committee of around 30, including about a dozen people with specific responsibilities. All of these people (me included) are volunteers, and we all work and/or study full-time.
Trying to co-ordinate this -- in particular, trying to balance the views of the "leadership" (who often spend a lot of time considering a question and shortlisting viable options before even consulting the full group) with the views of the main group (who collectively have far more experience, but often have laudable but unrealistic goals) -- is very challenging. What can I do if someone doesn't do their job properly?
All I can do is have a quiet word and ask them to change how they do something. If that doesn't work, my only real options are to put up with it, or to seek to have them removed. The latter is hardly a nice thing to do amongst a group of friends, and relies on finding another willing volunteer to take on the job. I don't have the options a business has of formal disciplinary procedures, nor the motivation of offering increased rewards for a good performance, and I couldn't rely on getting a good replacement if I had to get rid of someone, because unlike a business I can't just advertise a good remuneration package and wait for the phone calls.
And this is just with a group of 30 or so people, all in the same place, and often knowing each other well outside the organisation. Compare that to what the project leads on a large OSS project have to do, and it's easy to see why setting a clear direction (and, equally imporant, making sure people go that way afterwards) is so hard.
No offence, but you're missing the point exactly the same way Raymond did, for exactly the same reasons this article describes.
You can put as many buttons and help screens on as you like, and obviously they should do something if they're there. But the point is that making a program with good usability requires more than this. You have to have the right buttons and have helpful help text.
That is hard, and for now it seems it really is too much to expect, at least from open source projects. I use several of them every day, and have great respect for the development teams, but that doesn't change the fact that the help text in them usually doesn't (or, in some cases, isn't) and the old-fashioned, commercial, closed-source alternatives are years ahead in usability terms.
But isn't there a tax on recordable media in Canada that provides an alternative means of compensation to the recording industries (whether the stuff recorded on that media is actually copyright of someone in those industries or not, obviously)?
That's a significantly different situation to many other countries, the US and UK for example, where Internet distribution results in mass ripping with no compensation at all for the copyright holders.
Didn't anyone ever tell you that a picture is worth a thousand words?
(Of course, it has to be a good picture to be worth a thousand good words.)
Is it? We usually choose to represent it in a linguistic way, and attempts to use more graphical means have generally turned out pretty badly. However, it's debatable whether that failure was because software design is inherently more linguistic, or whether it just happened that the current linguistic notation was more concise and thus more efficient in use.
Languages are inherently linear. Structured programming (in the sequence, repetition and conditional sense) is a non-linear process: it has forks and loops. Simple functional decomposition is non-linear: it represents a tree of function calls. The relationships between modules in systems are more complex still, with class dependencies in an OO system a prime example.
Today, we happen to project these concepts onto a linear series of grammatical constructions in most languages, but that's only because you can't support anything more than a one-dimensional representation of the underlying structure in a text file. There are other ways, including plenty of research into alternatives to old school plain text representations, and the IDEs and diagramming tools used by many developers today are the current industrial results.
In your business environment, and many others, no doubt that is true. However, "enterprise applications" (or databases, as we used to call them) represent only a significant fraction of development work, not by any means all of it. A lot of real programs still use real algorithms that do more than construct a SQL query and whizz it off to some server via the latest and greatest RPC trick, y'know. :-)
In programs that do non-trivial processing of data, it's definitely useful to represent the algorithm itself in some concise and scannable form as well. Personally, I prefer pseudocode for this, but I could understand using flow charts, particularly if the algorithm is being developed by a group sitting around a whiteboard.
Please don't confuse OO with UML. None of the things you mention is necessary for OO (although some variation on things like class diagrams usually arises sooner or later) and some of them are equally applicable to other design methodologies.
While I have a lot of sympathy for the view that pencil and paper are an under-rated combination these days, I think that's going a bit far.
I've recently spent a fair amount of time drawing reasonably complex class diagrams to document the major design features of one of our systems. To give an idea of scale, these probably have 10-20 classes per page, and can usefully indicate a few key methods and data members on some of the classes.
I found having a good diagramming tool (in this case, the Pacestar UML Diagrammer I mentioned elsewhere in this thread) to be a great timesaver. It has the key advantage that you can adjust things after you've sketched most of the diagram. That might mean moving classes up a bit so you can fit another layer of a hierarchy in at the bottom, or extending one of the boxes to highlight where a couple of methods are over-ridden, for example. If I start using pencil and paper, I frequently find myself drawing the same diagram twice, once where I expected it to fit, and then a second, better laid out copy when I've seen which parts didn't fit the first time.
A good diagramming tool also produces better looking output, and in a more convenient form which can easily be included with design documentation if you like. That beats a cramped diagram with illegible handwriting scanned into a fixed graphic any day.
Of course, it's taken me several years to find a decent UML diagramming tool. Most of the freebies are bug-ridden and hard to use, and produce horrible output. Actually, some of the expensive ones (Rational Rose being a prime example) are among the worst. Certainly pen and paper is better than these...
If it's going to be in serious documentation, then yes, it should be smarter than a scanned napkin. Good visual layout that reflects the logical structure is half the value of something like a class or state diagram. Without that, you might just as well write it in words or a big table.
I downloaded the month-long free trial version of Pacestar UML Diagrammer at work recently. I only used it for class diagrams, although it obviously does many other types as well, but it produced nice output and was very ease to use. I'd certainly recommend giving it a try.
Yep: if you want publicity, send an article on a brand new language that isn't finished yet to Slashdot and wait. :-)
At least we're improving, though. The last one was "pre-alpha" (or vapourware, as it's technically known). This one is "beta" (or get-everyone-else-to-test-it-for-you, as it's technically known). One of these days, someone will write an article about a genuinely innovative language that really exists in usable form, and the eds will reject it because we've all got bored. :-)
Let's not over-generalise, eh? There are plenty of things that don't fit neatly into a purely OO form as commonly supported by major OO languages, and I'm not just talking about functional programming techniques. Not everything is an object (in the OO sense), simple as that.
It's certainly true that many people don't understand the rationale behind inheritance and polymorphism, both of which are key components of object oriented programming. It's also true that these features are heavily over-used in some systems as a result of that lack of understanding, leading to "clever" designs that are actually harder to maintain than a completely non-inheritance-based system would have been.
The key advantage of inheritance/polymorphism in an OO design is really just a well-defined structure for implicit type conversions. If you're not using polymorphism, there's usually not much point in inheritance either. (You could achieve code reuse using aggregation instead, without all the overheads of having a whole class hierarchy.)
However, without inheritance and polymorphism, you're not talking about OO. You're advocating modular design and/or the use of abstract data types (OK, those aren't independent concepts). I've often heard a data-centric approach without inheritance and polymorphism called "object based" programming, which strikes me as quite a good term for it.
You and your new-fangled concepts. People managed quite happily without zero for millions of years! Then along came your Babylonian friends, and look what happened...
...is why Microsoft don't state the genuine advantages they have over OpenOffice, such as:
rather than relying on random manager-ese waffle.
Oh, wait, hang on... I do know. It's because Office 2003 got rid of the useful indices into help and forced you to use Clippy for everything, got rid of the useful styles configuration tools and stuck irritating sidebars all over the place, and generally regressed several steps from the previous version. But if Microsoft wanted to produce an improvement on Office 2003, at least they only have to look to Office XP to do it. :-)
I long ago gave up using word processors to do technical documentation. They're hopelessly underpowered for the job. Use a serious DTP package, or a typesetting package like (La)TeX, and leave the word processors for typing letters and basic booklet work, which is about all they're good for.
That doesn't really make sense. Everything you can do with interfaces in Java you can also do with abstract base classes in C++. Moreover, C++ does allow generic programming via templates, where the interface methods are all that matters, regardless of base classes.
It's a different approach, and each has pros and cons. For example, in your typeless world, if you're going to depend on multiple methods to achieve your goal, you have to check for all of them being present and you have to assume that they interact in the ways you expect. If I'm using a type that guarantees (enforced by the language) to support a particular interface, I need only write my code to work with that interface. Some strongly OO based languages even provide explicit support for preconditions, postconditions and class invariants, providing an extra guarantee about the relationship between various methods on an object. That removes a whole potential class of errors in strongly typed systems.
May I respectfully suggest that you make fewer assumptions about who you're talking to? You've consistently played the "You just don't understand" card in this thread, to me and others, and that isn't a very convincing argument to those of us who've been familiar with the tools or techniques in question since forever.
And the problem with that is...?
Even in a typeless system, you can't just apply any old algorithm to any old data and expect an meaningful result. You have to know what an algorithm does, and what the rules are for how it manipulates data. In C++, you can use dynamic_cast to test whether an object supports a certain interface at run time, but even then you already know something about the object because of the static type system.
What if it looks like a duck, sounds like a duck, walks like a duck, but is poisonous when cooked crispy aromatic style and served with pancakes?
I have. In fact, I've worked on a fairly large (MLOC) project in C++ that was essentially a reimplementation of a previous project that was written in C. (It was being rewritten as a Windows application, compared to the DOS-based predecessor.) This offers a fairly direct comparison, except that the C++ version was so much easier to work with that there really was no comparison possible, and a lot of that was due to a decent overall design using a lot of OO, exception-handling and generic features that simply aren't available in C.
Actually, I'm not going to risk discussing your take on exceptions too much. It seems so far out of my own experience with them -- indeed, almost diametrically opposed in places -- that I'm