Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!unizh.UUCP!nagler%olsen From: nagler%olsen@unizh.UUCP (Robert Nagler) Newsgroups: comp.lang.modula2 Subject: Re: Modula 2 for the Sun 3 - summary of responses Message-ID: <8808031146.AA02768@klaus.olsen.uucp> Date: 3 Aug 88 11:46:17 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Info-Modula2 Distribution ListOrganization: The Internet Lines: 68 >If I were developing a serious product on Suns, I'd probably stick to C; >teaching in an environment where Modula-2 is known requires a M2 compiler. >Sun's is very good for the job. (I won't expound on that point in this >paragraph. ;-) After developing a "serious" system with Sun's M2, I think it is worth a couple of words to "expound" on the subject. I understand the statement that one should "probably stick to C". Believe me, I have had serious doubts about using M2 for our project. One of the first problems anyone runs into is the absolute awful quality of most M2 implementations. Sun's is "pretty good" compared with the others, but it certainly isn't a "production system". We also use Logitech's compiler. We have put in lots of glue to make the development environment "nicer". From past experience with C, the same glue is required. The main reason we haven't used other M2 products is that we write software in Modula-2 as defined in Wirth's books not in the languages supported by Oregon Software, Taylor Modula-2, and the like. These other compilers do not support use before definition. This is probably the biggest stumbling block you will find in Modula-2. If you pick to go with the one-pass compilers, then you won't be able to run with the two-pass compilers and vice-versa. As with any C developer who writes portable software, we have found a great need for a preprocessor. We use it to control what code is compiled. This could help us with the 1-pass/2-pass problem, if we need to switch. Most compilers don't provide conditional compilation and if they do, the control statements are in comments. (Rather silly place for conditional compilation control, if you ask me.) If you aren't developing portable software, then this probably is not that big of an issue. When you develop Modula-2, you need to do IO. Every implementation provides InOut and some other random set of library modules. In order to write portable software, we had to write a portable library which can be ported to different compilers, operating systems, etc. AND the library definition itself must be portable. The library is about 60 modules of which about 10 or so are implementation dependent. This is invaluable feature number 2. And, it allowed us to write the preprocessor in a portable fashion. There is a real advantage in writing your own library (or having the source to one): you can fix bugs and add new features on an as needed basis. There are many other problems one has to solve, but the biggest problem for most people is using a window system from M2. There are many aspects to this problem especially on the Sun. First, which window system do you want to use? You have Suntools, X, and NeWS. We've been tending towards X, because it is "portable" and it runs with NeWS and Suntools. Second, you must interface Modula-2 to the system you choose. With Sun there are two alternatives: SYSTEM.CCALL and DEFINITION FOR C MODULE. We use the latter here, because it makes it easier on the next guy. If you care about portability, then you will probably want to either buy into X or make up your own "standard". We're taking a hybrid approach. In hindsight, Modula-2 is a good system building language. With C++ becoming a new fad, perhaps it is a better choice. It certainly resolves many of the interface issues with C. However, C++ still doesn't have compiled interfaces and a hierarchical naming mechanism, thus M2 still has a considerable advantages. If you choose Modula-2 or C++, you probably have to be committed to it (or just committed). If you aren't willing to make the committment, you probably are better off sticking with a more conventional language such as C (but at least use lint!). Rob olsen!nagler@uunet.uu.net