37Fermer39
ZerosquareLe 07/01/2010 à 01:33
Brunni (./35) :
Je peux te demander pourquoi tu l'as utilisé subi, et en quoi c'était un supplice? ^^
Y'a un peu plus d'un an, j'ai accepté de développer une appli C# pour le boulot (langage imposé par le client), bien qu'à la base je m'occupe d'électronique et d'info embarquée bas (voire très bas) niveau.

À la base j'avais jamais fait de C# ou même de langage OO tout court, et j'avais un a priori assez négatif dessus. Je me suis dit que ça serait l'occasion de "tester" ça objectivement et d'ajouter une corde à mon arc (ça peut toujours servir). Et puis bon, un salaire mensuel, c'est un argument aussi.


(ce qui suit est un avis personnel)

Les points positifs que j'ai retenus :

- le langage est clairement mieux pensé/plus rigoureux/plus puissant que le C sur certains points (je peux pas comparer au C++, j'en ai jamais fait).

- y'a certains problèmes où l'approche OO facilite effectivement les choses.

- le framework contient énormément de trucs tout faits, ça éviter de perdre du temps à réinventer et déboguer la roue.

- Visual Studio dans son ensemble est vraiment bien foutu.


Et les points négatifs :

- finies les habitudes de l'ASM ou du C où on pouvait connaître la majorité des features "de tête". Les notions à connaître sont nombreuses, parfois subtiles et demandent de se taper des pages et des pages de documentation à lire. En gros j'ai eu l'impression de passer 90% du temps à lire, et 10% à coder effectivement.

- de même, il y a sûrement une fonction qui fait ce qu'on cherche à faire, mais encore faut-il la trouver... vu la taille gigantesque du framework, on a un peu l'impression de chercher une aiguille dans une botte de foin. Et une fois qu'on l'a trouvée, le périple n'est pas fini : reste à comprendre comment fonctionne la classe, qui à tous les coups dérive ou référence d'autres classes qu'il faut aussi décortiquer, etc.

- on perd aussi du temps à chercher comment adapter le problème aux concepts OO, refactoriser parce que la modélisation qu'on a choisie "coince" finalement sur un point particulier, etc. Je suis pas persuadé que l'approche soit toujours bénéfique, au final.

- y'a des limitations casse-pieds, par exemple l'absence d'un type "pointeur sur un objet" (y'a bien le mot-clé ref pour les paramètres des fonctions, mais ça ne marche que tant qu'on ne sort pas de la fonction en question). En l'occurrence, je voulais faire un truc un peu intéressant avec l'OO : paf, on peut le faire en C++, mais pas en C#.

- ça m'a donné l'impression de pédaler franchement dans la mélasse, même sur une bécane plutôt bonne (dual-core, 2 Go de RAM). Voir une appli toute bête mettre plusieurs secondes à s'initialiser et ramer lamentablement pour rafraîchir l'affichage, en 2009, ça m'énerve. Ne parlons même pas des perfs sur une config plus light (genre une VM pour tester la compatibilité sous d'autres versions de Windows).

- le fait de devoir installer le framework même pour une toute petite appli est pénible (OK, ce sera de moins en moins un problème vu que les versions récentes de Windows l'incluent de base)


Globalement, ça correspond pas du tout à ma façon de réfléchir et de bosser. Je m'en doutais un peu à l'avance, mais l'expérience l'a vraiment confirmé...