[M3devel] Modula-3 questions

[Daniel Alejandro Benavides D.]

Hi all:
I think is a good comparison to say C++ is to Java what Modula-3 is to Oberon.
The typing model is similarly relatively augmented from one to the other and UNSAFE features are allowed in the former without control over it (where is in Modula-3 is more confined to UNSAFE MODULEs).
Also a machine independent code is not so in the object-code sense (though Modula-3 has its own scripting extension engine).
Modula-3  OBJECT TYPEs are relative number ordered but other Record-Oriented languages may have a rather distinct type classification system.
C++ just makes the multiple-inheritance support system a big headache for every programmer accustomed to handle single-inheritance languages, but not counter wise case
In easy of use Modula-3 hands its own distinct picture of program in terms of Modules (which handle software re usability stronger than just Object-type systems). Object Oberon instead focuses on that counter-idea.
C++ is a lot like Java in the Class-word sense, which is hard to deal with when you don't have explicit INTERFACE TYPEs like Modula-3 ones (you can create object from OBJECTs their selves and INTERFACES TYPEs), Java still makes an emulation via interfaces but are not just for abstract classes, and not all kind of classes (if you don't program in that way), and you sort to adhere to that or leave it. Modula-3 modularity is more uniform from that.
C++ has the template mechanism but it isn't that well designated to be a GENERIC TYPE but some sort of template of code of untyped code. This can be powerful if you want to have polymorphism but you can have a hard type figuring out what kind of template class you want in any case. This is a Modula-3 advantage since most of the type system developed after them are really oriented towards controlling that complexity via Compile-type checking (which still can make the case for a Extended-Type Checker concept)
Thanks in advance

--- El jue, 19/4/12, Rodney M. Bates <rodney_bates at lcwb.coop> escribió:

> De: Rodney M. Bates <rodney_bates at lcwb.coop>
> Asunto: Re: [M3devel] Modula-3 questions
> Para: m3devel at elegosoft.com
> Fecha: jueves, 19 de abril, 2012 09:45
> 
> 
> On 04/18/2012 05:10 PM, penn43 at gmx.com
> wrote:
> > Dear Modula-3 developers,
> >
> > I am not a Modula-3 user, but I am considering becoming
> one. I have already had a look at the language, and it
> certainly looks interesting. However, I still have some
> misgivings about starting learning Modula-3, since it would
> be a considerable time investment and I am not even sure if
> Modula-3 is the right tool for me.
> > I hope you can help me clarify some points and dispel
> some doubts.
> >
> > The first point is that I would neither be working on
> large projects, nor doing systems programming. I understand
> these were the two major strengths of Modula-3, but neither
> would be useful in my case, as I would be programming mostly
> small- and medium-sized applications, not even
> industrial-level. What I need is simply a tool that can be
> used instead of C++ and Java. Modula-3 looks fine, because
> it promises to be simple. However, having read that Modula-3
> was designed especially for industrial-strength and advanced
> uses, I am afraid that adopting Modula-3 as my development
> tool might be an overkill. Could you advise me in this
> regard?
> >
> 
> C++ is 6 times more complicated than Modula-3, by reference
> manual page count, which is
> usually a reasonable, simple way to estimate
> complexity.  Java is 8 times, though its
> reference manual is significantly less dense than
> most.  Ada is 10 times.  With room
> for some minor quibbles, Modula-3 has more useful
> programming features than any of these,
> thus the best "economy of concept", or ratio of real power
> to complexity.
> 
> Java is especially low on this scale, since it is quite
> feeble, yet has an enormous
> reference manual.  Particularly, all array- and
> record-like constructs are forcibly heap
> allocated whether you need it or not, with resulting coding
> overhead.  You always have
> to allocate and either constantly NIL-check or create an
> argument in your head/comments
> that they are always non-NIL.  This is usually
> scattered around your code.  Unnecessary
> heap-allocation has execution space and time overhead too,
> but this would probably not
> be of concern to you.
> 
> Modula-3 is also particularly good at minimizing
> interactions among language features.
> This makes it easier to learn/use a subset of the language,
> with less risk of tripping
> over something you haven't studied.  That happens a
> _lot_ in C++ and Ada.  If you ever
> eventually want to use more features, they are there,
> without having to relearn the
> superficial syntax, etc., of the basic stuff.
> 
> > Secondly, could you please help me understand what are
> the reasons for which one may prefer Modula-3 over
> Oberon-2/Active Oberon? I have been considering Oberon too
> because, like Modula-3, it promises to be simple and
> minimalistic.
> > So, again, keeping in mind that I don't need the
> advanced features mentioned above, nor multithreading, does
> it make any sense for me to choose Modula-3 instead of
> Oberon, or Object Pascal?
> >
> 
> If you prefer absolute minimal language complexity without
> regard for programming richness,
> as opposed to economy of concept, the Oberon family fares
> better by that criterion.  But I
> think, even with your minimal goals, you will like some of
> the additional things Modula-3 has.
> 
> > Lastly, what is the current availability of Modula-3
> libraries? I have read that Modula-3 has a rich set of
> libraries, but that was many years ago. Are there any
> up-to-date libraries, fulfilling today's needs? I am mostly
> interested in GUI support (possibly bindings to some
> standard GUI toolkit, like GTK or QT, or wxWidgets),
> internet libraries and UTF-8 support.
> >
> > I thank you in advance.
> >
> > Best regards,
> >
> > Marresh
> >
> > P.S. is the creation and maintenance of module
> interfaces all that trouble? I read somewhere that it is a
> pain, and that the inconvenience of it would only be paid
> off when one has to manage large projects (which is not my
> case).
> >
> >
>