Re: What exactly is the licensing situation with GNAT?

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

On Mon, 17 Nov 2014 08:36:49 +0000 (UTC), Stan Mills wrote:

> On 2014-11-14, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Fri, 14 Nov 2014 10:38:17 +0000 (UTC), Stan Mills wrote:
>>
>>> On 2014-11-14, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>> On Fri, 14 Nov 2014 09:02:49 +0000 (UTC), Stan Mills wrote:
>>>>
>>>>> On 2014-11-14, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>>>> On Thu, 13 Nov 2014 17:36:06 -0800, Hubert wrote:
>>>>>>
>>> Oh, I beg to differ. Sun certainly dumbed down programming when they
>>> designed Java. It's about making unqualified people "productive" and the
>>> best way to do that is for qualified people to write as much code as
>>> possible for unqualified people to use. The primary feature of OO in
>>> practice is the huge set of class libraries to reduce the amount of future
>>> coding as much as possible to simple cut and paste of existing bad code.
>>
>> Well, and the alternative would be? To re-implement everything each time?
> 
> No, the alternative is if the qualified people who were involved in
> engineering the class libraries actually designed coded and maintained the
> whole application using those class libraries. Barring that, using qualified
> people would be a good start.

Where is a difference? If your program is going to use TCP/IP sockets, you
either hire gray-haired pensioners who wrote the Berkeley API (horrific
stuff, BTW) or you redesign it from scratch. Since the former is not
possible, only the later remains.

>> Actually, the maturity of an engineering discipline is measured by the
>> level of reuse of standardised solutions and components.
> 
> That works for engineering but large software systems are not successful
> when built entirely or even in major part with foreign components.

It is a risk which must be evaluated and contained. If the risk quite
frequently is too high that indicates immaturity of software engineering.
Nobody denies that fact.

>>> The
>>> only thing a regular programmer can't write in Java or C++ today is
>>> something that doesn't already have a class library to do it for him.
>>
>> Maybe. In this context, can the regular programmer do anything better with
>> any of competing paradigms:
>>
>> 1. Procedural
> 
> Bad programmers are exposed more quickly by procedural methodology more than
> OO. They can't deliver stuff that works, on time, so you fire them.

Which is why OO is better than procedural. The goal of software engineering
is to develop programs. It is not exposure of fools.
 
>> 2. Functional
> 
> Not sure it has any use in most commerce and industry.

Yep.

>> 3. Relational
> 
> What? ;-)

Like with functional there are a lot of people crazy enough to believe in
this paradigm.

>> I bet, that anybody is far better off with OO than with any from the
>>above.
> 
> I don't agree and the problem is not limited to OO. It's just magnitudes
> worse with OO because all the "hard" stuff is done by the other guy. This
> allows people to work over their heads and in my experience that is never
> ever a good thing.

This is called division of labor. Why is it bad thing in programming when
being good everywhere else?

> The main thing OO hides is unqualified programmers.

Yes, just like bus traffic hides unqualified horse riders...

> Using qualified people end to end. Then the problem goes away.

There are no people qualified to redesign everything needed by an average
SW project.

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