Mark.Bacas@p0.f16.n396.z1.fidonet.org (Mark Bacas) (03/11/91)
Has anyone bought or looked at this book. I'm planning on buying it and was wondering if anyone has any first hand knowledge about it. Any help will be greatly appreciatted. .\\ark -- uucp: uunet!m2xenix!puddle!396!16.0!Mark.Bacas Internet: Mark.Bacas@p0.f16.n396.z1.fidonet.org
pattis@cs.washington.edu (Richard Pattis) (03/12/91)
Doug Cooper rewrote his popular Oh! Pascal! book, changing lots of technical
details (to correspond to Modula-2) and changing lots of philosophical and
pedagogical material too. It is NOT a mere translation of Oh! Pascal!
Although I don't know the details, there is a very cheap way to get the
Stony Brook QuickMod compiler with this book. It also comes with a diskette
containing all sorts of interesting data files for use in programs.
Ohio State has adopted this text for its introductory programming course.
Rich Pattis
("cheap" means for a few dollars more; no where near $50).zander@sumax.seattleu.edu (Carol Zander) (03/14/91)
I'm currently teaching the standard beginning sequence of programming at Seattle University using Oh My! Modula-2! We're at the end of the second course. In the evaluations of the first course, the majority of students strongly disliked the book and I tend to agree with them. The book does not develop smoothly. The examples are poor -- some just stupid and some too complicated. He uses all non-standard libraries. Overall, the book isn't terrible, but it's not good either. I'm looking for a different text for next year. ------------------------------------------------------------------------ Carol Zander (206) 296-5508 | Computer Sci./Software Eng. Internet: zander@seattleu.edu | Seattle University UUCP: ...!uw-beaver!sumax.uucp!zander | Seattle, WA 98122 ------------------------------------------------------------------------
stucki@amygdala.cis.ohio-state.edu (David J Stucki) (03/15/91)
From: zander@sumax.seattleu.edu (Carol Zander) Organization: Seattle University, Seattle WA I'm currently teaching the standard beginning sequence of programming at Seattle University using Oh My! Modula-2! We're at the end of the second course. In the evaluations of the first course, the majority of students strongly disliked the book and I tend to agree with them. The book does not develop smoothly. The examples are poor -- some just stupid and some too complicated. He uses all non-standard libraries. Overall, the book isn't terrible, but it's not good either. I'm looking for a different text for next year. We are using Cooper's book here at Ohio State for the introductory courses for cis majors and are quite happy with it. This is the first quarter we have used it and also the first quarter that I have received positive comments on the required text from students. I have not seen a Modula-2 text that I would rather teach out of thus far. As far as the examples, they appear to have been chosen to support Cooper's philosophy of software design and engineering, which incorporates top-down design and object-oriented design. The use of non-standard libraries should not be a disadvantage, since the "standard" ones are rarely implemented correct wrt Wirth. Cooper's IO module is much cleaner than either the InOut provided by Metrowerks (for the MAC) or Sun. dave... -- David J Stucki /\ ~~ /\ ~~ /\ ~~ /\ ~~ c/o Dept. Computer and 537 Harley Dr. #6 / \ / \ / \ / \ / Information Science Columbus, OH 43202 \/ \ / \ / \ / 2036 Neil Ave. stucki@cis.ohio-state.edu ~ \/ ~~ \/ ~~ \/ Columbus, OH 43210
gkt@iitmax.iit.edu (George Thiruvathukal) (03/15/91)
In article <STUCKI.91Mar14120723@amygdala.cis.ohio-state.edu>, stucki@amygdala.cis.ohio-state.edu (David J Stucki) writes: > The use of non-standard libraries should not be a disadvantage, > since the "standard" ones are rarely implemented correct wrt Wirth. > Cooper's IO module is much cleaner than either the InOut provided by > Metrowerks (for the MAC) or Sun. I agree with the principle stated above; however, non-standard libraries ought to have a standard implementation. Without a standard set of libraries or, minimally, a library which is implemented in the standard language, how can any degree of portability between implementations be achieved? It cannot be achieved. It is somewhat regrettable that Niklaus Wirth left the issue of libraries so open-ended that programmers cannot rely upon a minimal set of libraries from implementation to implementation. Even in the C language, one can count on input/output functions. As the above excerpt suggests, one should not be able to count on input/output (something so fundamental) being well-implemented by compiler vendors. Would it not make some sense that one ought to question the abilities of a compiler writer who cannot design and implement simple libraries to accompany his/her compiler? Further, if the standard libaries cannot be implemented correctly, how on earth is a variation on the same theme to be implemented? -- George Thiruvathukal Laboratory for Parallel Computing and Languages Illinois Institute of Technology Chicago
vsnyder@jato.jpl.nasa.gov (Van Snyder) (03/15/91)
In article <1991Mar14.191513.20184@iitmax.iit.edu> gkt@iitmax.iit.edu (George Thiruvathukal) writes: >In article <STUCKI.91Mar14120723@amygdala.cis.ohio-state.edu>, stucki@amygdala.cis.ohio-state.edu (David J Stucki) writes: >> The use of non-standard libraries should not be a disadvantage, >> since the "standard" ones are rarely implemented correct wrt Wirth. >> Cooper's IO module is much cleaner than either the InOut provided by >> Metrowerks (for the MAC) or Sun. > >I agree with the principle stated above; however, non-standard libraries ought >to have a standard implementation. Without a standard set of libraries or, >minimally, a library which is implemented in the standard language, how can >any degree of portability between implementations be achieved? It cannot be >achieved. > >It is somewhat regrettable that Niklaus Wirth left the issue of libraries so >open-ended that programmers cannot rely upon a minimal set of libraries from >implementation to implementation. Even in the C language, one can count on >input/output functions. As the above excerpt suggests, one should not be able >to count on input/output (something so fundamental) being well-implemented by >compiler vendors. Would it not make some sense that one ought to question the >abilities of a compiler writer who cannot design and implement simple libraries >to accompany his/her compiler? Further, if the standard libaries cannot be >implemented correctly, how on earth is a variation on the same theme to be >implemented? >-- >George Thiruvathukal > >Laboratory for Parallel Computing and Languages >Illinois Institute of Technology >Chicago Is it any wonder that Fortran and Cobol don't go away? Back in the "dark ages" I/O was an integral, standardized, part of the language. In Ada, I/O (and tasking) are disguised to look like procedures, but at least they're standard- ized. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
aubrey@ccwf.cc.utexas.edu (Aubrey McIntosh) (03/16/91)
In article <1991Mar14.235248.24540@jato.jpl.nasa.gov> vsnyder@jato.Jpl.Nasa.Gov (Van Snyder) writes: >In article <1991Mar14.191513.20184@iitmax.iit.edu> gkt@iitmax.iit.edu (George Thiruvathukal) writes: >> >>It is somewhat regrettable that Niklaus Wirth left the issue of libraries so >>open-ended that programmers cannot rely upon a minimal set of libraries from >>implementation to implementation. Even in the C language, one can count on > Actually, an alternate interpretation of the PIM book is that he not only made recommendations, he gave examples. Additionally, the Source Code was available. I tend to believe that some vendors wanted to produce a mature product, and based their products on those libraries. I can clearly port code between very different machines, including IBM-PC, the Mac, and VAXes using these products. Other vendors suffer from sole source trapping in their marketing plans. in those systems, I cannot move code between vendors on the same CPU platform. (Of course, some folks have had trouble between versions 1.04, 1.12, and 2.0 by the same vendor) But I can buy the source to the libraries, and if they are well written, port them into the alternate compiler's environment. Sometimes there are booby traps there as well. I don't want to pick on a certain vendor without having code in front of me, but I have seen very non-standard CODE procedures in several library modules, and sometimes I felt that was gratuitous to prevent complete freedom of usage of the source. If there was a standard, and "Primo Donya Software" released a non-compliant version on "Spiffo Cpu" before anyone else, then we'd be right where we are now without a standard. What then? Well, same as now. Don't buy a product that prohibits second sourcing, portability, or which encourages use of non-standard extensions. And you can write clean Modula2 no matter what the vendor offers as bells and whistles. If this is a REAL nuisance in your mind, then invert that to a potential income advantage: Write a correct and portable library, and methodically place it on each available platform/vendor position. Either you should get rich, or you shouldn't be bitchin. I'm certain I can produce .OBJ files in the MS-DOS world that will link with FST, JPI, and Logitech 3.<any> all at the same time. I've been deep into the details, and I seriously doubt that I'm the only one who has. I'm certain I can produce code that is clean Modula2 or Clean Modula-2 .DEF and .ASM/.OBJ pairs to do this, so that it ports between vendors. With minimal thought, this would port to radically different platforms. The C community writes code that fixes problems, then releases it. If there is a need for a 'Terminal' or 'FileNameandOptions' module on a SPARC, then it could be written and distributed, just as mail, rn, uudecode, and most other utilities are. None of this is language or library deficiency. I bought a source license to one of the early ETH compilers, and partially ported it as a cross compiler on an IBM-PC using Logitech. This involves enough machine differences to make me believe that Modula-2, when well written, is inherently portable. -- Aubrey McIntosh / Chemistry / University of Texas / Austin, TX 78712 ..another Gaelic learner...
news@m2xenix.psg.com (Randy Bush) (03/16/91)
> It is somewhat regrettable that Niklaus Wirth left the issue of libraries so > open-ended that programmers cannot rely upon a minimal set of libraries from > implementation to implementation. I do not mean to put words into his mouth, and thus the following should be taken as my insufficiently humble opinion only. Professor Wirth often stresses that what one leaves out of a language is often as or more important than what one puts in. Somewhere, I also think he said that one should only include what one knows the [one] simple correct way of doing. Thus, Modula-2, the language, omits that which is contentious, unclear, or has multiple [good] solutions. As Modula-2 provides for a library, what better place to put all those things? And, as someone who has done a few libraries, and watched the standardization process's attemtps at libraries, I assure you that they're contentios, unclear, and admit of many solutions (but few good ones). At the last ISO Modula-2 meeting, I suggested that FROM SYSTEM (* or whatever *) IMPORT printf, ...; would be far better, was already a standard, is quite easy to implement, and will be more acceptable to the mass of users than anything the committee has come up with to date. Although few took me seriously (well, we were in the pub), I fear that it is the sad truth. -- Randy Bush / news@psg.com / ..!uunet!m2xenix!news
Jon.Guthrie@p25.f506.n106.z1.fidonet.org (Jon Guthrie) (03/21/91)
On a message of 18-Mar-91, Aubrey McIntosh Said: > But I can buy the source to the libraries, and if they are well > written, port them into the alternate compiler's environment. Yes, that IS possible. Now try to ship production code with those ported libraries imbedded in them. If you ever get over the legal difficulties, get back to me and I'll say 'I told you so.' > If there was a standard, and "Primo Donya Software" released a > non-compliant version on "Spiffo Cpu" before anyone else, then we'd > be right where we are now without a standard. No, that isn't necessarily true. (I think you're probably trying to draw an analogy with Turbo Pascal.) If there WERE a standard, there would be strong advantages in following it. (Which is why most C compiler vendors have already moved to ANSI C and are moving to C++ despite other alternatives that are every bit as good.) > If this is a REAL nuisance in your mind, then invert that to a > potential income advantage: Write a correct and portable library, > and methodically place it on each available platform/vendor > position. Either you should get rich, or you shouldn't be bitchin. You speak as if that were child's play to get compiler vendors to accept outside code. You also speak as if most people out there are using Modula-2. Might I remind you that an awful lot more work is done in C (which has had a well-defined I/O and support library almost since it's creation) than in M-2 and the lack of a library standard is one of the primary reasons. The REASON it's a difficulty because you are forced to learn another way of doing things every time you get a new compiler. Logitech expertise doesn't translate into Stonybrook which doesn't translate into TopSpeed which doesn't translate into FST. You can't say "I'm a Modula-2 programmer" without adding some kind of statement about which compiler you're using. While I can appreciate Randy Bush's point about there being no clearly superior way to define an I/O library, I must insist that C is an example that shows how powerful even a mediocre (and often actively bad) library I/O standard can be when it comes to portability. -- uucp: uunet!m2xenix!puddle!106!506.25!Jon.Guthrie Internet: Jon.Guthrie@p25.f506.n106.z1.fidonet.org