C++ (was RE: Python suitability)

[Michel Orengo]

Gordon McMillan wrote:

> If C++ (or Java) gave you those tools, there would be no
> "need" for UML. UML "works" (for some definition of "works"
> <wink>) because it hides language complexity. It also lacks
> expressiveness.
>
> Look at "Design Patterns". Most of those patterns are directly
> expressible in Python. So much so, that if you translate the
> UML into Python and use that, the result will be needlessly
> complex and stilted. What the UML actually expresses is how
> to get around language barriers.
>
> There are useful diagrams in UML, (eg, the state and
> transition diagrams). Unfortunately, the one most tools use to
> generate code (and draw from reverse engineering) has
> everything to do with language structure, and nothing to do
> with what actually happens at runtime. To put it bluntly:
> people spend most of their time designing the wrong thing.
>

I tend to agree that there is no much sense in designing forever an
application and at one point it's better to start coding.
However, we should draw a line between desing and business analysis. I
use UML to formalize the business rules.
Some people think that their business analysis is their design. That's
not true and with such thing in mind, they are designing an application
rather than understanding the business. That's why it is not uncommon to
find E/R models that are the exact image of a database schema, or Object
Models that represent technical objects.
There is no point of doing that.
Models should help to understand the business and put in a rather
"mathematical" or "logical" way business rules.
Once this is formalized, then it is possible to design or to go directly
to prototype.
Generating database schema from E/R diagram or object model or
generating code from whatever diagram is bullshit. It is no more than a
complex documentation of your program.
What you want to document is the business that make you design your
application the way you design it.


> The secret to good performance is to prototype and prototype,
> then code the bottlenecks in a faster language. The secret to
> large systems is to prototype and prototype, until you've got
> clean separation of the system into managable pieces, then
> code in whatever language most suits the need of each piece.
>
> This is contrary to the advice of a lot of the gurus you mention;
> but they have a large vested interest in the process.
>

That makes me want to write a book ;-)

Michel