[mercury-users] Native garbage collector for Mercury

[Richard A. O'Keefe]

	Well, this is what some of the talking heads of Sol 3 are saying: 
	
	        Mark Andressen says "If you write your apps in Java, you get
	                             less features and more instability".
	
	        Linus Torevalds says "Java on the desktop is dead.  And once
	                              you're dead on the desktop, your dead."
	
	        Mark L. Van Name & Bill Catchings 
	            "A second wave of hype advanced the notion of Java as
	             the right way to build back-end server applications.
	             We're skeptical that Java will succeed in this area
	             because server applications tend to have to scale well,
	             and interpretive languages such as Java must grapple
	             with inherent performance issues."
	
Any "talking head" that calls Java an "interpretive language"
is pig ignorant; if such a person says it's a fine sunny day,
be very sure to have your umbrella.  Yes, >>JVM codes<<< can
be interpreted, but they can also be compiled, and there is
no shortage of Java->native code compilers (like Toba) nor
any shortage of JVM->native code compilers either.  Heck, a
student I was co-supervising last year was benchmarking Java
running native about 18 months ago.

Van Name & Catchings also have a few important things to learn in this
business:  emulated systems like Quintus Prolog and Erlang/BEAM 
scale *better* than native code.

The kit of stuff available for Java is growing explosively.
For what it's worth, I *dislike* the Java language, and have no
affection for the JVM.  But this semester I set some students
the task of writing a word-counting program.  A rather trivial
task for 3rd-year students, you think?  Not so, they have to do
it, and do it _right_, using Unicode.  We have a *lot* of
programming languages available:  C, several Pascals, C++, Ada,
Tcl/Tk, Parlog, several Prologs, Fortran 77 and Fortran 90, Perl,
Scheme, Common Lisp, SML, Haskell, Clean, SISAL, (Small)Eiffel,
Sather, you name it, we've probably got it.  There is *ONE* of
those languages in which the problem is easy, and I didn't know
that until _after_ the assignment was set.   Which language?
Java.  In fact, much as I dislike Java, I have to admit that if
you want to teach I18N/L10N, Java is probably the language of
choice.

The use of Java as a first-year teaching language is also growing
explosively.

The set of languages for which compilers to JVM are available
is astonishing.  There are even a couple of commercial COBOL->JVM
compilers available.

There are enough people and organisations now committed to Java
that it'll keep rolling regardless of its merits.

	> The point is that they *became* very popular, that they became
	> *mainstream*, without ever having an operating system written in them.
	
	Actually, logic programing itself was once mainstream: it dominated the
	entire computer research agenda of an entire country (japan).  What counts
	is staying power.
	
But now you are introducing a completely new topic.

	While these guys were rising and falling, C was just getting bigger and
	bigger.  Why?  Because in addition to unix, one by one every desktop OS
	started to be written in C (and later, C++).
	
I have no idea whether Windows 95 is written in C++ or not.
What I do know is that nobody in his right mind cares *what* the
operating system is written in.  For heaven's sake,
when I used a /360, I knew the OS wasn't written in PL/I or Fortran,
but why should I care?  When I used a B6700, I knew the OS was written
in ESPOL, but I kept on using Algol and Fortran just the same (not least
because I _couldn't_ write application programs in ESPOL).  I presume
that early versions of MacOS were written assembler; that didn't worry
the people who wrote in Pascal for it.  VMS was written in BLISS-32,
with some MACRO-32, but VMS *application programmers* couldn't have
cared less; they wrote in COBOL or BASIC or Pascal or C or Fortran
or whatever suited their needs and had *no reason* to care what the
OS was written in.

You are here confusing
    "the operating system is WRITTEN IN language X"
with
    "all operating system services are AVAILABLE IN language X"
which are two totally independent questions.  All the VMS system
services were available to all the VMS languages.  All of the Win32
system services are equally available to C and Ada; if it were
rewritten in Ada, the only change anyone would notice would be
fewer BSDs.

	> I could add the XBASE family of languages,
	
	Yeah, same for Lotus 123 with its scripting language--and they suffered the
	same fate.  When the OS shifted out from under them, they fell like a
	house of cards on a 3-legged table.
	
Again, you are shifting topics.  Your claim was that a language had to be
suitable for writing an OS in order to become 'mainstream'.  I have
conclusively demolished that claim.  Now you are talking about 'staying
power'.  But that's a different topic.  Do you now claim that a language
must be suitable for writing an OS in order to have staying power?
But where are PL.516, PL/360, Bliss-10, ESPOL, and a host of others
today?  On the other hand, where are COBOL (still hanging on), the UNIX
shell (still around), and Fortran (still being actively developed,
because still useful and hard to beat in its own niche).

What exactly is it about a 3-legged table (THE MOST STABLE KIND?) that
makes card houses particularly likely to fall on it?  Need I remind you
that the XBASE family became popular on DOS, and that DOS programs can
still be run?  The problem was *not* in any way shape or form a problem
of OS change, it was the development of a *family* of languages all
heading off in different directions, fragmenting the market.  (Which
doesn't mean there aren't still a *lot* of people maintaining XBASE
applications and even developing new ones; there are.)

	> (which, I need hardly remind you, means Visual *Basic* for Applications).
	
	....which is yet another programming language which is tied to
	the agenda of an operating system.
	
Yes, but the claim I was attacking was that a successful language had to 
suitable for *IMPLEMENTING* an operating system.  Visual Basic for
Applications was *not* used to implement MacOS 8.1, which is what I am
constrained to use it on.  Nor is Visual Basic for Applications tied to
any of Apple's agendas that I've ever heard of.

	> The point is simply that a language doesn't have to be a SIL in order
	> to become `mainstream'.  It has to be very useful for *something*, but
	> that `thing' doesn't have to be OS implementation.
	
	True enough.  But most workaday programmers are of the "show me" mentality,
	and I still contend that the most vivid (and historically successful) way of
	proving that a programming language is good at something is to write an
	operating system in it.
	
This is a drastic weakening of the original claim.
Let's take the claim at face value.
Pop2 was used to implement an operating system.
Did that make Pop2 mainstream?
Lisp has been used for at least five operating systems;
Xerox Lisp Machines, Symbolics Lisp Machines, and LMI Lisp Machines,
and a couple of Japanese ones (no, the Japanese never put all their
eggs in one basket).
Did that make Lisp mainstream?
(Symbolics _thought_ it would, but they were, alas, wrong.)
Algol 60 dialects were used to write several operating systems.
Did Algol 60 ever become mainstream because of that?
Mesa was used to write an operating system,
one that actually had a good deal of influence (Star).
Did Mesa become mainstream?
Has Mesa's successor Modula-3 become mainstream?
Oberon was used in a really *brilliant* piece of work
to build a *small* but powerful operating system.
There are Oberon enthusiasts, but has Oberon become mainstream?
PULSE and RTEMS are written in Ada; has that made Ada as popular as C?

The claim that language success and SILness are even _weakly_
related thus appears to be comprehensively false:

    there are plenty of languages that _were_ good for writing
    operating systems that never became mainstream.

    there are plenty of languages that were _not_ good for
    writing operating systems that _did_ become mainstream.

    there is a huge number of languages that were not good
    for writing operating systems and did become mainstream.

    the set of languages that were good for writing operating
    systems and became mainstream appears to be a singleton:  {C}.

We now have two other claims on the table:
    "it isn't becoming mainstream that counts, it's staying power"
    "it's enough to be tied to the agenda of an operating system"

I suggest that the criteria for language success are actuall
dramatically different.  It's this simple:  a lot of people have
to *know* the language (so someone has to *teach* it to them)
and they have to *want to use it* (so it can't be *too* horrible
for at least one important problem area and there can't be a rival which
is *spectacularly* better).

You have to capture the hearts and minds of the people who _teach_
programming so that they will indoctrinate their students into believing
that your language is good.  You have to make it easy for people to
acquire your language:  a decent book is important and free compilers
help a lot.  (The Ada group would never have been able to persuade RMIT
CS to switch to Ada if it hadn't been for GNAT.)

	Moreover, what does Mercury lack besides real-time garbage
	collection to serve as the ultimate SIL?

Threads and IPC.
A really good book explaining _how_ to use it as an SIL.
A second source for Mercury compilers.
...