Toni

For variety the example makes use of ordinary interfaces and parametric methods - maybe we can do this with Java 1.5 (does it provide multiple bounds?). So 3 Java type interfaces and 3 static methods parameterized by multiple type bounds (the 4th static method accepts a single interface).

"weaken type safety" Again, most dynamically checked languages are type-safe.

Isaac ______________

// Nice

interface ISing { String sing(); }
interface ISpeak { String speak(); }
interface IWalk { String walk(); }
class Computer implements ISing, ISpeak {
   speak() = "hello";
   sing() = "beep, beep";
}
class Dog implements ISing, ISpeak, IWalk {
   speak() = "wof";
   sing() = "aaaauuuu";
   walk() = "tap, tap, tap";
}
class Duck implements ISpeak, IWalk {
   speak() = "Quack"; 
   walk() = "chap, chap, chap";
}
void main(String[] args){  
   let computer = new Computer();
   let dog = new Dog();
   let duck = new Duck();  
   broadway(dog);
   choir(dog);
   choir(computer);
   hike(dog);
   theater(dog);
   theater(duck);
}

<T | T<:ISing, T<:IWalk, T<:ISpeak > 
void broadway(T someone){
   println( someone.sing );
   println( someone.walk );
   println( someone.speak );
}
void choir(ISing someone){
   println( someone.sing );
}
<T | T<:ISing, T<:IWalk >
void hike(T someone){
   println( someone.sing );
   println( someone.walk );
}
<T | T<:IWalk, T<:ISpeak > 
void theater(T someone){
   println( someone.speak );
   println( someone.walk );
}
//---------------------

Toni

(1) Bruce Eckel, Thinking in Java, 3d edition, p. 325: "If you do want extra type safety..." What can "extra type safety" mean if the language by definition is already type safe?

The formatting in this wiki is getting worse and worse.

Nice allows static methods/functions (and variables/constants) to be defined in a package (main, broadway, choir, hike, theatre are all package level).

line counting - but is it easier to understand than the Java code? Isaac __________________________

We can still discuss the benefits/costs of finding errors at compile time vs finding errors at runtime, but let's not confuse that with type-safety.

