Deposing Dictators

[Dirck Blaskey]

"Stephen Horne" <steve at lurking.demon.co.uk> wrote in message
news:fls3mt0ofg36qek58fjm4ebqgnd7bcbuek at 4ax.com...
> On 27 Jul 2001 14:58:35 -0700, dirck at pacbell.net (Dirck Blaskey)
> wrote:
>
> >Inertia should always be taken into account, but it should never
> >be the single deciding factor - or we'd all be working legacy COBOL.
>
> A couple of years ago, you may remember a major panic caused by
> peoples realisation that a hell of a lot of COBOL code was going to
> stop working. The developers were long since retired. In many cases,
> the source code was long since lost. That COBOL program was still
> there and working, though, some 20 or 30 years after it was written.
>
> Useful programs aren't discarded so fast as development fashions and
> religions. The trouble is that Python programs - and libraries much
> more so - are quite often shared in source form.

I would much rather get the source instead of the executable,
at least then you have a chance when it breaks, for whatever reason.

I'm aware that this kind of code exists, but personally I don't consider it
the normal case, nor would I find myself faced with COBOL.  The closest
equivalent I can come up with: I still run into people using dBase III.

Current popular platforms didn't exist 20 or 30 years ago.
Minicomputers are no longer 'in fashion', I guess.

In general, I believe the axiom:
"Any useful program will need to be modified",
even though that's obviously not always the case.
On the other hand, that depends on your definition of "useful".

I don't consider Python a development fashion or religion.
( God save us from the true believer ;^)

I would agree that upgrading just for the sake of upgrading is pretty
silly - there has to be a payoff - even if it's simply -
"You can't stay on maintenance unless you accept a maintenance release."

On the other hand, I've never understood the corporate mentality of
"The bugs we know are safer than the fixes we don't know".

And on yet another hand ("the gripping hand"),
a big shop with a big investment has to consider the cost,
regardless of what they decide.

Inertia in the software world is a huge force, and always
to be fought tooth and nail, because generally what Inertia means is:
"Just live with our mistakes because we can't afford to fix them."
This is an extremely depressing state.

(Windows Me is still MSDOS, down deep, int 21Hs and all.  How odd.)

> >I think this is where most of the reactionary responses come from.
> >C is deeply ingrained in the programming culture, because in a lot
> >of ways it was, and in some ways still is, The Programming Language.
> >Anything you do, day in and day out, year after year, no matter how
> >odd or perverse or inconsequential, becomes 'the natural order of
things'.
> >The more deeply ingrained, the harder it is to actually see.
>
> If that was true, we wouldn't be using Python at all. After all, it is
> a dynamically typed language that stores its identifiers in a hash
> table - it provides a keyword to say 'a function definition is coming'
> rather than leaving it to issues that often depend on the semantics
> (rather than simply grammar rules) of what has happened in the past.
> And it doesn't even allow you to use braces for block structures. How
> not-like-C can you get?

I'd wager that by far most of the current Python users know C, and
probably a large percentage of them have a lot of C experience.

Python isn't written in Python.

Not yet anyway, and probably not for a long time.
On the other hand, we can always hope :^)

d