Re: Bug rate and choice of programming language

[Shark8 <onewingedshark@gmail.com>]

On Aug 10, 6:19 pm, Yannick Duchêne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
> I feel the last sentence (previous text was quoted for context), may be a  
> good reason to mitigate some (bad) evaluation of UML or UML- like  
> representations. It seems their experience shows some graphical  
> representation at some level may help. This does not really advocate for  
> UML, rather for some kind of multi-dimensional representations, like  
> graphical representations are.

UML is, in my opinion, over-rated and over-hyped in that it tries to
do two distinct and separate things at once while not realizing/
recognizing that they are separate things: that is representing the
DESIGN of a system AND representing the FLOW of the system.

The correct solution is, again in my opinion, something that
acknowledges the two as being distinct.
As a small example consider an [OOP-]object and its associated
functions/procedures/methods; there is the HOW DOES THIS OBJECT FIT
WITH OTHER OBJECTS [IN THE PROGRAM]? question, as well as the WHAT
HAPPENS WHEN [MESSAGE]? question. Both can be represented as graphs,
but one [the method] is in actuality a flowchart. In a GUI-system this
would look like an object having methods that when you examine/double-
click/access expand into a flowchart representation for that method.
[And the converse as well, when the method/procedure/function that you
are in has locally-declared objects you should be able to "zoom-in" on
those... taking you back to the OO-view but with that particular class-
of-object as the subject; this would also be how the theoretical/
imaginary/'main'/default-task would be viewed: as a function/procedure
which declares variables & objects.]

As an interesting and perhaps-or-perhaps-not practical extension of
the previous concept would be [in systems programming] the OS viewing
a program as an object, with its own methods [perhaps memory-
management], the defaulting one being that "main" thread.