🚀 go-pugleaf

> You also have to remember OS/2's 16-bit 
> origins -- assembly code was probably necessary.

Beg leave to disagree. I'm using Modula-2 (TopSpeed v3, but in principle 
v1 with the protected-mode code-generation fix would probably be OK) to 
build 16-bit protected-mode embedded-systems on the '386, and there is 
VERY little assembler involved (SetJmp/LongJmp replacement for 
compatibility with older code from a PC, inline RET inside LOOP/END to 
yield control of a task, inline expansion of LSL opcode, etc). All the 
rest is done using script-built tables (GDT, TSS, LDT where appropriate) 
which in most cases could (and eventually will) be built at runtime. Note 
in particular that exception handling is exclusively Modula-2, i.e. no 
assembler stubs whatever. (I accept that I wrote the boot ROMs in 
assembler, but there are limits).

The major incentive for assembly code in OS/2 v1 would have been to 
reduce the memory required, remember that it was targetted at 1 to 2 Mb 
systems (the user community lost patience with it at about the time when 
it looked like needing 3 to 4 Mb to run with PM and HPFS) and compiler 
efficiency has improved a lot since then, largely due to Waterloo.

> If OS/2 is such a mess, maybe the design was at fault.

OTOH, allowing that v2 is supposedly a complete rewrite and does not use 
x86 data structures, goodness only knows what sort of mess the 
programmers found themselves in. I would reckon that a lot of thought was 
put into _what_ the O/S would do and _how_ it would do it, but in those 
days there was very little reason to rate source-code portability highly 
unless one looked at Unix (which was such a singularly unattractive 
desktop solution that there is a possibility that the programmers didn't 
even bother to see what they could learn from it). Also there may have 
been substantially different methodologies inside Microsoft and IBM, 
remember that they still had access to each others source code until AT 
LEAST OS/2 2.10 and Windows 3.10.

Interestingly, I believe that one of the experimental GUI operating 
systems written for the Archimedes machine (desktop using ARM processor, 
mid 80s) was written entirely in Modula-2, but neither the compiler nor 
operating system were ever put on the market.

> Okay, C is admittedly far from ideal, especially for large projects.
> However, Modula-2 is also far from perfect.

Nothing is perfect, but some are less imperfect than others. One of our 
occasional subcontractors was telling me that when he started on Modula-2 
(at our behest) he cursed it, but then he got involved with a different 
job involving many programmers working on a large comms project hosted on 
a VAX and realised the extent to which the language was helping them.

> What programmers like about C is its power (which is, unfortunately, 
> all too often abused), its simplicity, and its consistency (well, 
> sometimes). C++ helps in many ways, but it is very different, of 
> course, being an object-oriented programming language. However, C++ 
> also manages to eliminate one of C's greatest strengths: its 
> simplicity. (SmallTalk is much more elegant for pure OOP, IMHO.)
> 
> The Modula-n programming languages are pretty good. However, they 
> suffer in their Pascal heritage. The C-type syntax is much more concise 
> and consistent (no flames please). What the world needs is a language 
> that offers both simplicity and elegance, along with the ability to 
> self-organize and self-document (code, that is). Is it time for a D 
> programming language?

OK, this is not a flame. I would say that one of the problems with C, and 
by extension C++, is the concise syntax. Personally, I like a language 
that I can read- aloud- and always encouraged students (and the 
occasional staff member) to pick variable names etc. that _sounded_ 
different (i.e. no subtle distinctions using upper- and lower-case 
letters). I would imagine that my attitude towards C is like most 
programmers' attitude to APL. C++ (also Ada and the later ALGOLs) are too 
damned BIG... I've got no objections reaching for a manual when I need to 
use a weird pragma or a compiler-specific pointer constructor or whatever 
but apart from that I like tools I can carry around- somebody [ummm... 
dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)] was commenting 
earlier today on the relative size of the Modula-3 and Ada definitions 
(50 vs 500 pages).

I must confess to never really seeing the point of SmallTalk. Now before 
anybody throws their hands up in horror, I was working with it fifteen 
years ago for my MPhil (Smalltalk/FORTH hybrid for embedded systems, 
anybody?) and am fully aware of the number of neat ideas that it has been 
responsible for. However, stripping off the ancillaries of the WIMP 
environment, and removing the fundamental object/inheritance/method 
paradigm (much from Simula) what one is really left with is a language 
much like LISP which can be tailored dynamically to suit the problem. In 
their way, I see environments such as Delphi, MS's VB range, and the Next 
system (which is generally credited as being seminal to this type of 
development) as being more significant than the SmallTalk _language_.

Mark Morgan Lloyd
mark_tbu@cix.compulink.co.uk

[Opinions above are the author's, not those of his employers or 
colleagues]

(But just now and then they know what's good for them... :-)