Citation:
Envoyé par
thierryc
Malheureusement, ton analyse est complétement erronée
Disons plutôt que c'est une opinion que tu ne partages pas.
Citation:
factuellement: l'activité principale des développeurs est la lecture (90%) et l'activité d'écriture représente environ (10%).
On ne peut pas généraliser sur l'activité principale présumée des développeurs. Il y a tellement de paramètres. L'activité d'un développeur commence souvent par essayer de comprendre ce que le cahier des charges veut bien dire, puis à réfléchir à la meilleure manière d'y arriver, rechercher le code existant ou les bibliothèques qui pourraient être utilisés, prototyper, tester, profiler, analyser, dessiner, discuter, regarder ce qui se fait ailleurs, partager ce qu'on fait, synchroniser, intégrer, valider, documenter, expliquer, comparer, imaginer, inventer, ... C'est un métier passionnant le développement, il ne consiste pas à uniquement rédiger et lire des specs compilables.
Dans beaucoup de ces tâches, le code source intervient peu, mais je suis d'accord sur le fait que quand on a affaire à du source, c'est plus souvent pour en lire qu'en écrire.
Citation:
Ce qui tu appelles mots clefs intrusifs, je l'appelle "anglais structuré". C'est justement ce qui fait la force de ces langages, dès lors qu'il faut communiquer avec la maîtrise d'ouvrage (les clients) : bien utilisés, on écrit des spécifications qui compilent.
Ça me parait un peu idyllique comme approche. Ton client ne va de toute façon pas de lire 100000 lignes de spécifications.
Citation:
Leur "verbosité" est une force qui permet au compilateur de détecter bien plus d'erreurs que dans d'autres langages qui pratiquent la concision et l'élision.
Ce sont souvent des erreurs faites essentiellement par des débutants. Le pascal est sûrement un bon langage pour enseigner la programmation, mais je trouve que sa verbosité est par la suite un handicap.
C'est un peu comme les petites roues de stabilisation sur un vélo d'enfant. C'est très bien pour l'apprentissage, mais un jour, il faut les enlever.
Tu es libre de penser autrement, je te donne juste mon avis. La lisibilité est un facteur important sur l'évaluation que je porte sur les divers langages de programmation que j'ai pu côtoyer et utiliser professionnellement depuis trente-cinq ans, mais ce n'est pas le seul. Par exemple le C++ a beau reprendre beaucoup de la syntaxe du C, je n'ai jamais apprécié lire ou écrire du C++. Au contraire, la syntaxe de SmallTalk n'a rien à voir avec celle du C et j'ai pourtant, en 1986, été enthousiasmé par ce langage et son environnement. J'aime bien aussi la concision de Python mais j'ai horreur de celle de Perl. Les goûts et les couleurs...
Citation:
Il reste bien sûr des erreurs sémantiques, mais ces erreurs sont facilement repérables par les clients non informaticiens car ceux-ci sont capable de lire et vérifier les spécification qu'on leur fournit.
Des clients non informaticiens qui lisent de l'ADA dans le texte, je demande à voir...
Citation:
Par ailleurs, tout environnement moderne permet de mettre en gras, d'afficher ou de masquer tout ou partie du source qui fait l'objet de la revue ou (plus rarement) de l'écriture. Le problème des mots-clefs ne se pose pas en pratique d'un point de vue rapidité d'écriture ou capacité à voir des éléments dans le source.
Si, ça me pose un problème. Je parle surtout ici de la rapidité de lecture, de l'« entropie» du code source, la proportion d'information non redondante, le rapport entre le poids total et la "charge utile" si tu préfères.
Citation:
Témoignage:
...
Au final, nous avons spécifié en Pascal, codé en C++, produit le logiciel en 70% du temps imparti, satisfait le client et la comptabilité, et obtenu zéro défaut. Un bon bilan, je crois.
Alors là, respect ! :ave:
En cherchant des projets similaires, je suis tombé sur Lookheed Martin qui a développé l'informatique embarquée de la navette spatiale. Il s'agit de 420000 lignes écrites en ADA, donc du même ordre de grandeur que ton projet de 100000 lignes exécutables, d'autant plus qu'eux, ils ne devaient pas lésiner sur les commentaires.
Voilà ce qu'on peut lire à propos de ce projet:
Citation:
This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.
Ok, c'était il y a vingt ans et la productivité des développeurs et la qualité des outils ont bien sûr progressé, mais à l'époque, il y avait deux cent soixante personnes pour développer tout ça, dont une bonne partie dont le rôle était uniquement de tester le code.
Le coût de développement de ces 420000 lignes de code qui ont demandé 21 ans de travail a été d'environ 700 millions de dollars...
Ok, je me doute bien que ton projet n'avait pas la complexité de celui de Lookheed Martin, et le nombre de lignes de code n'est pas une métrique très pertinente, mais quand même...
Citation:
On ne programme pas en Pascal, Ada, Obéron ou Eiffel comme on "code" en C/C++/Java...
Dans le temps, j'aimais bien crypter en assembleur...
D'ailleurs, il va falloir créer un nouveau smiley pour ne pas froisser les susceptibilités, celui-ci étant inadapté : :tagcode:
Citation:
Comme indiqué plus haut dans un autre post (et avec un peu d'humour), tu roules tranquillement en Twingo, je fonce en Ferrari, et je m'éclate :-). Rejoins-moi, si tu le veux?
Je roule dans la vraie vie. Une Ferrari, c'est bien pour frimer à Monte-Carlo mais dans les bouchons parisiens, c'est pas forcément la meilleure solution et pour ce qui est de foncer, méfie-toi ! Je viens de me faire flasher et perdre un point, comme quoi une Twingo, ça peut aussi être surdimensionné...
Citation:
Envoyé par
Pol63
et qu'il faut rajouter quelque chose à la fin de la boucle, ou une classe je suis obligé de trouver à quoi correspondent ces accolades
avec
Code:
1
2
3
4
5
| next
end sub
end class
end class
end namespace |
on comprend tout de suite la structure, qu'il y a une classe dans une classe etc...
Je ne lis que rarement le code source à partir de la fin donc en général, la structure globale, je la connais quand j'arrive à ces fins de blocs.
En plus, si je me pose la question de savoir à quoi correspond une accolade fermante, un appui sur "%" me permet sous vi de remonter à l'instruction ouvrante, et un nouvel appui me remet là où j'étais. Avec des BEGIN/END, le vi standard n'offre pas cette fonctionnalité et avec vim, il faut activer un plugin et le reconfigurer à chaque fois, c'est juste trop lourd.
Citation:
et tous ces mots c'est l'IDE qui les écrit donc ce n'est pas une perte de temps du tout
C'est surtout une perte de temps et une nuisance visuelle lors de la lecture et on lit et relit beaucoup plus de code qu'on en écrit.
Citation:
en plus le { a été prévu pour les claviers anglais ...
Pas faux, quand j'ai commencé a faire du développement, je ne travaillais qu'avec des claviers US, et la transition vers l'azerty a été très douloureuse pour l'écriture de source, heureusement compensée par la possibilité d'écrire des mails et de la doc en français avec les accents, les cédilles, etc.
Mais si on suit ton raisonnement, est-ce que tu écris les nombres en toutes lettres sous prétexte que les chiffres ont eux aussi été prévus pour les claviers anglais ?
On est à peu près le seul pays au monde a avoir un clavier où les chiffres ne sont pas accessibles directement...
