[M3devel] Downsides of Modula-3 ?

[Dragiša Durić]

What would be LONGADDRESS? Pointer to a location inside LONGRAM? :)

On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. wrote:

> 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
>>