[M3devel] Downsides of Modula-3 ?

[Dragiša Durić]

In other words, let's invent another non-portability :).

Pass, please :)

On Apr 22, 2012, at 7:18 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> I think it would be in I386 (I remember were 16 bits) and absolute address location of a Word.T were handled as such in I386 process at least that's in my MSJ Vol. 7 No.4, because it has Application Address Space and at top System Address Space.
> Similarly in ARMv7the virtual address space is 32-bit, but physically extended to be 40-bit.
> Then the question what it would be like AMD64.
> Thanks in advance
> 
> --- El sáb, 21/4/12, Dragiša Durić <dragisha at m3w.org> escribió:
> 
>> De: Dragiša Durić <dragisha at m3w.org>
>> Asunto: Re: [M3devel] Downsides of Modula-3 ?
>> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
>> CC: penn43 at gmx.com, "Mika Nystrom" <mika at async.caltech.edu>, m3devel at elegosoft.com
>> Fecha: sábado, 21 de abril, 2012 16:28
>> 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
>>>> 
>> 
>>