[Tutor] Pair 'o dimes wuz: Volunteer teacher

[Alan Gauld]

On 24/07/2022 01:53, Leam Hall wrote:

>> programming was akin to bricklaying. The final part of the process after
>> you had
>> analyzed the system and designed the solution. Then you got your
>> materials and
>> followed the design. And, agile theories not withstanding, it's still
>> how many large
>> organisations view things.
>>
>>> Those OOAD tomes are someone else's opinion on how we should do things,
>>
>> That's true, albeit based on a lot of data driven science rather than
>> the gut-feel
>> and "personal experience" theory that drives much of modern software
>> development.
>>
>> But especially OOP is a style of programming that needs understanding of
>> the
>> principles before programming constructs like classes etc make sense. OOP
>> came about before classes as we know them. Classes were borrowed from
>> Simula as a convenient mechanism for building OOP systems.
>>
>>> until we have a handle on what we're actually able to do then there's no |
>>> frame of reference for the OODA to stick to.
>>
>> I'd turn that around and say without the OOAD frame of reference you
>> can't make sense of OOP constructs. Sadly many students today are not
>> taught OOP but only taught how to build classes, as if classes were OOP.
>>
>> Then they call themselves OOP programmers but in reality build procedural
>> programs using quasi abstract-data- types implemented as classes. And many
>> never do understand the difference between programming with objects and
>> building genuinely object-oriented programs.
>>
> 
> About the only truly universal things are hydrogen and paperwork, most everything else is contextual.
> 

> I'd be surprised that the founding fathers couldn't code in anything before they came up with OOP.

Not OOP. But analysis and design. Remember the founding fathers of
programming didn't have any interactive capability, they couldn't easily
experiment. They had to write their code in assembler and transfer it to
punch cards or tape. So they made sure to design their code carefully
before they started writing it. They only had limited tools such as flow
charts and pseudo code but the structure had to be clear. Code was
ameans of translating a design idea into someting the machine understood
and could execute.

It was only after the development of teletypes and interpreters that
experimental programming came about or even became possible. But it was
still the exception. Even in the mid 80's a friend working for a large
insurance company was limited to one compile run per day, anything
beyond that needed formal sign-off from his boss. And in the early 90s I
was working pn a project where we could only build our own module, we
were'nt allowed to build the entire system(in case we broke it!).
System builds ran overnight(and too several hours)

So it is only in relatively recent times that the idea of programming as
an experimental/explorative activity has become common place. And there
is definirely a place for that, its a good way to learn language
features. But if looking at things like OOP which are mich higher level
it still helps to have a context and an idea of what we are trying to
achieve. Focusing on the minutiae of language features to build classes
can lead to very bad practices, misusing fratures. The classic example
is the abuse of inheritance as a code reuse tool rather than as part of
an OOD.

>  It seems odd to design a building before you know how bricks or 
> electrical systems work.

But that is exactly what happens. You design the structure first
then choose the appropriate materials. Yes you need to undersand
about bricks etc, and what they are capable of but you don't need
to be proficient in the craft of laying them.

>  The building architects and civil engineers I know really do 
> have a handle on the nuts and bolts of things, 

In my experience (in electrical engineering) very few engineers actually
have much practical experience of assembling and maintaining electrical
components. They have an army of technicians to do that. They know what
the components are for, how they work and may have basic construction
skills for prototyping. But they don't normally get involved at that
level. Software engineering is one of the few fields where the designer
is often the constructor too.

> they spend years as underlings before they ever get to be lead designer.

Of course, but they till need to know the design principles.

> Design isn't code, it won't run on the computer. 

Neither will code without a design. You can design it in your head as
you go along, but it will generally take longer and be less flexible
and harder to maintain. Especially when it goes above a few hundred
lines. And thats where things like OOP comer in because each object is
like a small standalone program. Which makes it easier to design minimally.

> spend a lot of resources on failed projects and no-longer-useful designs.

This is a flat out myth! The vast majority of lage scale projects
succeed, very few are cancelled or go badly wrong (they are often
over budget and over time, but thats only measuring against the
initial budgets and timescales). It's just that when they do fail they
attract a lot of attention because the cost a lot of money!
If a $10-50k 4-man project goes belly up nobody notices. But when
a 4 year, 1000 man, project costing $100 million goes belly up it is
very noticeable. But you can't build 4000 man-year projects using
agile - it's been tried and invariably winds up moving to more
traditional methods. Usually after a lot of wasted time and money.
But the fact is that our modern world is run by large scale software
projects successfully delivered by the fortune 500 companies. We just
don't think about it and take it for granted every time we board
a train or plane, turn on the electricity or water, collect our
wages, etc.

>  Does anyone not have at least one experience where the designers 
> cooked up something that wouldn't work?

I've seen stuff that was too ambitious or didn't run fast enough.
But I've never seen anything designed that just didn't work at all.
(I've seen designs rejected for that reason, but they never got built -
thus saving a huge amount of money! That's the purpose of design.)
but I've seen dozens of programs that were attempted without design
that just didn't run, did the wrong thing, soaked up memory, etc etc.
Its just easier to hide when there is limited evidence (documentation etc)

> I feel one of Python's strengths is that it can do OOP, 

You can do OOP in any language, even assembler.
OOP is a style of programming. Language features help make
it easier that's all. OOP helps control complexity. Sometimes
its the best approach, sometimes not. But that depends on
the nature of the problem not the language used.

>  what paradigms they use is irrelevant; working code wins.

Working code wins over non working code, for sure.
But working code alone is not good enough. It also needs to be
maintainable, efficient, and economical. For that you usually
need a design. Spaghetti code has caused far more project
failures than design faulures ever did.


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos