[Tutor] Dumb question

[alan.gauld@bt.com]

> The concept of a class fell out of the problem of *managing* 
> programs that were hundred's of thousands of lines long. 

Nope, sorry. Classes came from simulation.
Simula67 was devised to model problems in telecommunications.
Smalltalk 73 thru 80 came from experimenting with CS concepts.
The early LISP OO variants (Flavors, LOOPS etc) during the 
70s and early 80s likewise were focused on experimental 
projects, not large scale stuff. I could also mention CLU, 
Dylan etc...

It was only in the 1980s with C++ that using classes as 
an organisational concept to control large projects
(with millions not 100Ks of lines of code) came to be.

We were building programs with many 100K LOC without 
OO for a long time. 100K lines only needs 1 or 2 programmers.
Not hard to organise or maage, 10 million LOC needs scores 
of programmers and yes OO helps to organise that but its a 
beneficial side effect.

If classes were primarily about organising large projecs 
we wouldn't need them in python - very few projects in 
python (if any!) get close to 100+ programmers

> 1)Upgrading only parts of the entire program without wrecking 
> the rest of the application, 

Is much harder to achieve than it sounds - read the 
metaclasses book to understand why...

> 2)Debugging, 

There is much objective evidence that suggests that OO projects 
are no easier to  manage than non OO. What is more important 
is having a clearly defined architecture and code structure, 
with all programmers asdhering to those principles. One study 
indicated that using C++ on a project coud increase the 
mainteance overhead - especialy when multiple inheritance
is used(abused?)

> 3) coordinating the efforts of not one
> programmer, but scores of programmers. 

As I said thats a side effect, ot what any of the early 
OO languages were concerned with.

> won't see that until you start working (designing and coding) 
> on a huge project. 

The biggest project I've worked on was a 40 million line 
of code COBOL system written by over 400 programmers 
working for 3 companies in 4 countries. There were bits that 
were OO but most wasn't (The UI was written in Smalltalk)

The second biggest was 3.5 million lines of C/C++ and was 
entirely OO(even the C parts using a proprietary OO library)
This had over 100 programmers in 3 sites.

The organisation of both projects was very similar. The OO 
aspects had little to do with the success or failure of 
either project. Interestingly the COBOL system is still 
running, the C++ one was decommissioned 2 years ago after 
8 years of service.

I've been programming in objects since 1984 in 9 different 
OO languages, I think OO is a valuable tool in the 
programmers toolkit. Its also important to recognise 
the problems it introduces as well as the benefits it brings.

> In short, classes give you code organization. Joseph

They do indeed. But what organisation do you use?
You model your problem, that's what provides the intellectual
leverage to make large bodies of code comprehensible. 
You can trace requirements(and bugs) from the customers/users 
language right through to the entities in your code.

Alan g.