Re: What exactly is the licensing situation with GNAT?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 14 Nov 2014 01:19:04 -0800, Hubert wrote:

>> Hmm, actually OOD and OOP require more upfront design than traditional
>> procedural approach. Ad-hoch subprograms are much easier and quicker stuff
>> than ad-hoc type + subprograms (=class) with thinking about possible
>> inheritance etc.
> 
> That maybe the theory, but what I have experienced is that it is 
> immensely easy to just start writing code and have great success with 
> it. In fact it is much easier than writing subprograms and modules etc. 
> That is the stuff that requires planning.

I don't see how this could be true. One problem with such statements is
that people compare incomparable things or consider usage of ready
components as if it were the program of their own. If you carefully analyse
any of these activities under procedural vs. OO approach you will find
that:

1. Reuse is in order of magnitude easier and safer when with OO.

2. Writing your own new code requires more upfront thinking and writing but
is greatly safer in the long run.

Ergo, OO is good for software engineering, which should surprise nobody,
because in essence OO, leaving OOA/D religion aside, is nothing but an
improved type system.

> Objects just "flow from the brain into the computer". But later they are 
> going to bite you and that is my criticism. That it seems so easy and 
> natural in the beginning which gives the programmer a false sense of 
> security.

This is a logical fallacy. Compare: Ada gives the programmer a false sense
of security, therefore we must stick to ANSI C.

OO is as insecure as the OOPL allows it to be. E.g. Ada requires overriding
the primitive operations returning tagged results. That is secure. Ada does
not require either "overriding" or "not overriding" to appear. That is
insecure. So?

> Of course I know that UML is intended to be used in the planning 
> process, but it is so overcomplicated that many people will never use 
> it. I know I don't (except timing diagrams which are pretty handy when 
> it comes to multi threading programs).

Modeling is a part of OOA/D, not OOP. I am very sceptical about OOA/D.
Regarding modeling it is IMO a plain wrong approach to software
engineering. But again, that is not OOP. You can do OOP without modeling as
well as modeling without OOP or even without having an OOPL.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de