[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