|
Sir,
I found an apparent contradiction in Chris
Rimmer's editorial
reply to the Bytegeist article. Chris
suggests that the fault of the OOP system not being
able to handle the addition of reconciliation was
caused by not understanding the business requirements
well-enough UP FRONT rather than a failure of OOP
itself. However, he later makes anecdotal claims
that OOP helps "in reducing development time
by making the system more robust against changing
requirements..."
A request to add reconciliation
certainly sounds like a "changing requirement" to
me. One never knows what will be requested of a
system in the future.
Bryce Jacobs
Sir,
Dermot Hogan says "What I’d done was
to modify the behaviour of a base class. And this
behaviour had then propagated with effortless ease
through the whole damned system."
If you don't use OOP and change some function,
which can be called from anywhere, isn't there the
same problem? Could you explain why this is related
to OOP? I agree, OOP is not perfect, but I think
this problem can occur on every system, which allows
you to call subroutines.
Jens Gruschel
Sir,
Many thanks for the Smalltalk
tutorial.
I struggled to learn Smalltalk some years ago but
could never get very far. I’m not sure why
but I think it was all that stuff about ‘sending
messages’ that baffled me. It was good to
get to grips with the language again. Your tutorial
was a big help and I really found myself enjoying
writing Smalltalk code this time around. I hope
you’ll
continue with your Smalltalk coverage in future!
Danny Weston
Sir,
Congratulations on The
Strange Death of Visual Basic by
Dermot. My only comments would be that picking
on GoSub as a specific case may close many minds.
I have experience of many languages -- writing
compilers for some -- and so I know to avoid
GoSub because of portability issues. Our code
deliberately has zero instances of this construct.
However, instead
of considering the plight of a company with 100,000
lines, try 10 times that, much of which relies
of COM apartment threading, custom shared-memory
mechanisms, COM's "deterministic finalisation",
interfaces to Windows Services and other features
which require access to true VB run-time support
(not the VB.NET variations), and a proper Variant
data type, otherwise we lose that compatibility.
Although we're relatively successful, we're also
pretty small. We're struggling to find the money
and resources to re-design our products (not
just do a syntax port) for the .NET environment.
Continued support for the old code base also means
duplicating Development, QA, Support, and Documentation
effort until such a time as all our customers have
switched. Given all these headaches, VB.NET will
be our last choice of a target language, assuming
we manage the transition of course.
Name withheld
by request |
