[M3devel] Downsides of Modula-3 ?

Daniel Alejandro Benavides D. dabenavidesd at yahoo.es
Sat Apr 21 18:26:48 CEST 2012


Hi all:
If we accept to exist LONGINT and ADDRESS is a Word.T why we don't have LONGADDRESS? That's you don't care if that's in UNSAFE TYPE, do you?
Assembly in lining was handled about perfect in Modula-2 for VMS I wonder why DEC didn't provide Modula-3 support with that as well.
Thanks in advance

--- El vie, 20/4/12, Mika Nystrom <mika at async.caltech.edu> escribió:

> De: Mika Nystrom <mika at async.caltech.edu>
> Asunto: Re: [M3devel] Downsides of Modula-3 ?
> Para: penn43 at gmx.com
> CC: m3devel at elegosoft.com
> Fecha: viernes, 20 de abril, 2012 15:29
> 
> Now that I have the rather unpleasant task of writing C code
> for a client,
> I have a few things I "like" about C and that I "miss"
> somewhat when
> I write Modula-3.
> 
> I find that I sort of like the C preprocessor.  But
> maybe it's just the
> sort of code I'm writing with it... (test programs, which
> need lots and
> lots of annotations and instrumentation, something easy to
> do with cpp).
> 
> No alloca....
> 
> No varargs...
> 
> No real "const" (Java "final").  Sometimes WITH can do
> it.
> 
> No GO TO.............. can't believe I just wrote that but
> Modula-3 had
> as one of its design objectives to be a good target for code
> generation,
> and having goto would make that easier!  (Look at the
> C-Mix partial
> evaluator for an application.)
> 
> A C++ programmer would undoubtedly miss a lot of crazy C++
> stuff 
> that lets you do tricky stuff entirely without heap
> allocation.
> And operator overloading.
> 
> Then there are some annoying implementation limitations:
> 
> No EXTENDED floating point in the standard implementation.
> 
> Bugs in the "standard" threading library (pthreads
> based).  Have
> to use the longjmp hack version.
> 
> Dubious "enhancements" relative to the Green Book: LONGINT,
> WIDECHAR
> (and a lot of issues with TEXT as a result).  And
> efficiency problems
> in the CM3 code in *some cases* (compared with the older SRC
> M3).
> 
> ----
> 
> My own evaluation of the above is that the things lacking
> relative to C
> are really pretty minor and the language is so much easier
> to use
> and better engineered that you almost never say to yourself
> "oh I wish
> I could write this procedure in C" (you might say it of one
> line of code).
> 
> The implementation issues are things that could "easily" be
> fixed by
> someone who had the time..
> 
> Oh regarding efficiency problems: I still find that CM3 with
> optimization
> turned on produces code that runs faster and with a far
> smaller memory
> footprint than code doing the same thing in Java, most of
> the time.
> That's when you try to do as close to an apples-to-apples
> comparison
> as possible.  If you take into account the fact that in
> Modula-3 you can
> allocate structured memory in "batches" (called "arrays"!)
> the difference
> is even bigger.  Modula-3 also links far easier with C
> and Fortran than
> Java does.
> 
>      Mika
> 
> 
> 
> penn43 at gmx.com
> writes:
> >An object appraisal must take into account the problems
> too. So I am asking yo
> >u, could you please mention any downsides of using
> Modula-3, in your experienc
> >e?
> >
> >Of course, the non-existent language community has
> already been mentioned as a
> > major downside. 
> >And the lack of documentation.
> >What about other issues, such as compiler efficiency? Or
> interaction with fore
> >ign libraries?
> >
> >Thanks
> >
> >Marresh
> 



More information about the M3devel mailing list