Antoine a écrit 5722 commentaires

Tu crées un compte juste pour l'occasion et pourtant tu dois surement fréquenter un minimum LinuxFR pour connaître ce journal ? Qui donc ce cache sous ce compte ? Qui donc n'assume pas ?

Le journal semble écrit par un analphabète, ou quelqu'un proche du coma éthylique. Je doute que ce soit un camouflage, car quel intérêt de s'évertuer à passer pour un con ?

Le plus de vieux matos pourri, certes.

$ sudo aptitude install autocad
Impossible de trouver un paquet dont le nom ou la description correspond à « autocad »
Aucun paquet ne va être installé, mis à jour ou enlevé.
0 paquets mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de télécharger 0 o d'archives. Après dépaquetage, 0 o seront utilisés.

Je préfère avoir personnellement un service informatique qui développe ses compétences et sais comment fonctionne et sais bricoler le système d'information.

Oui mais est-ce que DLFP a les moyens de payer des consultants expérimentés pour faire tourner son SI ?

Tant de constance au fil des années force le respect.

Heu, le « bazar » est un mode d'organisation sociale. Ça n'implique pas de tout recoder from scratch à chaque fois que les orteils te démangent.

(l'ironie de tout ça est que le terme bazaar en anglais désigne les bazars orientaux, où il n'y a pas de production à proprement parler : ce sont juste des marchands en concurrence les uns avec les autres, leur travail n'a pas pour résultat une œuvre composite ni collaborative. Raymond a été incapable de trouver un exemple dans le monde physique qui colle avec l'organisation qu'il préconisait.)

un éléphant, dans une fabrique de cristal.

Tout devient clair : le coupable, c'est PHP !

Et comme j ai dit, la problematique des BOFs t en as vite fait le tour

Ah ok... Tiens, un bug qui m'a pourri la vie plusieurs jours (crash aléatoire dans le driver Intel pour X11). C'est un buffer overflow.
https://bugs.mageia.org/show_bug.cgi?id=2067

Puisque tu es si fort, tu veux pas faire la maintenance de X11 et ses drivers ?

Deux DVD Debian ? Marrant, mon install ne prend pas autant de place...

Je ne sais pas pour l'install (la flemme d'aller voir) mais mon ISO de Visual Studio 2008 Professional fait 3,5 Go. Certes, c'est pas deux DVD, mais c'est quand même très gros.

Heu, entre un utilisateur qui va bouffer statistiquement 0.1W sur un service mutualisé et optimisé aux petits oignons, et un serveur dédié qui va bouffer plusieurs dizaines de Watts même au repos, il y a un ratio assez énorme.

un serveur mail auto-hébergé risque de se faire filtrer par "les gros" FAI

? Si on parle ici de POP/IMAP, je ne vois pas trop ce que ça veut dire.
Et pour le SMTP, on peut utiliser celui de son FAI, à moins qu'il soit vraiment pourri.

désolé pour python, c'est typiquement le genre de détail me que laisse une très mauvaise impression sur ce langage.

Ce qui amusant c'est que tu prends pour référence un langage (Javascript) avec une quantité de "détails" rédhibitoires absolument monstrueuse. Rien que sur le sujet en discussion, regarde la signature de func.apply(...) où tu dois passer un "this" à null si la fonction n'est pas une méthode. Joli hein ?

Donc pour revenir au sujet, je ne connais aucun développeur Python confirmé qui ait un problème avec le "self" explicite, et qui voudrait le retirer. Je pense au contraire que cela rend intégralement explicite le contexte d'exécution, ce qui est une qualité.

Pour le reste et "l'impression sur le langage", il faudrait que tu le pratiques un peu histoire de dépasser les jugements stéréotypés (j'imagine que le "self" explicite arrive en deuxième après l'indentation dans la liste des clichés anti-Python).

la majorité des erreurs d'utilisation de ce type de fonction est la non lecture attentive de la doc

Cette remarque sonne à la fois paternaliste et arbitraire.

Grosso modo, si certains programmeurs se retrouvent avec des trous de sécurité, ce serait de leur faute (ils n'ont pas bien lu la doc, ou ont oublié la moitié de ce qu'ils ont lu, etc.). Le problème, c'est que cette position ne répond absolument pas à la question. On peut certes considérer que toute erreur est une faute humaine, et appuyer péremptoirement sur la culpabilité du programmeur ; la question est bien de minimiser les conséquences des dites fautes ou erreurs.

Note que je n'ai parlé que de ces 2 fonctions. Libre à too de généraliser à toutes les fonctions que tu veux. Ca sera juste un hors sujet de ta part.

