4 ms·

Great and fair summary. But what do you mean by lack of type (...) polymorphism?

by 6ren 13y ago

kyllo 13y ago
Type inference = the compiler being able to figure out what types your variables, function arguments, and return values are without you having to explicitly tell it. Polymorphism = the ability to write one function that works for multiple types. So for example, if you want to implement a sorting algorithm, you can write one function that is capable of sorting ints, floats, doubles, chars, and Strings. Java doesn't have this, so if you want to sort four different types, you have to write four functions instead of one, using overloading (you give all four functions the same name but they accept and return different types). If you're interested in these topics I recommend learning a language like Scala, SML, OCaml, or Haskell. It will open your eyes to some of the very powerful features of higher-level and functional programming languages.
- neilk 13y ago
  It's not quite fair to say Java lacks polymorphism, it just doesn't extend to primitive types.
  - kyllo 13y ago
    Well, apparently "polymorphism" in the Java world just means that subclasses can override the superclass's methods. http://docs.oracle.com/javase/tutorial/java/IandI/polymorphism.html http://docs.oracle.com/javase/tutorial/java/IandI/polymorphi... Yes, the Java 1.5+ generic data structure classes that take parameterized types allow a sort of polymorphism, but only for objects (including wrapper classes), but it's not quite as powerful as functional polymorphism. For example, in SML you can swap an ordered pair of any two datatypes with one line of code: fun swap(x: 'a, y: 'b): 'b * 'a = (y,x) And to illustrate my other point about type inference, this is also legal SML and does the same thing. You can leave the type annotations off and the compiler will figure them out for you: fun swap(x,y)= (y,x) where x and y can each be any datatype. I don't really know Scala but from reading about it I get the impression that it also allows this. Have fun doing it in Java though... you'll have to implement your own generic ordered pair class.
- tomjen3 13y ago
  Java has polymorphism, your type can implement (I think) comparator and that should be it. Of course, that doesn't work for int, float, etc because those types aren't objects, but then you typically don't have an array of those.
  - kyllo 13y ago
    Huh? You don't typically have an array of primitives? Says who? In Java, with the exception of String[], you would normally only use an array with primitives. If you're working with objects you would want to use a different data structure such as a linked list.
- adimitrov 13y ago
  What you are describing (calling it overloading,) having different functions of the same name implement different algorithms based on types, is called "ad-hoc" polymorphism, but Java isn't limited to that, and it isn't the best way to do things, because you invariably end up duplicating parts of the algorithm. Java is very capable of writing parametrically polymorphic functions — on object types. They are called Generics, in Java-Parlance. Primitive types are excluded from that, but as you've already pointed out above, one can write ad-hoc polymorphic functions (methods.) Finally, Java has subtype polymorphism — that kind of polymorphism that allows you to write a `Comparable` interface and have your class implement it, so the generic sorting function will work. So in a sense, Java has "more" polymorphism than most other languages: ad-hoc, subtype, and polymorphic. With the exception of primitive types, for which only ad-hoc polymorphism works. Arrays are another icky area, you should avoid using them with Generics (parametric polymorphism) if at all possible. Generally, you would want to use primitive types and arrays in performance-critical areas of your code. Ideally, those shouldn't be many, so in practice, I found that to be a non-issue. What is an issue is that Generics (parametric polymorphism) are a bit weird in Java-land, mostly because of type-erasure, their poor interaction with Arrays, and weird stuff with static and/or child classes.[1] BTW, Haskell only has (bounded) parametric polymorphism. The "bounded" here is actually pretty important. The languages you mention implement some variant of System F as their type system. Haskell has System FC, and IIRC, OCaml has System F_ω. Java's Generics were inspired by Haskell's type system (Phil Wadler was one of the driving forces behind Java's generics.) [1] Note: type erasure isn't a problem per se. Haskell has type erasure, and it's all well and good. The problem really comes from mixing type-erased generics with subytping and dynamic casts. That's just a mess.
  - kyllo 13y ago
    Forgive me for only considering parametric polymorphism as the real thing :) Ad-hoc polymorphism = overloading functions or methods within a class Subtype polymorphism = overloading methods from the superclass. Java is fine for working with objects, but it's just a terrible language for working with primitive datatypes. Part of the reason it's not really used for performance-critical code.
  - ky3 13y ago

