On voit souvent des "quel linux choisir ?", des "pourquoi linux ?" etc.
Mais finalement à devoir choisir entre la peste (du côté de chez MS) et
la grippe (notre bon vieux nunux), celà ne vous arrive pas le matin en
vous réveillant de vous dire que les programmes qui font fonctionner
votre machines ne sont que des bidouillages plus ou moins réussis ?
Regardez les codes sources d'un programme en C. Même le code d'un bon
programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi
cette abomination de la programmation ? Il n'y a aucune sémantique
valable là derrière. D'ailleurs les types en C n'ont de type que le nom.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de
10 éléments. Ce langage surestime beaucoup les capacités des personnes
qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment
imaginer que ce genre de choses peut être voulu par le programmeur ?
Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber cet
emboîtement de new, cette masse colossale de classes à faire pour faire
trois fois rien ! J'ose même pas imaginer la quantité de calculs
inutiles faits par la machine pour gérer ces merdes. D'accord il y a de
l'optimisation, mais c'est loin d'être suffisant.
Dans le temps les programmes étaient bidouillés parce qu'il n'y avait
pas assez de mémoire : par exemple on utilisait une variable pour
stocker deux informations. Maintenant l'horreur est à l'autre extrême :
on a tellement de mémoire de disponible que l'on utilise trop. En C :
tant pis c'est perdu. Un trou de mémoire ? Tant que le pc doit pas
redémarrer toutes les heures à cause de ça on s'en fout. En JAVA : il y
a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette
ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
On en vient à une époque où on trouve acceptable un programme quand il a
moins de cent bugs alors que rien que le fait de consommer trop de
ressources fait que le programme n'est pas bon. Aujourd'hui on nous
parle de .NET et de merdouilles dans le genre. A quoi ça sert de se
lancer dans la création de langages qui se copient les uns les autres.
C, C++, JAVA, Pascal : c'est la même chose, la même façon de penser. Et
c'est une manière de penser qui pousse à faire des fautes.
Bref l'informatique ne va pas fort.
l'hermaphrodisme supposé des marmottes d'Outre Quiévrain, c'est plus
Que vient faire Naibed dans ce troll ?
-- _/°< "fermez pas la porte, j'arrive."
nicolas vigier
On 2005-03-09, Tom wrote:
Hu ? Un type en C sert à déterminer la signification que l'on prête à une valeur. Comment se fait il alors qu'on puisse ajouter un entier à un caractère ?
Qu'on puisse diviser un void par une chaine de caractères ? Ca a une sémantique cohérente cette chose ? Non.
Ca s'appelle un langage bas niveau.
On ne peut pas. cf plus haut. Ne pas confondre le tableau et la représentation mentale
que l'on a du tableau. A moins qu'il y a unsuper patch magique qui nous empêche le fameux segmentation fault que nous adorons tous.
C'est un langage qui fait confiance au programmeur, nuance !
Il ne devrait pas. Mon Gaim qui plante est d'accord avec moi. Pourtant ça doit pas être un mauvais programmeur celui qui l'a fait je suppose. C'est cette confiance qui fait que Debian doit sortir une version Stable, une Testing et une Unstable ?
C'est vrai qu'avec des programmes entierement ecrits en caml, tout serait different. Il suffit de regarder mldonkey, pour lequel on se demande pourquoi ils ont creer une mailling list mldonkey-bugs : http://lists.nongnu.org/mailman/listinfo/mldonkey-bugs A peine une centaine de messages par mois, ca doit surement etre pour dire qu'en Caml, il n'y a pas de bugs possibles.
Oui, mais s'ils sont compliqués c'est qu'il font des choses compliquées.
Pas forcément. C'est là que ça devient grâve. Regardez un Hello World en Java : je dois rire ou pleurer ?
Oui, ca fait quelques lignes. Et ? C'est sur, si tu veux te contenter d'un HelloWorld, Java est pas forcement le langage le plus adapte.
le reste il faut prouver.
Est ce que tu as deja essaie de prouver un programme qui fait autre chose qu'un hello world ?
Bref l'informatique ne va pas fort. Mais si, mais si.
Tout va bien dans le meilleur des mondes. Dans combien de temps vous viendrez pleurer ? Dans cinquante ans ?
Toi aussi t'es comme luc2 ? Le sauveur qui vient nous sauver de cet abominable piege qu'est le C ?
Hu ? Un type en C sert à déterminer la signification que l'on prête à
une valeur.
Comment se fait il alors qu'on puisse ajouter un entier à un caractère ?
Qu'on puisse diviser un void par une chaine de caractères ? Ca a une
sémantique cohérente cette chose ? Non.
Ca s'appelle un langage bas niveau.
On ne peut pas.
cf plus haut. Ne pas confondre le tableau et la représentation mentale
que l'on a du tableau. A moins qu'il y a unsuper patch magique qui nous
empêche le fameux segmentation fault que nous adorons tous.
C'est un langage qui fait confiance au programmeur, nuance !
Il ne devrait pas. Mon Gaim qui plante est d'accord avec moi. Pourtant
ça doit pas être un mauvais programmeur celui qui l'a fait je suppose.
C'est cette confiance qui fait que Debian doit sortir une version
Stable, une Testing et une Unstable ?
C'est vrai qu'avec des programmes entierement ecrits en caml, tout serait
different. Il suffit de regarder mldonkey, pour lequel on se demande
pourquoi ils ont creer une mailling list mldonkey-bugs :
http://lists.nongnu.org/mailman/listinfo/mldonkey-bugs
A peine une centaine de messages par mois, ca doit surement etre pour
dire qu'en Caml, il n'y a pas de bugs possibles.
Oui, mais s'ils sont compliqués c'est qu'il font des choses compliquées.
Pas forcément. C'est là que ça devient grâve. Regardez un Hello World en
Java : je dois rire ou pleurer ?
Oui, ca fait quelques lignes. Et ? C'est sur, si tu veux te contenter
d'un HelloWorld, Java est pas forcement le langage le plus adapte.
le reste il faut prouver.
Est ce que tu as deja essaie de prouver un programme qui fait autre
chose qu'un hello world ?
Bref l'informatique ne va pas fort.
Mais si, mais si.
Tout va bien dans le meilleur des mondes. Dans combien de temps vous
viendrez pleurer ? Dans cinquante ans ?
Toi aussi t'es comme luc2 ? Le sauveur qui vient nous sauver de cet
abominable piege qu'est le C ?
Hu ? Un type en C sert à déterminer la signification que l'on prête à une valeur. Comment se fait il alors qu'on puisse ajouter un entier à un caractère ?
Qu'on puisse diviser un void par une chaine de caractères ? Ca a une sémantique cohérente cette chose ? Non.
Ca s'appelle un langage bas niveau.
On ne peut pas. cf plus haut. Ne pas confondre le tableau et la représentation mentale
que l'on a du tableau. A moins qu'il y a unsuper patch magique qui nous empêche le fameux segmentation fault que nous adorons tous.
C'est un langage qui fait confiance au programmeur, nuance !
Il ne devrait pas. Mon Gaim qui plante est d'accord avec moi. Pourtant ça doit pas être un mauvais programmeur celui qui l'a fait je suppose. C'est cette confiance qui fait que Debian doit sortir une version Stable, une Testing et une Unstable ?
C'est vrai qu'avec des programmes entierement ecrits en caml, tout serait different. Il suffit de regarder mldonkey, pour lequel on se demande pourquoi ils ont creer une mailling list mldonkey-bugs : http://lists.nongnu.org/mailman/listinfo/mldonkey-bugs A peine une centaine de messages par mois, ca doit surement etre pour dire qu'en Caml, il n'y a pas de bugs possibles.
Oui, mais s'ils sont compliqués c'est qu'il font des choses compliquées.
Pas forcément. C'est là que ça devient grâve. Regardez un Hello World en Java : je dois rire ou pleurer ?
Oui, ca fait quelques lignes. Et ? C'est sur, si tu veux te contenter d'un HelloWorld, Java est pas forcement le langage le plus adapte.
le reste il faut prouver.
Est ce que tu as deja essaie de prouver un programme qui fait autre chose qu'un hello world ?
Bref l'informatique ne va pas fort. Mais si, mais si.
Tout va bien dans le meilleur des mondes. Dans combien de temps vous viendrez pleurer ? Dans cinquante ans ?
Toi aussi t'es comme luc2 ? Le sauveur qui vient nous sauver de cet abominable piege qu'est le C ?
Ben, il faut arrêter les trucs d'il y a vingt ans.
Faut arrêter le C dans ce cas parce que c'était déjà vieux il y a vingt ans.
La dernière norme date de 1999. Elle est suffisamment vieille pour être utilisable et suffisament récente pour ne pas faire du langage C un langage désuet.
-- Richard
Ben, il faut arrêter les trucs d'il y a vingt ans.
Faut arrêter le C dans ce cas parce que c'était déjà vieux il y a vingt
ans.
La dernière norme date de 1999. Elle est suffisamment vieille pour être
utilisable et suffisament récente pour ne pas faire du langage C un
langage désuet.
Ben, il faut arrêter les trucs d'il y a vingt ans.
Faut arrêter le C dans ce cas parce que c'était déjà vieux il y a vingt ans.
La dernière norme date de 1999. Elle est suffisamment vieille pour être utilisable et suffisament récente pour ne pas faire du langage C un langage désuet.
-- Richard
Richard Delorme
Ça ne s'adresse donc pas à moi, puisque je ne l'affirme pas _péremptoirement_, mais en connaissance de cause, et avec la réserve de rigueur du fait de respecter la norme.
Compilez Visual C++ sur Linux. Je suis curieux de voir à quel point il est portable.
La portabilité est une possibilité, pas une obligation. En C ou en C++, on peut écrire aussi du code non portable si on le souhaite.
-- Richard
Ça ne s'adresse donc pas à moi, puisque je ne l'affirme pas
_péremptoirement_, mais en connaissance de cause, et avec la réserve de
rigueur du fait de respecter la norme.
Compilez Visual C++ sur Linux. Je suis curieux de voir à quel point il
est portable.
La portabilité est une possibilité, pas une obligation. En C ou en C++,
on peut écrire aussi du code non portable si on le souhaite.
Ça ne s'adresse donc pas à moi, puisque je ne l'affirme pas _péremptoirement_, mais en connaissance de cause, et avec la réserve de rigueur du fait de respecter la norme.
Compilez Visual C++ sur Linux. Je suis curieux de voir à quel point il est portable.
La portabilité est une possibilité, pas une obligation. En C ou en C++, on peut écrire aussi du code non portable si on le souhaite.
-- Richard
Richard Delorme
Contrairement à ce que l'on croit, la portabilité d'un langage est uniquement déterminée par la qualité de sa spécification. Un langage d'assemblage est portable car sa sémantique est univoque, alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la portabilité du langage sur des architectures très différentes.
???
Vous rendez-vous compte de ce que vous dites ?
Oui et je maintiens. D'après le rationale, qui explique les intentions de la norme du langage, les comportements indéfinis sont bien là pour facilité les implémentations :
http://www.lysator.liu.se/c/rat/a.html#1-6
« The terms unspecified behavior, undefined behavior, and implementation-defined behavior are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits quality of implementation to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of conformance to the Standard. Appendix F to the Standard catalogs those behaviors which fall into one of these three categories.
Unspecified behavior gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program.
Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior.
Implementation-defined behavior gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response. »
Le résultat est que qu'il existe des compilateurs C pour presque tout ce qui a un processeur, ce qui est loin d'être le cas pour les autres langages.
L'existence d'un compilateur sur chaque machine existante ne rend pas un langage plus portable, sinon tout est portable : il suffit d'en faire un compilateur.
Il y a un problème de faisabilité. Les comportements indéfinis sont là pour rendre le portage faisable. Par exemple Java n'a aucun comportement indéfini mais existe sur très peu d'architectures, et n'existera jamais pour MS-DOS, par exemple.
Le C n'est pas portable car ce n'est pas un langage déterministe.
Un programme strictement conforme (sans comportement indéfini) est déterministe. La portabilité en C est possible, elle n'est pas obligatoire.
N'importe quel l'angage d'assemblage est plus portable que le C car ils sont déterministes : toute implémentation suivant les spécifications donne les mêmes résultats. C'est ça la portabilité, pas ces pseudos-arguments de marchands de soupe qui veulent nous faire croire que c'est le plus populaire qui l'emporte.
Je le répète, cette portabilité existe en C.
-- Richard
Contrairement à ce que l'on croit, la portabilité d'un langage est
uniquement déterminée par la qualité de sa spécification. Un
langage d'assemblage est portable car sa sémantique est univoque,
alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment
péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la
portabilité du langage sur des architectures très différentes.
???
Vous rendez-vous compte de ce que vous dites ?
Oui et je maintiens. D'après le rationale, qui explique les intentions
de la norme du langage, les comportements indéfinis sont bien là pour
facilité les implémentations :
http://www.lysator.liu.se/c/rat/a.html#1-6
« The terms unspecified behavior, undefined behavior, and
implementation-defined behavior are used to categorize the result of
writing programs whose properties the Standard does not, or cannot,
completely describe. The goal of adopting this categorization is to
allow a certain variety among implementations which permits quality of
implementation to be an active force in the marketplace as well as to
allow certain popular extensions, without removing the cachet of
conformance to the Standard. Appendix F to the Standard catalogs those
behaviors which fall into one of these three categories.
Unspecified behavior gives the implementor some latitude in translating
programs. This latitude does not extend as far as failing to translate
the program.
Undefined behavior gives the implementor license not to catch certain
program errors that are difficult to diagnose. It also identifies areas
of possible conforming language extension: the implementor may augment
the language by providing a definition of the officially undefined
behavior.
Implementation-defined behavior gives an implementor the freedom to
choose the appropriate approach, but requires that this choice be
explained to the user. Behaviors designated as implementation-defined
are generally those in which a user could make meaningful coding
decisions based on the implementation definition. Implementors should
bear in mind this criterion when deciding how extensive an
implementation definition ought to be. As with unspecified behavior,
simply failing to translate the source containing the
implementation-defined behavior is not an adequate response. »
Le résultat est que qu'il existe des compilateurs C pour presque tout
ce qui a un processeur, ce qui est loin d'être le cas pour les autres
langages.
L'existence d'un compilateur sur chaque machine existante ne rend pas un
langage plus portable, sinon tout est portable : il suffit d'en faire un
compilateur.
Il y a un problème de faisabilité. Les comportements indéfinis sont là
pour rendre le portage faisable. Par exemple Java n'a aucun comportement
indéfini mais existe sur très peu d'architectures, et n'existera jamais
pour MS-DOS, par exemple.
Le C n'est pas portable car ce n'est pas un langage déterministe.
Un programme strictement conforme (sans comportement indéfini) est
déterministe. La portabilité en C est possible, elle n'est pas obligatoire.
N'importe quel l'angage d'assemblage est plus portable que le C car ils
sont déterministes : toute implémentation suivant les spécifications
donne les mêmes résultats. C'est ça la portabilité, pas ces
pseudos-arguments de marchands de soupe qui veulent nous faire croire
que c'est le plus populaire qui l'emporte.
Contrairement à ce que l'on croit, la portabilité d'un langage est uniquement déterminée par la qualité de sa spécification. Un langage d'assemblage est portable car sa sémantique est univoque, alors que la liste des « undefined behaviors » du C fait 20 pages.
Permettez-moi donc de traiter de con tout ceux qui affirment péremptoirement que le C est portable.
Justement, les comportements indéfinis sont là pour faciliter la portabilité du langage sur des architectures très différentes.
???
Vous rendez-vous compte de ce que vous dites ?
Oui et je maintiens. D'après le rationale, qui explique les intentions de la norme du langage, les comportements indéfinis sont bien là pour facilité les implémentations :
http://www.lysator.liu.se/c/rat/a.html#1-6
« The terms unspecified behavior, undefined behavior, and implementation-defined behavior are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits quality of implementation to be an active force in the marketplace as well as to allow certain popular extensions, without removing the cachet of conformance to the Standard. Appendix F to the Standard catalogs those behaviors which fall into one of these three categories.
Unspecified behavior gives the implementor some latitude in translating programs. This latitude does not extend as far as failing to translate the program.
Undefined behavior gives the implementor license not to catch certain program errors that are difficult to diagnose. It also identifies areas of possible conforming language extension: the implementor may augment the language by providing a definition of the officially undefined behavior.
Implementation-defined behavior gives an implementor the freedom to choose the appropriate approach, but requires that this choice be explained to the user. Behaviors designated as implementation-defined are generally those in which a user could make meaningful coding decisions based on the implementation definition. Implementors should bear in mind this criterion when deciding how extensive an implementation definition ought to be. As with unspecified behavior, simply failing to translate the source containing the implementation-defined behavior is not an adequate response. »
Le résultat est que qu'il existe des compilateurs C pour presque tout ce qui a un processeur, ce qui est loin d'être le cas pour les autres langages.
L'existence d'un compilateur sur chaque machine existante ne rend pas un langage plus portable, sinon tout est portable : il suffit d'en faire un compilateur.
Il y a un problème de faisabilité. Les comportements indéfinis sont là pour rendre le portage faisable. Par exemple Java n'a aucun comportement indéfini mais existe sur très peu d'architectures, et n'existera jamais pour MS-DOS, par exemple.
Le C n'est pas portable car ce n'est pas un langage déterministe.
Un programme strictement conforme (sans comportement indéfini) est déterministe. La portabilité en C est possible, elle n'est pas obligatoire.
N'importe quel l'angage d'assemblage est plus portable que le C car ils sont déterministes : toute implémentation suivant les spécifications donne les mêmes résultats. C'est ça la portabilité, pas ces pseudos-arguments de marchands de soupe qui veulent nous faire croire que c'est le plus populaire qui l'emporte.
Je le répète, cette portabilité existe en C.
-- Richard
d4rk
Tom wrote:
Le C n'est peut-être pas parfait, évidemment, mais on peut _tout_ faire avec, y compris des erreurs, mais c'est le prix à payer je pense.
Prix bien trop cher. Si on veut faire quelque chose on le fait bien ou on ne le fait pas.
Tom
Si on veut faire qq chose, on le fait bien, je suis d'accord. Mais je ne vois pas trop le problème: quand on commence à coder, on ne pense pas "tiens je vais faire un programme mais je ne veut pas qu'il fonctionne", en général on fait au mieux en fonction de ses compétences et de ses moyens (techniques, financiers etc.)
Pour revenir sur les langages fonctionnels, le concept est aussi vieux, quasiment, que la naissance d'unix (années 70), or on est en 2005, et toujours avec des langages impératifs. Si les langages fonctionnels étaient 'La Réponse', il me semble que les choses auraient bougées depuis 30 ans. Si ce n'est pas le cas, c'est bien que la programmation impérative est parfaitement adaptée à des situations qui ne sont pas gérables avec un langages comme CAML par exemple. Et l'inverse est vraie aussi, aucun des deux n'est inutile. Les contextes d'utilisation sont différents. La grande idée serait d'arriver à fusionner les avantages des deux styles, mais est-ce possible? Comment developper un driver en CAML? Si ça devient possible, alors oui, on peut remettre les choses en question.
Tom wrote:
Le C n'est peut-être pas parfait, évidemment, mais on peut _tout_
faire avec, y compris des erreurs, mais c'est le prix à payer je pense.
Prix bien trop cher. Si on veut faire quelque chose on le fait bien ou
on ne le fait pas.
Tom
Si on veut faire qq chose, on le fait bien, je suis d'accord.
Mais je ne vois pas trop le problème: quand on commence à coder, on ne
pense pas "tiens je vais faire un programme mais je ne veut pas qu'il
fonctionne", en général on fait au mieux en fonction de ses compétences
et de ses moyens (techniques, financiers etc.)
Pour revenir sur les langages fonctionnels, le concept est aussi vieux,
quasiment, que la naissance d'unix (années 70), or on est en 2005, et
toujours avec des langages impératifs. Si les langages fonctionnels
étaient 'La Réponse', il me semble que les choses auraient bougées
depuis 30 ans. Si ce n'est pas le cas, c'est bien que la programmation
impérative est parfaitement adaptée à des situations qui ne sont pas
gérables avec un langages comme CAML par exemple. Et l'inverse est vraie
aussi, aucun des deux n'est inutile. Les contextes d'utilisation sont
différents. La grande idée serait d'arriver à fusionner les avantages
des deux styles, mais est-ce possible? Comment developper un driver en
CAML? Si ça devient possible, alors oui, on peut remettre les choses en
question.
Le C n'est peut-être pas parfait, évidemment, mais on peut _tout_ faire avec, y compris des erreurs, mais c'est le prix à payer je pense.
Prix bien trop cher. Si on veut faire quelque chose on le fait bien ou on ne le fait pas.
Tom
Si on veut faire qq chose, on le fait bien, je suis d'accord. Mais je ne vois pas trop le problème: quand on commence à coder, on ne pense pas "tiens je vais faire un programme mais je ne veut pas qu'il fonctionne", en général on fait au mieux en fonction de ses compétences et de ses moyens (techniques, financiers etc.)
Pour revenir sur les langages fonctionnels, le concept est aussi vieux, quasiment, que la naissance d'unix (années 70), or on est en 2005, et toujours avec des langages impératifs. Si les langages fonctionnels étaient 'La Réponse', il me semble que les choses auraient bougées depuis 30 ans. Si ce n'est pas le cas, c'est bien que la programmation impérative est parfaitement adaptée à des situations qui ne sont pas gérables avec un langages comme CAML par exemple. Et l'inverse est vraie aussi, aucun des deux n'est inutile. Les contextes d'utilisation sont différents. La grande idée serait d'arriver à fusionner les avantages des deux styles, mais est-ce possible? Comment developper un driver en CAML? Si ça devient possible, alors oui, on peut remettre les choses en question.
Richard Delorme
Mais pourtant il y a Ada et AdaOS ;-)
Ada est réputé pour être un langage sûr.
La sûreté d'Ada n'a pas empêché Ariane d'exploser. Un programme non testé n'est pas sûr, quelque soit le langage.
-- Richard
Mais pourtant il y a Ada et AdaOS ;-)
Ada est réputé pour être un langage sûr.
La sûreté d'Ada n'a pas empêché Ariane d'exploser. Un programme non
testé n'est pas sûr, quelque soit le langage.
La sûreté d'Ada n'a pas empêché Ariane d'exploser. Un programme non testé n'est pas sûr, quelque soit le langage.
-- Richard
d4rk
Joe Cool wrote:
On 2005-03-09, Tom wrote:
Avec le Caml on arrive déjà au marteau.
Au lieu de t'énerver, montre-nous ce que tu as réalisé avec ton "language-of-choice", comme ça on pourra comparer...
Quand on arrive à l'argument d'autorité, c'est qu'on à plus rien à dire.
Vous êtes dos au mur.
"vous êtes dos au mur"... Personne n'est accusé de quoi que ce soit ici,
que je sache.
C'est surtout qu'en disant "tout est à mettre à la poubelle" sans proposer d'alternative, ça ne fait pas avancer le débat... Caml est inadapté à la 'programmation système', le C (d'après vous) est une horreur, DONC: que peut-on proposer?
Joe Cool wrote:
On 2005-03-09, Tom <tom@tom.com> wrote:
Avec le Caml on arrive déjà au marteau.
Au lieu de t'énerver, montre-nous ce que tu as
réalisé avec ton "language-of-choice", comme ça
on pourra comparer...
Quand on arrive à l'argument d'autorité, c'est qu'on à plus rien à dire.
Vous êtes dos au mur.
"vous êtes dos au mur"... Personne n'est accusé de quoi que ce soit ici,
que je sache.
C'est surtout qu'en disant "tout est à mettre à la poubelle" sans
proposer d'alternative, ça ne fait pas avancer le débat...
Caml est inadapté à la 'programmation système', le C (d'après vous) est
une horreur, DONC: que peut-on proposer?
Au lieu de t'énerver, montre-nous ce que tu as réalisé avec ton "language-of-choice", comme ça on pourra comparer...
Quand on arrive à l'argument d'autorité, c'est qu'on à plus rien à dire.
Vous êtes dos au mur.
"vous êtes dos au mur"... Personne n'est accusé de quoi que ce soit ici,
que je sache.
C'est surtout qu'en disant "tout est à mettre à la poubelle" sans proposer d'alternative, ça ne fait pas avancer le débat... Caml est inadapté à la 'programmation système', le C (d'après vous) est une horreur, DONC: que peut-on proposer?
Richard Delorme
Benjamin FRANCOIS wrote:
Vient donc la question: dans quel langage devrait-on le récrire, à ton avis, pour que ça devienne bien foutu ?
Je propose le Cobol.
Je vote contre. Les sources du noyau Linux sont assez grosses comme ça.
-- Richard
Benjamin FRANCOIS wrote:
Vient donc la question: dans quel langage devrait-on le récrire, à ton
avis, pour que ça devienne bien foutu ?
Je propose le Cobol.
Je vote contre. Les sources du noyau Linux sont assez grosses comme ça.
