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...
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
tg
Emmanuel Florac 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
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é ?
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
Jérémy JUST
Le 10 Jul 2006 21:07:19 +0200,
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
Le 10 Jul 2006 21:07:19 +0200,
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).
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
Stéphane Zuckerman
On Mon, 10 Jul 2006, wrote:
Stéphane Zuckerman 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:
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)
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)
Stéphane Zuckerman
On Mon, 10 Jul 2006, 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)
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)
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)
Miguel Moquillon
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
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...
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
Patrice Karatchentzeff
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_...
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_...
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_...
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
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.
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
Patrice Karatchentzeff
writes:
Stéphane Zuckerman 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...
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...
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...
