steven@boring.UUCP (01/14/85)
In article <25@seismo.UUCP> keith@seismo.UUCP (Keith Bostic) writes: > Come on -- let's not start a PASCAL vs. C debate, okay? Quite. But then why say more? > Pascal in its standard form is simply not useable for anything except cute > little application programs. I'm not the world's greatest Pascal fan, but this is just not true! I've seen many large useful programs written in standard Pascal, and written well. Steven Pemberton, CWI, Amsterdam.
g-frank@gumby.UUCP (01/15/85)
> In article <25@seismo.UUCP> keith@seismo.UUCP (Keith Bostic) writes: > > Come on -- let's not start a PASCAL vs. C debate, okay? > Quite. But then why say more? > > > Pascal in its standard form is simply not useable for anything except cute > > little application programs. > I'm not the world's greatest Pascal fan, but this is just not true! I've > seen many large useful programs written in standard Pascal, and written well. > > Steven Pemberton, CWI, Amsterdam. This discussion is a little stacked. No one really thinks that ISO Pascal IS good for anything except cute little application programs. That's why everyone and his sister and brother and major professor is out selling some souped-up variant of the language. This makes it almost impossible to discuss "Pascal" vs. anything. The better comparison is Modula-2 vs. C. The language attempts to address the same kinds of goals (i.e., systems programming, operating systems) while preserving strong typing and adding other advanced concepts (modularity, monitors, coroutines, etc.). It is also a standard, so discussions don't have to center on whose implementation does that thing you just said the language didn't do. Modula-2 is a much better answer to the old, "but strongly typed languages are so INFLEXIBLE" chestnut. -- Dan Frank "good news is just life's way of keeping you off balance."
mark@rtech.ARPA (Mark Wittenberg) (02/02/85)
> >> Just to add coals to the fire, between Modula-2 and Concurrent Euclid > >> I'd choose CE anyday. > >> > >> Mark Wittenberg > >> Relational Technology, Inc. > >> Berkeley, CA > > >No arguments from me, Mark. CE is indeed a VERY beautiful language. > >-- > > Dan Frank > > U of Wisconsin CS dept > > In which case, I'm afraid I can't resist an opposing view. > > CE compares favourably with Modula-1 but not with the more recent Modula-2. > > (1) The concurrency features (processes/monitors/signals) are just > what the original Modula-1 offered. They are implemented by magic > kernel primitives over which you have no control. In particular, > you can't create new processes dynamically at run-time. Modula-2 > is lower level and gives you coroutines out of which you can build > a library module which gives you all the CE/Modula-1 concurrency stuff > if you want it, or anything else if you don't. OK, so you lose a bit > of syntactic sugar, but you gain in flexibility. > > (2) The separate compilation/strong type checking stuff in CE is again > more like Modula-1 than Modula-2. In CE there is no separation > between the implementation part of the module, and the interface to > the module - in Modula-2 these are two separate bits of the module > which must each be compiled individually. Both the compiler and the > linker will check for and enforce consistency - the version of CE I saw > just used the standard Unix linker so didn't do any consistency > checking at link time - it would have been easy to get the versions > mixed up and link incompatible code, completely subverting the original > intention of the type checking. > > All this modulo the particular Modula-2 and CE implementations I played > with circa 1981. > > Robert Stroud, > Computing Lab, > University of Newcastle upon Tyne. > > ARPA robert%cheviot%newcastle.mailnet@mit-multics.arpa > UUCP ...!ukc!cheviot!robert > > "Strong typing is for people with weak memories" > 1) Modula-2 gives you co-routines, not processes. Mutual exclusion with co-routines is much simpler than it is with processes. It is easy to implement co-routines in CE, but not to implement processes in M-2. You are right that you cannot dynamically create processes in CE. Monitors are implemented in the kernel but they aren't "magic" (by which I mean the implementation is straight-forward and reasonable). 2) CE does separate implementation from interface, but you are correct in noting that the linker doesn't enforce it. Nothing's perfect. In particular, you didn't mention that in CE you can't separate a monitor from the data it's protecting, by which I mean that if you have two object that you wish to protect in identical fashion you must write two monitors: you can't write one monitor and point it first one object and then to another. Too bad. Thanks for the best short note I've seen describing where M-2 might reasonably be considered better than CE. Mark Wittenberg RTI Berkeley, CA