Yes, but only because they didn't use an application server (after all.NET actually has no such thing), but they put all the application logic in stored procedures. If you implemented the equivalent J2EE application using JSP and stored procedure's you'd probably get similar performances. C# will probably always need less code, although most of the code (other than the actual application logic) they got rid of is trivial getters and setters.
Actually Eiffel# has two deficiencies compared with Eiffel proper. It lacks covariance, and it has no multiple inheritance. These are two of Eiffel's most important features. The other two are design by contract and genericity.
Design by contract was never going to be an issue, because "its just code". Generics they have implemented, but the only way to implement them is by type erasure (as Java does). Thats inefficient for primitive types, and will make Eiffel# generic types non-type-safe when they're used in code in other languages, or, indeed, in Eiffel# code that does not have the source available at compile time.
The end result is a radically different language from Eiffel. One, in fact, that looks like C# with design-by-contract and Java-style generics, but Eiffel's *syntax*. This is true regardless of Meyer's genius (which I don't dispute). In fact, it is a language you could implement on the JVM just as easily as you can implement it on the CLR.
So why does Meyer say the CLR is "truly language independent" ? This seems to me to be an extraordinary assertion. Now, maybe he has some assurances from Microsoft that the capabilities of the CLR will expand in future versions, but if he does he is probably being naive to believe them. If not, as an assertion it does not reflect at all well on his intellectual integrity. Sure: you can implement any language on the CLR, just as you can on the JVM, but some languages will require so much effort, and be so inefficient, it will not be worth it. I don't care how clever Meyer is: the CLR has a profound bias towards statically typed, single dispatch, single implementation inheritance languages. Only 2 such languages exist: Java and C#. To implement multiple inheritance of mutliple dispath would require very considerable efforts. He admits as much himself later in the article, so why is he pushing this ?
Meyer's article does indeed make several good points, but on the "true language independence" he does not substantiate his case, and, indeed, undermines it is several places. The CLR is clearly not "truly" language independent.
... for a single project of any size. Its very important that everyone can read and modify everyone else's code (not that they DO, just that they CAN). Using libraries written in another language: maybe. Using many languages on one project: insane.
There are also two errors in the rest of your post: Java's platform independence works just fine, and C# and the CLR have been released, they're not "planned".
Meyer brought into.NET from an early stage, as did several other academics with pet languages noone ever uses. He doesn't tackle the (huge) issues with actually implementing Eiffel on the CLR, probably because he's starting to lose touch with reality due to spending too much time being a pundit.
Exactly. Never. Java is a neat little concept - that has some neat little benefits. But it has caught on for large-scale applications.
Though I suspect that was a typo. Java has caught on for large-scale applications. The reason you can't buy Java apps in Best Buy is because they don't sell large scale applications. They sell boxed programs for PCs and Macs that are almost exclusively written in C++. Java's principle use is for the server side of various business systems.
This is the field MS are aiming for with.NET, too. Indeed, that seems to be its principle purpose: to displace Java from back-end server systems. Microsoft already owns the desktop, and Java is no particular threat there for reasons that don't need to be rehearsed again. For the device market, they have other plans.
The point of encapsulation is not to slavishly conceal all the data possessed by an instance of a class. In many cases its quite legitimate to expose functions to get and set data values - although I can provide you with much abuse of programmers who do so thoughtlessly. Properties (as in C#) just provide a formalised mechanism for doing this.
If this isn't clear to you, we need to examine what exactly encapsulation is, and what it is intended to accomplish. To do that, we need to do right back to the roots of modular programming, and the concept of coupling. Modules - including classes for these purposes - are meant to be decoupled from one another. Thats just a smart way of saying that a module should only depend on the interface of any any other module, and that interface should support all the possible alternative implementations. Decoupling matters because it allows the implementation of each module to vary independently of the rest.
Encapsulation is just part of the OO way of allowing for decoupling. The implementation varies between OO languages, but the common theme is that they place what functions and data are exposed by a class under the control of the developer of that class, rather than its user. So, for instance, while in C if my struct foo has a field bar, anyone who imports the definition of foo can access bar, OO languages provide mechanisms by which the person responsible for foo can prevent this. The point is not "data hiding" as people often naively say, objects very frequently expose data (although not actual fields) but hiding of the details of how foo is implemented.
Now, you're claiming that C#'s property mechanism removes this useful property of OO languages. That is not true, and won't become so regardless of how often you repeat the assertion. Much though I dislike the language and the politics behind it, I'll stop short of endorsing false statements about it.
Developers of C# classes do not have to expose their fields as properties, nor are they committed, by exposing a property, to keeping the corresponding field in place. Thus, when I write code that makes use of a property, I am not preventing the developer of the class from varying its implementation. Both encapsulation, and the real reason for having it - decoupling - are still there.
Reread the admirable definition of encapsulation you posted: objects publish their interfaces, and contain all the code and data needed to implement those interfaces. That is just as true in C# as it is in Java or C++.
In C# and Delphi "property" has a special meaning distinct from "field". A field is a bit of storage set aside for storing a value. These, of course, should not be public because they are an implementation detail.
It is common, however, in OO languages to expose getX and/or setX methods for a value X which may or may not be stored in a field. Thats OK, provided it is done for a good reason, and not abused to violate class invariants, because the implementations can be changed. So if getX starts off returning the value of a field X, I can later change it to return Y * 42, or whatever else I please. In the jargon, exposing setter and getter methods decouples the implementation from the interface exposed, whereas exposing the field X directly would not. It is this, and not slavishly hiding data values, that matters, because it makes software easier to maintain.
The only problem is that writing a.setX(3) or p = a.getX() is clumsy compared with writing a.x = 3 or p = a.x. Thus a series of languages, starting with Common Lisp, and the most recent example being C#, have provided mechansisms by which the standard = notation can be used to call a setter method, and standard expression notation can be used to call a getter. Its only a syntactic convenience, though. The actual implementation - whether there is a field or not - is still hidden.
To anyone who has developed a big application in language - like Java or C++ - without this feature, the attraction should be obvious.
Can you give more detail, or a references (preferably a non-marketing-bullshit reference) on how.NET is more productive than Java ? I find Java - with the appropriate supporting tools - substantially more productive than most of the alternatives.
As to the "unsafe" features in C#, I see what you are saying, but they still worry me. Aside from very deeply embedded stuff - and there's very little of that these days - there is no need for pointer arithmetic, or manual control over memory allocation.
To say "if you don't like it, don't use it", is only one half of the story. The second part is, we live in an industry full over people with an over-confident view of their own abilities and an obsession with efficiency. Keeping dangerous features out of the language helps keep those people under control.
A full application server environment also contains an EJB container, JMS, etc. EJB in particular is tremendously useful for applications that require persistence, and it also does a certain amount to help with session management. If you write centralised web applications, the whole thing helps tremendously in the same way you describe for.NET.
C# has properties - a mechanism also seen in Delphi. The same chap designed both languages, but the features is not new. It was also in common lisp. A property looks like a public field to the outside world, but under the covers overridable accessor methods get called, so you can override the behaviour or make them read-only.
1. My arse it is. I have a printed copy of the spec. It takes 3 lever arch files. Its vague, imprecise and cumbersome. If you think the difference between aggregation and composition is clear, go on and explain it. I can find 3 slightly contradictory explanations, all from "official" sources within a few minutes.
2. Well, bully for you, but the number of possible states of most systems is too big or too small for them to be useful. They're handy if you're writing things that go through small series of intricate state transitions - like network protocols, or maybe session management - but not otherwise. For the vast majority of applications, they're not applicable. Thats why we don't teach them.
3. But the use case notation is useless. You can show the same thing more clearly as text. Personally, I prefer scenarios for talking to clients anyway. If you can wave diagrams and clients and believe they understand what is going on then you're either very lucky in your clients or deluded. Indeed UML does not imply cases tools. Whiteboards generally work better, but there's stuff in UML - unsurprisingly, given its source - that seems only of use for selling case tools, such as the Use Case notation.
4. If a feature makes no sense in context, then why not tell people not to use it ? If you use UML as a communications tool with other developers, the most important thing is that everyone has the same understanding. Funny wee diamonds, and wierd associations, generally hinder understanding, and the same concepts can be explained more clearly using the minimal notation and a note.
You seem to assume a level of conceptual unity in UML that just ain't there. Because it is quite deliberately *not* a methodology, there's no reason to use the tools that you don't find useful, and if you, in turn are teaching other people a way of doing things that you find works, it makes sense to tell them to do the same. Much of UML is just there because someone once invented a methodology that used it. Often 20 years ago. I believe I do understand most of the features, but have found that most people don't, and that those who do "understand" them differently from me.
I'm not a believer in heavyweigth process, or ornate notation. Clear communication is far more important than precise documentation. In general people have more success, and more fun, using the techniques we teach than they do trying to use the full "power" of UML.
What Cooper seems to be called "Interaction Design", sounds like what most people call "Analysis": figuring out what the system must do, how it is to be used, what information it works with, and so on. I'm not sure why Cooper has invented a new word. Possibly self-publicity, possibly that there's a school of voodoo analysis that involves people who write a flowchart and a couple of CREATE TABLE statements and then **** off. Either way, its another one for my list of Damning Inditements of Our Industry.
One you realise Cooper is really talking about analysis, the conflict with XP becomes much clearer. The biggest issue I have with XP is that they don't do analysis: they don't find out anything about the customer's domain before trying to start work. Admittedly they will find out as they go along, but it does seem effort is being wasted in there.
Most coding is easy. Thats exactly where XP is coming from. Most people have the instinctive hatred of rewriting stuff, but given that coding is easy, there is no good reason for this. You can see it in what Cooper says: comparing coding to pouring cement. XP involves rewriting lots of code, so Cooper reckons its like demolishing bits of building and rebuiling them.
According to XP, he's wrong, and there are reasons to believe it is right. Rewriting code is not nearly as expensive as building and rebuilding walls, and by writing and then rewriting something, you gain a better knowledge both of the customer, and of the problem.
... learning about things before criticising them ? I agree about the name, but XP's primary purpose (as Cooper points out in that interview) is to accept the fact users initially have no clue what they want, and work with it. If the customers see every iteration of the system, and the system is released every week or so with at least one new, small, useful feature, they become much better at describing what they want to change, and much less prone to last minute "bright ideas".
The rest of XP is mostly there to make constant change possible without producing an engineering disaster. Since most projects exist in a state of constant change anyway, this seems better than the usual approach: to become inflexible and dogmatic in the face of the customer's unreasonable stupidity.
The trouble with UML, as several posters have pointed out, is that the semantics of the language are ill-defined. There's no clear guideline as to when to use, for instance, ternary associations, or association classes. Hence, when people do use these things in their diagrams, miscommunications tend to occur.
I teach introductory OOA&D courses, and as part of those we do an introduction to the part of UML we feel is actually useful. That takes about 2 hours and a couple of exercises.
Only class diagrams, object diagrams and sequence diagrams are actually useful. You don't need diagrams to communicate use cases properly (unless you're trying to sell case tools), and state diagrams are only useful if you're developing protocol stacks.
Within class diagrams, only ever use simple associations: you can use diamonds once you can explain to me precisely how composition differs from aggregation. Never try to include all variables and comments in your classes. Always label both ends of the association, and provide both cardinalities. Don't bother with arrows. Never, ever, ever use association classes or ternary associations, unless your group has a really precise definition of them and sticks to it.
Certainly if you don't try to write a system like that, but just use it to get the idea, then its harmless. I was particularly worried that the original poster mentioned it in the context of being taught Java, though. Unless it was a "your first language" course, in which case he probably should not have attended.
One course I teach is basically "OO for beginners", which is intended for new graduate recruits (not CS grads), and for non-engineerings managers. In that, we get over the brain friction with a role playing exercise that involves people first simulating a business sytem by passing bits of paper around, and then simulating the same system as an OO system, with each person playing an object, by passing messages around. After that, they seem to get the idea of objects, messages and most importantly, classes and polymorphism, quite well.
Encapsulation is only half the story. To get any benefit from OO, polymorphism is essential. Encapsulation does indeed get you nice organisation by itself, but you don't get any improvement of flexibility. With polymorphism added, you gain the vital ability to operate on objects without having to discover their runtime type. This lets you write, for instance, a catalogue system that can operate on video tapes or books, without having to have any knowledge of what exactly its working on.
But there's a bit more to it than that. OO is just a way of acheiving well designed software. It has its failings, but its the best I know of. So what does it mean for software to be well designed ? Well (and this goes back much further than OO), it should consist of loosely coupled components, each of which is highly cohesive internally. Each component should hide a small group of closely related design decisions (ideally one) so that the rest of the system can be built independent of its details.
In the end, OO is not about being able to write better algorithms, but about how long your software will last, of how much value it will be to its users, and how much grief it will cause its maintainers. These are principally concerns in commercial environments (where value==price and hassle==cost), but they're relevant everywhere software is written and used more than once.
Now, looking at your problems and your question, here are some random thoughts. I'll be the first to admit to not having the faintest idea what most of those problems are, so some of this is about the peripheral aspects.
Firstly, all OO language in common use are procedural. The opposite of procedural is declarative, but there are very few declarative languages and they are principally of academic interest. In the end, code in OO languages is just like code in C, Pascal or Fortran.
So, thinking about your algorithms: does the algorithm always operate on the same domain ? For instance, do your fluid dynamics always model fluids ? or might it be modelling some complex economic system ? If so, you can split the domain off from the algorithm uding the techniques off OO, by representing it as a set of abstract classes or interfaces. Of course, this is only of interest if the algorithm is part of a larger system with some purpose, and not just an academic toy.
Similarly, are there several algorithms for solving a problem ? or can the algorithm be tuned differently. I know this is the case with some stochastic methods (I used to work on a system that used simulated annealing for place and route - in Smalltalk). In these cases the abstract properties of the algorithm can be encapsulated in an abstract base class, and concrete specialisations used to offer a choise of implementations.
I hope that helps somewhat. Just one thing to bare in mind: beware of C++. Java is unnfortunately inappropriate for heavy numerical lifting, but C++ contains many pitfalls for the unwary. Its worth learning a more rigorously OO language - like Java - and then going back to C++.
People still teach that ? I give OO training courses, and we mock that stuff mercilessly. Thats just a (bad) way of doing analysis. If you try to go straight from that to code, you'll end up with a poor, naive implementation, probably with all the "real work" done by one method and all the OO superstructure looking like useless fussiness. Its that kind of thing puts people off OO.
One way of looking at software engineering divides it into levels of abstraction at which people work. In the traditional view, engineering proceeded by starting at the highest level and proceeding in a orderly manner towards code. We're coming to realise that approach is wrong, but the levels of abstraction still exist. You can use OO at all these levels, by modelling things in terms of classes.
At the highest level, often called analysis, classes, objects and the relationships between them should correspond to concepts in the problem domain. Implementation issues should not come into it. An analysis model should end up representing the system as the user thinks about it.
At the code level, objects are indeed methods combined with data, but while the analysis model won't have captured all, or even most, of the code you end up writing, the concepts in it should still be present in the code.
What the article describes - a common interface to the lowest common denominator of a wide range of GUI toolkits - is exactly what the Java AWT did. Unfortunately the intersection of all common toolkits is quite small: many don't support graphics on buttons, or sliders. There are also significant differences in the behaviour of the widgets between platforms that create problems. It looks to me as if you haven't examined the AWT and the reasons for its failure in enough detail, so you're going to make the same naive mistake again.
On top of that, the callback/event-look API described surely went out with the ark.
Look, your post above makes a very interesting potential case: that search engines cannot make money. I'm not trying to be adverserial here: I just want to know how you calculated what you say you have calculated. If you could just supply links for the sources of your numbers, and give me an idea of how you did the maths, I'll be happy.
?? I don't quite understand this question. But if it helps the cost of approx 1 cent is the final cost, including bandwith, sys-admin support, R&D, not just the CPU.
Well, good, but how did you calculate these costs ?
[costs of searches and how they grow] First hand experience on the development side of search engines.
Fine. I'll believe what you say. So what is the relationship ?
[size of the web] Widely available in the academic literature. (Try searching for information retrieval).
The suggested search produced nothing of use. Could you please supply a link.
[revenue per impression for banner ads]Give me a break. This is also widely available.
As above. All the links I found said "numbers vary widely". As for google, someone has posted the publically available numbers below.
Slashdot Mirror
There's a JCP standard now. Its slated for implementation in 1.5
Yes, but only because they didn't use an application server (after all .NET actually has no such thing), but they put all the application logic in stored procedures. If you implemented the equivalent J2EE application using JSP and stored procedure's you'd probably get similar performances. C# will probably always need less code, although most of the code (other than the actual application logic) they got rid of is trivial getters and setters.
Actually Eiffel# has two deficiencies compared with Eiffel proper. It lacks covariance, and it has no multiple inheritance. These are two of Eiffel's most important features. The other two are design by contract and genericity.
Design by contract was never going to be an issue, because "its just code". Generics they have implemented, but the only way to implement them is by type erasure (as Java does). Thats inefficient for primitive types, and will make Eiffel# generic types non-type-safe when they're used in code in other languages, or, indeed, in Eiffel# code that does not have the source available at compile time.
The end result is a radically different language from Eiffel. One, in fact, that looks like C# with design-by-contract and Java-style generics, but Eiffel's *syntax*. This is true regardless of Meyer's genius (which I don't dispute). In fact, it is a language you could implement on the JVM just as easily as you can implement it on the CLR.
So why does Meyer say the CLR is "truly language independent" ? This seems to me to be an extraordinary assertion. Now, maybe he has some assurances from Microsoft that the capabilities of the CLR will expand in future versions, but if he does he is probably being naive to believe them. If not, as an assertion it does not reflect at all well on his intellectual integrity. Sure: you can implement any language on the CLR, just as you can on the JVM, but some languages will require so much effort, and be so inefficient, it will not be worth it. I don't care how clever Meyer is: the CLR has a profound bias towards statically typed, single dispatch, single implementation inheritance languages. Only 2 such languages exist: Java and C#. To implement multiple inheritance of mutliple dispath would require very considerable efforts. He admits as much himself later in the article, so why is he pushing this ?
Meyer's article does indeed make several good points, but on the "true language independence" he does not substantiate his case, and, indeed, undermines it is several places. The CLR is clearly not "truly" language independent.
... for a single project of any size. Its very important that everyone can read and modify everyone else's code (not that they DO, just that they CAN). Using libraries written in another language: maybe. Using many languages on one project: insane.
There are also two errors in the rest of your post: Java's platform independence works just fine, and C# and the CLR have been released, they're not "planned".
Meyer brought into .NET from an early stage, as did several other academics with pet languages noone ever uses. He doesn't tackle the (huge) issues with actually implementing Eiffel on the CLR, probably because he's starting to lose touch with reality due to spending too much time being a pundit.
Exactly. Never. Java is a neat little concept - that has some neat little benefits. But it has caught on for large-scale applications.
Though I suspect that was a typo. Java has caught on for large-scale applications. The reason you can't buy Java apps in Best Buy is because they don't sell large scale applications. They sell boxed programs for PCs and Macs that are almost exclusively written in C++. Java's principle use is for the server side of various business systems.
This is the field MS are aiming for with .NET, too. Indeed, that seems to be its principle purpose: to displace Java from back-end server systems. Microsoft already owns the desktop, and Java is no particular threat there for reasons that don't need to be rehearsed again. For the device market, they have other plans.
The point of encapsulation is not to slavishly conceal all the data possessed by an instance of a class. In many cases its quite legitimate to expose functions to get and set data values - although I can provide you with much abuse of programmers who do so thoughtlessly. Properties (as in C#) just provide a formalised mechanism for doing this.
If this isn't clear to you, we need to examine what exactly encapsulation is, and what it is intended to accomplish. To do that, we need to do right back to the roots of modular programming, and the concept of coupling. Modules - including classes for these purposes - are meant to be decoupled from one another. Thats just a smart way of saying that a module should only depend on the interface of any any other module, and that interface should support all the possible alternative implementations. Decoupling matters because it allows the implementation of each module to vary independently of the rest.
Encapsulation is just part of the OO way of allowing for decoupling. The implementation varies between OO languages, but the common theme is that they place what functions and data are exposed by a class under the control of the developer of that class, rather than its user. So, for instance, while in C if my struct foo has a field bar, anyone who imports the definition of foo can access bar, OO languages provide mechanisms by which the person responsible for foo can prevent this. The point is not "data hiding" as people often naively say, objects very frequently expose data (although not actual fields) but hiding of the details of how foo is implemented.
Now, you're claiming that C#'s property mechanism removes this useful property of OO languages. That is not true, and won't become so regardless of how often you repeat the assertion. Much though I dislike the language and the politics behind it, I'll stop short of endorsing false statements about it.
Developers of C# classes do not have to expose their fields as properties, nor are they committed, by exposing a property, to keeping the corresponding field in place. Thus, when I write code that makes use of a property, I am not preventing the developer of the class from varying its implementation. Both encapsulation, and the real reason for having it - decoupling - are still there.
Reread the admirable definition of encapsulation you posted: objects publish their interfaces, and contain all the code and data needed to implement those interfaces. That is just as true in C# as it is in Java or C++.
In C# and Delphi "property" has a special meaning distinct from "field". A field is a bit of storage set aside for storing a value. These, of course, should not be public because they are an implementation detail.
It is common, however, in OO languages to expose getX and/or setX methods for a value X which may or may not be stored in a field. Thats OK, provided it is done for a good reason, and not abused to violate class invariants, because the implementations can be changed. So if getX starts off returning the value of a field X, I can later change it to return Y * 42, or whatever else I please. In the jargon, exposing setter and getter methods decouples the implementation from the interface exposed, whereas exposing the field X directly would not. It is this, and not slavishly hiding data values, that matters, because it makes software easier to maintain.
The only problem is that writing a.setX(3) or p = a.getX() is clumsy compared with writing a.x = 3 or p = a.x. Thus a series of languages, starting with Common Lisp, and the most recent example being C#, have provided mechansisms by which the standard = notation can be used to call a setter method, and standard expression notation can be used to call a getter. Its only a syntactic convenience, though. The actual implementation - whether there is a field or not - is still hidden.
To anyone who has developed a big application in language - like Java or C++ - without this feature, the attraction should be obvious.
Can you give more detail, or a references (preferably a non-marketing-bullshit reference) on how .NET is more productive than Java ? I find Java - with the appropriate supporting tools - substantially more productive than most of the alternatives.
As to the "unsafe" features in C#, I see what you are saying, but they still worry me. Aside from very deeply embedded stuff - and there's very little of that these days - there is no need for pointer arithmetic, or manual control over memory allocation.
To say "if you don't like it, don't use it", is only one half of the story. The second part is, we live in an industry full over people with an over-confident view of their own abilities and an obsession with efficiency. Keeping dangerous features out of the language helps keep those people under control.
A full application server environment also contains an EJB container, JMS, etc. EJB in particular is tremendously useful for applications that require persistence, and it also does a certain amount to help with session management. If you write centralised web applications, the whole thing helps tremendously in the same way you describe for .NET.
C# has properties - a mechanism also seen in Delphi. The same chap designed both languages, but the features is not new. It was also in common lisp. A property looks like a public field to the outside world, but under the covers overridable accessor methods get called, so you can override the behaviour or make them read-only.
1. My arse it is. I have a printed copy of the spec. It takes 3 lever arch files. Its vague, imprecise and cumbersome. If you think the difference between aggregation and composition is clear, go on and explain it. I can find 3 slightly contradictory explanations, all from "official" sources within a few minutes.
2. Well, bully for you, but the number of possible states of most systems is too big or too small for them to be useful. They're handy if you're writing things that go through small series of intricate state transitions - like network protocols, or maybe session management - but not otherwise. For the vast majority of applications, they're not applicable. Thats why we don't teach them.
3. But the use case notation is useless. You can show the same thing more clearly as text. Personally, I prefer scenarios for talking to clients anyway. If you can wave diagrams and clients and believe they understand what is going on then you're either very lucky in your clients or deluded. Indeed UML does not imply cases tools. Whiteboards generally work better, but there's stuff in UML - unsurprisingly, given its source - that seems only of use for selling case tools, such as the Use Case notation.
4. If a feature makes no sense in context, then why not tell people not to use it ? If you use UML as a communications tool with other developers, the most important thing is that everyone has the same understanding. Funny wee diamonds, and wierd associations, generally hinder understanding, and the same concepts can be explained more clearly using the minimal notation and a note.
You seem to assume a level of conceptual unity in UML that just ain't there. Because it is quite deliberately *not* a methodology, there's no reason to use the tools that you don't find useful, and if you, in turn are teaching other people a way of doing things that you find works, it makes sense to tell them to do the same. Much of UML is just there because someone once invented a methodology that used it. Often 20 years ago. I believe I do understand most of the features, but have found that most people don't, and that those who do "understand" them differently from me.
I'm not a believer in heavyweigth process, or ornate notation. Clear communication is far more important than precise documentation. In general people have more success, and more fun, using the techniques we teach than they do trying to use the full "power" of UML.
Simon
What Cooper seems to be called "Interaction Design", sounds like what most people call "Analysis": figuring out what the system must do, how it is to be used, what information it works with, and so on. I'm not sure why Cooper has invented a new word. Possibly self-publicity, possibly that there's a school of voodoo analysis that involves people who write a flowchart and a couple of CREATE TABLE statements and then **** off. Either way, its another one for my list of Damning Inditements of Our Industry.
One you realise Cooper is really talking about analysis, the conflict with XP becomes much clearer. The biggest issue I have with XP is that they don't do analysis: they don't find out anything about the customer's domain before trying to start work. Admittedly they will find out as they go along, but it does seem effort is being wasted in there.
Most coding is easy. Thats exactly where XP is coming from. Most people have the instinctive hatred of rewriting stuff, but given that coding is easy, there is no good reason for this. You can see it in what Cooper says: comparing coding to pouring cement. XP involves rewriting lots of code, so Cooper reckons its like demolishing bits of building and rebuiling them.
According to XP, he's wrong, and there are reasons to believe it is right. Rewriting code is not nearly as expensive as building and rebuilding walls, and by writing and then rewriting something, you gain a better knowledge both of the customer, and of the problem.
... learning about things before criticising them ? I agree about the name, but XP's primary purpose (as Cooper points out in that interview) is to accept the fact users initially have no clue what they want, and work with it. If the customers see every iteration of the system, and the system is released every week or so with at least one new, small, useful feature, they become much better at describing what they want to change, and much less prone to last minute "bright ideas".
The rest of XP is mostly there to make constant change possible without producing an engineering disaster. Since most projects exist in a state of constant change anyway, this seems better than the usual approach: to become inflexible and dogmatic in the face of the customer's unreasonable stupidity.
The trouble with UML, as several posters have pointed out, is that the semantics of the language are ill-defined. There's no clear guideline as to when to use, for instance, ternary associations, or association classes. Hence, when people do use these things in their diagrams, miscommunications tend to occur.
I teach introductory OOA&D courses, and as part of those we do an introduction to the part of UML we feel is actually useful. That takes about 2 hours and a couple of exercises.
Only class diagrams, object diagrams and sequence diagrams are actually useful. You don't need diagrams to communicate use cases properly (unless you're trying to sell case tools), and state diagrams are only useful if you're developing protocol stacks.
Within class diagrams, only ever use simple associations: you can use diamonds once you can explain to me precisely how composition differs from aggregation. Never try to include all variables and comments in your classes. Always label both ends of the association, and provide both cardinalities. Don't bother with arrows. Never, ever, ever use association classes or ternary associations, unless your group has a really precise definition of them and sticks to it.
... isn't that entrapment (and therefore inadmissable as evidence) in common-law jurisdictions ?
Certainly if you don't try to write a system like that, but just use it to get the idea, then its harmless. I was particularly worried that the original poster mentioned it in the context of being taught Java, though. Unless it was a "your first language" course, in which case he probably should not have attended.
One course I teach is basically "OO for beginners", which is intended for new graduate recruits (not CS grads), and for non-engineerings managers. In that, we get over the brain friction with a role playing exercise that involves people first simulating a business sytem by passing bits of paper around, and then simulating the same system as an OO system, with each person playing an object, by passing messages around. After that, they seem to get the idea of objects, messages and most importantly, classes and polymorphism, quite well.
Encapsulation is only half the story. To get any benefit from OO, polymorphism is essential. Encapsulation does indeed get you nice organisation by itself, but you don't get any improvement of flexibility. With polymorphism added, you gain the vital ability to operate on objects without having to discover their runtime type. This lets you write, for instance, a catalogue system that can operate on video tapes or books, without having to have any knowledge of what exactly its working on.
But there's a bit more to it than that. OO is just a way of acheiving well designed software. It has its failings, but its the best I know of. So what does it mean for software to be well designed ? Well (and this goes back much further than OO), it should consist of loosely coupled components, each of which is highly cohesive internally. Each component should hide a small group of closely related design decisions (ideally one) so that the rest of the system can be built independent of its details.
In the end, OO is not about being able to write better algorithms, but about how long your software will last, of how much value it will be to its users, and how much grief it will cause its maintainers. These are principally concerns in commercial environments (where value==price and hassle==cost), but they're relevant everywhere software is written and used more than once.
Now, looking at your problems and your question, here are some random thoughts. I'll be the first to admit to not having the faintest idea what most of those problems are, so some of this is about the peripheral aspects.
Firstly, all OO language in common use are procedural. The opposite of procedural is declarative, but there are very few declarative languages and they are principally of academic interest. In the end, code in OO languages is just like code in C, Pascal or Fortran.
So, thinking about your algorithms: does the algorithm always operate on the same domain ? For instance, do your fluid dynamics always model fluids ? or might it be modelling some complex economic system ? If so, you can split the domain off from the algorithm uding the techniques off OO, by representing it as a set of abstract classes or interfaces. Of course, this is only of interest if the algorithm is part of a larger system with some purpose, and not just an academic toy.
Similarly, are there several algorithms for solving a problem ? or can the algorithm be tuned differently. I know this is the case with some stochastic methods (I used to work on a system that used simulated annealing for place and route - in Smalltalk). In these cases the abstract properties of the algorithm can be encapsulated in an abstract base class, and concrete specialisations used to offer a choise of implementations.
I hope that helps somewhat. Just one thing to bare in mind: beware of C++. Java is unnfortunately inappropriate for heavy numerical lifting, but C++ contains many pitfalls for the unwary. Its worth learning a more rigorously OO language - like Java - and then going back to C++.
People still teach that ? I give OO training courses, and we mock that stuff mercilessly. Thats just a (bad) way of doing analysis. If you try to go straight from that to code, you'll end up with a poor, naive implementation, probably with all the "real work" done by one method and all the OO superstructure looking like useless fussiness. Its that kind of thing puts people off OO.
One way of looking at software engineering divides it into levels of abstraction at which people work. In the traditional view, engineering proceeded by starting at the highest level and proceeding in a orderly manner towards code. We're coming to realise that approach is wrong, but the levels of abstraction still exist. You can use OO at all these levels, by modelling things in terms of classes.
At the highest level, often called analysis, classes, objects and the relationships between them should correspond to concepts in the problem domain. Implementation issues should not come into it. An analysis model should end up representing the system as the user thinks about it.
At the code level, objects are indeed methods combined with data, but while the analysis model won't have captured all, or even most, of the code you end up writing, the concepts in it should still be present in the code.
Do you have a compelling reason not to use Java in this case ? It would seem to provide everything you require.
Even just writing portable C++ code can be tricky, especially if one of the target platforms is Microsoft.
What the article describes - a common interface to the lowest common denominator of a wide range of GUI toolkits - is exactly what the Java AWT did. Unfortunately the intersection of all common toolkits is quite small: many don't support graphics on buttons, or sliders. There are also significant differences in the behaviour of the widgets between platforms that create problems. It looks to me as if you haven't examined the AWT and the reasons for its failure in enough detail, so you're going to make the same naive mistake again.
On top of that, the callback/event-look API described surely went out with the ark.
Look, your post above makes a very interesting potential case: that search engines cannot make money. I'm not trying to be adverserial here: I just want to know how you calculated what you say you have calculated. If you could just supply links for the sources of your numbers, and give me an idea of how you did the maths, I'll be happy.
?? I don't quite understand this question. But if it helps the cost of approx 1 cent is the final cost, including bandwith, sys-admin support, R&D, not just the CPU.
Well, good, but how did you calculate these costs ?
[costs of searches and how they grow] First hand experience on the development side of search engines.
Fine. I'll believe what you say. So what is the relationship ?
[size of the web] Widely available in the academic literature. (Try searching for information retrieval).
The suggested search produced nothing of use. Could you please supply a link.
[revenue per impression for banner ads]Give me a break. This is also widely available.
As above. All the links I found said "numbers vary widely". As for google, someone has posted the publically available numbers below.