Great and fair summary. But what do you mean by lack of type (...) polymorphism?

by 6ren 13y ago

Great and fair summary. But what do you mean by lack of type (...) polymorphism?

kyllo 13y ago

Type inference = the compiler being able to figure out what types your variables, function arguments, and return values are without you having to explicitly tell it. Polymorphism = the ability to write one function that works for multiple types. So for example, if you want to implement a sorting algorithm, you can write one function that is capable of sorting ints, floats, doubles, chars, and Strings. Java doesn't have this, so if you want to sort four different types, you have to write four functions instead of one, using overloading (you give all four functions the same name but they accept and return different types). If you're interested in these topics I recommend learning a language like Scala, SML, OCaml, or Haskell. It will open your eyes to some of the very powerful features of higher-level and functional programming languages.

neilk 13y ago
It's not quite fair to say Java lacks polymorphism, it just doesn't extend to primitive types.
- kyllo 13y ago
  Well, apparently "polymorphism" in the Java world just means that subclasses can override the superclass's methods. http://docs.oracle.com/javase/tutorial/java/IandI/polymorphism.html http://docs.oracle.com/javase/tutorial/java/IandI/polymorphi... Yes, the Java 1.5+ generic data structure classes that take parameterized types allow a sort of polymorphism, but only for objects (including wrapper classes), but it's not quite as powerful as functional polymorphism. For example, in SML you can swap an ordered pair of any two datatypes with one line of code: fun swap(x: 'a, y: 'b): 'b * 'a = (y,x) And to illustrate my other point about type inference, this is also legal SML and does the same thing. You can leave the type annotations off and the compiler will figure them out for you: fun swap(x,y)= (y,x) where x and y can each be any datatype. I don't really know Scala but from reading about it I get the impression that it also allows this. Have fun doing it in Java though... you'll have to implement your own generic ordered pair class.
tomjen3 13y ago
Java has polymorphism, your type can implement (I think) comparator and that should be it. Of course, that doesn't work for int, float, etc because those types aren't objects, but then you typically don't have an array of those.
- kyllo 13y ago
  Huh? You don't typically have an array of primitives? Says who? In Java, with the exception of String[], you would normally only use an array with primitives. If you're working with objects you would want to use a different data structure such as a linked list.
adimitrov 13y ago
What you are describing (calling it overloading,) having different functions of the same name implement different algorithms based on types, is called "ad-hoc" polymorphism, but Java isn't limited to that, and it isn't the best way to do things, because you invariably end up duplicating parts of the algorithm. Java is very capable of writing parametrically polymorphic functions — on object types. They are called Generics, in Java-Parlance. Primitive types are excluded from that, but as you've already pointed out above, one can write ad-hoc polymorphic functions (methods.) Finally, Java has subtype polymorphism — that kind of polymorphism that allows you to write a `Comparable` interface and have your class implement it, so the generic sorting function will work. So in a sense, Java has "more" polymorphism than most other languages: ad-hoc, subtype, and polymorphic. With the exception of primitive types, for which only ad-hoc polymorphism works. Arrays are another icky area, you should avoid using them with Generics (parametric polymorphism) if at all possible. Generally, you would want to use primitive types and arrays in performance-critical areas of your code. Ideally, those shouldn't be many, so in practice, I found that to be a non-issue. What is an issue is that Generics (parametric polymorphism) are a bit weird in Java-land, mostly because of type-erasure, their poor interaction with Arrays, and weird stuff with static and/or child classes.[1] BTW, Haskell only has (bounded) parametric polymorphism. The "bounded" here is actually pretty important. The languages you mention implement some variant of System F as their type system. Haskell has System FC, and IIRC, OCaml has System F_ω. Java's Generics were inspired by Haskell's type system (Phil Wadler was one of the driving forces behind Java's generics.) [1] Note: type erasure isn't a problem per se. Haskell has type erasure, and it's all well and good. The problem really comes from mixing type-erased generics with subytping and dynamic casts. That's just a mess.
- kyllo 13y ago
  Forgive me for only considering parametric polymorphism as the real thing :) Ad-hoc polymorphism = overloading functions or methods within a class Subtype polymorphism = overloading methods from the superclass. Java is fine for working with objects, but it's just a terrible language for working with primitive datatypes. Part of the reason it's not really used for performance-critical code.
- ky3 13y ago