jbbourgoin a écrit 297 commentaires

Mais dans cet ouvrage il ne s'agit pas d'apprendre à programmer en Python ou en Java pour que demain vous puissiez bosser chez IBM ou Google.

Il s'agit d'apprendre la programmation de la simple affectation de valeur à une variable à l'écriture et l'analyse d'un sous-ensemble de C et de Scheme.

Ce que l'on apprend dans cet ouvrage est utile quand on fait du Python ou du Java.

De toute manière le plus n'est pas d'apprendre un langage particulier (ça peut aller très vite, surtout avec Python), le plus dur c'est d'apprendre à programmer et à construire ses programmes.

Mais dans cet ouvrage il ne s'agit pas d'apprendre à programmer en Python ou en Java pour que demain vous puissiez bosser chez IBM ou Google.

Il s'agit d'apprendre la programmation de la simple affectation de valeur à une variable à l'écriture et l'analyse d'un sous-ensemble de C et de Scheme.

Ce que l'on apprend dans cet ouvrage est utile quand on fait du Python ou du Java.

De toute manière le plus n'est pas d'apprendre un langage particulier (ça peut aller très vite, surtout avec Python), le plus dur c'est d'apprendre à programmer et à construire ses programmes.

C'est du papier chez Ellipses :

http://editions-ellipses.fr/fiche_detaille.asp?identite=7515

Droit d'auteur français "classique".

Pour le nom "Dr Racket" ?

J'ai oublié de préciser, au cas où, Dr Racket, anciennement PLT Scheme, est une implémentation très "populaire" de Scheme, "batteries included", orienté recherche et enseignement.

Non, pas du tout ! Je suis un simple amateur de Scheme.

Maintenant, se faire lyncher alors que je les remercie et exprime mon contentement sur la futur roadmap qui me permettra de contribuer a ce projet je comprends pas trop mais bon.

Vous avez bien eu raison de me moinsser. Ayant mal lu l'article, je n'avais pas fait attention au fait que la réécriture du noyau du projet en C faisait partie de la roadmap.

Lisant votre message j'avais simplement eu l'impression que vous demandiez cette réécriture parce que ça vous arrange pas python. Alors je me suis torché d'un petit commentaire visant à faire ressortir le ridicule de la demande (ce qui n'était, il faut l'avouer, pas très charitable).

Puisque c'est moi qui me suis trompé, c'est moi qui suis ridicule ;)

Ouais, merci, et vivement une réécriture de la future version en C en Scheme, parce que franchement... python je n'y arrive pas (à quoi en fait ?).

Ah, s'il-vous-plait : une réécriture avec l'implémentation Racket, ou Guile, parce que Bigloo c'est sympa, mais c'est du java, et java non plus je n'y arrive pas !

