On 19/05/18 01:17 PM, D. Hugh
Redelmeier via talk wrote:
| From: David Collier-Brown via talk <talk@gtalug.org>
| It's notable that Linux numbers the interface, not the library. This came from
| Multics, and was heavily used by Solaris and the glibc developers to avoid an
| NP_complete problem of "how do I have two versions of something at the same
| time?" More details that you ever wanted in
| https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/
Interesting. I haven't (yet) read references from the blog posting.
The example of memcpy with overlapped arguments is interesting.
Primarily, it's a trivial example that everyone will understand.
It is also an example of a bug and people trying to code in
terms of the bug. Arguably not a good thing to do ...
If I remember correctly, overlapping arguments was banned in about
1980. So the chances of C code being older than that is rather low
these days. Less so code that is unmaintained.
So using overapping is a bug. Do we really want to keep old libraries
to support buggy code?
Some people don't have the source to their programs, so they can get
stuck using an old interface, and be unable to recompile if the
library changed. We had that with linker records at Honeywell: we
could add new ones, and even require people to set a particular flag
to force them to be still honored, but we didn't succeed in taking
the one I was involved in out. Others removals went fine, so no-one
seemed to have been wedged by them.
I used the example in part to illustrate that there are tradeoffs,
and also "religious" debates over whether something is a bug or a
feature.
There's one religious debate going on right now about closures in
Go. Everyone who has been caught by the bug splits into one of two
camps. One group says "fix it, it doesn't break any programs that
have coded around the bug". The other group says "It's a feature. I
had code around it, and everyone else should have to, too"
That one's an example that argues for not supporting old interfaces,
while the lost-code example argues for retaining them even when it's
to enable deliberately doing a wrong thing.
I think code improves when it tracks the things it depends on. Look
at C and its compilers: it has gotten much better at letting the
programmer express intentions and detecting inconsistencies. Code
that doesn't use those features is likely less reliable.
Yes. For a language to advance, it has to be able to stop supporting
old interfaces. Thus my snarky comment about coding in terms of a
bug (;-))
Doing so may take a deep text-to-text transformer like "go fix", and
it may take a sliding window of how old an interface can be, with
occasional special case like the Honeywell GCOS linker's
-allow-old-call-frames option.
I find it disgraceful that the transition from Python 2 to Python 3 is
still a thing 10 years on.
IMHO, they need a "python fix" program that transforms at the parse
tree level, not just textually like 2to3 and 3to2 do.
--dave
[There's a ton of interesting stuff in the David J Brown paper]
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net | -- Mark Twain