lasher a écrit 2738 commentaires

Ouais, mords-y l'oeil !

Sinon je suis tout à fait d'accord avec toi. J'ai lu les six volumes, (je me suis pas précipité pour acheter le 6è, il se trouve que je faisais mes courses et que je suis tombé dessus), et je trouve que, même si ce n'est pas forcément ce que j'ai lu de mieux, c'est tout de même une très bonne série de bouquins, bien construite.

Non. La licence D20 permet une utilisation non-commerciale.

Ben oui, mais du coup, mon titre n'est plus racoleur, et plus personne ne me lit :-)

Une femme peut être une salope, un homme non. Un homme ne sera jamais un salop... un homme peut-être un salaud à la rigueur.


En fait, d'après mon dictionnaire, si.

Je ne trouve vraiment pas le langage C 'simple' car il contient trop d'élément de syntaxe différent (boucle, affectation, pointeur, référence, tableau, fonction, macro ...).


Euh, boucles, affectations, tableaux, fonctions, tout ça tu le retrouves (heureusement) dans tous les langages. Quant aux références, c'est du Java et pas du C. Tiens d'ailleurs, un truc tout bête :

en C, tout est passé par valeur. TOUT. En Java, les types primitifs sont passés par valeur (donc par copie), mais tous les types "complexes" (les objets) sont passés par référence. Et note bien que j'ai parlé de la simplicité du langage/de sa syntaxe, pas de la facilité à programmer avec le langage C. Je trouve que ce dernier est plutôt rapide à mettre en oeuvre justement parce qu'il n'y a pas trop de concepts à connaître (mis à part la notion de pointeur, mais honnêtement, comme je l'ai dit, il n'y a pas besoin de manipuler les pointeurs pour commencer à programmer).

quand je parlais d'algo, je pensais plutôt à des trucs basiques comme un quick sort ou la création de listes chainées

Quand tu commences à programmer, un quicksort ou un algo de listes chaînées n'est pas simple, quel que soit le langage.

Prend le code Java (ou Ruby ou O'Caml) et compare avec un code en C

Je ne connais pas Ruby. En ce qui concerne Java, si tu n'as aucune notion de comment est allouée la mémoire, de comment fonctionne le garbage collector, etc., je ne vois pas comment tu peux comprendre la signification d'un NullPointerException. Java te fait croire qu'il n'y a pas de pointeurs, alors qu'il n'y a que ça, partout. Si tu ne comprends pas le principe d'une référence, je ne vois pas trop comment tu peux faire des choses un tant soit peu complexes en Java, ce qui revient à comprendre les pointeurs en C. Dans les deux cas, il faut parler d'adresse mémoire.

Donc le paradigme objet ne te servira à pas grand chose au début, la seule chose c'est que Java par exemple permet de se détacher un minimun de la machine

La méthode objet ne sert à rien au début. Si on te fait prendre l'habitude dès le départ (enfin, très vite, dirons-nous) de programmer sous forme de modules (fonctions/procédures), les concepts objets seront relativement simples à comprendre (il faut quand même une période d'adaptation, bien sûr). Et justement, prends Java : lorsque tu fais de la prog non objet, tu te retrouves avec le corps minimal suivant :

public class MaClasse {
public static void main(String[] args) {
// programme
}
}