(et puis il parait que Java c'est pas top pour les photos et les vidéos porno)

C'est assez drôle l'arrivée de GNOME 3, on retrouve à peu près la même ambiance que lors de l'arrivée de KDE 4.0...

Bah, dans un an les choses se seront tassées, les technos auront été polies et tout le monde se fera gentiment la bise.

Vous mélangez tout, et le plus drôle c'est que lorsque vous traitez réellement du sujet de votre interlocuteur c'est pour lui donner raison !

DCOP etait trop KDE oriente du coup cela a ete CORBA avec le succes que l'on connait

Il y a de quoi rire aussi :

Et niveau protocole ils ont aussi pris les icones

Tout le reste de votre discours consiste à dire pourquoi vous n'aimez pas la manière dont les devs de GNOME conçoivent GNOME. C'est bien, mais ça n'est pas le sujet !

KDE reprendre des trucs de GNOME ? C'est bien, mais ça n'est pas le sujet !

Le sujet est : qu'est-ce qu'une spécification et comment les projets KDE et GNOME se situent par rapport à la réalisation d'une specs.

En gros mon impression est celle-ci : GNOME a une approche specs, on intègre ce qui vient de chez nous (normal) ou les trucs freedesktop. KDE a une approche "pratique" : on intègre ce qui fonctionne, y compris si c'est un truc GNOME, mais on est incapable de faire une spec car on est persuadé que cela consiste uniquement à proposer un truc fonctionnel et tout prêt, qu'il soit ou non dépendant de toutes les libs KDE.

Canonical a une approche semblable à celle de KDE : "Quoi ? On propose un truc qui fonctionne et vous refusez, c'est inacceptable !"

Jusqu'à preuve du contraire le projet GNOME a encore le droit de choisir ce que son environnement intègrera "officiellement". Pour ceux qui veulent appindicator, il suffit d'installer la lib et d'utiliser les logiciels qui l'utilise, mêmes les applis GNOME ne manquent et je ne crois pas que le projet GNOME voit cela d'un mauvais œeil.

Les "nazis" de l'interface ne sont pas ceux que l'on croit. Certes le projet GNOME est très circonspect quand il s'agit d'intégrer des fonctionnalités nouvelles à son bureau mais au moins il n'a jamais dit à la communauté KDE la manière dont elle devait gérer leur projet...

Chesterton disait :

"Trop de capitalisme ne signifie pas trop de capitalistes, mais pas assez."

Merci !

Oui, c'est à peu près ça.

En fait ce qui m'étonne dans ce fil c'est que le CPAN soit si peu connu alors qu'il est une sorte de pilier du monde libre. Qu'on aime ou non Perl, le CPAN a influencé énormément de projets, dont, par exemple le CTAN le LaTeX.

Je n'ai pas précisé ce qu'était le CPAN car je pensais sincèrement que les lecteurs de linuxfr le connaissaient, comme on s'attend à ce qu'ils connaissent KDE, Python ou X11.

Lyx 2.0 est-il garanti sans fuites ?

Car avec un wiki de ce nom là, wiki.lyx, on est en droit de se poser la question...

Quoi ?

Ok. -----> []

Un "living standard" c'est osé, c'est fun, c'est du bon sens pratique (concernant HTML).

Si cela peut dynamiser le W3C, alléluia !

Les flasheux ne pourront plus venir dire qu'il faut 20 ans pour voir apparaître une nouvelle version d'HTML.

Les commerciaux ne pourront plus venir nous saouler avec des "HTML5/6/7 powered" criés à tort et à travers.

Les archives officielles proposées par Mozilla fonctionnent aussi très bien ;)

Surtout depuis que l'installation d'un plugin pour Mozilla via le gestionnaire de paquet (je parle de Debian là) est reconnue lorsque l'on utilise une archive officielle installée dans son répertoire personnel !

Ce qui n'était pas le cas il y a quelque temps. Si quelqu'un peut m'expliquer le pourquoi de la chose, je suis preneur :)

Il faut également ajouter qu'il existe sur Linux plein d'alternatives très légères pour ce "vieux" matériel. Que ce soit en navigateurs web, en gestionnaires de fenêtres, ou n'importe quoi d'autre.

"Evidemment, le problème qu'il y aura si des applications Qt sont livrés avec Ubuntu par défaut, c'est le "look and feel". Ca demandera encore du travail pour qu'on ne puisse pas différencier entre une application écrite en Qt et une application GTK. Mais ça devrait être possible."

Le "thème" GTK de QT4 reproduit parfaitement GTK, jusqu'à permettre l'appel du gestionnaire de fichiers de GTK lorsqu'on ouvre un fichier à partir d'une telle application dans un environnement GNOME.

L'intégration est DÉJÀ quasiment parfaite en terme de Look.

Il reste le "feel"...

Ah oui, Rainbow Island est une tuerie !

J'y ai joué pendant des heures sur mon Amiga 500, et je me suis pas mal éclaté dessus avec la version arcade (MAME...).

Univers très enfantin sympathique, gameplay grandiose. Un must !

À l'époque où je jouais sur Amiga Rodland m'avait fait la même impression. Rodland est une sorte de clone de Bubble Bobble, et Bubble Bobble c'est... l'ancêtre de Rainbow Island !

C'est vraiment un langage qu'il faut que j'essaie Haskell, ça fait un bout de temps qu'il me fait de l'œil mais que je n'ose pas l'approcher :D

Perl est le COBOL des langages de scripts

