• [^] # Re: Java et Linux

    Posté par . En réponse au journal Java et Linux. Évalué à 4.

    >- pas de covariance (enfin si dans les tableaux) ;

    Le covariance est le fait de faire varier le types des paramètres (ecriture et lecture) dans le même sens que l'héritage.

    exemple (en pseudo code) :

    class Animal {
    void mange(Nouriture);
    }
    class Vache extends Animal {
    void mange(Herbe);
    }

    >- pas de réflexivité (seulement de l'introspection) ;

    L'introspection c'est pourvoir « lire » les infos structurelles du langage (exemple parcourir les méthodes d'une classe).
    La réflexivité c'est pouvoir « modifier » les infos structurelles du langage (exemple modifier une méthode d'une classe)

    >- pas de fonctions lambda :) ;

    ce sont des fonctions anonymes crées à la demande. Une des nombreuses utilités est de pouvoir avoir une méthode de comparaison ad-hoc pour faire des tris, des itérateurs, etc. en fait ce que j'apelle « lamda » regroupe plutot les fermeture et autres blocs mais le principe à la base est globalement le même.

    >- pas de contrats.

    C'est le fait d'écrire les contraintes de fonctionnement requis dans le code plutôt que dans la doc. Le programme pouvant alors s'auto-vérifier dans les phases de débug.

    exemple grossier pour comprendre

    class A {
    int toto;
    void set_toto(int t)
    require t > 0
    { toto = t }
    ensure t = toto
    }

    ici la fonction set_toto exprime que son paramètre doit être positif et que le résultat de son action sera de rentre l'attribut toto egal à t.
    L'interet de ce genre de chose est de faciliter le developpement et de séparer interface et implémentation.


    « Personnellement le langage me convient (question d'habitude,j'ai été élevé au C). »

    est-ce une raison pour ne pas chercher les limites du langage ? est-ce une raison pour ne par chercher, ne serait-ce que par curiosité, comment dépasser ces limites ?

    J'ai également été élevé au C, c'est pas pour autant je n'essaye pas de porter un regard critique (certains diront « de critique ») sur les langages que j'étudie.

    « Le fait d'avoir des noms longs ne me dérange pas, je trouve même que c'est un avantage, si on s'en sert bien on arrive à avoir du code très facilement relisible et reprenable. ... »

    Oui mais ya souvent de l'abus, il suffit d'une chaine avec 3 ou 4 envois de messages, un peu d'indentation et on dépasse les 80 caractères. Question lisibilité c'est pas forcément ce qu'on fait de mieux.
    Je reconnais que ce point est faible. et puis on a le complettement automatique et de grands écrans.

    « Pour info, c'est quoi tes langages préférés, ou plutot, est-ce que tu connais un langage qui correspond à ce que tu décris plus haut ? »

    J'en ai pas, je me contente de critiquer comme un vieux raleur. :)

    Eiffel : un langage grandiose et largement en avance sur son temps au niveau des concepts (c'est un peu comme si linux 2.6 était sorti en même temps de DOS 3.0). Malheureusement il est verbeux et tros rigoureux pour une utilisation comme la mienne. Mais en entreprise il roxor d'après des gens. Son principal défaut : les boucles sont vraiment nulles (for, while, etc.)

    Ruby : un langage de script tout objet bien qu'étant le contraire d'Eiffel. Proche de SmallTalk il gère les lambas de façon élégantes. Son défaut : héritage multiple remplacé par des mixins, c'est pas si grave vu qu'il est a typage dynamique (c'est juste lourd parfois).

    CLOS : (Comon (LISt Processing) Object System). Il faut aimer les parenthèses. J'ai jamais accroché au LISP mais ya des gens qui aiment. Point fort : selection multiple (en gros tous les arguments d'un appel de méthode sont les receveurs).

    OCaml : plusieurs fois j'ai essayé de m'y mettre sérieusement mais à chaque fois je me suis évanoui en lisant la syntaxe (et pourtant je connais BrainFuck et GOTO++ donc niveau syntaxe je me pensais blindé).

    En ce moment je bosse en Eiffel pour mon travail.