Non, justement, ce n'est pas du tout hors sujet.

Si deux primitives aussi simples que la copie et le formatage de chaînes nécessitent une attention soutenue pour ne pas se retrouver avec un trou de sécurité, alors la programmation d'une appli complexe en C relève de l'acrobatie ou du jemenfoutisme.

(sauf bien sûr à postuler l'existence d'une race inconnue de programmeurs parfaits)

Chouette, on va avoir droit à des keynotes de folie.

Sur une planète gazeuse ?

Non, il n'a pas tort, notamment pour ce qui est de la notion de pointeur et de la gestion de la mémoire. Comprendre comment ça fonctionne aux niveaux les plus bas permet de mieux comprendre comment fonctionnent les langages haut niveau. La notion de garbage collector reste extrêmement floue si tu n'as pas un minimum d'idée de ce qui se passe derrière.

Ceci dit, pour cela, nul besoin de former des experts en C, juste de donner aux étudiants les bases nécessaires.

Si tu donnes a une fonction de formatage de la data non controlee, elle va formater n importe comment..

Ben, entre ça et ouvrir une brèche de sécurité, il y a un gouffre. Un problème du C, c'est qu'un bug peut très vite se transformer en faille.

A partir du moment où on ne respecte pas le copyright on peut pirater du code en GPL (c'est à dire l'utiliser le modifier le compiler et distribuer uniquement des binaires).

Tu es conscient qu'on peut décider de respecter quelque chose (à savoir le GPL, à savoir le souhait exprimé par l'auteur) sans que la loi nous y oblige ?

quitte à vous fâcher avec la belle-famille, offrez une yaourtière, vous vous en tirerez pour 20 à 50 euros

Une hagiographie de Sarkozy c'est encore moins cher.

Pour compléter, n'oublions pas que java, pour des raisons qui m'échappent, a plus de succès en France que dans d'autres pays, en particulier aux USA où le C++ lui est largement préféré.

Prédominance des SSII qui pratiquent le nivelage par le bas et l'uniformisation culturelle ?
(juste une hypothèse... en tout cas je ne crois pas que l'explication soit technique)

Et si l'indice auquel tu veux accéder est connu seulement à l'éxecution ? Il va bien falloir vérifier qu'il est compris entre les borne au moment ou tu accède au tableau, de même si les bornes ne sont pas connues à la compilation ect.

Oui bien sûr. Mais je ne crois pas que cela représente la majorité des situations où les performances sont critiques.

Quant aux bornes "non connues à la compilation", certes, avec un langage comme C où un tableau se résume à un pointeur sur le début des données, mais même C++ avec la STL permet d'éviter ce souci.

Enfin bon, on peut toujours vouloir faire de l'optimisation prématurée pour montrer qu'on est un dur, hein...

Je crois que le plus stupide, sur le plan de la communication, c'est que Google t'envoie un message d'invite pour ensuite, quand tu cliques sur le lien, te dire qu'il est impossible de s'inscrire au truc pour des raisons de capacité.
(de même, les "+1" qui ont commencé à apparaître dans les résultats de recherche et qui t'invitent à ouvrir un compte Google+... oups)

Ils feraient mieux de ne rien envoyer du tout.

Meme en C, si on le souhaite, on peut coder des libs pour gerer l espace memoire, limiter les BOFs ... le premier venu qui connait snprintf, strncpy, sizeof et strlen sait bloquer les BOFs!

Je suis sûr que même en assembleur on s'y retrouve facilement. Pourquoi s'embêter avec des langages structurés ? Le premier venu qui connaît BOUND sait éviter les BOFs !

En haute performance, on utilise pas la vérification automatique de dépassement de taille de tableau, car le seul moyen de le faire correctement, c'est de vérifier les bornes pour chaque accès

??? L'analyse statique, ce n'est pas pour les chiens. Si j'ai un tableau de 1000 entrées et que mon indice va de 0 à 999, il est inutile de "vérifier les bornes pour chaque accès".

C te force à tout penser

Fortran propose tout un tas de constructions de relativement haut niveau

Faudrait savoir : il vaut mieux un langage qui te force à tout penser, ou un langage qui propose des constructions de relativement haut niveau ? C'est le grand n'importe quoi, là.

C'est assez débile. Les autres langages obligent aussi à faire attention à son code, si l'on veut limiter les bugs. Simplement, ils libèrent de toute une catégorie de problèmes à la noix, ce qui est toujours une bonne chose.

Enfin, j'imagine qu'on trouve des conducteurs qui ne veulent pas de ceinture de sécurité parce qu'ils ont peur que ça les déresponsabilise (sic).