Talk:Modula-3 programming language

The author of this page obviously had no experience with Modula-3 programming, and some of the statements are just wrong. To be sure, Modula-3 had its defects, and its failure was not entirely undeserved; but Modula-3's object model, in particular, was a distinct improvement on its sucessors, vastly better than Java's. Too bad that the world was not prepared to understand it....Jorge Stolfi 09:11, 17 Apr 2004 (UTC)

I removed the comment about Java not supporting interfaces, because it clearly does. While it's true most Java coders do not separate implementation from interface the feature is always available for that style. MShonle 09:19, 17 Apr 2004 (UTC)

I think perhaps the point that the writer of that comment was trying to make is that interfaces in Java are used differently (I'm not familiar with Modula-3, but I may be on the ball anyway), in Java, multiple classes can implement the one interface, whilst in other systems, an object's interface is exclusive to that object. The Java "interface" is more like an Objective-C protocol. Dysprosia 09:24, 17 Apr 2004 (UTC)

MShonle, please have my apologies for the knee-jerk comments. I confess that I have rather limited experience with Java, but that experience was quite disappointing. I tried hard to achieve the same level of Intf-Impl separation that was used to in Modula-3, but could not get even close to it, and fellow Java experts could not help me, either. Java's interface does not seem to be designed for systematic or casual use, and so the common practice of exposing the implementation is not so much a matter of choice as of necessity.

In my view, Modula-3 object model was the cleanest I have seen (except perhaps Oberon's), and yet just as powerful as any other language's. If anything, it was still a bit too complex... Jorge Stolfi 09:35, 17 Apr 2004 (UTC)

Actually, if you want a very clean object-model, check out Dylan. Makes all the other OO models look like hacks. While it's true that separation is harder in Java, it's still possible, but actually the growing trend is that it's needed less. Ideas like open-implementation and XP are part of that change. AspectJ also introduces some killer concepts for better separation of concerns. MShonle 09:42, 17 Apr 2004 (UTC)

---

Technically, Pascal was not a type-safe language. It was a strongly typed language, but without garbage collection, it could not be completely type safe. The proof is somewhat technical, but the idea is that if a language does not have garbage collection (or reference counting), a dangling pointer could exist in the system such that it points to a newly allocated object that contains a field with a different type. If the dangling pointer had an integer field, but in that same spot the new object had a pointer, the pointer could take on any value and type-safety is violated. MShonle 09:17, 17 Apr 2004 (UTC)

Actually it is the other way around... "Type-safe" by definition means that the programmer cannot break the type system, in particular by doing pointer arithmetic or casting. Pascal WAS type-safe; Modula-3 was (unless you explicitly asked otherwise); C and C++ are inherently unsafe; Java is safe. Pascal can have garbage collection, if it had not it was only because of programming cost. Modula-3 was defined to have garbage collection built-in.Jorge Stolfi 09:43, 17 Apr 2004 (UTC)

No, according to the mathematical definition of type-safe (from M. Felleisen) Pascal is not type safe because of the dangling pointer issue. It makes it harder to do pointer arithmetic, but not impossible. Languages like Java and Scheme have been mathematically proven to be typesafe. MShonle 09:50, 17 Apr 2004 (UTC)