(Not sure that Bruce claims to be an authority on type systems, meanwhile let's prefer the judgement of Cardelli and Krishnamurthi.) ______________

"let's not confuse that with type-safety" I don't agree. If almost every modern language is by default type-safe, and almost everybody agrees that type safety is a must, then the concept becomes meaningless. It would be meaningless for Bonniot to discuss "Type safety in Nice" (http://nice.sourceforge.net/safety.html). I think it's legitimate to take the concept further and to distinguish strong vs. weak/static vs. dynamic type safety. I also think that your strict usage of the term is unintuitive: "safety" implies more than "throw a RuntimeException?". The effect of a "type-safe" failure is often indistinguishable from an "unsafe" failure (if not, blame the operating system). And the question is not only when to find errors but whether to find them at all (there's a difference between "observing a runtime failure" and "finding an error"). - But I will have a look into Krishnamurthi anyway.

Toni

"let's not confuse that with type-safety" I don't agree. If almost every modern language is by default type-safe, and almost everybody agrees that type safety is a must, then the concept becomes meaningless. It would be meaningless for Bonniot to discuss "Type safety in Nice" (http://nice.sourceforge.net/safety.html). I think it's legitimate to take the concept further and to distinguish strong vs. weak/static vs. dynamic type safety. I also think that your strict usage of the term is unintuitive: "safety" implies more than "throw a RuntimeException??". The effect of a "type-safe" failure is often indistinguishable from an "unsafe" failure (if not, blame the operating system). And the question is not only when to find errors but whether to find them at all (there's a difference between "observing a runtime failure" and "finding an error").

• But I will have a look into Krishnamurthi anyway. Toni

every modern language is by default type-safe And here's where we get into special pleading - by default type-safe? So they are type-safe except when they aren't type-safe? When we mean type-safe and statically-checked, let's say so!

The effect of a "type-safe" failure is often indistinguishable from an "unsafe" failure There's a huge difference between raising a runtime error and letting the program silently trash the system. Don't we know that from unchecked buffer-overflows?

Tony Hoare on implementing Algol 60 (in 1961)

"(1) The first principle was security: ... 
A consequence of this principle is that every occurrence of every subscript
of every subscripted variable was on every occasion checked at run time 
against both the upper and the lower declared bounds of the array. 

Many years later we asked our customers whether they wished us to provide
an option to switch off these checks in the interests of efficiency on 
production runs. Unanimously, they urged us not to - they already knew how
frequently subscript errors occur on production runs where failure to 
detect them could be disastrous."

By the way, even pure mathematicians sometimes don't agree about certain definitions, or they have to refine definitions that already exist in the literature, or there exist different versions of the same definition (sometimes called "weak" and "strong"). By the way, who are you?

Toni

Isaac Gouy _____________________

Toni

best wishes, Isaac ______________

Be Krishnamurthi with you ;-) Toni

There are Nice examples on their wiki http://nice.sourceforge.net/cgi-bin/twiki/view/Doc/CodeExamples

Au revoir! __________

Now for Python I do not know how well it would work. One of the advantages of Python is that I can take a 2000 line program and instantly run it, great for fast turnaround. Type inference engines I heard of usually work for traditional compilers. Now I think O'caml has an interactive shell so maybe it is technically possible to have a really interactive experience using type inference. But if I am interpreting one line at a time, would that be any different from how Python works now? Maybe it is something to include in Pychecker?

As far as the code example. You do not usually start writing code like that in Java. You usually find out with time that you need to refactor some of the interfaces later on. The example is just what it would require to get the equivalent flexibility of the Python example in Java.

A more interesting exercise would be seeing somebody translate a real world example like this to Java? Notice how the parameter s of unique() could be almost anything. Anybody up to the task?

Nestor

The only case that isn't covered in the above code are primitive types. To make the example work, an int[] array would have to be converted to an Integer[] array. This is a well-known drawback of Java.

Toni

If it is an array a, not "an array of a".

   
        public Object removeDuplicates( Object c){
                if ( c instanceof Collection)
                        return new ArrayList( new HashSet( (Collection) c));
                else if ( c instanceof Object[])
                        return new HashSet( Arrays.asList( (Object[]) c)).toArray();
                else throw new IllegalArgumentException( c.getClass().toString());
        } 

It can be done, but there's no good reason to do it - it doesn't make sense. You don't know what you will get back, you will have to cast it in any case and probably have to transform it to a List or whatever it is you really want. What would otherwise be one line of plain Java code - adapted to a specific purpose - becomes a confusing and unsafe method call plus a cast. Moreover, when I need a collection without duplicates, it is likely that I will choose a Set right from the beginning.

Maybe this "one size fits all" kind of approach is natural in the Python world; in Java, there's no place for it.

Toni

So maybe what we need is less Java and more JVM.

I was beginning to think that Bruce gets it, but then I read "So I understand that Java generics are really just autocasting for nicer use of containers, and that's good and useful and it doesn't go any further than that. The generics chapter of Thinking in Java, 4e will thus be easier to write (nothing really complex will happen as in Thinking in C++, volume 2)."

I think Bruce now better understands (though doesn't appreciate) the spirit of the Java programming language both with and without the generics extension, but I think he will do his readers a real disservice if he leads them to believe that generics are just for containers and eliminating casts. They're part of the type system, Bruce! Read Bracha's generics tutorial.

Here's the walk, speak, and sing example redone to take advantage of Generics (could someone please add tags?):

interface Walk {String walk();}
interface Sing {String sing();}
interface Speak {String speak();}

class Computer implements Speak, Sing {
        public String speak() {return "hello";}
        public String sing() {return "beep, beep";}
}
class Dog implements Speak, Sing, Walk {
        public String speak() {return "wof";}
        public String sing() {return "aaaauuuu";}
        public String walk() {return "tap, tap, tap";}
}
class Duck implements Speak, Walk {
        public String speak() {return "Quack";}
        public String walk() {return "chap, chap, chap";}
}
public class RunIt {
        public static void main(String[] args) {
                Computer computer=new Computer();
                Dog dog=new Dog();
                Duck duck=new Duck();
                broadway(dog);
                choir(dog);
                choir(computer);
                hike(dog);
                theater(dog);
                theater(duck);
        }
        public static <T extends Speak & Sing & Walk> void broadway(T someone) {
                System.out.println(someone.sing());
                System.out.println(someone.walk());
                System.out.println(someone.speak());
        }
        public static void choir(Sing someone) {
                System.out.println(someone.sing());
        }
        public static <T extends Sing & Walk> void hike(T someone){
                System.out.println(someone.sing());
                System.out.println(someone.walk());
        }
        public static <T extends Speak & Walk> void theater(T someone) {
                System.out.println(someone.speak());
                System.out.println(someone.walk());
        }
}

David

David

A lot of Bruce's arguments seem to be based on a situation where one solitary coder has a sudden need for a new program, and needs to create a quick solution to that and that's basically it. I do not know what kind of projects Bruce is involved with, but to me the given arguments pro Python / latent typing and con Java / fixed typing are really not relevant at all. For the "typical" situations where Java is used the time that getting code to run first time is not really that important. With projects having lots of developers that need to be able to communicate, and typically what, 80-90% of effort going into maintenance, readability and maintainability are what counts. Arguments against Java's verbosity and "since coders produce at average 10 lines of code per day so I want those 10 lines to contain as much functionality" borderline on stupidity...

I think the main difference is between compile time and run time checks. The compiler checks all the code, the run time systems checks just along the paths it encounters. I stress the notion path, because this means just making sure that every statement executed at least once will not suffice. Instead you are concerned with the execution of every statement in every reachable system state - this is normally infinite. Thus, when you end your tests you know there will be still further cases that might have been considered. At the end of the compiler run, you know that everything checkable by the compiler was checked indeed. Now, when you shipped your system to your users, they will certainly not appreciate that the run time error which hit them in the middle of their work and left them with possibly corrupted data, just means that the type checking succeeded in the end. For you, this means you have to fix the bug, do a new system test (which may be relatively cheap due to automation) and distribute a bug warning and the fix to all your users. When reasoning about productivity you need take all these efforts into accout as well. And the news about the bug will not improve your position in the market. So, I think that you can tolerate quite a lot of trade off in programming productivity for a more thorough compile time checking.

Rolf Bartholomae