Sei que algumas coisas são mais fáceis / difíceis em um idioma que no outro, mas estou interessado apenas em recursos relacionados ao tipo que são possíveis em um e impossíveis / irrelevantes no outro. Para torná-lo mais específico, vamos ignorar as extensões do tipo Haskell, já que existem muitas por aí que fazem todo tipo de coisas loucas / legais.

("Java", conforme usado aqui, é definido como padrão Java SE 7 ; "Haskell", conforme usado aqui, é definido como padrão Haskell 2010. )

Coisas que o sistema de tipos de Java tem, mas o de Haskell não:

• polimorfismo do subtipo nominal
• informações do tipo de tempo de execução parcial

Coisas que o sistema de tipos de Haskell tem, mas o Java não:

• polimorfismo ad-hoc limitado
  • gera polimorfismo de subtipo "baseado em restrições"
• polimorfismo paramétrico de tipo superior
• digitação principal

EDITAR:

Exemplos de cada um dos pontos listados acima:

Exclusivo para Java (em comparação com Haskell)

Polimorfismo do subtipo nominal

/* declare explicit subtypes (limited multiple inheritance is allowed) */
abstract class MyList extends AbstractList<String> implements RandomAccess {

    /* specify a type's additional initialization requirements */
    public MyList(elem1: String) {
        super() /* explicit call to a supertype's implementation */
        this.add(elem1) /* might be overridden in a subtype of this type */
    }

}

/* use a type as one of its supertypes (implicit upcasting) */
List<String> l = new ArrayList<>() /* some inference is available for generics */

Informações do tipo de tempo de execução parcial

/* find the outermost actual type of a value at runtime */
Class<?> c = l.getClass // will be 'java.util.ArrayList'

/* query the relationship between runtime and compile-time types */
Boolean b = l instanceOf MyList // will be 'false'

Exclusivo para Haskell (em comparação com Java)

Polimorfismo ad-hoc limitado

-- declare a parametrized bound
class A t where
  -- provide a function via this bound
  tInt :: t Int
  -- require other bounds within the functions provided by this bound
  mtInt :: Monad m => m (t Int)
  mtInt = return tInt -- define bound-provided functions via other bound-provided functions

-- fullfill a bound
instance A Maybe where
  tInt = Just 5
  mtInt = return Nothing -- override defaults

-- require exactly the bounds you need (ideally)
tString :: (Functor t, A t) => t String
tString = fmap show tInt -- use bounds that are implied by a concrete type (e.g., "Show Int")

Polimorfismo de subtipo "baseado em restrições" (baseado em polimorfismo ad-hoc limitado)

-- declare that a bound implies other bounds (introduce a subbound)
class (A t, Applicative t) => B t where -- bounds don't have to provide functions

-- use multiple bounds (intersection types in the context, union types in the full type)
mtString :: (Monad m, B t) => m (t String)
mtString = return mtInt -- use a bound that is implied by another bound (implicit upcasting)

optString :: Maybe String
optString = join mtString -- full types are contravariant in their contexts

Polimorfismo paramétrico de tipo superior

-- parametrize types over type variables that are themselves parametrized
data OneOrTwoTs t x = OneVariableT (t x) | TwoFixedTs (t Int) (t String)

-- bounds can be higher-kinded, too
class MonadStrip s where
  -- use arbitrarily nested higher-kinded type variables
  strip :: (Monad m, MonadTrans t) => s t m a -> t m a -> m a

Digitação principal

É difícil dar um exemplo direto disso, mas significa que toda expressão tem exatamente um tipo maximamente geral (chamado de tipo principal ), que é considerado o tipo canônico dessa expressão. Em termos de polimorfismo de subtipo "baseado em restrição" (veja acima), o tipo principal de uma expressão é o subtipo exclusivo de todos os tipos possíveis com os quais essa expressão pode ser usada. A presença da digitação principal em Haskell (sem extensão) é o que permite inferência de tipo completa (ou seja, inferência de tipo bem-sucedida para cada expressão, sem a necessidade de nenhuma anotação de tipo). As extensões que quebram a digitação principal (das quais existem muitas) também quebram a integridade da inferência de tipo.

O sistema de tipos do Java não possui polimorfismo de tipo superior; O sistema de tipos de Haskell possui.

Em outras palavras: em Java, construtores de tipo podem abstrair sobre tipos, mas não sobre construtores de tipo, enquanto em Haskell, construtores de tipo podem abstrair sobre construtores de tipo, bem como tipos.

Em inglês: em Java, um genérico não pode pegar outro tipo genérico e parametrizá-lo,

public void <Foo> nonsense(Foo<Integer> i, Foo<String> j)

enquanto em Haskell isso é bem fácil

higherKinded :: Functor f => f Int -> f String
higherKinded = fmap show

Para complementar as outras respostas, o sistema de tipos de Haskell não possui subtipagem , enquanto as linguagens orientadas a objetos digitadas, como o Java.

Na teoria da linguagem de programação , subtipo (também polimorfismo de subtipo ou polimorfismo de inclusão ) é uma forma de polimorfismo de tipo no qual um subtipo é um tipo de dados que está relacionado a outro tipo de dados (o supertipo ) por alguma noção de substituibilidade , o que significa que os elementos do programa, tipicamente sub-rotinas ou funções, escritas para operar em elementos do supertipo, também podem operar em elementos do subtipo. Se S é um subtipo de T, a relação de subtipo é frequentemente escrita S <: T, para significar que qualquer termo do tipo S pode ser usado com segurança em um contexto em queé esperado um termo do tipo T. A semântica precisa da subtipagem depende crucialmente dos detalhes do que "usado com segurança em um contexto em que" significa em uma determinada linguagem de programação. O sistema de tipos de uma linguagem de programação define essencialmente sua própria relação de subtipagem, que pode muito bem ser trivial.

Devido à relação de subtipagem, um termo pode pertencer a mais de um tipo. A subtipagem é, portanto, uma forma de polimorfismo de tipo. Na programação orientada a objetos, o termo 'polimorfismo' é comumente usado para se referir apenas a esse subtipo de polimorfismo , enquanto as técnicas do polimorfismo paramétrico seriam consideradas programação genérica ...

Uma coisa que ninguém mencionou até agora é a inferência de tipos: um compilador Haskell geralmente pode inferir o tipo de expressões, mas você precisa informar ao compilador Java seus tipos em detalhes. Estritamente, esse é um recurso do compilador, mas o design do sistema de idiomas e tipos determina se a inferência de tipos é viável. Em particular, a inferência de tipo interage mal com o polimorfismo de subtipo de Java e a sobrecarga ad hoc. Por outro lado, os designers de Haskell se esforçam para não introduzir recursos que impactam a inferência de tipo.

Outra coisa que as pessoas parecem não ter mencionado até agora são os tipos de dados algébricos. Ou seja, a capacidade de construir tipos a partir de somas ('ou') e produtos ('e') de outros tipos. As classes Java fazem os produtos (campo ae campo b, digamos) bem. Mas eles realmente não fazem somas (campo a OU campo b, digamos). O Scala deve codificar isso como várias classes de casos, o que não é exatamente o mesmo. E, embora funcione para o Scala, é um pouco difícil dizer que o Java o possui.

Haskell também pode construir tipos de funções usando o construtor de funções, ->. Embora os métodos do Java tenham assinaturas de tipo, você não pode combiná-los.

O sistema de tipos do Java permite um tipo de modularidade que Haskell não possui. Vai demorar um pouco até que haja um OSGi para Haskell.