Envoyé par
alex_pi
Je ne comprends pas... D'un coté, tu es contre le GC parce que ça inciterait à trop se reposer sur la machine, mais de l'autre, tu veux du typage statique.
Le typage statique demande un minimum de réflexion de la part du développeur... Et plus il est strict, plus il doit réfléchir.
Envoyé par
alex_pi
Ca n'insiterait pas à ne pas réfléchir et à juste faire confiance au typeur ?
Justement : c'est un échec à la compilation, et non pas à l'exécution, qui se produit avec un typage statique... Les erreurs de typage dynamique sont en général assez infectes à lever, et dans le pire des cas on a un débutant qui ne comprends même pas la différence entre un nombre (variable entière) et sa représentation textuelle (variable chaîne contenant la représentations ASCII du nombre en question)...
Envoyé par
alex_pi
Je n'ai *jamais* compris l'intéret d'emmerder le débutant avec une gestion manuelle de la mémoire.
Moi, si... Pour avoir vu (et déplanté) un paquet de code C/C++ provenant de "spécialistes Java", d'ailleurs. Ils ne savent pas ce qu'est la gestion mémoire, et n'arrivent souvent pas à l'assimiler naturellement...
J'ai même vu des horreurs sans nom, dans le genre classe C++ complexe
sans destructeur implémenté, alors que la classe allouait à tout va !! Et, ô surprise, c'était un fervent défenseur du Java...
Envoyé par
alex_pi
La moralité, ça va être qu'il aura la moitié de ses programmes où il se prendra des crash (ceux où il aura fait des free au mauvais endroit) et l'autre moitié avec des mem-leak à tout va. Et au final il préferera la seconde catégorie parce qu'au moins ça ne plante pas.
La plupart des langages ont un GC "global" au programme, c'est à dire que l'allocation se fait dans une zone réservée par le runtime... Une fuite mémoire peut exister, certes, mais sans mettre en péril le système d'exploitation. Ce n'est pas "propre", certes, mais c'est un moindre mal.
De l'autre côté, il y a des habitudes, notamment les bonnes, à prendre dès le départ. Sinon, les développeurs ne les prennent
JAMAIS, parce que c'est "trop contraignant". Parmi ces habitudes, on a :
- Documenter son code,
- Le tester un minimum sérieusement,
- Savoir à l'avance ce que l'on va faire, et non pas "bidouiller" en avançant à tâtons,
- Vérifier la libération de ce que l'on a alloué.
Envoyé par
alex_pi
Quand on voit le faible nombre de programmeur C qui utilisent des outils comme Valgrind, et le nombre incroyable de mem leak dans les programmes de tous les jours, j'avoue que ça me fait douter sur le fait que "programmer sans GC fait qu'on fait plus attention à la gestion des ressources"..
C'est un fait. Combien, parmi ces "débutants", on commencé par un langage "académique", toutefois ? Moi aussi, je connais hélas trop cette situation... J'y vois des gens ayant débuté par du Java, du Basic (Visual ou non), des langages interprétés, etc. Et, bien sûr, ceux qui n'ont démarré qu'avec le C, et n'ont jamais connu d'autre langage !!
Ceux ayant débuté par des langages plus stricts sans être trop lourds (Pascal, Ada en tête de liste) ont en général bien moins de mauvaises habitudes... Ou, pour être plus précis, leurs erreurs d'allocation/libération restent dans des limites "acceptables", c'est à dire qu'elle ne crashent pas le programme dans les 10 minutes suite à une fuite mémoire plus proche de la chute d'eau que du robinet qui goutte.
Envoyé par
alex_pi
Et en plus, ça interdira au débutant un paquet d'algorithme ou de paradigme parce qu'il n'arrivera pas à faire une gestion manuelle de la mémoire là dessus.
Lesquels ? L'algorithmique, ça s'apprend par le commencement, pas par la fin... Tu arrives à accepter, toi, qu'un stagiaire passe une heure à trouver une librairie pour faire un tri au lieu de l'implémenter lui-même ? Surtout quand ça porte à l'origine sur un tableau d'une vingtaine d'éléments, trié une seule fois ?
Envoyé par
alex_pi
Est ce que devoir avoir compris les magic pointeur avant de coder est vraiement indispensable...
Utiliser les "smart pointers" est néfaste en soi pour un débutant, car cela le fait ignorer un mécanisme crucial
qui n'existera pas toujours sur les plate-formes qu'il sera amené à utiliser. L'embarqué se porte bien, très bien même... Et là dessus, tu as rarement une usine à gaz type JRE pesant plus lourd que la capacité mémoire disponible pour faire n'importe quoi n'importe comment... Et de toutes façons, les performances exigées mettent hors concours tout ce qui n'est pas langage compilé natif.
Or, à force d'apprendre le développement "façon assisté", tu vois de moins en moins de développeurs réellement compétents dès qu'il s'agit de développement bas niveau, temps réel ou embarqué... Certes, ils savent faire de belles IHM en Java et ouvrir tout plein de communications TCP/IP en même temps, ou se connecter à une BDD. Mais ils sont infoutus de faire un système d'acquisition temps réel, un driver ou un module exigeant des performances sévères.
Envoyé par
alex_pi
Je ne vois vraiment pas ce que pour un débutant, avoir à gérer sa mémoire à la paluche apporte sur le plan pédagogique
Je ne vois vraiment pas pourquoi on apprends aux gamins à se brosser les dents dès qu'ils savent tenir debout, alors qu'on se fiche complètement des dents de lait : il ne faut s'en occuper que quand leur dentition définitive pousse !
Ah, on me souffle que c'est pour leur en donner l'habitude, parce que ça ne devient pas un réflexe quand c'est appris "trop tard"... Tiens donc...
1 |
0 |
tout le monde, j'aimerais avoir votre avis sur le langage à apprendre pour débuter la programmation. 
, et dans une très petite mesure ils permettent même une approche fonctionnelle en distinguant nettement les "fonctions" des "procédures". Certes, c'est pas du Lisp non plus côté approche fonctionnelle, c'est évident. Mais ça donne un petit avant-goût... Juste de quoi ne pas se sentir totalement paumé quand on approche un vrai langage fonctionnel.