Re: Remarks on SWI 7

On 27/11/2013, at 9:28 AM, Feliks Kluzniak wrote:

> 
> Now SWI-Prolog seems to be becoming a new language.  It might be a better one, for all I know.  There might even be a need for it, though the evidence seems scanty so far.  But I am very much afraid that it might soon evolve to a point where it is no longer Prolog: that „traditional” flag is likely to become more and more of a burden, and command less and less attention (even Jan’s very considerable talents and energy are necessarily limited).

By the way, let me offer a parallel.

Some years ago I got interested in Eiffel.
At that time there was an innovative free implementation from INRI
called SmallEiffel, later renamed to SmartEiffel.
The inventor of the language made some changes to the language,
and the implementors of SmartEiffel made some different changes
to the language, and eventually the author of the main
multi-implementation library for Eiffel gave up porting to
SmartEiffel.  A couple of years later SmartEiffel was dead.
There is an attempt to revive it, but Liberty Eiffel is not
yet in a state where I can use it, and when I _did_ need to use
Eiffel this year, it was the one from the ISE company I used,
which is free as in beer for personal use.

A thing I was passionate about for years but eventually got
quite depressed about was multi-implementation libraries for
Prolog.  I have enormous admiration for Paulo Moula, still in
there slogging.  The more bikeshedding differences (like []
vs '[]') are introduced, the harder it gets to write and port
such things, and the worse off everyone is.

The point of a standard isn't to be the *best possible* language,
but to let people *share their work*.

Just recently one of my colleagues was ranting to me about
a change to the C++ STL library, where ostrstream was
deprecated in favour of ostringstream, which is _almost_ the
same, in order to help the more hard-of-thinking C++ programmers.
He has perfectly good working code which his compiler just
recently started nagging him to change.  He'll probably end up
writing his own replacement so that he can be *sure* it will
hang around, which is not the best way for the world to use
his time.

When I ported my Smalltalk to OpenBSD it nagged me about
perfectly safe uses of strcpy() and sprintf(); to shut it
up I had to waste a couple of days rewriting *working* code
for no net benefit except to cope with a gratuitous porting
difficulty.

One important thing about the [] \== '[]' change is that
for any particular chunk of Prolog code, there is no tool
that will let you *tell* whether it is broken by the
change, short of *thorough* inspection and re-testing.
Even if the code *isn't* affected, there's a high cost in
not *knowing* whether it is affected.  And no benefit at
the other end, because once you start writing code for a
system that distinguishes, will your code work in a
system that conforms to the standard?  (Hint: _don't_
work in the new system and then port back; you have to
_keep_ testing more or less simultaneously in both, and
you have to keep in mind _all the time_ that [] might or
might _not_ be different from '[]'.)

I liked SmartEiffel, and I thought its changes were _better_
than those in what became ECMA Eiffel, but I hated being
trapped in the ghetto of SmartEiffel, and
I never want to be in such a trap again.