Le problème de Java c'est que ça masque pas mal de concepts bas niveau, comme les adresses (pourtant utilisées dans les références, avec plein de limitations), la décomposition de la mémoire en octets (pas d'union, pas de cast de pointeurs, pas d'équivalent à void*), etc. Et donc l'étudiant qui programme en Java n'a limite pas besoin de savoir que ses variables sont stockées en binaire en mémoire, ce qui donne des situations où ils ne comprennent pas ce qu'est un masquage de bits ou un décalage, alors que ça sert tout le temps.
Ces trucs là, c'est utile à savoir oui... en fait, les cours de système devraient être obligatoires pour tous les étudiants... de même que les étudiants devraient savoir toutes les étapes pour afficher une page de http://linuxfr.org/ ...
Perso, je programme en Java et en C et je ne me sers pratiquement jamais de ces trucs en C, si ce n'est pour émuler des fonctionnalités de langages objet (genre, les unions pour de l'héritage, les void* ... euh non merci...
Les masquages/décalages de bits, ça m'arrive en Java et en C, mais ce n'est quand même pas ce qu'il y a de plus courant.
Le fait est que bien penser un design, ça demande du temps de cerveau disponible... et perso, je préfère l'utiliser pour faire un belle architecture ou diminuer la complexité de mon algo que me prendre la tête à gérer une fuite de mémoire.
De mon expérience, on passe au moins 25% du temps à corriger des bugs de mémoire en C, je dirai 1% dans le cas d'applications Java (oui, on peut aussi perdre de la mémoire en Java)... ce temps est du temps perdu.
Je ne parle même pas de l'utilisation faible d'algorithmes efficaces dans la plupart des projets C par le manque de ré-utilisation de code, du coup, Hop, listes chaînes pour tout le monde (ou le contraire, des tableaux pour tout le monde)... des limitations de merde dans tous les sens (BUFFER_MAX_SZ : hop !)... bref, au final, mon code est le plus souvent bcp plus rapide en Java qu'en C, ce n'est pas une question de compétence, mais une question de temps passé réellement sur les algos.
Alors oui, mettez deux génies dans une salle avec un temps infini, et oui, sans doute, au final le dev C aura un code plus rapide... à vrai dire, je m'en fout.
[^] # Re: Chacun son style
Posté par bad sheep . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 6.
Ces trucs là, c'est utile à savoir oui... en fait, les cours de système devraient être obligatoires pour tous les étudiants... de même que les étudiants devraient savoir toutes les étapes pour afficher une page de http://linuxfr.org/ ...
Perso, je programme en Java et en C et je ne me sers pratiquement jamais de ces trucs en C, si ce n'est pour émuler des fonctionnalités de langages objet (genre, les unions pour de l'héritage, les void* ... euh non merci...
Les masquages/décalages de bits, ça m'arrive en Java et en C, mais ce n'est quand même pas ce qu'il y a de plus courant.
Le fait est que bien penser un design, ça demande du temps de cerveau disponible... et perso, je préfère l'utiliser pour faire un belle architecture ou diminuer la complexité de mon algo que me prendre la tête à gérer une fuite de mémoire.
De mon expérience, on passe au moins 25% du temps à corriger des bugs de mémoire en C, je dirai 1% dans le cas d'applications Java (oui, on peut aussi perdre de la mémoire en Java)... ce temps est du temps perdu.
Je ne parle même pas de l'utilisation faible d'algorithmes efficaces dans la plupart des projets C par le manque de ré-utilisation de code, du coup, Hop, listes chaînes pour tout le monde (ou le contraire, des tableaux pour tout le monde)... des limitations de merde dans tous les sens (BUFFER_MAX_SZ : hop !)... bref, au final, mon code est le plus souvent bcp plus rapide en Java qu'en C, ce n'est pas une question de compétence, mais une question de temps passé réellement sur les algos.
Alors oui, mettez deux génies dans une salle avec un temps infini, et oui, sans doute, au final le dev C aura un code plus rapide... à vrai dire, je m'en fout.