Je comprends rien à ta raison "démographie". Je vois pas l'impact.
Ni le rapport avec les "blancs" (l'homosexualité a rien à voir avec la couleur de la peau il me semble) et leur démographie faible (En quoi ça peut faire bouger le taux de natalité d'adopter ou non ?)
Sauf si tu parles d'adoption d'enfants étrangers, et là tes propos me plaisent pas du tout (un gamin c'est un gamin, quelle importance à son origine ?)
Je me plains pas, je constate : le couple gcj / framework java libre est pas encore assez complet / mûr pour faire tourner eclipse CDT. Par contre il troune pas trop mal avec la JVM de SUN (j'entends sans bug qui le rende complètement inutilisable), c'est tout.
Je rebondissais sur le fait que qu'eclipse tourne avec un java entièrement libre. Certe, il tourne, mais c'est pas encore la panacée. J'ai pas vraiment testé eclipse sous une JVM libre pour le dev java uniquement.
Au passage : on trouve CDT sur le site d'eclipse, chez IBM, ça ressemble donc à un projet "officiel" eclipse, bien que ce soit un plugin.
Pour eclipse, (dans debian aussi), c'est pas forcément la joie non plus. Je l'ai testé avec CDT pour le C++, et l'indexeur de code se vautre régulièrement, bouffe 100% du proc, il y a des problème de mémoires, des boucles manifestement infinies qui bouffent 100% du proc, ... Ca fonctionne, mais beaucoup moin bien qu'avec le jvm de sun.
J'ai rien dit a propos du langage. Je sais pas si python serait mieux. Mais je persiste a penser qu'un environnement style eclipse et un langage comme java c'set pas ce qu'il y a de plus ludique/adapté. J'ai jamais dit qu'eclipse c'était de la merde, ni java d'ailleurs. Simplement, à 11 ans, on a d'autres priorités que java/eclipse, genre coder un jeu vidéo, et que c'est pas simple, et qu'il y a pleins de concepts à piger.
Quelque chose de plus orienté fun et pédagogie, de plus guidé, de plus illustratifs, genre des exemples interractifs, des objets qui se voient concrêtement à l'écran, qu'on peut manipuler un peu plus à la souris, piger le concept de méthodes/attributs de manière ludique en interagissant avec un objet a l'écran, rajouter ses propres méthodes (sans forcément dans un premier temps d'approprier la totalité de la syntaxe du langage, le gosse, il s'en fout), ca serait mieux. En bref, je pense que la forme du bouquin, les outils utilisés, sont pas adpatés pour un enfant, surtout s'il est jeune, et que à première vue les exemples sont chiants à mourrir.
Sur mon amstrad, ce que je voulais c'est pas pouvoir me repérer dans une API XML avec pleins d'objets, de méthodes, et une doc de malade, c'était voir des trucs bouger à l'écran. La complétion, c'est certe sympa, mais c'est loin d'être suffisant dans mon optique.
J'ai regardé blue/j, et je vois pas trop l'utililité d'apprendre UML à un gamin. Après ça dépend si tu veux en faire un parfait développeur dès l'age de 12 ans, mais je te suivrais pas là dessus. Un syndrome du geek qui veut transmettre ça à ses gosses ?
Ca doit rester pédagogique et surtout fun, si tu veux pas le dégouter.
[+]
Pour le concept objet, je suis pas tout à fait d'accord (cf cf mon commentaire au dessus.)
Présenté comme en java, c'est sûr que c'est pas évident. Mais présenté comme un objet "graphique" genre une raquette de pong, ça m'a l'air très intuitif. La raquette, on comprends bien que c'est un tout. Elle est à un endroit (droite/gauche, hauteur) et on peut faire des opérations dessus (la monter, la descendre, ...)
Même pas besoin d'expliquer ce qu'est une incrémentation dans un premier temps. On peut filer des objets prédéfinis dans un premier temps, laisser le gamin le manipuler (cliquer sur l'objet graphique, afficher les opérations qu'on peut faire dessus, déclencher les opérations monter/descendre, voir les implications sur les attributs, le fait qu'a l'écran la raquette monte/descend, ...). Ensuite on peut le guider pour coder une balle (elle a une direction, une opération "avancer", une coordonée x/y, ...).
Dans un langage comme java, avec pleins de mots clé obscurs, des blocs, c'est pas gagné, mais un peu guidé avec un cliquodrome/des aides a la génération, ça doit être plus facile.
En même temps, ça me semble pas très ludique comme apprentissage.
Il faut installer eclipse, apprendre des tas de concepts, une syntaxe, le principe des layouts pour constuire des widgets (ce que j'ai vu rapidement en parcourant le livre).
Alors certe eclipse ça saute (masque) la phase "compilation", ca t'aide un peu, mais le gamin de 11 ans qui a pas abandonné avant d'arriver à des trucs intéressants, il est sacrément mûr/motivé/poussé par ses parents.
Je me souviens avoir débuté en basic sur amstrad : t'allumes le pc, tu peux taper les programmes exemples du manuel dans un langage relativement simple à comprendre. C'est rapide, et, à mon avis ludique. Eclipse c'est AMHA pas très ludique. Et puis il y a des tas de concepts à apprendre en java avant d'arriver à un résultats. Perso je pense que le concept d'objet peut être vachement utile pour un gamin/débutant, mais il faut bien le présenter de manière intuitive, et avec des exemples sympa et une syntaxe pas trop lourde ni chiante, avec une bonne bibliothèque pour faire facilement des graphismes/des éléments de jeux, faire bouger des objets à l'écran.
Sur le langage a apprendre aux enfants, faut-il leur faire utiliser/apprendre un langage d'adulte ou leur faire appréhender les concepts de la programmation de façon ludique ? Pour moi l'important c'est qu'ils puissent arriver à un résultat sympa sans se décourager. Je crois pas trop au couple java/eclipse, ils y viendront assez rapidement si ils sont intéressés.
Et si les médias matraquait aux informations les dangés lié à cette loi
Le discours "Tu pourras te faire virer n'importe quand pendant deux ans sans motif" a plus d'impact que "Tu pourras plus lire de la musique avec des LL" (grosse ellipse/caricature).
Il faut voir aussi qu'une pétition signée par 165 000 personnes face à un mouvement qui, sans parler des violences, a mis 10 x plus de gens dans la rue, ça pèse pas le même poids. D'ailleurs des pétitions signée par 165 000 personnes, je pense pas que ce soit si rare que ça (en pourcentage de la population, on est déja loin des 1).
Je pense surtout que le problème des artistes, c'est la musique, et s'ils laissent des maisons de disques les diffuser, c'est qu'ils veulent pas s'emmerder avec les questions de production/distribution/vente. La maison de disque doit rien leur dire du tout de ce point de vue là.
(Avertissement, je suis pas non plus un expert en algo génétique, il y a des oublis, approximations, erreurs ?)
"L'objet" en question peut être la solution d'un problème (un chemin dans un graphe, pour le problème du voyageur de commerce par exemple) écrit sous la forme d'une chaine par exemple.
Son évolution dépends des opérateurs qu'on lui affecte :
-> "petites" mutations pour une recherche locale (swap de deux sommets villes dans le chemin, par exemple),
-> opérateurs un peu plus radicaux lors du croisement de deux solutions (crossover) : on mixe des chemins, prendre le début d'un, la fin d'un autre, et tout coller.
Ensuite on les 'répares' éventuellement si au passage on a créé des fausses solutions (un chemin dans lequel on a deux fois le même sommets), on garde les meilleurs, et on recommence. L'algo est pas modifié.
Note que ton "si vous voulez un logiciel, payez moi pour le développer" s'applique très bien aux SSII, modèle proprio la plupart du temps.
"Une fois le travail/logiciel achevé il appartient à tous."
Ca ça dépend. Une entreprise peut très bien choisir de garde le logiciel et son code GPL pour elle.
Du coup une conclusion me vient à l'esprit : du dev spécifique, ça peut couter très cher (le salaire d'un/plusieurs développeurs pendant X temps, libre comme proprio), plus cher qu'une licence d'un logiciel courant (le cout est partagé entre tous les acheteurs, a priori). Surtout si l'entreprise en supporte seule le coût.
Un gros avantage du LL à mon sens, c'est la mutualisation. Linux par exemple, tout le monde peut récupérer le travail fait dessus, et rajouter du code et des fonctionnalités au panier. Dans le cas de dev très spécifique ou très peu de mutualisation est dispo, il y a au moins les bibliothèques libres, pour certaines parties du code. Mais l'intérêt du libre n'est plus dans le coût, alors. Fournir un logiciel stratégique qui pourrait aider la concurrence alors qu'elle n'en a pas supporté le dev, je comprends que ça puisse refroidir.
C'est plutôt dans l'autre sens que ça marche en général. Le client peut l'être chez toi ou ailleurs, tu vas pas forcer les gens à acheter/t'employer. Après, à toi de coller au mieux à leurs besoins ...
Certe, on reproduit tout ce qu'on veut éviter sur son propre bureau, mais la grosse différence avec ce genre de systèmes c'est que tu peux garder ton bureau bordélique mais trouver un truc quand même hyper rapidement, genre tu peux faire une grosse pile, voir ce qu'il y a dedans en 2 secondes, ouvir/manipuler ton documents, le tout sans changer la forme ou la place de la pile, qui va se reformer d'elle même.
Le gros avantage que j'y vois c'est qu'on réfléchi, genre en quel endroit PHYSIQUE j'ai rangé ça, en haut, en bas, comme on le ferai sur son bureau (physique) perso, avec les feuilles qui volent partout dans mon cas, sauf que quelque part c'est quand même rangé et plus facile à laisser organisé (pas forcément besoin de reranger ton document une fois ouvert).
Je suis assez d'accord, c'est pour ça que je disais que si je retentais un truc comme ça, je le ferai certainement pas avec de l'asm classique, mais certainement dans une machine virtuelle avec un jeu d'instruction plus réduit et bien choisi, un univers un peu différent d'un PC et sa mémoire.
Dans le cas de programme, on peux imaginer "d'aider" un peu le système à la base en lui fournissant des bouts de code nécessaire au croisement avec d'autres processus, avec possibilité d'évolution limitée, un sous-système formalisant les mutations, ...
Avec des bouts de codes complètement aléatoires, c'est sur qu'il y a pas des masses de chances que ça converge. Mais tout l'intérêt de la chose AMHA est qu'il peut potentiellement en émerger à peu prêt n'importe quoi, des trucs inimaginables pour nous en tout cas. Et puis, en rêvant un peu (beaucoup), combien de chance avait de converger vers la vie avec l'ADN, la reproduction et tout ce qu'on lui connait à partir de la physique de notre univers ;)
Cela dit, c'était juste une vieille idée, j'y connaissais encore pas grand chose en informatique. J'avais rien écris.
Première étape : modification aléatoire de code. Deuxième phase: seuls les processus qui plantent pas survivent. Troisième phase : ils inventent le fork. Quatrième phase : le besoin vital de mémoire. Un processus bouffe la mémoire de l'autre, ou il se faire bouffer. 5ème étape : l'un d'entre eux découvre les entrées sorties. Un carte réseau. Il apprends à parler ethernet. IP. TCP. http. Je laisse votre imagination faire le reste.
(j'avais eu l'idée de faire un truc comme ça un jour, un système évolutif de processus qui peuvent s'automodifié basé sur du code asm, quand j'étais jeune, quand d'autres pensent qu'ils vont inventer un programme intelligent ou un OS révolutionnaire. Étonament j'ai laissé tombé. Si je devais recommencer je me baserai plus sur une machine virtuelle. rha la la nostalgie)
D'autre part, en ce moment sur cooker, ça parle de faire du préchargement de fichier en regardant les accès fichiers au boot via strace et ensuite les précharger au prochain boot...
Il y avait pas un genre de système un peu dans l'esprit sous windows, genre l'arrangement des fichiers pour les applis les plus utilisés démarrent plus vite ? j'imagine qu'ils s'arrangaient pour tout placer sur des secteurs de disques consécutifs ... (cela dit c'est un très vague et très approximatif souvenir)
A propos de wikipedia et la coupe du monde, c'est pas un peu le bordel à la fin des matchs ou au moment de faire des mises à jour de score ? Genre pleins de wikipediens-footeux se précipitent en même temps ? (A ma conaissance il y a pas de gestion de conflits / d'édition multiples, à part l'historique)
[^] # Re: divergence d'opinion
Posté par thoasm . En réponse au journal Une présidentiable de gauche rencontre une figure emblématique du LL. Évalué à 2.
[^] # Re: divergence d'opinion
Posté par thoasm . En réponse au journal Une présidentiable de gauche rencontre une figure emblématique du LL. Évalué à 6.
Ni le rapport avec les "blancs" (l'homosexualité a rien à voir avec la couleur de la peau il me semble) et leur démographie faible (En quoi ça peut faire bouger le taux de natalité d'adopter ou non ?)
Sauf si tu parles d'adoption d'enfants étrangers, et là tes propos me plaisent pas du tout (un gamin c'est un gamin, quelle importance à son origine ?)
[^] # Re: Un logiciel sans licence est une contrefaçon.
Posté par thoasm . En réponse au journal Licence, licence, vous avez dit licence. Évalué à 1.
[^] # Re: javasapusaipalibre
Posté par thoasm . En réponse à la dépêche Programmation Java pour les enfants, les parents et les grands-parents. Évalué à 3.
Je rebondissais sur le fait que qu'eclipse tourne avec un java entièrement libre. Certe, il tourne, mais c'est pas encore la panacée. J'ai pas vraiment testé eclipse sous une JVM libre pour le dev java uniquement.
Au passage : on trouve CDT sur le site d'eclipse, chez IBM, ça ressemble donc à un projet "officiel" eclipse, bien que ce soit un plugin.
[^] # Re: javasapusaipalibre
Posté par thoasm . En réponse à la dépêche Programmation Java pour les enfants, les parents et les grands-parents. Évalué à 3.
[^] # Re: Java pour les enfants
Posté par thoasm . En réponse à la dépêche Programmation Java pour les enfants, les parents et les grands-parents. Évalué à 4.
Quelque chose de plus orienté fun et pédagogie, de plus guidé, de plus illustratifs, genre des exemples interractifs, des objets qui se voient concrêtement à l'écran, qu'on peut manipuler un peu plus à la souris, piger le concept de méthodes/attributs de manière ludique en interagissant avec un objet a l'écran, rajouter ses propres méthodes (sans forcément dans un premier temps d'approprier la totalité de la syntaxe du langage, le gosse, il s'en fout), ca serait mieux. En bref, je pense que la forme du bouquin, les outils utilisés, sont pas adpatés pour un enfant, surtout s'il est jeune, et que à première vue les exemples sont chiants à mourrir.
Sur mon amstrad, ce que je voulais c'est pas pouvoir me repérer dans une API XML avec pleins d'objets, de méthodes, et une doc de malade, c'était voir des trucs bouger à l'écran. La complétion, c'est certe sympa, mais c'est loin d'être suffisant dans mon optique.
J'ai regardé blue/j, et je vois pas trop l'utililité d'apprendre UML à un gamin. Après ça dépend si tu veux en faire un parfait développeur dès l'age de 12 ans, mais je te suivrais pas là dessus. Un syndrome du geek qui veut transmettre ça à ses gosses ?
Ca doit rester pédagogique et surtout fun, si tu veux pas le dégouter.
[^] # Re: Bah
Posté par thoasm . En réponse à la dépêche Programmation Java pour les enfants, les parents et les grands-parents. Évalué à 2.
Pour le concept objet, je suis pas tout à fait d'accord (cf cf mon commentaire au dessus.)
Présenté comme en java, c'est sûr que c'est pas évident. Mais présenté comme un objet "graphique" genre une raquette de pong, ça m'a l'air très intuitif. La raquette, on comprends bien que c'est un tout. Elle est à un endroit (droite/gauche, hauteur) et on peut faire des opérations dessus (la monter, la descendre, ...)
Même pas besoin d'expliquer ce qu'est une incrémentation dans un premier temps. On peut filer des objets prédéfinis dans un premier temps, laisser le gamin le manipuler (cliquer sur l'objet graphique, afficher les opérations qu'on peut faire dessus, déclencher les opérations monter/descendre, voir les implications sur les attributs, le fait qu'a l'écran la raquette monte/descend, ...). Ensuite on peut le guider pour coder une balle (elle a une direction, une opération "avancer", une coordonée x/y, ...).
Dans un langage comme java, avec pleins de mots clé obscurs, des blocs, c'est pas gagné, mais un peu guidé avec un cliquodrome/des aides a la génération, ça doit être plus facile.
[^] # Re: Java pour les enfants
Posté par thoasm . En réponse à la dépêche Programmation Java pour les enfants, les parents et les grands-parents. Évalué à 9.
Il faut installer eclipse, apprendre des tas de concepts, une syntaxe, le principe des layouts pour constuire des widgets (ce que j'ai vu rapidement en parcourant le livre).
Alors certe eclipse ça saute (masque) la phase "compilation", ca t'aide un peu, mais le gamin de 11 ans qui a pas abandonné avant d'arriver à des trucs intéressants, il est sacrément mûr/motivé/poussé par ses parents.
Je me souviens avoir débuté en basic sur amstrad : t'allumes le pc, tu peux taper les programmes exemples du manuel dans un langage relativement simple à comprendre. C'est rapide, et, à mon avis ludique. Eclipse c'est AMHA pas très ludique. Et puis il y a des tas de concepts à apprendre en java avant d'arriver à un résultats. Perso je pense que le concept d'objet peut être vachement utile pour un gamin/débutant, mais il faut bien le présenter de manière intuitive, et avec des exemples sympa et une syntaxe pas trop lourde ni chiante, avec une bonne bibliothèque pour faire facilement des graphismes/des éléments de jeux, faire bouger des objets à l'écran.
Sur le langage a apprendre aux enfants, faut-il leur faire utiliser/apprendre un langage d'adulte ou leur faire appréhender les concepts de la programmation de façon ludique ? Pour moi l'important c'est qu'ils puissent arriver à un résultat sympa sans se décourager. Je crois pas trop au couple java/eclipse, ils y viendront assez rapidement si ils sont intéressés.
[^] # Re: Image intéressante à propos de Dadvsi
Posté par thoasm . En réponse au journal DADVSI: il est urgent d'agir. Évalué à 4.
Le discours "Tu pourras te faire virer n'importe quand pendant deux ans sans motif" a plus d'impact que "Tu pourras plus lire de la musique avec des LL" (grosse ellipse/caricature).
[^] # Re: Image intéressante à propos de Dadvsi
Posté par thoasm . En réponse au journal DADVSI: il est urgent d'agir. Évalué à 2.
[^] # Re: CMP-DADVSI-DTC
Posté par thoasm . En réponse à la dépêche DADVSI : l'assaut final. Évalué à 3.
Je vois mal comment on peux faire plus Poujadiste dans la forme.
[^] # Re: CMP-DADVSI-DTC
Posté par thoasm . En réponse à la dépêche DADVSI : l'assaut final. Évalué à 2.
Entre nous, j'aimerai bien voir ton programme.
[^] # Re: C'est pas etonnant
Posté par thoasm . En réponse au journal Humour de répé. Évalué à 3.
[^] # Re: Anis !
Posté par thoasm . En réponse au journal Olivia Ruiz, Olivia Rox !. Évalué à 2.
[^] # Re: Olivia Ruiz, elle sucks pas
Posté par thoasm . En réponse au journal Olivia Ruiz, Olivia Rox !. Évalué à 2.
[^] # Re: JIT
Posté par thoasm . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 3.
"L'objet" en question peut être la solution d'un problème (un chemin dans un graphe, pour le problème du voyageur de commerce par exemple) écrit sous la forme d'une chaine par exemple.
Son évolution dépends des opérateurs qu'on lui affecte :
-> "petites" mutations pour une recherche locale (swap de deux sommets villes dans le chemin, par exemple),
-> opérateurs un peu plus radicaux lors du croisement de deux solutions (crossover) : on mixe des chemins, prendre le début d'un, la fin d'un autre, et tout coller.
Ensuite on les 'répares' éventuellement si au passage on a créé des fausses solutions (un chemin dans lequel on a deux fois le même sommets), on garde les meilleurs, et on recommence. L'algo est pas modifié.
[^] # Re: Trop complexe pour être résumé si vite
Posté par thoasm . En réponse au journal L'effet boomerang de la GPL. Évalué à 2.
"Une fois le travail/logiciel achevé il appartient à tous."
Ca ça dépend. Une entreprise peut très bien choisir de garde le logiciel et son code GPL pour elle.
Du coup une conclusion me vient à l'esprit : du dev spécifique, ça peut couter très cher (le salaire d'un/plusieurs développeurs pendant X temps, libre comme proprio), plus cher qu'une licence d'un logiciel courant (le cout est partagé entre tous les acheteurs, a priori). Surtout si l'entreprise en supporte seule le coût.
Un gros avantage du LL à mon sens, c'est la mutualisation. Linux par exemple, tout le monde peut récupérer le travail fait dessus, et rajouter du code et des fonctionnalités au panier. Dans le cas de dev très spécifique ou très peu de mutualisation est dispo, il y a au moins les bibliothèques libres, pour certaines parties du code. Mais l'intérêt du libre n'est plus dans le coût, alors. Fournir un logiciel stratégique qui pourrait aider la concurrence alors qu'elle n'en a pas supporté le dev, je comprends que ça puisse refroidir.
[^] # Re: Oui mais !
Posté par thoasm . En réponse au journal L'effet boomerang de la GPL. Évalué à 5.
C'est plutôt dans l'autre sens que ça marche en général. Le client peut l'être chez toi ou ailleurs, tu vas pas forcer les gens à acheter/t'employer. Après, à toi de coller au mieux à leurs besoins ...
[^] # Re: Cool
Posté par thoasm . En réponse au journal Un grand moment culinaire. Évalué à 2.
[^] # Re: Bah ... pas moche.
Posté par thoasm . En réponse au journal encore un bureau pas pratique. Évalué à 3.
Le gros avantage que j'y vois c'est qu'on réfléchi, genre en quel endroit PHYSIQUE j'ai rangé ça, en haut, en bas, comme on le ferai sur son bureau (physique) perso, avec les feuilles qui volent partout dans mon cas, sauf que quelque part c'est quand même rangé et plus facile à laisser organisé (pas forcément besoin de reranger ton document une fois ouvert).
[^] # Re: JIT
Posté par thoasm . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 2.
[^] # Re: JIT
Posté par thoasm . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 2.
Dans le cas de programme, on peux imaginer "d'aider" un peu le système à la base en lui fournissant des bouts de code nécessaire au croisement avec d'autres processus, avec possibilité d'évolution limitée, un sous-système formalisant les mutations, ...
Avec des bouts de codes complètement aléatoires, c'est sur qu'il y a pas des masses de chances que ça converge. Mais tout l'intérêt de la chose AMHA est qu'il peut potentiellement en émerger à peu prêt n'importe quoi, des trucs inimaginables pour nous en tout cas. Et puis, en rêvant un peu (beaucoup), combien de chance avait de converger vers la vie avec l'ADN, la reproduction et tout ce qu'on lui connait à partir de la physique de notre univers ;)
Cela dit, c'était juste une vieille idée, j'y connaissais encore pas grand chose en informatique. J'avais rien écris.
[^] # Re: JIT
Posté par thoasm . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 2.
(j'avais eu l'idée de faire un truc comme ça un jour, un système évolutif de processus qui peuvent s'automodifié basé sur du code asm, quand j'étais jeune, quand d'autres pensent qu'ils vont inventer un programme intelligent ou un OS révolutionnaire. Étonament j'ai laissé tombé. Si je devais recommencer je me baserai plus sur une machine virtuelle. rha la la nostalgie)
[^] # Re: "L'optimisation de l'image du noyau au démarrage"
Posté par thoasm . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 2.
Il y avait pas un genre de système un peu dans l'esprit sous windows, genre l'arrangement des fichiers pour les applis les plus utilisés démarrent plus vite ? j'imagine qu'ils s'arrangaient pour tout placer sur des secteurs de disques consécutifs ... (cela dit c'est un très vague et très approximatif souvenir)
[^] # [HS] Re: Wikipedia ou Google
Posté par thoasm . En réponse au journal La coupe du monde de football sur Internet. Évalué à 3.