Mouarf !

Il faudrait déjà savoir ce qu'est un "langage de scripts" pour pouvoir dire ce genre de chose ;)

Si par langage de scripts il faut entendre : "langage conçu pour réaliser de petits programmes servant de glu entre différents programmes".

Alors soit Perl n'est pas un langage de scripts, car il sait faire bien plus que cela, soit il en est un mais alors TOUS les langages de programmation sont des langages de scripts.

Il est vrai que Perl est un excellent langage de progra généraliste, mais est également une très bonne glu ;)

Ce qu'il y a d'extraordinaire avec Perl ce sont les clichés qu'il trimballe.

Tout le monde que Perl c'est illisible, donc Perl est illisible. (sur ce point il est ex-æquo avec ce pauvre LISP qui dispose pourtant de la syntaxe la plus simple qui soit)

Tout le monde dit que Perl c'est un truc fait pour faire des petits scripts auxquels qu'on ne retouche jamais, donc on le répète.

Bien souvent, ceux qui répètent ces âneries n'ont jamais touchés sérieusement à Perl.

La vérité c'est que la communauté Perl a mis en place des "bonnes pratiques" depuis longtemps. Les idiomes sont connus. Faire du Perl "maintenable" et lisible (pour quelqu'un qui connaît un peu le langage évidemment), c'est FACILE.

Dernièrement est sorti un français un petit ouvrage qui s'intitule Perl Moderne, ça devrait dépoussiérer le cerveau de nombre de lecteurs de nombreux clichés.

Je préfère des langages où il n'y a pas 36000 façons de faire une chose.

Là oui, c'est un vrai argument.

On compare dans ce domaine deux langages : Python et Perl. On a bien raison, ils sont sur ce point réellement antagonistes.

Perl est un langage conçu pour pouvoir être parlé de diverses manières, un peu comme une langue vivante. Il y a le langage familier, grossier, ordurier, noble, technique etc.

Python est langage conçu pour n'être parlé que d'une manière. Un peu comme les langues mortes encore utilisée dans des cadres très spécifiques.

Ainsi en Perl quasiment TOUT est réellement possible : programmation objet (divers modèles de OO), programmation fonctionnelle, orientée aspect programmation en latin ;) etc. Tout de diverses manières.

En Python, il faut se limiter aux choix de GvR :

GvR n'aime pas la progra concurrente ? Hop un GIL !

GvR n'aime pas les récursions terminales ? Zou, à la trappe :)

GvR ne croit pas en la progra fonctionnelle ?

Etc. etc,

Perl et Python sont vraiment des langages de caractère, c'est certains ;)

Entre un langage qui offre les moyens de faire ce que l'on veut de diverses manières et un autre qui vous impose les convictions de son concepteur, il y a sans doute de nombreux intermédiaires.

Mais une chose est certaine, ces deux langages là ont leur caractère ;)

P.S. : j'ai coutume de dire que Python pourrait très bien être un sous-ensemble de Perl...

Oui, ainsi que la possibilité d'utiliser le typage statique, les minilangages, ou les jonctions.

C'est vraiment un langage étonnant !

Je suis en train de le découvrir avec le calendrier de l'Avent Perl6 : https://perl6advent.wordpress.com

Il y a des choses bien pratiques comme ce système très simple de création d'arguments pour des programmes "en ligne de commande" (je reprends les exemples de perl6advent ) :


$ cat add.pl
sub MAIN($x, $y) {
say $x + $y
}
$ perl6 add.pl 3 4
7
$ perl6 add.pl too many arguments
Usage:
add.pl x y


Et des choses très amusantes comme l'opérateur de séquence :


> my @Fibonacci := 0, 1, * + * ... *; 1;
1
> @Fibonacci ...^ * > 10000
0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765
> @Fibonacci[30]
832040


Et plein d'autres trucs bien évidemment.

Merci ! C'est l'occasion de tester Perl 6 ;)

Ni sur leretourdesanticlericaux.com ;)

Ca doit sans doute te faire le même effet que lorsque j'entends parler d'affacturage à forfait ou de chalandage de formes d'audit :D