J'ai entre-aperçu un gros bouquin sur le noyau linux. Pas
le temps (ni la compétence) de m'en faire une idée en le
feuilletant avec le gras du pouce.

Que conseillerez-vous comme lecture ?

Autre conseil (hors charte et dans le désert mais comme le
groupe idoine n'est pas très fourni non plus) : j'ai vu, pour
une somme d'un fort beau gabarit :

"L'art de Prolog", L. Sterling (ça ne s'invente pas !) & Shapiro,
chez Masson. Une critique dit que c'est pour les nerds, une autre
est plus "soins palliatifs" (chez Amazon). Si quelqu'un l'a lu...

costaclt

tg@Slack.Slack13.org a écrit :

> "L'art de Prolog", L. Sterling (ça ne s'invente pas !) & Shapiro,
> chez Masson. Une critique dit que c'est pour les nerds, une autre
> est plus "soins palliatifs" (chez Amazon). Si quelqu'un l'a lu...

Si mes souvenirs sont bons c'est écrit par les auteurs du langage ;
c'est en tout cas la référence, mais ce n'est certainement pas par là
qu'il faut commencer si on aime apprendre avec des tutoriaux et des
exemples débilitant et qui ne font rien comprendre des causes et des
raisons.

SL <nospam@nospam.com> writes:

> Si mes souvenirs sont bons c'est écrit par les auteurs du langage ;
> c'est en tout cas la référence, mais ce n'est certainement pas par là
> qu'il faut commencer si on aime apprendre avec des tutoriaux et des
> exemples débilitant et qui ne font rien comprendre des causes et des
> raisons.

Donc en gros, c'est bon mais faut attendre la 500eme page pour lancer
la première commande prolog, c'est ça ?

Et la tour d'Hanoï...

costaclt

tg@Slack.Slack13.org a écrit :

>> Si mes souvenirs sont bons c'est écrit par les auteurs du langage ;
>> c'est en tout cas la référence, mais ce n'est certainement pas par
>> là qu'il faut commencer si on aime apprendre avec des tutoriaux et
>> des exemples débilitant et qui ne font rien comprendre des causes
>> et des raisons.
>
> Donc en gros, c'est bon mais faut attendre la 500eme page pour
> lancer la première commande prolog, c'est ça ?

Il y a pas mal d'exemples, mais je m'en souviens pas plus que
ça. C'est surtout que Prolog est justifié pour un type très
particulier de problèmes (notamment le traitement de la langue, mais
pas que), et qu'il faut voir si ça vaut la peine...

tg@Slack.Slack13.org a écrit :

> Et la tour d'Hanoï...

<http://www.csupomona.edu/~jrfisher/www/prolog_tutorial/2_3.html>

SL <nospam@nospam.com> writes:

> Il y a pas mal d'exemples, mais je m'en souviens pas plus que
> ça. C'est surtout que Prolog est justifié pour un type très
> particulier de problèmes (notamment le traitement de la langue, mais
> pas que), et qu'il faut voir si ça vaut la peine...

Prolog a toujours été aussi populaire que lisp ou landru.

costaclt

tg@Slack.Slack13.org a écrit :

> Prolog a toujours été aussi populaire que lisp ou landru.

Pour landru il y a le film de chabrol, tandis que sur Prolog je crois
qu'il a rien fait. C'est dire.

Le Sat, 08 Jul 2006 22:22:08 +0200, tg a écrit:

>
> Prolog a toujours été aussi populaire que lisp ou landru.

Il y a un tutorial sympa sur Perlmonks je crois (pour le module
AI::Prolog). Ovid est un fan de Prolog (un vicieux, certainement).

--
Sutor ne ultra Crepidam.

Le Sat, 08 Jul 2006 16:15:31 +0200, tg a écrit:
> J'ai entre-aperçu un gros bouquin sur le noyau linux. Pas
> le temps (ni la compétence) de m'en faire une idée en le
> feuilletant avec le gras du pouce.

Si tu veux acquérir les bases de tout ce qui est noyal, système
d'exploitation et autres concepts joyeux, je te conseille la lecture du
livre "Système d'exploitation" de Tanenbaum. La traduction française
doit en être à la troisième édition (si mes souvenirs sont bons) et il
doit etre aux editions "Pearson" ou quelque chose dans ce gout là. Ca
permet de voir de la théorie pure avant de passer à la pratique. C'est
clairement indigeste et pas très bien écrit, mais permet ensuite d'avoir
la chance de comprendre les bouquins sur des sujets pointus comme la
programmation noyaux ou le développement de pilotes. Bref, bon courage si
tu choisis de le lire !

On Mon, 10 Jul 2006, Julien wrote:

> Le Sat, 08 Jul 2006 16:15:31 +0200, tg a écrit:
>> J'ai entre-aperçu un gros bouquin sur le noyau linux. Pas
>> le temps (ni la compétence) de m'en faire une idée en le
>> feuilletant avec le gras du pouce.
>
> Si tu veux acquérir les bases de tout ce qui est noyal, système
> d'exploitation et autres concepts joyeux, je te conseille la lecture du
> livre "Système d'exploitation" de Tanenbaum. La traduction française
> doit en être à la troisième édition (si mes souvenirs sont bons) et il
> doit etre aux editions "Pearson" ou quelque chose dans ce gout là. Ca
> permet de voir de la théorie pure avant de passer à la pratique. C'est
> clairement indigeste et pas très bien écrit, mais permet ensuite d'avoir
> la chance de comprendre les bouquins sur des sujets pointus comme la
> programmation noyaux ou le développement de pilotes. Bref, bon courage si
> tu choisis de le lire !


Pour le coup je ne suis pas d'accord. Que ce soit pour les réseaux ou les
SE, je trouve les livres de Tanenbaum extrêmement bien faits. Ils sont
techniques et ne prennent pas le lecteur pour un nul, mais il fait
beaucoup d'efforts pour être compréhensible, et ses exemples sont presque
toujours très imagés.

Sinon, si le "gros bouquin sur le noyau linux" est de chez O'Reilly, je
n'en ai entendu que du bien.

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

SL <nospam@nospam.com> writes:

> tg@Slack.Slack13.org a écrit :
>
> > "L'art de Prolog", L. Sterling (ça ne s'invente pas !) & Shapiro,
> > chez Masson. Une critique dit que c'est pour les nerds, une autre
> > est plus "soins palliatifs" (chez Amazon). Si quelqu'un l'a lu...
>
> Si mes souvenirs sont bons c'est écrit par les auteurs du langage ;

Philippe Roussel et Alain Colmerauer s'en retourneraient dans leurs
tombes, si ils étaient morts.

MB

--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

Stéphane Zuckerman <szuckerm@etu.utc.fr> writes:

> Sinon, si le "gros bouquin sur le noyau linux" est de chez O'Reilly,
> je n'en ai entendu que du bien.

Je me suis un peu trompé question "noyau". En fait, le bouquin feuilleté,
c'est "Programmation système en C sous linux" de C. Blaess.

Quelqu'un a lu ça ?

Sinon, Tannenbaum j'en entends toujours parler, mais je voudrais du
plus simple.

Ahum...

costaclt

Emmanuel Florac <eflorac@imaginet.fr> writes:

> Il y a un tutorial sympa sur Perlmonks je crois (pour le module
> AI::Prolog). Ovid est un fan de Prolog (un vicieux, certainement).

J'aime assez car c'est totalement surprenant. En revanche, je peine
beaucoup questions applicatifs car la doc est assez rare. Je suppose
que ce qu'il y a suffit, mais pour les néophytes des bouquins du
genre "construivez-vous ceci avec le programme machin" sont très
pratiques. On a ça en x exemplaires avec Java, VB, C++ etc.

Dans le registre "le bon outil pour le bon dessein", je me demande
comment font les informaticiens pour parvenir à programmer aussi vite
en adoptant cet adage. C'est qu'on s'embrouille très vite sur des
langages dont la syntaxe est assez proche.

Comme je ne connais que des tâcherons (ils programment en général
uniquement en WinDev - et ne connaissent que ça - ou en Delphi à la
limite), je me suis toujours demandé si les informaticiens utilisant
toujours l'outil le plus adapté existaient vraiment.

Que dire des langages tels que Caml, Python, Ada, Fortran... enfin
toutes ces bestioles dont on entend peu parler (ou de moins en moins
parler). Ont-ils réellement quelque chose de dépassé ?

costaclt

Le 10 Jul 2006 21:07:19 +0200,
tg@Slack.Slack13.org a écrit :

> je me suis toujours demandé si les informaticiens utilisant toujours
> l'outil le plus adapté existaient vraiment.

Généralement, non. Chaque personne utilise couramment deux ou trois
langages et choisit parmi eux pour les différents problèmes.
Il est assez fréquent, aussi, que le langage soit imposé par la
hiérarchie, pour d'obscures raisons (souvent liées aux modes du
moment).


J'ai lu plusieurs fois des conseils comme « apprenez un nouveau
langage par an, pour voir de nouvelles choses ». Mais je ne vois pas
comment c'est applicable: il faut déjà entre deux et cinq ans
d'utilisation quasi-quotidienne pour percevoir l'esprit d'un langage
et développer de façon idiomatique et efficace.


> Que dire des langages tels que Caml, Python, Ada, Fortran... enfin
> toutes ces bestioles dont on entend peu parler (ou de moins en moins
> parler). Ont-ils réellement quelque chose de dépassé ?

Tu vas froisser les utilisateurs de Python et Caml, qui sont des
langages tout à faits actuels et utilisés pour de nouveaux
développements!

Pour Ada, Fortran et Caml, ce sont des langages qui sont
progressivement devenus « hors des modes », dans le sens où,
maintenant, quand on s'en sert, c'est qu'ils offrent un réel avantage
pour le projet, et non que « ça fait tendance ». J'aurais tendance à
dire que Lisp, Prolog, Perl, C et C++ entrent dans cette catégorie.
Ça ne veut pas dire du tout que ces langages font vieux. Au
contraire, c'est qu'ils ont fait leurs preuves et que leurs
utilisateurs ont compris leur positionnement: ils sont mûrs.
Par contre, Python, Java, Ruby sont encore soumis aux modes: ils sont
souvent utilisés juste « parce que ça fait bien ».

À côté de ces exemples, il existe des centaines d'autres langages qui
n'ont pas fait leurs preuves et qui ne sont plus à la mode. On ne parle
même plus d'eux (sauf dans les manuels d'histoire).


--
Jérémy JUST <jeremy_just@netcourrier.com>

On Mon, 10 Jul 2006, tg@Slack.Slack13.org wrote:

> Stéphane Zuckerman <szuckerm@etu.utc.fr> writes:
>
>> Sinon, si le "gros bouquin sur le noyau linux" est de chez O'Reilly,
>> je n'en ai entendu que du bien.
>
> Je me suis un peu trompé question "noyau". En fait, le bouquin feuilleté,
> c'est "Programmation système en C sous linux" de C. Blaess.
>
> Quelqu'un a lu ça ?

Il est tout bonnement excellent, de mon point de vue. Ensuite, s'il faut
vraiment approfondir, les bouquins sur la programmation des IPC et
d'applis réseau pour UNIX de Stevens sont eux aussi très bons.

> Sinon, Tannenbaum j'en entends toujours parler, mais je voudrais du
> plus simple.

Euh. Son bouquin sur les OS (attention, il y en a 2 : l'un qui parle du
fonctionnement, l'autre de la conception) est je trouve super bien foutu :
c'est son bouquin de cours, après tout. J'ai eu l'occasion de comparer
notre Pujolles national et Tanenbaum pour des bouquins sur les réseaux, et
je trouve que lorsque les thèmes abordés sont les mêmes, Tanenbaum est
bien facile à comprendre en première lecture.

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

On Mon, 10 Jul 2006, tg@Slack.Slack13.org wrote:

> Dans le registre "le bon outil pour le bon dessein", je me demande
> comment font les informaticiens pour parvenir à programmer aussi vite
> en adoptant cet adage. C'est qu'on s'embrouille très vite sur des
> langages dont la syntaxe est assez proche.
>
> Comme je ne connais que des tâcherons (ils programment en général
> uniquement en WinDev - et ne connaissent que ça - ou en Delphi à la
> limite), je me suis toujours demandé si les informaticiens utilisant
> toujours l'outil le plus adapté existaient vraiment.
>
> Que dire des langages tels que Caml, Python, Ada, Fortran... enfin
> toutes ces bestioles dont on entend peu parler (ou de moins en moins
> parler). Ont-ils réellement quelque chose de dépassé ?

Je n'ai pas une expérience monstre du milieu de l'entreprise pour le
moment, mais de ce que j'ai vu, lorsqu'on utilise un langage « exotique »
c'est comme pour Linux, mais en pire. Des admins UNIX/Linux on en trouve
assez facilement, alors que des programmeurs ADA, OCAML, ou PROLOG
beaucoup moins. Du coup, lorsqu'on parle de maintenance du code, ça
devient chaud. J'ai oui dire qu'à une époque AutoCAD était prototypé en
LISP avant d'être recodé en C++ - sauf que là, c'est une boite qui vend un
soft, avec a priori des programmeurs qui ont aidé à coder le bouzin, donc
pour la maintenance c'est plus simple.

Quand on parle de fournir un logiciel à une boite, si on lui dit "ouais,
on fait ça en Objective Caml, mais vous inquiétez pas, grâce à ça, on aura
tout un tas de preuves qui font que les bugs seront moins nombreux, etc.",
ce sera peut-être vrai, mais la boite cliente devra trouver ensuite des
gens capables de lire de l'OCaml dans le texte...

Du coup, on est coincé avec C, C++, Java, C# (j'ai l'impression que
Perl/Python n'ont pas trop de problèmes non plus pour se faire utiliser).

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Stéphane Zuckerman wrote:
> Je n'ai pas une expérience monstre du milieu de l'entreprise [...]
Tu n'as peut-être pas d'expériences montres du milieu de l'entreprise, mais
tu as très bien résumé la situation. Le pire est que nous sommes dans un
cercle vicieux:
- les entreprises demandes préfèrent choisir, en terme de compétences, la
masse la plus nombreuse, ce qui lui permet de toujours pouvoir trouver une
personne avec les compétences recherchées et à un prix plus bas (normal, il
y a bcp de monde sur le créneau).
- les étudiants préfèrent suivre les enseignements qui répondent au tendance
du "marché" : ils vont donc participer un peu plus à la masse déjà
existante, donnant ainsi aux entreprises toutes les raisons d'encore plus
préférer les compétences dites de masse, même si ces dernièrent ne
répondent pas efficacement à leur problématique.

=> Le résultat ? Simple, on est entré dans une ère de l'utilitaire : tout ce
qui ne semble pas utile est écarté ! La conséquence ? Un appauvrissement de
la culture générale dans le développement logiciel, déjà que le génie
logiciel en France souffre pas mal...

Miguel

tg@Slack.Slack13.org writes:

[...]

> Que dire des langages tels que Caml, Python, Ada, Fortran... enfin
> toutes ces bestioles dont on entend peu parler (ou de moins en moins
> parler). Ont-ils réellement quelque chose de dépassé ?

Pour Caml (et Python), je dirai la doc chez O'Reilly. La doc de Caml
est d'ailleurs tout à fait symptomatique: après 200 pages dans le
bouquin, écrire un bête « hello world » relève de l'exploit...

Cela n'aide pas à la diffusion... à comparer avec _Introduction à
Perl_...

PK

--
|\_,,,---,,_PatriceKARATCHENTZEFF
ZZZzz/,`.-'`'-.;-;;,_mailto:p.karatchentzeff@free.fr
|,4-))-,_.,\(`'-'http://p.karatchentzeff.free.fr
'---''(_/--'`-'\_)

Stéphane Zuckerman <szuckerm@etu.utc.fr> writes:


> Quand on parle de fournir un logiciel à une boite, si on lui dit
> "ouais, on fait ça en Objective Caml, mais vous inquiétez pas, grâce à
> ça, on aura tout un tas de preuves qui font que les bugs seront moins
> nombreux, etc.", ce sera peut-être vrai, mais la boite cliente devra
> trouver ensuite des gens capables de lire de l'OCaml dans le texte...

Si je comprends bien, un informaticien a toutes les raisons du monde
(pour se rendre indispensable) de proposer une programmation dans
un langage ésotérique quand le client est naïf.

costaclt

tg@Slack.Slack13.org writes:

> Stéphane Zuckerman <szuckerm@etu.utc.fr> writes:
>
>
>> Quand on parle de fournir un logiciel à une boite, si on lui dit
>> "ouais, on fait ça en Objective Caml, mais vous inquiétez pas, grâce à
>> ça, on aura tout un tas de preuves qui font que les bugs seront moins
>> nombreux, etc.", ce sera peut-être vrai, mais la boite cliente devra
>> trouver ensuite des gens capables de lire de l'OCaml dans le texte...
>
> Si je comprends bien, un informaticien a toutes les raisons du monde
> (pour se rendre indispensable) de proposer une programmation dans
> un langage ésotérique quand le client est naïf.

La meilleure méthode consiste encore de ne pas livrer ses sources...

PK

--
|\_,,,---,,_PatriceKARATCHENTZEFF
ZZZzz/,`.-'`'-.;-;;,_mailto:p.karatchentzeff@free.fr
|,4-))-,_.,\(`'-'http://p.karatchentzeff.free.fr
'---''(_/--'`-'\_)

Patrice Karatchentzeff <p.karatchentzeff@free.fr> writes:

> La meilleure méthode consiste encore de ne pas livrer ses sources...

Ou donner ses sources en Objective caml...

costaclt

Stéphane Zuckerman <szuckerm@etu.utc.fr> writes:

> > c'est "Programmation système en C sous linux" de C. Blaess.

> Il est tout bonnement excellent, de mon point de vue. Ensuite, s'il
> faut vraiment approfondir, les bouquins sur la programmation des IPC
> et d'applis réseau pour UNIX de Stevens sont eux aussi très bons.

Ah, je viens de le recevoir aujourd'hui. Heureusement que je disposais
d'un chariot élévateur pour le déplacer.

> foutu : c'est son bouquin de cours, après tout. J'ai eu l'occasion de
> comparer notre Pujolles national et Tanenbaum pour des bouquins sur
> les réseaux, et je trouve que lorsque les thèmes abordés sont les
> mêmes, Tanenbaum est bien facile à comprendre en première lecture.

Ca à l'air alléchant. Quelle misère qu'il y ait autant de si bons livres !

costaclt

Michel Billaud a écrit :
> SL <nospam@nospam.com> writes:
>
>> tg@Slack.Slack13.org a écrit :
>>
>> > "L'art de Prolog", L. Sterling (ça ne s'invente pas !) & Shapiro,
>> > chez Masson. Une critique dit que c'est pour les nerds, une autre
>> > est plus "soins palliatifs" (chez Amazon). Si quelqu'un l'a lu...
>>
>> Si mes souvenirs sont bons c'est écrit par les auteurs du langage ;
>
> Philippe Roussel et Alain Colmerauer s'en retourneraient dans leurs
> tombes, si ils étaient morts.

Zut, c'est ça. Merci d'avoir corrigé.

tg@slack.slack13.org wrote:
>
> Ca à l'air alléchant. Quelle misère qu'il y ait autant de si bons livres !

Il y a très peu de très bon livres. Tannenbaum en est un. Stevens est la bible
absolue de la programmation sous Unix. Pour la description d'un OS Unix au bon
niveau d'abstraction il n'y a qu'un seul bon livre,
The Design and Implementation of the 4.4 BSD UNIX Operating System. ...
LEFFLER,S.,MC KUSICK, MK, KARELS, MJ, AND QUATERMAN
il a été mis à jour pour FreeBSD-5, mais je trouve la nouvelle version moins
percutante.
Pour les algorithmes, il y a Princeton ou MIT, c'est à dire Sedgewick ou
Cormen, Leiserson, Rivest et Stein, plus des choses spécialisées par exemple
sur la compilation Aho, Sethi, Ullman Principles of Compiler Design.
Il me semble que ce sont les livres qui sont généralement recommandés tant
dans l'enseignement français qu'étranger.

>
> costaclt

--

Michel TALON

On Sat, 15 Jul 2006, Michel Talon wrote:

> tg@slack.slack13.org wrote:
>>
>> Ca à l'air alléchant. Quelle misère qu'il y ait autant de si bons livres !
>
> Il y a très peu de très bon livres. Tannenbaum en est un. Stevens est la bible
> absolue de la programmation sous Unix. Pour la description d'un OS Unix au bon
> niveau d'abstraction il n'y a qu'un seul bon livre,
> The Design and Implementation of the 4.4 BSD UNIX Operating System. ...
> LEFFLER,S.,MC KUSICK, MK, KARELS, MJ, AND QUATERMAN
> il a été mis à jour pour FreeBSD-5, mais je trouve la nouvelle version moins
> percutante.
> Pour les algorithmes, il y a Princeton ou MIT, c'est à dire Sedgewick ou
> Cormen, Leiserson, Rivest et Stein, plus des choses spécialisées par exemple
> sur la compilation Aho, Sethi, Ullman Principles of Compiler Design.
> Il me semble que ce sont les livres qui sont généralement recommandés tant
> dans l'enseignement français qu'étranger.
>

C'est vrai, tant qu'on reste dans un domaine assez généraliste (l'intro à
l'algo par exemple est très bien pour un niveau licence/master, et surtout
elle permet de voir comment faire les preuves d'algo). Les Sedgewick
permettent d'aller plus loin. Mais par contre, dès qu'on veut entrer dans
des domaines spécifiques de l'algo, il existe tout un tas de livres
relativement minces et assez chers (une bonne partie éditée chez
Springer).

Pour la compilation oui, le dragon book est la bible, mais est un peu
daté, et du coup, même si une grande partie de ce qui est dit dedans reste
vraie, il faut lui adjoindre un autre bouquin (« Advanced Compiler Design
and Implementation » de Muchnick, et « Optimizing Compilers for Modern
Architectures: A Dependence-based Approach » de Allen & Kennedy sont
d'excellents exemples). Mais là encore, c'est dans une optique
d'approfondissement.

Tout dépend du niveau qu'on cherche je suppose (pour ce qui est des
bouquins parlant de dissémination de l'information, il y a d'excellents
livres chez Springer... et du coup vraiment pas accessibles :-/).

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)