Tu dois donc dire à l'étudiant en prog "oui bon, ben, oublie tout le squelette pour le moment, je t'expliquerai plus tard". En C, tu peux aisément expliquer les choses :

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
/* ... *
return EXIT_SUCCESS;
}

(et encore, les #include étant comparables aux import, je ne devrais pas les mettre dans le "source").

Pour ce qui est des macros, tu ne les utilises pas au début, et bizarrement ça ne manque pas.

Et alors quel est l'intêret de commencer à apprendre avec un langage aussi 'primitif' que C si on n'utilise même pas ses 'features' les plus intéressantes

Ben justement, le langage est simple. Pour apprendre à programmer, y'a rien de tel : tu codes ton truc, et dès que tu as besoin d'une fonctionnalité avancée, tu te la programmes. C'est comme ça qu'on apprend. C'est très très formateur d'apprendre à réécrire la libc par exemple (c'est d'ailleurs plus ou moins l'approche utilisée dans le Kernighan & Ritchie, mais le bouquin en lui-même n'est pas pour les débutants).

Cela dit, tu peux déjà programmer pas mal de choses en C rien qu'avec la notion de tableaux.

Et tu utilises une syntaxe "propre" pour masquer les pointeurs dans les cas où tu en as besoin, du genre

typedef char CHAINE20[21];

Plus le langage est simple, plus il est facile d'apprendre a s'en servir. Cela dit, faire de la programmation « sérieuse » proprement en C, c'est une autre paire de manches.

De plus, commencer par utiliser un langage totalement orienté objet (comme Java ou Ruby), même si on peut toujours détourner le langage pour en garder le côté procédural, est une mauvaise idée à mon avis. Les algos sont rarement orientés objet au départ; ils sont adaptés au paradigme objet, mais proviennent pour la plupart des travaux de recherche effectués dans les années 60/70...

c'est à se demander comment il se fait qu'un projet tel qu'OpenSSH survive depuis tant d'années... Sans parler de X (oui, ça fait redite avec un post précédent :-) ) ou Apache, les divers projets de Jakarta, Struts ...

[Dans le film de Moore] la seule vraie raison de la violence aux EU apparaît dans un fatras d'autres causes illusoires (ex: la télévision)

Absolument pas.

Il dit que ce qui est la cause de la violence aux USA est l'injection permanente de peur dans l'esprit des gens. Il prend la télévision comme exemple, mais il sous-entend surtout que les média les plus utilisés par la grande majorité des étatsuniens véhiculent une propagande de la peur. Pour avoir de la famille là-bas, je peux te dire que c'est exactement comme ça. Lorsqu'il y avait [1] la 2è guerre du golfe, on maintenant dans l'esprit des gens qu'ils étaient susceptibles d'être attaqués à tout moment, afin de les gardés convaincus du bien fondé de cette "guerre préventive". Le propos de Moore est de dire que la violence naît de la peur. Et franchement, c'est vrai. Regarde en France : un Sarkozy promet de nettoyer une cité (avec toute la démagogie qui va avec), et il apparaît en homme fort, qui va nous débarrasser de la racaille comm... euh, de la racaille. C'est entre autres grâce à la peur que ce genre de choses est possible.

[1] enfin, "avait", "a", ... Bref, je sais plus trop là. :-)

La GPL et sa nature récursive (virale ?), ne permet pas de refermer l'accès au code et permet au logiciel d'avoir une descendance.

Tu déformes un peu tes propos précédents je trouve : la GPL permet tout, y compris de rendre du code propriétaire (et donc d'obtenir une "feuille" dans l'arbre des développements) ; la GPL impose qu'on continue de développer l'arbre. C'est "tout".

On peut comparer la licence BSD à la production des mulets, forts comme des chevaux et intelligents comme les ânes, mais stériles.

Ben non, on ne peut pas. OpenBSD est un fork de NetBSD, mais est libre. DragonFlyBSD est un fork de FreeBSD 4.X, mais est libre. OpenSSH a pour base de départ la dernière version libre de SSH.

La GPL ne fait pas confiance aux gens pour "coller" à l'esprit du libre toute leur vie, du coup elle leur impose. La licence BSD permet aux gens de faire comme ils l'entendent. A eux de prendre leurs responsabilités. Comme je le disais dans un message plus bas, la licence BSD fait qu'on considère comme la moindre des politesses de rendre un peu à la communauté qui a donné beaucoup. Maintenant, lorsqu'on te fait un cadeau, rien ne t'oblige à dire merci si tu n'en as pas envie, mais c'est pas poli.

Dire que la licence BSD est stérile est un travestissement de la réalité. Elle permet juste aux égoïstes de l'être toujours, tout comme elle n'empêche pas les gens de contribuer au développement du logiciel considéré. Il y a sans doute beaucoup de gens qui font du proprio à partir de LL sous licence BSD (je ne parle même pas de ceux qui repompent des LL GPL honteusement), mais ils respectent les règles du jeu, et comme il n'est pas dans leur intérêt de trop trop aller vite dans leurs dévs (puisque s'ils rendent le logiciel "parfait", qui voudrait de la version suivante ?), ils risquent d'aller moins vite que le logiciel libre qu'ils ont repompé. Evidemment, ça suppose que ledit logiciel ait le soutien suffisant pour continuer à exister.

On voit ensuite je crois le résultat ici (documentaire que je recommande vivement):
http://www.bowlingforcolumbine.com(...)

Sauf que dans ce documentaire, M. Moore montre bien qu'au Canada, ils ont autant d'armes à feu qu'aux US, et qu'il y a clairement moins de meurtres.

Globalement je suis d'accord avec ton analyse, mais il y a une chose que je trouve fausse :

Un système de code GPL va donc avoir tendance à grossir et évoluer de manière naturelle alors que les systèmes de type BSD et propriétaire vont nécessiter un mécanisme actif permettant de garantir un flux entrant d'information (et ceci explique a priori le succès des licences GPL) [...] les systèmes BSD ne peuvent exister de manière stable et efficace face au propriétaire.

Ce serait vite oublier la licence qui anime quelques très gros projets libres. Je pense notamment à X / Xorg, à Bind, Perl, Apache, etc. (bon certes, mis à part Xorg, dans les exemples précédents, il s'agit surtout d'outils pour les professionnels ou les amateurs éclairés).

Ah oui, j'oubliais OpenSSH ! Bref, je trouve qu'on oublie bien vite que les gros projets libres, s'ils sont souvent sous GPL, sont aussi souvent sous une licence "BSDisante"...

Lorsqu'on fait du logiciel libre sous licence BSD, on fait le pari que, si jamais le logiciel plaît, et qu'une boite veut le reprendre, celle-ci aura fort à faire pour rester à jour contre toute une communauté de développeurs motivés. Alors oui, la GPL force de facto les utilisateurs-programmeurs à rendre ce qu'ils ont emprunté. Les BSDistes préfèrent dire que c'est plus poli de faire ainsi, mais que chacun fait comme il veut. Et honnêtement, je ne vois pas comment un standard (au hasard, la pile TCP/IP) pourrait se répandre facilement si en intégrant le code dudit standard on doive changer la licence pour tout un projet (d'aucuns argueront que la LGPL est faite pour ça, mais la licence BSD est qd même préférée dans la majorité des cas)

Et pour en revenir au P2P, télécharger des artistes peu connu ou peu vendu ou peu distribué, c'est aussi les priver du fruit de leur travail,

C'est marrant, à un concert des Fatals Picards, un pote qui voulait acheter leur CD n'a pas pu : tous les disques étaient partis. Réponse d'Ivan (le chanteur) : "boah, t'as qu'à le télécharger sur le net".

Ils sont pas cons les FP (et je dis pas seulement ça parce qu'ils paient des coups :) ) : ils savent très bien qu'ils gagnent beaucoup en laissant des morceaux sur le net, parce que ça ramène des gens à leurs concerts, que ça fait vendre des t-shirts, des CD, etc.

J'ai oublié de préciser que c'était très bientôt, le 26 (jeudi quoi ;-) ) !

Venez nombreux !

Euh, le moinssage je m'en fous, mais vous savez que j'ai raison hein ? En Anglais, "Authentification" n'existe pas. Alors quand je vois un sigle mal retranscrit, désolé de vouloir rectifier...

tout est dans le titre :)

Euh, tu sais que c'était de la radio d'être un livre, hein ? tu le sais, ça ? :-)

Si l'affirmation n'était pas vraie, et bien on ne ferait rien de plus de nos ordinateurs qu'il y a 10 ans ! Or, aujourd'hui, on rippe des DVD, on grave des CD/DVD, on fait du montage vidéo, on lit du DivX, etc., tout ça en écoutant de la musique et en surfant sur internet, et en plus, pour un prix incroyablement plus bas qu'il y a 10 ans.

L'affirmation n'est pas totalement fausse. Beaucoup de programmes sont écrits en VB/Delphi/etc. Une certaine quantité en Java, et bien sûr il y a C et C++, Perl, Python, Ruby, et les autres.

Pour ne prendre que le cas de Java (mais c'est globalement vrai pour tous les langages), il existe beaucoup de programmeurs qui utilisent les mauvaises structures de données aux mauvais endroits. Ce qui implique que de la mémoire est franchement gâchée (non pas parce que lesdites structures sont mal codées, mais surtout mal employées). Cela fait dire à certains que Java est lent, ce qui est faux depuis un moment maintenant. Idem pour les langages de script.

Je pense qu'il faut parler d'optimisation en faisant surtout un parallèle avec "bonne conception". Une bonne conception utilise les bonnes structures.

Pour illustrer : si je me souviens bien, il y avait de gros soucis de perfs avec la VM dans Linux 2.4 (swap continu quasiment dès le départ dans certaines configurations du système). Le fait de changer le modèle pour la VM a résolu en grande partie le problème.

Il est évident qu'il faut d'abord que "ça marche" et qu'ensuite seulement il est temps d'optimiser.

Et sinon :


ordinateur PC 486 SX 25 doté de 4 Mo de mémoire, avec une carte graphique 256 couleurs, un disque dur 120 Mo, un lecteur disquette 3"1/2 1,44 Mo, et sans écran (ni lecteur CD, ni carte son évidemment) pour la modique somme de 140.000 francs hors taxes, soit 166.040 francs TTC


Ca me paraît vraiment énorme comme prix. A l'époque (à peu près au même moment), mes parents avaient acheté un 386 DX 33 avec 4Mo de RAM, 1Mo de vidéo, 120 Mo de HDD, un écran 14" qui montait jusqu'en 800*600 (1024*768 entrelacé). Le tout pour 14000F TTC.

Juste pour info, le sophisme à la base, c'est purement l'art de convaincre, ni plus ni moins. Un bon sophiste était censé pour voir parler de tout et convaincre son auditoire un jour que la pluie était ce qui pouvait arriver de mieux à la république, et le lendemain que le soleil et la sécheresse, c'était ça, le progrès.

Oui. Et dans ce cas tu ne prendras pas un langage interprêté, parce qu'à ma connaissance aucun n'est capable de ce genre de perfs. Donc ton argument n'a absolument aucune valeur.

En apparté, pour ce qui est de la rapidité d'exécution/de la performance d'un code, je te renvoie à Abrash (Black book of programming, dispo gratuitement sur le net), au tout premier chapitre. En résumé : il démontre qu'à moins de maîtriser parfaitement l'assembleur (et donc la machine sur laquelle on programme, quelque part), la différence de performance entre un code écrit en c et d'un autre en ASM est négligeable. Et il écrivait ça il y a plus de 10 ans (à une époque où l'optimisation des compilateurs n'était pas ce qu'elle est maintenant), à l'époque des 486...

Il faudrait que tu précises alors. Parce que du Web dynamique en Perl, j'en ai fait, et ça se passe plutôt très bien.

Au pire (et pour répondre à un message plus bas) il existe l'équivalent de php avec perl (avec les mêmes inconvénients aussi).

L'overhead de Perl lorsqu'il est utilisé pour faire du cgi est extrêmement réduit dans le cas d'Apache, et ce grâce à mod_perl.

Pour ceux qui parleraient (encore) de l'illisibilité de Perl vis à vis des autres langages, je ne vois pas trop quel est le problème.

PHP est un langage qui peut lui aussi être très crade (car le code est embarqué au milieu du code HTML... Alors oui, on peut toujours faire des include, tout ça... Mais c'est quand même pas génial, ça force quand même à insérer du "<?php $maVar ?>" de temps à autres ...

... De même que le C ou le C++, pour ne prendre que ces langages comme exemple. Franchement, entre

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>

int main(void) {
    FILE *f = NULL;
    char buffer[81];
    
    f = fopen("fichier.txt","r");
    while (fread(buffer, sizeof(buffer), f) != NULL) 
        printf("%s\n", buffer);
    if (ferror(f))
    {
        perror("fread");
        exit(errno);
    }
    if (fclose(f) != 0)
    {
        perror("fclose");
        exit(errno);
    }
    return EXIT_SUCCESS;
}

et

#!/usr/bin/perl

use strict;
use warnings;

open(FICHIER, "<fichier.txt") || die "Erreur à l'ouverture du fichier";
print while(<FICHIER>); # erreurs détectées automatiquement
close(FICHIER) || die "Erreur à la fermeture du fichier";

Je me demande vraiment quel est le langage le plus illisible (et pourtant tous les deux peuvent être considérés comme lisibles je pense, sur un exemple aussi simple).

Tout ça pour revenir à la même rengaine : c'est la conception qui compte plus que tout ...

En Perl, c'est plus ou moins pareil, mais à l'envers : il faut insérer du code HTML dans du code Perl - et là on est heureux d'avoir des emprunts au shell du type :

print << EOHtml
<code HTML .../>
EOHtml

En Java, il y a Struts ou JSF (qui ont le bon goût de masquer le code Java en utilisant des balises - JSTL + Struts tags par exemple - ce qui permet de ne plus avoir de code Java dans 99% des cas à l'intérieur du JSP), voire d'utiliser XML+XSLT pour le rendu...

... Mais mon petit doigt me dit qu'il existe des choses équivalentes en Perl :-)

Par contre je ne suis pas sur que Perl soit aussi facile a gerer dans des contextes exigeant en terme de rapidite d'execution que le C justement ?

J'avais fait une appli en Perl qui devait parser des mails, générer un fichier XML décrivant ces mails, contacter une base MySQL, utiliser Image Magick pour déterminer les dimensions d'une image .... Bref, faire des trucs assez complexes. Avec une contrainte : mon appli plus les traitements des autres applis (programmées en Perl elles aussi) ne devait pas dépasser 8 secondes de délai entre réception du mail et émission du SMS de confirmation...

Mon petit parser de mail effectuait son boulot en moins de 0.5 seconde. Les autres applis en Perl faisaient à peu près pareil (avec en plus de l'analyse XML, des écritures dans la base, etc). Bref, Perl est rapide.

En C, ça aurait sans doute pris moins de temps à l'exécution. Maintenant, les quelques millièmes de secondes gagnés par le programme en C sont négligeables devant les quelques semaines de dév gagnées grâce à Perl.

Salut

Je ne suis pas certain que tu aies raison. Lorsque le Monde proposait de consulter ses archives en ligne, ses rédacteurs ont gueulé en disant (avec raison) qu'ils n'avaient été payés que pour une seule publication de l'article.

En quoi ce cas-ci est-il différent ?

Par exemple pour jayacard, si tu n'as eu aucun contributeur, ça veut dire que personne ne s'y est interessé. Donc pas non plus un concurrent, donc.
Si le projet avait été close source, ça n'aurait donc rien changé.

C'est un raccourci un peu facile. Lorsque ton produit concerne la sécurité, et un support de sécu comme les cartes à puce, le côté "y'a pas beaucoup de monde" ne veut pas dire que le peu de monde qui s'intéresse à ce genre de solutions ne sera pas intéressé par tes idées.

Et de même que des applications libres peuvent répliquer le fonctionnement d'un logiciel proprio en changeant l'algo qui parvient au même résultat, qu'est-ce qui empêche une société de repomper un logiciel libre (en ayant un avantage : le source est à disposition), et de modifier les parties de code qui vont bien ? Ils y auront gagné beaucoup de temps en dév qd même.

Pire : une boite peu scrupuleuse pourrait très bien reprendre le code, le mettre en closed source, et comme il s'agit de cartes à puces, il serait difficile de prouver que le code est bien issu du libre.

Dans le cas "générique", tu as peut-être raison : un produit "ultra-spécialisé", qui n'intéresse que peu de boites pourrait peut-être marcher dans le monde du libre. Mais là il s'agit d'un produit axé sécurité. C'est plus le même genre de produit selon moi.

Le cas ne s'est jamais posé dans mon entourage, j'en sais donc rien. Par contre, les cas où l'on fait une prise de sang à la demande des autorités c'est quand même pas fréquent...

Donc tu crois vraiment que le cannabis ne jouera pas ? :-)

Et je n'ai pas jugé comme bonne ou mauvaise la prise de cannabis, chacun fait comme il veut, et surtout chacun assume :-)

Si la possession est illégale, la consommation aussi, non ? :)
Et sinon, oui, consommer du cannabis c'est illégal. A ton avis, pourquoi on demandait la dépénalisation y'a pas si longtemps ?