Quo vadis, GPC?

[Frank Heckenbach]

Mike Reid wrote:

> I'm one of those who uses GPC for legacy code. Important legacy code,
> since it's the major code we use in our modelling and data analysis,
> which I started back in the 80s as a postdoc. 
> 
> So I am eternally grateful that GPC saved me the trouble of rewriting
> the code when our main platforms became Linux, after using CDC, Prime,
> AIX, Sun and DEC machines (and perhaps some others that I've
> forgotten...) 

:-)

> My code is mostly generic Pascal, but I do interface with the Lapack
> libraries and some of the C file-handling functions. In fact, I mostly
> use an ancient Linux version of the compiler, since I have no need for
> developments of the language itself. 

Of course, these ancient versions continue to be available, though
it will probably get harder to use them over time with each upgrade.

FWIW, I recently set up a Debian squeeze testing system for other
projects and also tried the GPC package in it (based on gcc-4.1).
After I found that it doesn't work satisfactory for my purposes (see
my article), I just installed the package from etch (2 major
releases earlier), the last one based on gcc-3. It installed without
any problems or dependency conflicts and works well, as far as I've
tested so far. So at least for the lifetime of squeeze (another few
years), there will be a working GPC easily available under Debian
Linux, and if GPC development doesn't continue, I will use this time
to port my programs without hurry.

Rugxulo wrote:

> GPC's strengths are its multi-platform, cross-compilable base with
> good optimizations and support for lots of dialects (and good docs and
> examples, IMHO). The downside is few developers (so?),

... so development stalls. :-(

> relying on
> semi-outdated GCC versions (so?),

... so much effort is required which there's noone there to do. :-(

> somewhat hard to bootstrap on
> non-*nix (so?),

Maybe not so big a problem, since The Chief, Maurice and Adriaan
have provided binaries for the main three non-Unix platforms.

> big runtimes and thus big .EXEs (so?),

Not a problem for most cases, sometimes a problem for embedded
systems etc. and for people with a 1980s mindset ("oh shock, a few
megabytes executable"). ;-)

> lacking the
> latest / greatest from Delphi (so?),

Ask some Delphi developers. ;-) For me, the lack of other features
is more pressing, as I wrote.

> and lacking a public CVS/SVN repo
> for current sources (not needed by me, but ...).

We once had one, it didn't change much in our development, except
causing extra work for us to maintain it. It was said back then how
important it was, but the simple truth is that any infrastructure
problems (including the build process, which takes some steps to set
up, but that's it) are minor compared to the actual effort of
getting fluent with GPC's internals, so none of the infrastructure
initiatives did anything to get us more developers (for the actual
compiler).

John Gordon Ollason wrote:

> Without a thriving population of young programmers the language will die,
> and I suspect that the formal virtues of a language in the ALGOL tradition  
> are not being transmitted, and perhaps new programmers are not being  
> equipped to recognize the admirable qualities of Pascal.

I don't want to get too philosophical, but I think a reason for its
decline was that in several ways it just was too strict. E.g., while
I dislike "goto" as much as Dijkstra did, I'm not so much opposed to
"Exit" (which some dismiss as a disguised goto, and ISO Pascal
doesn't have). Quite often, a routine needs to return early based on
some initial checks. The alternative, wrapping the whole body in an
if-block, though syntactically cleaner, just doesn't help
readability, neither when tracing the "Exit" case (look over the
whole if-block to find out that it extends until the end of the
routine), or the normal case (look over the whole if-block to make
sure no statments appear after it that would be executed in both
cases), and last (and least) of all, adding more indentation levels.

Similar for the I/O system in ISO Pascal which is so simplistic that
it might be suitable for simple (I hate to say, academic) cases, but
anything that requires more control is outside of the scope, thus
inviting diverging extensions. (In fact, it might have been better
to leave I/O completely out of the language, like C did, and let
library authors develop it -- except, of course, that the original
language didn't even have libraries or modules in the first place,
a big shortcoming in itself.)

Same with the lack of an official, and therefore standardized way,
to interface with foreign-language libraries, a common necessity in
real-world programs. (Sure, you can reinvent every wheel, i.e.
reimplement every library in Pascal, but that's not productive.)

So that's perhaps why BP was popular under Dos, because it was one
fixed dialect (so diverging extensions, though massively present,
and their long-time consequences, were not known to the majority of
programmers), I/O was extended to be at least suitable for Dos
(though it maps less well to other systems which were ignored by
most Dos programmers) and supported modules (units) which allowed
some other needed facilities (such as CRT) to be supplied. But all
of this was too short-sighted: We now have a mess of dialects;
Dos-style I/O is too limited on modern systems; even CRT (one of the
least bad designed BP units IMHO) wasn't as lasting as its C
roughly-counterpart curses). So it's no surprise that BP's
popularity sharply declines with Dos's. And under Windows, I'm not
an expert, but ISTM that Delphi's decline is largely due to MS's
pushing their own languages -- which is, of course, always a natural
risk for anyone targeting Windows exclusively).

> I suggest, therefore, that no substantial development of GPC would be cost  
> effective unless there were a large base of users of the language, and  
> that the first priority should be to determine the number of current users  
> of the language and to estimate its expected future use. My own  
> pessimistic assessment may be mistaken; I hope it is, but it would make  
> sense to find out before committing a substantial amount of effort in  
> further development of a language that is only used by a small minority of  
> programmers.

I agree with you here. Indeed, one of the purposes of my posting was
to determine the number of current users of the language and to
estimate its expected future use. But I'm also still pessimistic
that a rewrite is really worthwhile, also because, as far as I've
gathered so far, the current GPC users seem to be rather diverse
(WRT dialects, platforms and features used etc.), which also doesn't
bode well for a new project.

Don't get me wrong: I don't regret the time I spent with GPC, even
if it was to die now. It was an interesting experience, learning a
lot not only about the various Pascal dialects, but also about
compiler construction in general (which has benefitted me in other
projects since then), and since I did professional work with it, it
was even paid. :-) And while it was at it, it was only natural to
write my hobby projects in it as well. But as with many things,
their time comes and it goes, and it may be its time has gone now
and maintaining a compiler only for my hobby projects is just not
efficient.

Frank

-- 
Frank Heckenbach, f.heckenbach at fh-soft.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8