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